Plans

Plans is where big, multi-step work lives. When a job is too large for a single chat — “scout these URLs, summarise each, draft a post for every social network, get my approval, then schedule the approved ones” — Theodor drafts a Plan: a chain of tasks handed to the right workers, run in the right order, in the background. You approve it once; the app does the rest and reports back.

How to get here

Click 📋 Plans in the sidebar. You can also land here automatically: when Theodor finishes drafting a Plan in a chat, or when you click a finished-plan message in your Inbox, the relevant plan opens straight to its detail view.

What a Plan is

A Plan is a DAG — a set of tasks with dependencies, so a step only starts once the steps it needs are done. Each task is assigned to a worker and (usually) runs in its own chat. The background scheduler dispatches tasks as their dependencies clear, retries failures with exponential backoff, and marks the whole Plan done once every task is.

Nothing runs until you say so

Theodor proposes a Plan; he can’t start it himself. Every Plan lands in Pending approval and waits for your green light. That approval gate is the core safety promise of the screen — autonomy you opted into, not autonomy that surprised you.

Plan cards, grouped by status

Plans are sorted into groups, action-required first:

• ⏳ Pending approval — Theodor drafted these; click one to review and approve.
• ▶ Running — the scheduler is advancing these now.
• ⏸ Paused — held, awaiting a nudge.
• ✓ Done · ✗ Failed · ✕ Cancelled — the terminal states, kept for the record.

Open any card to see the full picture: a coloured status pill, a live progress bar (“4 of 7 tasks done · 57%”), the original brief, and every task with its assignee and status. A task awaiting review gets inline ✓ Approve / ↩ Rework buttons; a task with a chat gets an Open chat ↗ link so you can read exactly what the worker did.

Approve, cancel, or check in

• Pending Plans show a green ✓ Approve + start banner — and an ✕ Cancel plan button if you’d rather not.
• Running / paused Plans can be cancelled at any time (you can add a reason).
• Done / failed Plans show a final report plus a 📂 Deliverables list — the documents the workers produced, each one a click away in the Library.
• Every Plan has a 💬 Talk to Theodor about this plan button. It drops you back into the original chat if it still exists, or opens a fresh one pre-loaded so you can ask “where are we?” without hunting through days of conversations.

The template gallery

At the top sits 📚 Plan templates — a collapsed strip of starter ideas (content calendars, research sweeps, and more). Click Use this → on any template and the app opens a Theodor chat with a pre-filled brief asking him to draft a real Plan via propose_plan. You’re never handed a canned Plan that skips review — the template just saves you from a blank page; the approval gate stays exactly where it is.

Staying up to date

The screen polls every 10 seconds and also listens for live “plan changed” events, so the progress bar moves the moment a worker finishes a step — no manual refresh needed. There’s a ↻ Refresh button if you want to force it.

Let Theodor scope it

Don’t worry about designing the task graph yourself. Describe the outcome you want — including any “get my approval before X” checkpoints — and let Theodor shape the steps, pick the workers, and wire the dependencies. You review the result before anything runs.

In practice

Describe the outcome and the checkpoints; let Theodor design the graph. You don’t need to work out the task order yourself. A good brief reads like an instruction to a competent contractor: “Research these five competitors, write a one-page comparison, and show me the draft before anything is published.” The “show me before” clause becomes a real approval step in the Plan.

Two jobs where a Plan clearly beats a long chat:

• A content batch. Scout sources, summarise each, draft a post per network, hold for approval, schedule the approved ones. In chat you’d shepherd every handoff; as a Plan you approve once at the start and once at the gate.
• A recurring research sweep. The same shape each time, with the tasks fanning out to whichever workers hold the right tools, and the Reviewer checking output before it’s marked done.

Nothing starts without you. Theodor can only propose — propose_plan creates a Plan in Pending approval and cannot start it. That’s the safety property that makes it reasonable to let an orchestrator draft work in the first place.

Read the tasks before approving, not the summary. The brief tells you what Theodor understood; the task list tells you what will actually happen and who to. Mis-scoped work is far cheaper to catch here than after the scheduler has spent tokens on it.

Deliverables are the point of a finished Plan. The 📂 list on a done Plan links straight to the documents produced, so a completed Plan hands you files rather than a transcript to mine.

Templates save the blank page, not the review. Using one opens a Theodor chat with a pre-filled brief; he still drafts a real Plan and it still lands in Pending approval. You never get a canned Plan that skips the gate.

🎓 Learn it hands-on: Plans: multi-step delegation

Terms in this page

• Plan — an orchestrated, multi-step workflow: a set of tasks assigned to workers and run in order by the scheduler.
• Task — one step of a Plan, given to a worker, with its own status (todo, in progress, review, blocked, done, failed).
• DAG — directed acyclic graph. A way of wiring tasks so each one waits for the steps it depends on, with no circular loops.
• Dependency — the “this must finish before that can start” link between two tasks.
• Theodor — the built-in orchestrator (“chief-of-staff”) who drafts Plans and coordinates the workers that carry them out.
• propose_plan — the tool Theodor calls to draft a Plan. It creates the Plan in Pending approval state; it never starts it.
• Approval gate — the rule that a Plan stays paused until you approve it, so nothing autonomous runs without your consent.
• Scheduler — the background engine that dispatches ready tasks, retries failures, and finishes the Plan.
• Exponential backoff — a retry strategy that waits progressively longer between attempts, so a flaky step gets a few chances before the task is marked failed.
• Status pill — the small coloured label showing a Plan’s or task’s current state.
• Brief — the plain-language description of what the Plan should accomplish, written when it’s drafted.
• Final report — the summary a finished (or failed) Plan leaves behind, explaining the outcome.
• Deliverables — the documents workers produced while running the Plan, surfaced for one-click opening in the Library.
• Template — a pre-written starter brief you can apply to have Theodor draft a real Plan for a common job.
• Review (task status) — a task that finished its work and is waiting for you to Approve it or send it back for Rework.
• Poll — re-checking for updates on a fixed timer (here, every 10 seconds) so the screen stays current.