On July 8, 2026, Microsoft shipped orchestration 1.0 for its Agent Framework across both Python and .NET. Five patterns went stable: sequential, concurrent, group chat, handoff, and the one everyone's actually excited about, magentic.

Magentic is the least hand-wired of the bunch. You hand a manager a goal and a roster of specialists, and the manager figures out how the team should work at runtime. You don't draw the flowchart. The manager invents it, step by step, as the work unfolds.

That sounds great until you watch $40 of tokens evaporate while your "self-organizing team" argues with itself about who does what next.

Here's the thing almost nobody will get right: everyone is going to lovingly tune their specialist agents. The researcher prompt, the coder prompt, the writer prompt. And almost no one is going to touch the manager's prompt, which is the single piece that decides whether magentic converges on an answer or spins in a re-plan loop until your budget alert fires.

This post is about the manager. Specifically, the manager's ledger prompt.

The manager isn't a router. It's a bookkeeper.

Magentic inherits its brain from the Magentic-One research system. The manager runs two loops and keeps two ledgers.

The outer loop maintains the Task Ledger. This is the manager's working memory for the whole job: facts it's been given, facts it still needs to look up, facts it can derive, and a category most people miss, educated guesses. The plan lives here.

The inner loop maintains the Progress Ledger. Every single round, the manager stops and asks itself a small set of questions, forced into JSON: Is the request satisfied? Are we in a loop? Is progress being made? Who speaks next? What exactly should they do?

That inner-loop self-check is the stall detector. It's the mechanism that notices "we've asked the researcher the same thing three times and gotten nowhere" and does something about it.

How load-bearing is this bookkeeping? In the original research, stripping the ledgers out dropped correct task completion by at least 31%. The ledgers aren't polish on top of the agents. They are the coordination system. The agents are just hands.

The prompt surface you're allowed to touch

In Microsoft Agent Framework, the manager is a StandardMagenticManager, and it exposes the ledger prompts as constructor parameters. You override them directly. The important ones:

task_ledger_facts_prompt builds the fact sheet.
task_ledger_plan_prompt builds the plan.
progress_ledger_prompt produces that JSON stall-detection schema every round.
task_ledger_facts_update_prompt and task_ledger_plan_update_prompt fire on a reset, when the manager gives up on the current plan and re-plans.

Most teams never open these. They accept the defaults, point magentic at a real goal, and are surprised when it wanders. So let's write a manager prompt that actually holds the line.

The Prompt:

You are the manager of a small team of specialist agents. You do not do
the work yourself. You plan it, assign it, and track it.

GOAL:
{task}

AVAILABLE SPECIALISTS:
{team}

STEP 1 - BUILD THE FACT SHEET. Before assigning anything, list:
  GIVEN: facts stated in the goal or provided context.
  TO LOOK UP: facts a specialist must retrieve. Name the specialist.
  TO DERIVE: facts we can compute or reason out once we have inputs.
  EDUCATED GUESSES: your best prior-knowledge guesses, each labeled
    (GUESS) so a specialist can confirm or overwrite it. Never let a
    guess masquerade as a verified fact.

STEP 2 - WRITE THE PLAN as an ordered list of steps. Each step names
  exactly ONE specialist and ONE concrete instruction with a checkable
  done-condition. No step may say "figure out" or "handle" -- say what
  output proves the step is complete.

STEP 3 - EACH ROUND, before choosing the next speaker, answer in JSON:
  {
    "request_satisfied": true|false,   // is the GOAL fully met?
    "in_loop": true|false,             // are we repeating a step with
                                       // no new information?
    "progress_made": true|false,       // did the last round add a
                                       // verified fact or output?
    "next_speaker": "<specialist>",
    "instruction": "<one concrete task with a done-condition>"
  }

RULES:
- If request_satisfied is true, stop and assemble the final answer. Do
  not add "nice to have" steps.
- If in_loop is true OR progress_made is false, do NOT repeat the last
  instruction. Change the specialist, change the sub-task, or mark the
  fact as unobtainable and route around it.
- A specialist's result only counts if its final message states the
  result in plain text. If a specialist used a tool but did not report
  the outcome, treat progress_made as false and instruct it to
  summarize what it found.

