AI Conductor Academy

Core: 0 of 6 done

Orchestration Planning & Artifacts About 24 min ← All modules

Core · Module 3

Orchestration Planning & Artifacts

Course outcome 3Project 2: council plan

Plan how a small team of agents hands work to each other, and where the finished work is saved. You’re writing the plan here, not running it live.

Big question When is one agent enough, and when do you need a council?

By the end of this module, you’ll be able to:

  1. Specify a multi-agent handoff plan with distinct roles, a shared schema, handoff rules, and success criteria.
  2. Differentiate chat-only answers from work that’s saved outside chat in a file, doc, or schema.
  3. Critique a flawed handoff plan by spotting missing roles, schema gaps, or unclear handoffs.

How you’ll show it: the “spot the problems” practice, then Project 2, your council plan (download). Course outcome 3 of 6

What good looks like

This is the bar each part needs to reach (Meets). You’ll get feedback on each part when you check your work.

  • Roles: at least 2 roles, each with its own job (not the same job twice). A named human approver is a plus.
  • Shared schema: at least 2 named fields, each with an owner, saved somewhere outside chat, such as a named file or doc.
  • Handoff rules: when the work moves, what moves, and which of your roles receives it.
  • Success criteria: a result someone could check (a number, score, or checklist), tied to the saved file or artifact.
  • Practice: in “Spot the problems”, check every real problem and nothing that isn’t one.

How you pass: every part of your plan at Meets or better, plus the practice. Finishing M3 opens the electives.

The automatic check looks for a few signals of these. It can’t judge quality, so aim for the description, not the keywords.

Warm-up: quick recall

Two quick questions from earlier modules. Pulling ideas back from memory helps them stick. This is just for practice and isn’t scored.

One agent or a council?

Not every job needs a team. Use a council when the work has distinct jobs that benefit from different instructions, or when a human has to approve before anything ships.

One agent is enough when…A council helps when…
The task is a single job with one kind of output (e.g. summarize feedback).The work splits into different jobs (audit, rewrite, approve) that need different instructions.
No one else needs to review the result before it’s used.A person or another agent must check or sign off before it ships.
The output is used once and thrown away.The output feeds a file or doc that several people keep using.

Tip: Once there’s more than one agent, the risk is losing work between them. That’s why a council plan spells out a shared schema and handoff rules.

Practice: spot the problems needed for your download

Some of the statements below describe real problems with this plan, and some don’t. Check only the real ones.

Quick Module Review Council (a flawed plan)

PartWhat it says
RolesOnly “ReviewBot” is listed
Shared schema“Put notes somewhere in chat”, with no fields and no owner
Handoff rules“Pass it along when ready”
Success criteria“Looks good to go”
Which problems do you see?

Your project: a mini council plan

Your scenario: Three specialist agents review an enablement module. The final, aligned brief has to be saved outside chat so the SME can sign off.

Build the plan, check it, then download it. Nothing runs live.

See a strong example (for a different scenario)

Scenario: refreshing an outdated onboarding course. It’s a different job from yours, so borrow the pattern, not the words.

Roles
Content Auditor Bot: finds outdated screenshots and steps in each lesson. Update Writer Bot: drafts replacement steps. Enablement Lead (human): approves every change. Distinct jobs, plus a human approver.
Shared schema
stale_items.md (owner: Content Auditor Bot) · rewrite_drafts (owner: Update Writer Bot) · approval_status (owner: Enablement Lead) Every field has an owner and lives in a saved file.
Handoff rules
When the Content Auditor Bot finishes a lesson, it sends stale_items.md to the Update Writer Bot. Once rewrites are drafted, they go to the Enablement Lead. If an item has no evidence, the lead blocks it and returns it for rework. When, what, to whom, and a failure path.
Success criteria
Every flagged item is resolved in the stale_items.md file, with 100% approved in approval_status before the refresh ships. A measurable bar tied to the saved file.
Roles (at least 2)
Shared schema (at least 2 fields)

List the fields that live in a saved file, doc, or schema (not in chat) and who owns each one.

When does work move, what moves, and to whom? Role names count. 40+ characters.
Something checkable (a number, score, or checklist) that names the saved file or artifact. 40+ characters.

Tip: Feedback is automatic. It looks for specific details, like a number, a named owner, or a “when”. It’s a quick check, not a grade.

Download as

Next: M3.5 Evaluate →