Does Magentic orchestration support multi-turn conversation via AG-UI? If not, is this planned?

[Kevinjvn]

Summary

We are trying to build a multi-turn chat experience using the Magentic orchestration pattern exposed through an AG-UI endpoint. After testing and investigation, it appears that Magentic does not support multi-turn conversation in the same way that Handoff does, and we want to confirm whether this is by design or a gap.

Environment

• agent-framework-core 1.x (Python)
• agent-framework-ag-ui
• agent-framework-orchestrations
• Foundry project endpoint

What we observe

With Handoff workflow — works correctly

After each agent turn, RUN_FINISHED contains an interrupt array:

{
  "type": "RUN_FINISHED",
  "threadId": "...",
  "runId": "...",
  "interrupt": [{
    "id": "366a9397-...",
    "value": { "agent_response": { ... } }
  }]
}

The next user turn is sent as a resume payload referencing that interrupt ID, and the workflow continues correctly.

With Magentic workflow — fails on second turn

RUN_FINISHED emits no interrupt array. Sending a second user message (with a new run_id, same thread_id) immediately fails with:

RuntimeError: This Magentic workflow has already been completed.
No further messages can be processed.
Use the builder to create a new workflow instance to handle additional tasks.

Root cause hypothesis

The Handoff pattern's multi-turn support is powered by HandoffAgentUserRequest: when an agent completes its turn without requesting a handoff, the workflow pauses, emits an interrupt, and waits for the next user message. Magentic has no equivalent mechanism — it is designed around single-task completion and marks itself done after one full execution cycle.

This means:

1. The checkpoint storage passed to MagenticBuilder does not function as a conversational memory store across turns — it only serves plan review and mid-run resume (e.g. enable_plan_review=True).
2. There is no native way to continue a completed Magentic run with a new user message via AG-UI without rebuilding the workflow instance and manually injecting conversation history.

Questions for the team

1. Is multi-turn conversational chat an unsupported use case for Magentic + AG-UI? Or is there a resume/interrupt mechanism for Magentic that is not documented?
2. Does checkpoint_storage in MagenticBuilder serve any purpose beyond plan review and mid-run recovery? Does it persist agent thread history across completed runs?
3. Is support for multi-turn Magentic conversations planned? If so, is there a tracking issue or roadmap item?
4. Is the correct guidance to use Handoff for interactive multi-turn chat and reserve Magentic for single-shot complex tasks?

Why this matters

Magentic is the only orchestration pattern that handles mixed-intent questions well (e.g. "Deploy my React app to App Service — I'm getting this container startup error", which spans both Azure product knowledge and coding). Handoff's routing model forces a question into a single agent's domain, causing loops on mixed-intent input.

A pattern that can handle both multi-turn chat and mixed-intent delegation would be ideal. Right now these two requirements appear to require different patterns with no single solution.

Related

• .NET: Python: [Bug]: Multi-turn tool calls fail with both Responses API and Chat Completions API when used via agent-framework-ag-ui (Foundry project endpoint) #5941 — multi-turn tool calls fail via AG-UI (Python, Foundry endpoint)
• Python: [AG-UI] Error occurs when using with_plan_review in Magentic workflow #3331 — with_plan_review in Magentic + AG-UI errors

[moonbox3]

There are complexities around Magentic + AG-UI due to the internal state that is part of the ledger/inner-loop/outer-loop. As an aside from using it with AG-UI, once the magentic loop is done, that's why we've included the check that you saw:

RuntimeError: This Magentic workflow has already been completed.
No further messages can be processed.
Use the builder to create a new workflow instance to handle additional tasks.

Could you please help us understand the scenarios where you'd want to resume a previously completed magentic task with something new?

[Kevinjvn]

Hi Evan, thanks for the quick response and for taking the time to clarify the design.

To answer your question directly: the scenario is multi-turn chat, not resuming a completed task.

The business case

I'm building a knowledge assistant chat application where users can ask questions across two domains:

• Microsoft/Azure products and services (handled by microsoft_agent with a Microsoft Learn MCP tool)
• Coding, frameworks, SDKs, and software architecture (handled by context7_coding_agent with a Context7 MCP tool)

The application is exposed via AG-UI to a frontend. A user conversation looks like this:

User: Hello
Assistant: Hi! How can I help you today?

User: I'm getting an error during deployment look at this statcktrace [...] looks like the dockerfile is wrong but the error also states a problem with the resource in azure?
Assistant: [microsoft_agent and context7_coding_agent answers (magentic_flow plan an execution)]

User: Great your suggestion helped but now I got this error [...]
Assistant: [microsoft_agent and context7_coding_agent answers (magentic_flow plan an execution)]

Each user message is a new, independent task — I am not trying to resume a previously completed Magentic run. The conversation thread (thread_id) is the session; each question is a fresh Magentic workflow execution. The user experience is a normal chat interface.