Why This Works: It forces the manager to separate verified facts from guesses (so downstream agents don't build on hallucinations), and the per-round JSON check gives the framework a machine-readable signal to detect a stall instead of a vibe. The done-condition rule is what stops the manager from declaring victory early or wandering into scope creep.

Expected Output:

FACT SHEET GIVEN: Target is the ACME Q2 support-ticket export (CSV, provided). TO LOOK UP: current refund-policy window (assign: researcher). TO DERIVE: % of tickets that are refund-eligible (assign: analyst, after policy known). EDUCATED GUESSES: refund window is likely 30 days (GUESS).

PLAN 1. researcher: retrieve the current published refund window. Done when a specific number of days is stated with a source. 2. analyst: tag each ticket refund-eligible or not using that window. Done when the CSV has an added eligibility column. 3. writer: summarize eligible-ticket volume and top three refund reasons. Done when a 5-bullet summary exists.

ROUND 1 CHECK

Notice the last rule in the prompt. The planner only ever sees the chat history, not your agents' tool internals. If a specialist runs a search or a query and then returns a terse "done," the manager sees nothing and logs a false stall. Telling your specialists to summarize their tool results in their final message fixes a shocking number of phantom "no progress" loops.

The loop limits are the token-bill defense

The ledger keeps the manager honest about progress. The builder settings keep it from bankrupting you when honesty isn't enough.

MagenticBuilder(
    participants=[...],
    manager_agent=manager,
    max_round_count=10,   # hard ceiling on coordination rounds
    max_stall_count=3,    # non-progressing rounds before a reset
    max_reset_count=2,    # how many times it may re-plan before quitting
).build()

The mechanics are simple. Every round where progress_made comes back false bumps a stall counter. Cross max_stall_count and the manager throws out the current plan and re-plans from the fact sheet. max_reset_count caps how many times it's allowed to do that before it gives up and returns what it has.

Why care this much? Multi-agent systems are expensive by nature. Anthropic's own engineering research put multi-agent token usage at roughly 15x a single chat, with token consumption explaining about 80% of performance variance. And because every LLM call is stateless, agents resend the entire history each turn. By step 20 of a runaway loop, one late step can top 50K input tokens. Fifty steps of that and you're past $5 for a single task that should have finished in three rounds.

The number one documented failure mode for these systems is exactly the loop magentic is built to catch: nobody owns the task, so every agent keeps re-planning forever. The in_loop check plus the stall counter is the built-in answer. But it only works if you set the limits. The defaults above are a sane first deployment.

One honest warning, because Qurtoo doesn't do hype. Magentic gives you round, stall, and reset ceilings. It does not give you a token or dollar budget. Neither does LangGraph, CrewAI, or Google ADK as of mid-2026. None of them will stop the bill for you. Put a hard token budget at your gateway or proxy layer, because the framework won't.

Two defaults that will bite you

The Python and .NET builds ship with opposite safety postures, and this trips people up constantly.

In Python, plan review is off by default (enable_plan_review=False). The manager writes a plan and runs it, no human in the loop.

In .NET, plan review is on by default (RequirePlanSignoff=true). Same framework, and it pauses for your approval before executing.

For your first real runs, turn plan review on regardless of language. Read the plan the manager produces. It's the cheapest way to catch a manager prompt that's about to send five agents down the wrong road, and it costs you nothing but a few seconds.

When not to reach for magentic

Microsoft's own docs say the quiet part: not every problem deserves a multi-agent circus. If one agent with the right tools can reliably solve the task, start there. If you need light coordination, the Group Chat pattern is simpler. Magentic earns its cost only when the solution path is genuinely unknown in advance, when you truly can't draw the flowchart yourself.

That's the real test. If you can write the steps down, write them down and use a cheaper pattern. Save magentic for the jobs where the manager's runtime planning is the whole point, and then spend your prompt-engineering effort where it actually matters: on the manager's ledger, not just the specialists.

If your team is standing up multi-agent workflows and wants to get the orchestration layer right before the token bill teaches you the hard way, we run hands-on prompt engineering training on exactly this. Connect with Kief Studio on Discord or schedule a session.

magentic orchestration prompt

Magentic Just Hit 1.0 — And Your Whole Agent Team Lives or Dies by the Manager's Ledger Prompt