Briefs and plans

Pasted inputs are the brief. The Planner turns them into a plan you can read before the Composer runs.

The 30-second version

A brief is anything you paste into a workroom — client emails, meeting notes, a transcript, a sample of past work. Each block is tagged with a kind (brief, meeting_notes, email, sample, etc.). The Planner reads the goal and inputs and produces an ordered task plan with agent assignments and rough time estimates. The Composer runs once the tasks are done.

Why this matters

Without a plan, an LLM either over-asks ("Tell me more about your tone") or under-delivers (a generic 1-page proposal). The Planner is a small, fast LLM call whose only job is to turn unstructured inputs into a structured task graph: section by section, agent by agent, dependency by dependency.

You can read the plan before composition starts, and you can replan if the structure is wrong. That's the human-in-the-loop checkpoint.

How it works

Pasting a brief

In a workroom you can paste up to 10 input blocks, totalling up to 100 KB of text. Each block has:

• Kind — the schema enum: brief, meeting_notes, slack_thread, doc, email, transcript, sample, other.
• Label — a short human description (optional).
• Content — the raw text.

Picking the right kind matters because:

• brief → treated as the primary requirement.
• sample → fed into the Composer as voice reference, not as content.
• meeting_notes / email → mined for context and constraints.

If you don't supply a goal, AtelyaOS infers a starting goal from the kinds present (e.g. paste a brief alone → "Produce a deliverable from this brief").

Note: AtelyaOS does not auto-extract structured fields like client name or deadline from the pasted text today. If a deadline matters, set it in the workroom constraints field.

What the Planner produces

The Planner returns a JSON plan validated against PlannerResponseSchema. Each task has:

• ordinal — execution order.
• title and description.
• task_type — agent_work, user_input, approval, composition, tool_call, or wait.
• assigned_role_hint and assigned_bot_id.
• depends_on_ordinals — dependency edges.
• estimated_duration_seconds.

The final task is always a composition task, which produces the deliverable.

[SCREENSHOT: planner output showing task list with dependencies]

Plans are auto-executed

When the Planner finishes, the workroom transitions from planning → executing automatically. There is no separate plan-approval gate today. If you want to review the plan before tasks run, set the workroom to paused as soon as it enters executing — or use Replan afterward to discard non-completed tasks and regenerate.

Replan

Replan calls the Planner again, fed with the original inputs plus the current state. Tasks already marked done are kept; everything else is discarded and rebuilt. Use it when the first plan misses an important section or assigns the wrong agent.

Common pitfalls

• Pasting one giant block tagged other. Split into the actual kinds. The Planner weights brief and sample differently — collapsing them makes the plan worse.
• Expecting structured extraction. Don't write "deadline: next Friday" in a brief block and expect the workroom to know. Use the constraints field for hard requirements.
• Replanning mid-execution to fix small issues. Replan throws away in-flight task work. For small tweaks, wait for the deliverable and use Request revision instead.
• Mixing voice samples with new requirements. A sample is a voice reference, not a brief. Don't write "and please use this format" inside a sample block.

What's next

• Paste a brief — the workflow walkthrough.
• Review the plan — what to do once the Planner finishes.
• Workrooms — lifecycle in more detail.