Why Magentic seemed like the right fit

The Handoff orchestration pattern works for multi-turn via AG-UI (the HandoffAgentUserRequest interrupt/resume mechanism handles this naturally), but it struggles with mixed-intent questions — for example:

"Help me deploy my React app to Azure App Service, I'm getting this container error: LastErrorDetails: Container did not start within expected time"

This question spans both domains simultaneously. With Handoff, the routing loop causes the question to bounce between agents without ever producing a synthesized answer. Magentic handles this perfectly because the manager can coordinate both specialists and produce a single coherent response — but it can't be used in a multi-turn chat via AG-UI.

The core tension

As I understand it:

• Handoff supports multi-turn chat via AG-UI natively, but cannot handle mixed-intent questions well.
• Magentic handles mixed-intent questions perfectly, but is designed as a single-task executor and cannot support multi-turn chat via AG-UI.

Questions for the team

1. Is there a recommended pattern for exposing a Magentic workflow in a multi-turn chat context via AG-UI? For example, would workflow.as_agent() + a session be the right approach here? The docs suggest sessions give multi-turn history out of the box, but we haven't been able to confirm whether add_agent_framework_fastapi_endpoint accepts a WorkflowAgent directly.

2. Are workflows designed to be used in multi-turn conversations? wich is the right approach? right now exposing the workflow seems not be the right solution.

Any guidance on the intended architecture for this use case would be really appreciated. This seems like a common scenario — a chat assistant with multiple specialist agents and tool access — and I want to make sure I'm using the framework the way it was designed to be used.

[moonbox3]

Thanks, that distinction helps. I agree this is not really “resume a completed task”; it is a chat session where each user turn may create a new complex task.

The current Magentic workflow shape is task-oriented rather than chat-turn-oriented. A Magentic workflow instance is expected to receive one task message, run its manager/ledger loop, produce a final answer, and then be done. That is why reusing the same Magentic workflow instance for the next AG-UI turn fails.

A few clarifications:

1. workflow.as_agent() is supported by the AG-UI endpoint because it becomes a normal SupportsAgentRun. However, for Magentic specifically, as_agent() does not remove the single-task constraint. A normal chat transcript is multiple messages, and Magentic currently validates that it starts from exactly one task message.

2. Workflows can be used in multi-turn conversations, but the answer is workflow-pattern-dependent. workflow.as_agent() + AgentSession works well when the workflow’s start executor accepts conversation history. Magentic’s current contract is different: it treats the incoming message as the task to solve, and its own internal chat history is part of that task execution.

3. checkpoint_storage is not intended to be completed-chat memory. It is for workflow execution persistence: plan review, pending request_info, mid-run recovery, and resume after process restart. For chat memory across completed user turns, use an agent session/history provider or application-level memory.

For your scenario, the architecture I’d recommend today is:

• Keep AG-UI attached to an outer chat/coordinator agent that owns the conversation/session.
• On each user turn, create a fresh Magentic workflow for that turn’s task.
• Pass the latest user request plus any relevant conversation summary/context into Magentic as a single task message.
• Let Magentic coordinate the Azure and coding specialists for that task, then return the synthesized answer to the chat agent.

So the short guidance is: use Handoff when you need workflow-level interrupt/resume multi-turn behavior; use Magentic for a single complex task. For your mixed-intent chat case, Magentic can still be useful, but as a per-turn delegated task solver behind a chat/session layer, not as one long-lived Magentic workflow instance per AG-UI thread.

[Kevinjvn]

Hi Evan, thanks for answering.

The distinction between workflow execution persistence (checkpoint_storage) and chat memory across completed turns (session/history provider) was the key insight we were missing. That explains everything we were seeing.

Your recommended architecture makes complete sense:

Outer chat/coordinator agent (owns the session) → per-turn fresh Magentic workflow (solves the task) → synthesized answer back to the chat agent

A couple of follow-up questions before we implement:

1. For the outer coordinator agent exposed via AG-UI — is a plain Agent with add_agent_framework_fastapi_endpoint the right choice for the chat/session layer? Or is there a specific construct (e.g. AgentSession, a dedicated coordinator pattern) you'd recommend for owning the conversation state?

2. For invoking Magentic per turn from the coordinator — what is the recommended invocation pattern? Should the coordinator call workflow.run() directly and await the result, or is there a higher-level construct for delegating to a workflow from within an agent turn?

3. On the workflow patterns that do support multi-turn via workflow.as_agent() + AgentSession — you mentioned this works well when the workflow's start executor accepts conversation history. Which of the built-in orchestration patterns (Handoff, Group Chat, Sequential, Concurrent) fall into that category? Understanding which patterns are natively chat-compatible versus task-oriented would help us make the right architectural choices going forward.

Thanks again for taking the time to engage on this.