Magentic Orchestration: Planning, Verifying and Replanning with Microsoft Agent Framework

In our previous post, we made ownership visible to a human. A travel problem moved between specialist agents and paused whenever a real person needed to make a decision. Handoff worked because we could enumerate every possible route in advance, even if we couldn't predict which agent would end up owning it.

Sometimes the outcome is clear but the route cannot be drawn before the work begins. A new observation challenges the whole record. A calculation depends on that record nobody has verified. A specialist discovers that the next sensible step is not in the original plan and so on. The system does not only need to select an agent. It needs to create a plan, test whether that plan is still working and revise it when reality disagrees. That is where Magentic orchestration begins.

When the route cannot be compiled in advance

Every pattern in this series has given the system a recognisable role. Sequential orchestration knows the order. Concurrent orchestration knows what can run in parallel and where the results must meet. Group Chat knows who is in the room. Handoff knows which ownership transfers are allowed. Magentic is for the uncomfortable category where the goal is known but the path is not.

The Microsoft Agent Framework documentation describes a manager that creates a plan, selects specialist agents, tracks progress and adapts the workflow as the task unfolds. It is inspired by Magentic-One, the Microsoft Research system in which an orchestrator plans, delegates and replans to recover from errors. The interesting bit is not manager. We already had managers in Group Chat. The interesting bit is replans.

Introducing CivicWorks

For this final episode, our example is CivicWorks, a decision-support workspace for a fictional NSW local council.

Case CW-2047 · Marrin Precinct begins with a practical objective. Investigate recurring ponding, cracked and uneven footpaths and an incomplete accessible route between Marrin Library, the community centre and bus stop 214. Compare the possible next steps, keep tree and business-access constraints visible and prepare a preliminary options brief for a council officer.

You can explore and run the complete CivicWorks Magentic orchestration sample on GitHub.

Initially the route appears straightforward. It confirms the community impact, inspects the accessibility record, reads the drainage asset register. It then checks the site observation, accounts for any place constraints and lastly compare some options. Then the evidence arrives. The asset record AR-DN-44 describes a concrete piped drain on one alignment. Site observation OBS-07 describes a sandstone opening on another. The original direct-works route now rests on an assumption the evidence no longer supports. That is the moment CivicWorks becomes a Magentic problem.

The shape of the investigation

The manager keeps the objective in view, but it does not perform the specialist work. It proposes the route, delegates the right specialist to act, evaluates and decides whether the next step still makes sense.

The manager may call the same specialist more than once, reorder the remaining work or replace the plan altogether. Completion and exhaustion are both legitimate terminal states in these scenarios.

A manager, not a super-agent

It is tempting to let the manager research the case, calculate the costs, judge the evidence and write the answer. Whilst it gives us one powerful agent with several assistants waiting for instructions, it also makes failures difficult to locate.

CivicWorks keeps the boundary sharper:

The specialists have the read-only evidence tools. The manager does not. It coordinates the work using what the specialists bring back.

For instance if a cost range appears before the survey evidence exists, we know which boundary failed. If a conclusion has no source, the verifier can reject it. If the manager sends the team around the same loop, the progress ledger can say so.

Plan 01 is a hypothesis

In a deterministic workflow, the plan lives mostly in code. In Magentic orchestration, the plan is a runtime artefact because it depends on the request and what has already been learned.

CivicWorks asks the manager to begin with the expected route:

1. Confirm the service requests and access impact
2. Read the accessible-route audit
3. Read the civil asset record
4. Compare it with the current site observation
5. Check the known place constraints
6. Prepare preliminary options

