Running the project — how Madis delivers the Marren rollout¶
Sofia's deal is won, and Studio OS has opened a project: "Marren — Studio OS rollout." It's now Madis's job to take it from a one-line brief to a finished, paid piece of work. This chapter follows that delivery: the tasks that make it up, how the communication flows — with Sofia, with your own team, and with you — and how the project moves through its stages to done.
The theme is the same as before: Madis does the running; you make the calls that matter.
The project has a home¶
Every project gets its own page — a single place where everything about it lives:
┌─ Marren — Studio OS rollout ───────────────────────── Status: Planning ─┐
│ Client: Marren · Owner: Madis · Budget: — (to set) │
│ │
│ Plan / tasks Activity Emails · Docs │
│ ───────────── ──────── ─────────── │
│ ○ Scope the rollout Madis opened the project Sofia's thread │
│ ○ Agree kickoff & plan Kairi handed off the deal (proposal, reply) │
│ ○ … … … │
└──────────────────────────────────────────────────────────────────────────┘
You never have to assemble the story of a project from scattered emails and chat threads. The plan, the running commentary, the customer's messages, and the documents are all in one view — and so is the status, which tells you at a glance where the work stands.
The stages a project moves through¶
A project has a simple, honest lifecycle. You can always see which stage a project is in, and Studio OS moves it forward as the work does:
| Stage | What it means | Who moves it |
|---|---|---|
| Planning | Just opened. Being scoped — goals, budget, plan, first steps. | Madis, as he scopes |
| In progress | Kickoff agreed, work is actively happening. | Madis, once you approve the kickoff |
| On hold | Blocked and waiting — on the customer, on information, on a decision. | Madis, when something stalls |
| Done | Delivered and closed. | Madis, at completion |
The stage is never a mystery, and it never lies: if a project is On hold because Marren hasn't sent their data yet, that's exactly what you'll see, along with the note explaining why.
Stage 1 — Planning: Madis scopes the work¶
The first thing Madis does is turn the brief into a real plan.
What Madis is thinking: "New rollout for Marren — twelve users, starting next month, budget approved. Let me set a budget and a target date on the project so it's a real commitment, not a vague intention. Then break the work into concrete tasks. What's the first move? A kickoff: agree scope and timeline with Sofia. I'll draft that kickoff email — but I don't send anything myself; I write it and it goes to the operator to approve, like every outbound message."
Madis lays out the plan as a task list. For a Studio OS rollout, it looks like this:
- Scope & kickoff — confirm goals, users, and timeline with Sofia
- Provision Marren's Studio OS — set up their workspace and their AI team
- Connect their tools — email, calendar, and accounting integrations
- Configure & tailor — adjust the agents to how Marren actually works
- Pilot with a small group — run it live with a few users, gather feedback
- Train the team — a short onboarding for Marren's staff
- Go live — switch the whole team over
- Invoice the kickoff milestone — bill the first stage of work
Each of these is a task Madis tracks. Some he can do himself. Some need a human — a colleague of yours, or you. Some need another specialist on the AI team. Studio OS routes each one to the right place, which is the subject of the rest of this chapter.
On your screen: the project's plan fills in, its status still reads Planning, and a single card lands in your queue — Madis's kickoff email to Sofia, for you to approve. Same rhythm as always: glance, understand, decide.
Stage 2 — In progress: the work, and how it communicates¶
You approve the kickoff email, Sofia agrees, and Madis moves the project to In progress. Now the real work — and the real communication — begins. There are three directions it flows.
Talking to the customer¶
Every message to Sofia is written by Madis (he has the full project context) but sent only after you approve it — and every one goes through the same single outbox and approval step you already know from Kairi. There's no second system to learn: whether it's Kairi replying to a prospect or Madis updating a customer mid-project, it's one queue, one approval, one place where "everything we've sent" is recorded.
What Madis is thinking: "Marren's workspace is provisioned. Sofia should know we've hit the first milestone and what's next. I'll draft a short progress note for her — approve-and-send, as usual — so she's never wondering where things stand."
Talking to the rest of the AI team¶
Madis doesn't work alone. When the project needs something outside his lane, he asks the right specialist — and these internal hand-offs happen automatically, without bothering you:
- Need a market or technical question answered? Madis asks Ralf, who researches and reports back.
- Need a finance question, or an invoice raised? Madis asks Liisa.
- Is it really about an event, not delivery? That would go to Marta.
These are the same clean hand-offs you saw when Kairi passed the won deal to Madis — the baton moves with full context, and you see it on the timeline without having to intervene.
Talking to you¶
For the things only you should decide, Madis brings them to you — as an approval card or a progress report. A budget change, a scope decision, a risk worth knowing about: these surface in your queue with the reasoning attached. Madis keeps you informed without making you manage him.
Stage 3 — When a task needs a human on your team¶
Here's a common, important case. One of the tasks — "Connect Marren's accounting system" — isn't something the AI team can finish on its own. It needs a real person with hands on the tools: say Jaan, an integration specialist on your team.
Can Madis reach Jaan directly? Yes — in two ways, and you stay in control of both.
1. Madis can send Jaan a message. Just as Madis drafts emails to customers, he can draft a message to a teammate — "Jaan, we need Marren's accounting connected by Friday; here's the login process and the contact on their side." Like every outbound message, it's a draft that you approve before it goes out. So Madis absolutely can email or message your colleague — with you as the light touch that signs it off.
2. Madis can assign Jaan the task inside Studio OS. If Jaan has his own Studio OS login, Madis can hand the task to Jaan directly, so it lands in Jaan's inbox — not yours. Jaan sees exactly what's needed and why, does the work, and marks it done. Madis notices it close and carries the project forward. This keeps the work off your plate entirely: the right task goes to the right person, and you only see it if something needs your decision.
What Madis is thinking: "Connecting Marren's accounting is a hands-on job — that's Jaan's. I'll assign it to him with the context he needs and a due date, and flag the project as waiting on that step. When Jaan marks it done, I'll pick the thread back up and move on to the pilot."
On your screen: you see the task exists and that it's assigned to Jaan and in progress — but it's not asking anything of you. This is the difference between a tool that dumps everything on the owner and a system that routes work to whoever should actually do it. Studio OS gives every task an owner, human or AI, and only escalates to you the decisions that are genuinely yours.
A note on roles. People on your team can have their own Studio OS logins, and what they can see and approve depends on their role. An operator like you approves the consequential actions; a teammate like Jaan can be given tasks and can act on their own inbox. You decide who's who.
Stage 4 — On hold, and back again¶
Real projects stall sometimes. Suppose Marren is slow to send the accounting credentials Jaan needs. Rather than let the task rot silently, Madis moves the project to On hold and records why — and, if useful, drafts a gentle nudge to Sofia for you to approve. The status tells the truth: waiting on the customer. When the credentials arrive, Madis moves it back to In progress and the work resumes. You always know whether a project is moving or blocked, and never have to ask.
Stage 5 — Done, and paid¶
The pilot goes well, Marren's team is trained, and the rollout goes live. Madis walks the last tasks to completion and, at the agreed milestone, asks Liisa to raise the invoice. Liisa prepares it; posting and sending it — like every consequential action — waits for your approval. Once it's out, the invoice is delivered to Sofia through the same familiar outbox.
Madis moves the project to Done. And because Studio OS has been quietly keeping score the whole time, this shows up where it should: in Uku's picture of the company — a delivered project, a paid invoice, a happy client — and in tomorrow morning's board report.
What running a project felt like¶
Across the whole delivery, here's what you actually did: approved a handful of messages, made one or two real decisions, and signed off an invoice. Here's what happened around you: a project was scoped and planned, tasks were routed to the right people and specialists, a teammate did the hands-on work, the customer was kept informed, and the work turned into money — all of it visible, all of it explained.
That's the point of Studio OS. A project isn't a folder you have to babysit; it's a piece of work with an owner who runs it, a team that helps, and an operator — you — who steers.
The final chapter zooms out from Sofia's story to your day as the operator: how you work the approval inbox, how you stay in control, and how you bring your whole team — human and AI — into one place.