What you will be able to do
- Explain why splitting work across a supervisor and subagents creates separate contexts that can drift apart
- Trace inconsistent outputs back to how much routing context the orchestrator has: subagent descriptions and orchestrator instructions
- Tell when conflicting decisions come from state that lives in one interaction and when they come from durable knowledge that every agent is meant to share
- Use traces to separate shared-context failures from look-alike causes such as missing permissions or timeouts
Key concept
Shared-context gap — In a multi-agent system, each subagent reasons only over the context it is given. When the facts, constraints or decisions that matter to the whole task do not reach every agent that needs them, the agents act on different pictures of the same task. The result is inconsistent outputs, contradictory actions and reliability that gets worse as the task grows.
1.Why multi-agent systems lose shared context
Databricks describes agent design as a continuum. It runs from deterministic chains, through a single dynamic agent, to multi-agent systems in which several specialized agents work together. The thing that sets the multi-agent end apart is that the specialists do not share one context window. Each has its own instructions, its own tools and its own view of the conversation. That separation is the point of the design: it keeps each specialist focused. It is also where this subdomain's failures come from. Any fact that only one agent can see is a fact the others will contradict sooner or later.
In a single agent, everything the model has learned during the task sits in one transcript, so later steps naturally stay consistent with earlier ones. Once the task is split, that consistency has to be designed in. The supervisor or orchestrator decides what each subagent receives and how the results come back together. When that hand-off leaves something out, the system fails in one of three ways. Inconsistent outputs: the same question gets different answers depending on which agent handled it. Conflicting decisions: agents take actions that contradict each other. Degraded reliability: quality slips as tasks get longer or span more agents. The design-patterns guide is candid about the cost: multi-agent systems are harder to orchestrate and harder to debug than a single agent.
Checkpoint 1 of 7· Check yourself
According to the Databricks design-pattern comparison, which drawback is specifically listed for multi-agent systems?
The pattern table lists orchestration complexity and debuggability as the costs of the multi-agent pattern. That is why shared-context failures take deliberate diagnosis.
“Complex to orchestrate Harder to trace and debug”Source: docs.databricks.com
2.Inconsistent outputs: when the orchestrator lacks routing context
The first context every multi-agent system needs is the orchestrator's knowledge of what each subagent is for. In the Databricks Apps orchestrator pattern, every subagent is exposed to the orchestrator as a tool. The orchestrator picks one based on its own instructions and the subagent descriptions. If those descriptions are vague or overlap, the orchestrator cannot tell which specialist owns a question. Semantically identical requests then land on different subagents, and each one answers from different data. A Genie Agent working over structured tables and a knowledge assistant working over documents can return two different, equally confident numbers for the same metric.
The symptom is inconsistency between runs or between similar phrasings. The cause is missing routing context, not a weak model. The fix is to give the orchestrator that context: say what each subagent covers, what kind of question it handles, and what to do when it is unsure.
Agent(
name="Orchestrator",
instructions=(
"You are an orchestrator agent. Route the user's request to the "
"most appropriate tool or data source:\n"
"- Use the Genie MCP tools for questions about structured data in <dataset_name> that contains information about <topic>\n"
"- Use query_app_agent for questions or tasks that the specialist app agent handles for ...\n"
"- Use query_knowledge_assistant for knowledge-base lookups about <topic>.\n"
"If unsure, ask the user for clarification."
),Checkpoint 2 of 7· Check yourself
Users report that the same metrics question sometimes gets a Genie-based answer and sometimes a document-based answer, and the numbers differ. Which change targets the root cause most directly?
Routing inconsistency comes from the orchestrator not knowing which subagent owns a question. Specific descriptions give it that shared routing context.
“Description quality is directly related to how well the orchestrator can route requests to the correct subagent”Source: docs.databricks.com
Checkpoint 3 of 7· Exam question
Which of the following best defines the "shared context failure" category of multi-agent failure modes, as distinct from a single-agent context failure such as context poisoning or context clash?
Correct answer: A — It arises from insufficient information propagated between multiple cooperating agents, rather than from a problem within one agent's context window.
- A. Correct. This accurately defines shared context failure as a multi-agent problem where the failure stems from insufficient information being passed between agents, rather than from internal context corruption within a single agent. It highlights the key distinction from single-agent failures like context poisoning or context clash.
- B. Incorrect. Shared context failure is about gaps in information propagation, not about model compatibility. It can occur even when all cooperating agents use the same large language model and share identical internal representations, as the root cause is missing shared context, not model differences.
- C. Incorrect. Exceeding a single agent's context window leads to a local truncation issue, which is a single-agent failure mode. While it can affect multi-agent collaboration, it does not define shared context failure, which specifically refers to insufficient information exchange across agents.
- D. Incorrect. A retrieval index failure is a Domain 3 retrieval concern, where irrelevant artifacts are fetched for a single agent’s use. Shared context failure, in contrast, is about the lack of proper context sharing and coordination among multiple agents, not about one agent's retrieval mechanism.
Sources3
3.Conflicting decisions: state that never reached the other agents
Inconsistent answers are irritating. Conflicting decisions do real damage. Say one subagent decides to escalate a return to a human, and another subagent, unaware of that, triggers the return and issues a shipping label. Each agent acted reasonably on what it knew. The fault is that a decision made in one place never reached the others.
To diagnose this, ask what kind of state was missing. Databricks separates two stores, both backed by Lakebase. Session state holds the working transcript of one interaction: messages, tool calls and results. Memory holds durable facts, preferences and decisions that should still apply in later, unrelated conversations. A conflict inside a single task usually means the current interaction's state was not passed to the agent that acted. A conflict across conversations, such as one agent honoring a customer preference that another ignores, usually means a durable fact was never written to memory, or was written under a scope the other agent never reads.
| Store | Scope | Typical contents | Missing it causes |
|---|---|---|---|
| Managed agent sessions | One interaction (actor_id, optional session_id) | Conversation history: messages, tool calls, results | Agents within one task acting on different views of what has already happened |
| Managed agent memory | A subject, across conversations | Durable facts, preferences, past decisions | Agents in later conversations contradicting decisions or preferences established earlier |
Memory. The preference lived only in the first interaction's session state. It was never distilled into a durable memory entry that the other subagent recalls, so the second conversation started without it.
Checkpoint 4 of 7· Match them up
Match each symptom to the missing context most likely behind it
Tap a term, then the definition that fits it.
Sessions cover one interaction, memory covers a subject across conversations, and routing depends on the orchestrator's instructions. Each gap produces its own symptom.
“Memories are scoped to a subject, not an interaction”Source: docs.databricks.com
Checkpoint 5 of 7· Exam question
A Databricks multi-agent supervisor routes a customer's question about Q3 revenue to a Genie agent, which answers using a Delta table. Two turns later, a follow-up question is routed to a function-calling agent, which retrieves an older quarterly report via vector search and gives a different revenue figure. Neither agent was aware of what the other had already told the customer. What is the most likely root cause of the contradictory answers?
Correct answer: A — The two agents lack shared context about the prior conversation turns, so each answered independently without awareness of the other's response.
- A. Correct. The two agents lack shared context about the prior conversation turns, so each answered independently without awareness of the other's response. This isolation means neither agent uses the conversation history or other agent’s output, leading to contradictory answers. The problem is a failure to propagate shared context in a multi-agent system.
- B. Incorrect. The scenario describes contradictory answers due to missing shared awareness between agents, not a misconfigured SQL warehouse. There is no evidence that the Genie agent’s query logic or data access was at fault; the root cause is the lack of shared context.
- C. Incorrect. A stale vector index could explain an outdated report, but it does not account for why the agents were unaware of each other’s prior answers. The core issue is the absence of shared context across agents, not the freshness of retrieval data.
- D. Incorrect. The contradictory answers stem from a lack of shared context, not from Unity Catalog permission errors. There is no indication that the supervisor routed to an incorrect table; the failure is that neither agent shared its output with the other.
4.Degraded reliability: confirming the diagnosis with traces
The third failure mode is gradual. As a task runs longer or passes through more agents, accuracy drops, agents redo work they have already done, and summaries handed back up to the supervisor lose the detail that later steps needed. Databricks' own writing on agent harnesses calls this pattern out: unmanaged, growing context degrades performance on long-running tasks. In a multi-agent system, the result summary is a hand-off. Whatever the summary leaves out is gone for every agent downstream.
The symptoms in this lesson also have look-alike causes, so a diagnosis has to rest on evidence. MLflow Tracing records every intermediate step, including subagent calls, as spans. Open a failing trace and compare what each subagent actually received with what the task required. If the needed fact is absent from that span's inputs, you have a shared-context failure. Rule out the impostors as well. A supervisor returns poor subagent answers when the end user lacks explicit permission on that subagent. A long-running supervisor task can still time out inside a single slow tool call. Neither is a context problem, and fixing context will not help. Across many traces, Detect Issues clusters recurring failures and computes per-agent cost baselines. A recurring cluster tied to one hand-off points to where context is being dropped.
Checkpoint 6 of 7· Check yourself
A supervisor gives unhelpful answers whenever a particular group of users asks about one subagent's domain. Traces show the subagent was routed correctly and given full task context. What should you check next?
Routing and context are both confirmed as correct, and the failure is tied to a set of users. That points to permissions, which can look like a context failure.
“Without explicit access, the supervisor cannot return helpful responses from a subagent.”Source: docs.databricks.com
Checkpoint 7 of 7· Exam question
A support-ticket triage system routes a ticket to a billing agent, which decides the issue is technical and hands it to a technical agent, which decides it is a billing issue and sends it back. This bounce continues for many turns without resolution, consuming an increasing share of the context window. Which failure mode does this scenario best illustrate?
Correct answer: A — Sub-agents lack shared context about what has already been tried, causing tickets to bounce indefinitely and degrading system reliability.
- A. Correct. The agents lack shared context about what has been attempted, so they repeatedly hand off the ticket without recognizing the loop. This directly matches the failure mode of degraded reliability from insufficient shared context among cooperating agents.
- B. Incorrect. The scenario does not suggest the ticket was miscategorized at creation. The root cause is the lack of shared context between agents, not that routing permanently assigns it to billing.
- C. Incorrect. There is no mention of Unity Catalog or stale lineage in the scenario. The continuous bounce is a coordination failure due to absent shared context, not a malfunctioning routing function.
- D. Incorrect. The scenario does not indicate context window compaction or deletion of the original ticket text. The agents still have the ticket details but disagree on ownership because they lack a shared record of prior handoffs.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Splitting an overloaded agent into more subagents automatically makes the system more reliable.Why is that wrong?
Multi-agent designs add orchestration and debugging cost, and every hand-off is a new place for context to be lost. Splitting only helps if shared context is propagated on purpose.
Covered in Why multi-agent systems lose shared context
2.Persisting conversation history in a session store gives every agent shared knowledge of past decisions across conversations.Why is that wrong?
Sessions are scoped to one interaction. Decisions and preferences that should outlive a conversation have to be distilled into memory, which is scoped to a subject.
Covered in Conflicting decisions: state that never reached the other agents
3.Any unhelpful subagent answer relayed by a supervisor is a shared-context failure.Why is that wrong?
Missing end-user permissions on a subagent produce the same symptom. Check traces and permissions before you redesign context propagation.
Covered in Degraded reliability: confirming the diagnosis with traces
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“with distinct logic or conversation contexts”
↩︎ Why multi-agent systems lose shared context“with distinct logic or conversation contexts”
↩︎ Key concept“Complex to orchestrate Harder to trace and debug”
↩︎ Exam trap 1“Complex to orchestrate Harder to trace and debug”
↩︎ Checkpoint - 2.
“Supervisor Agent uses advanced AI orchestration patterns to manage agent interactions, task delegation, and result synthesis”
↩︎ Why multi-agent systems lose shared context“Without explicit access, the supervisor cannot return helpful responses from a subagent.”
↩︎ Exam trap 3“Without explicit access, the supervisor cannot return helpful responses from a subagent.”
↩︎ Checkpoint - 3.
“The orchestrator treats each subagent as a tool and uses its instructions to route requests to the right one.”
↩︎ Inconsistent outputs: when the orchestrator lacks routing context“The more specific the orchestrator instructions, the more accurately it routes requests.”
↩︎ Inconsistent outputs: when the orchestrator lacks routing context“Description quality is directly related to how well the orchestrator can route requests to the correct subagent”
↩︎ Checkpoint - 4.
“Sessions are scoped to one interaction”
↩︎ Conflicting decisions: state that never reached the other agents“Sessions are scoped to one interaction”
↩︎ Exam trap 2“Memories are scoped to a subject, not an interaction”
↩︎ Checkpoint - 5.
“Share accumulated knowledge across agents and projects.”
↩︎ Conflicting decisions: state that never reached the other agents - 6.
“Tracing records the inputs, outputs, latency, token usage, and cost of every intermediate step”
↩︎ Degraded reliability: confirming the diagnosis with traces - 7.https://docs.databricks.com/aws/en/mlflow3/genai/tracing/observe-with-traces/analyze-tracesOfficial docs
“computes per-agent cost baselines to flag anomalies”
↩︎ Degraded reliability: confirming the diagnosis with traces - 8.https://docs.databricks.com/aws/en/agents/agent-bricks/multi-agent-supervisor-long-running-tasksOfficial docs
“the continuation checkpoint can only be triggered between steps”
↩︎ Degraded reliability: confirming the diagnosis with traces - 9.https://www.databricks.com/blog/ai-harnessSecondary source
“Without a strategy to trim or summarize older context, performance often breaks down on long-running tasks.”
↩︎ Degraded reliability: confirming the diagnosis with traces