What you will be able to do
- Explain what a sub-agent actually receives when an orchestrator dispatches work to it as a tool call
- Diagnose downstream multi-agent failures whose root cause is that sub-agents got a single task message instead of the relevant agent trace
- Use MLflow traces to confirm the root cause by inspecting the inputs passed between agents
- Select the dispatch configuration that fixes the failure without expanding each sub-agent's context window
Key concept
Dispatch-time context — A sub-agent knows only what the orchestrator sends it when it is invoked. If the dispatch carries just a one-line task message, every decision, constraint and intermediate result that lives in the orchestrator's trace is invisible to the sub-agent, however large its context window is.
1.What actually crosses the dispatch boundary
On Databricks, both the Supervisor Agent and a custom orchestrator built on Databricks Apps follow the same pattern. A coordinating agent breaks a request into parts and hands each part to a specialised sub-agent. In the Apps template, each configured sub-agent becomes a tool the orchestrator can call. Treating a sub-agent as a tool is what makes the system modular, and it also decides what information reaches the sub-agent.
A tool call carries the arguments the calling model writes, and nothing more. The orchestrator's own context holds the user's original request, the clarifications that followed, the plan it reasoned out, and results from earlier sub-agents. Those stay behind unless the orchestrator puts them into the call. The design-patterns guidance describes this separation directly: in a multi-agent system, each agent keeps its own context. That separation is deliberate, because it is what lets a specialised agent stay focused. The cost is that a coordinator who dispatches nothing but the latest instruction ("compute quarterly revenue", "draft the reply", "file the ticket") sends a sub-agent into its task without anything the coordinator learned earlier.
It helps to separate two kinds of payload. A task message is the single instruction for this step. An agent trace is the record of how the work got here: the messages, tool calls, results and decisions that came before. Databricks' session documentation describes that record as an interaction's working state, an ordered transcript of messages, tool calls and results. This subdomain covers the failure that happens when sub-agents get the first payload when they needed the relevant parts of the second.
Checkpoint 1 of 6· Match them up
Match each property to the kind of component it describes in the Databricks concepts guide.
Tap a term, then the definition that fits it.
The concepts guide contrasts stateless tools with stateful agents. A sub-agent may keep its own state while it runs, but the orchestrator calls it as a tool, so its starting context is only the dispatch payload.
“Tools are generally stateless and do not maintain ongoing context beyond each invocation. Agents maintain state as they iteratively solve tasks.”Source: docs.databricks.com
Checkpoint 2 of 6· Exam question
A coordinating agent splits a competitive-analysis task into four subtopics and dispatches one sub-agent per subtopic, sending each sub-agent only a single line such as "Research subtopic X." When the sub-agents report back, three summaries repeat the same industry background facts, and two use incompatible output formats. What is the most likely root cause?
Correct answer: A — Sub-agents got bare one-line tasks instead of a shared briefing on objective and format
2.Recognising the symptoms and confirming the root cause
Dispatch failures rarely look like errors. Every sub-agent returns a fluent, confident answer, and the problems appear downstream. Common signs:
- A sub-agent redoes a decision the orchestrator already made, and gets a different answer (a different date range, metric definition or customer). - Two sub-agents working on parts of the same task make incompatible assumptions, because neither saw the constraint that tied them together. - A sub-agent asks for information the user already gave, or quietly fills the gap with a default. - The final synthesis is internally inconsistent, even though each sub-agent's output looks reasonable on its own.
In all of these, each sub-agent does its own job well with the inputs it got. That points away from the sub-agent's model, prompt or tools, and towards the inputs. Comparing final answers won't show this. You have to see what was handed across each boundary.
The final response mixes several sub-agents' outputs. Each output can be correct for the message it received and still be wrong for the task. You can only see that the sub-agent never received the decision it contradicted by inspecting the input to each dispatch step.
MLflow Tracing gives you the evidence. A trace is a tree of spans, and each span records the inputs and outputs of one operation. For a multi-agent run, the span for each sub-agent call shows exactly what the orchestrator sent. MLflow's autologging integrations for multi-agent frameworks such as AutoGen capture the messages passed between agents. To diagnose, open a failing trace, find the sub-agent span that produced the inconsistent result, and read its input. If the input is a bare instruction and the missing constraint appears only in earlier spans of the orchestrator, you have confirmed the root cause: the trace was never propagated at dispatch time.
Checkpoint 3 of 6· Check yourself
A coordinating agent dispatches three sub-agents. Each output is plausible on its own, but they contradict each other on a constraint the user set early in the conversation. What is the most direct way to confirm whether dispatch context is the root cause?
Each span records what went into one operation, so the sub-agent span shows whether the user's constraint was ever dispatched. Final-response scoring, token limits and routing descriptions don't show what crossed the boundary.
“Each span represents one operation: it records what went in, what came out, how long it took, and any metadata.”Source: docs.databricks.com
Checkpoint 4 of 6· Exam question
Continuing from the same competitive-analysis system: the team confirms the root cause is that sub-agents were dispatched bare task lines instead of self-contained instructions. They must fix this without enlarging any sub-agent's context window. Which configuration change should they make?
Correct answer: A — Have the coordinator craft each dispatch message with an objective, output format, and scope boundary
3.Selecting the fix without growing the context window
No. A bigger window only helps if the missing information was sent and then truncated. In this failure it was never sent. The sub-agent's window is mostly empty, and the constraint it needed sits in the orchestrator's context. That is why the exam frames the right answer as a change to dispatch configuration, not to sub-agent capacity.
The opposite reflex, forwarding the orchestrator's entire raw transcript to every sub-agent, is also wrong. It goes against the reason for splitting the work in the first place. Each sub-agent gets the noise of every other branch, and the context can grow too large for a single agent to keep track of. The correct configuration sits in between. At dispatch time, send the task message together with the relevant agent trace: the user's goal, the decisions and constraints already settled, and the earlier results this step depends on. That gives the sub-agent the history its task depends on while keeping the payload small.
One way to set this up on Databricks is to keep the trace in shared, durable session state instead of copying it into every call. Managed agent sessions store an interaction's ordered history and can rebuild full context, including tool calls and reasoning, on a later request. A session's actor_id can identify another agent as well as an end user. Sub-agents can read the shared record of the interaction instead of relying on a one-line instruction. They still start their own work with a focused context, and nobody has to raise a context limit.
Checkpoint 5 of 6· Check yourself
Diagnosis confirmed: sub-agents receive only individual task messages and miss decisions the orchestrator made earlier. Which change resolves the failure without expanding each sub-agent's context window?
The failure comes from what is sent, not how much fits. Propagating the relevant trace at dispatch closes the gap. A bigger window or an unfiltered dump doesn't address it, and routing descriptions only change which sub-agent is called.
“Reconstruct full context (including tool calls and reasoning) on a follow-up message.”Source: docs.databricks.com
Checkpoint 6 of 6· Exam question
A coordinating agent decomposes a codebase refactor into per-module tasks and dispatches a sub-agent to each module with a short instruction like "Refactor module A for the new interface." The sub-agents never learn what interface signature the coordinator already agreed on, so two modules end up implementing different, incompatible method signatures. What should the team conclude?
Correct answer: A — The dispatch messages omitted the shared decisions each sub-agent needed to stay consistent
Sources6
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Sub-agents are missing context, so the fix is to give each sub-agent a larger context window.Why is that wrong?
The information was never sent, so window size is irrelevant. The fix is to change what the orchestrator sends at dispatch, so the relevant trace goes with the task.
Covered in Selecting the fix without growing the context window
2.Sub-agents producing inconsistent results means routing is wrong, so improving sub-agent descriptions will fix it.Why is that wrong?
Description quality affects which sub-agent the orchestrator chooses. Here the right sub-agent was chosen but given too little information, which is a dispatch-content problem.
Covered in Recognising the symptoms and confirming the root cause
3.Propagating the agent trace means copying the orchestrator's entire raw transcript into every sub-agent call.Why is that wrong?
Dumping everything brings back the overload that multi-agent decomposition is meant to avoid. Send the trace the step depends on, or let sub-agents read it from shared session state.
Covered in Selecting the fix without growing the context window
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“The orchestrator treats each subagent as a tool and uses its instructions to route requests to the right one.”
↩︎ What actually crosses the dispatch boundary“Description quality is directly related to how well the orchestrator can route requests to the correct subagent”
↩︎ Exam trap 2 - 2.
“Each agent has its own domain or task expertise, context, and potentially distinct tool sets.”
↩︎ What actually crosses the dispatch boundary - 3.
“Most commonly this is the conversation history (the ordered transcript of messages, tool calls, and results)”
↩︎ What actually crosses the dispatch boundary - 4.
“With only an input and final response, you cannot tell which intermediate decision caused a failure.”
↩︎ Recognising the symptoms and confirming the root cause - 5.
“Messages passed between agents”
↩︎ Recognising the symptoms and confirming the root cause - 6.
“Reconstruct full context (including tool calls and reasoning) on a follow-up message.”
↩︎ Selecting the fix without growing the context window“actor_id (required): who the session belongs to, such as an end user or another agent.”
↩︎ Selecting the fix without growing the context window
Also cited
- https://docs.databricks.com/aws/en/agents/conceptsOfficial docs
“Tools are generally stateless and do not maintain ongoing context beyond each invocation.”
↩︎ Key concept“Tools are generally stateless and do not maintain ongoing context beyond each invocation.”
↩︎ Exam trap 1“Tools are generally stateless and do not maintain ongoing context beyond each invocation. Agents maintain state as they iteratively solve tasks.”
↩︎ Checkpoint - https://www.databricks.com/blog/multi-agent-supervisor-architecture-orchestrating-enterprise-ai-scaleOfficial docs
“the context grows too complex for a single agent to keep track of”
↩︎ Exam trap 3 “Each span represents one operation: it records what went in, what came out, how long it took, and any metadata.”
↩︎ Checkpoint