Before any evidence tool runs, a council officer (in our case, it's Sarah Nguyen) reviews this plan. They can approve it, request a revision and attach constraints such as keeping evidence read-only, retain business and accessible access and never assume heritage significance.

Plan review does not mean approving every agent message. The officer shapes the route and its limits. Specialists still work within that approved route and the final outcome remains advice for an accountable person to assess.

The first plan is deliberately prevented (as an example) from anticipating the sandstone issue. If it already included every heritage and survey check, the later change would be theatre. The demo requires both AR-DN-44 and the tool-backed OBS-07 observation before the manager can say the route has been invalidated.

The evidence changes the route

Once the two records conflict, continuing directly to a works comparison would create precise-looking answers on top of an unresolved site condition which will never lead to an outcome. The manager notices that progress has stopped, the workflow performs one reset and a revised task ledger appears. Plan 02 adds the checks that the evidence needs, heritage-register verification and other necessary stuff with an independent evidence challenge.

Plan 01 assumed the drainage alignment was known and moved toward a works comparison. Plan 02 stops and asks a more basic question first: what's actually down there, and what else do we need to check before we trust any option?

Replanning here isn't a failure, it's the point of choosing this pattern. The real failure would be hiding the conflict, repeating the same research or changing direction without keeping a record of the evidence that justified the change.

The progress ledger turns activity into state

A stream of agent messages can make a demo look busy without telling us whether the investigation is advancing. The Magentic manager maintains a progress ledger for each coordination round. It records whether the request is satisfied, whether the team appears to be in a loop, whether progress is being made along with which specialist should act next and what that specialist needs to do.

Agent Framework exposes this operational state through plan-created, replanned and progress-ledger events. In .NET, CivicWorks listens for MagenticPlanCreatedEvent, MagenticReplannedEvent and MagenticProgressLedgerUpdatedEvent. Those events update the interface with the current plan, revision reason, active specialist and remaining budget. They are not a chain-of-thought feed. They are basically the application state and shows what changed, why the route changed and what the workflow is waiting for.

Now another problem is with the reset that the framework rebuilds the conversation history, but it doesn't remember the evidence that was already verified before the reset. CivicWorks solves this by saving a read-only snapshot of that evidence and handing it back to the manager after replanning. So the team can change route without losing track of why it changed.

Autonomy needs a budget

Planning can recover from a wrong route, but it can also make expensive procrastination look intelligent. A team that responds to every unknown with research more is not adapting. It is looping with better vocabulary.

CivicWorks makes its inner limits visible in the workflow builder:

Workflow workflow = new MagenticWorkflowBuilder(manager)
    .AddParticipants(participants)
    .WithName("CivicWorks Magentic Investigation")
    .WithDescription(
        "Produces an evidence-bound preliminary works options brief.")
    .RequirePlanSignoff(true)
    .WithMaxRounds(CivicWorksRunState.MaximumRounds)
    .WithMaxStalls(CivicWorksRunState.MaximumStallsBeforeReplan)
    .WithMaxResets(CivicWorksRunState.MaximumResets + 1)
    .Build();

Our current example allows twelve coordination rounds, twenty-four evidence-tool calls one completed reset and ten minutes of elapsed time. The application reports those counters beside the plan. The current framework checks the reset threshold before beginning the following round, which is why the builder receives MaximumResets + 1 while CivicWorks exposes one usable reset to the officer.

A real system would add model and tool spend, source limits, retry policy and approval requirements for any action with side effects. CivicWorks keeps every case tool read-only and stops with a bounded-incomplete result if the evidence packet cannot be verified in time. The most autonomous pattern in this series should also be the most explicit about where autonomy ends.

Finally, a long-running investigation produces a lot of words. Most of them should not reach the decision-maker.CivicWorks finishes with a structured PreliminaryWorksOptionsBrief, not a transcript:

{
  "recommendation": "C",
  "summary": "Investigate the site condition before designing works.",
  "options": [
    {
      "code": "A",
      "title": "Repair known surface defects",
      "supportStatus": "Leaves the drainage conflict unresolved"
    },
    {
      "code": "B",
      "title": "Renew route and drainage together",
      "supportStatus": "Relies on an unverified excavation assumption"
    },
    {
      "code": "C",
      "title": "Investigate first",
      "supportStatus": "Best-supported next step"
    }
  ],
  "claims": [
    {
      "claim": "The recorded drainage alignment remains unresolved.",
      "evidenceReferences": ["AR-DN-44", "OBS-07"]
    }
  ],
  "openMatters": [
    "Whether the sandstone feature has heritage significance",
    "The verified subsurface drainage alignment"
  ]
}

Every material claim must retain its evidence references. Unknowns remain unknown. Option C is a recommendation to investigate first, not permission to disturb the site or perform works.

This is where the Evidence Verifier matters. It does not join the team merely to provide another opinion. It checks that the required evidence exists, challenges the option claims and refuses to let the manager declare success before EV-REPORT-01 is complete.

What the demo makes visible

The CivicWorks interface is built around governance rather than agent animation. It shows the case objective, Plan 01, the officer checkpoint, the active specialist, evidence cards, the AR-DN-44 and OBS-07 conflict, Plan 02, the execution budget and the final brief.

Every manager and specialist turn uses the configured Microsoft Foundry model. The case tools are deterministic because the evidence needs to be safe and repeatable. All the plans, agent dialogue and final brief are not replaced with a script. Missing configuration or a failed live model call can fail if not provided correctly. You can see the manager form a plan, watch real evidence invalidate it, approve the revised route and inspect the lineage behind the final recommendation.

Mythbusting around GroupChat

Magentic is not Group Chat with a better moderator. The two patterns share a manager-led shape, so the boundary can look blurry.

If the participants need two rounds of discussion before a manager (or chair) summarises, use Group Chat. Whereas, if the process is research, calculation and verification in that order, use Sequential orchestration and write those steps down. Use Magentic when the system cannot honestly know what should happen next until it sees what just happened.

Summing it up for good

We started this series with a warning that once several agents share a goal, somebody has to decide how context moves, who acts next and what “done” means. Sequential gave us order. Concurrent gave us speed. Group Chat gave us discussion. Handoff gave us ownership. Magentic gives us planning and recovery when the route itself is uncertain.

Magentic is also the most dangerous pattern in the set. The manager can make the wrong plan, select the wrong specialist, loop without progress and spend real money producing a confident answer from weak evidence. The answer is bounded orchestration with observable plans, verifiable progress and a clear human boundary.

The engineering lesson underneath all six parts is simple. Use the least autonomous pattern that can easily solve the problem.

Until next time.