What you will be able to do
- Explain why specialised sub-agents with separate contexts end up producing conflicting outputs
- Match a conflict symptom to the propagation change that prevents it: shared constraints sent down, earlier decisions passed across, or durable state shared between agents
- Reject distractor fixes that only clean up a conflict after it happens or that swap components, and pick the change that controls what context each agent receives
Key concept
Context propagation — Context propagation is the deliberate choice of which constraints, definitions, decisions and identity an orchestrator passes to each sub-agent, and which state those agents share. Every sub-agent reasons only over its own context, so two agents agree only on what was actually propagated to both of them.
1.Why sub-agents disagree in the first place
Separate contexts are the whole point of a multi-agent design. Databricks describes the multi-agent pattern as specialised agents, each with its own expertise, context and possibly its own tools. A coordinator or supervisor routes requests between them. That isolation keeps each specialist focused. It also means no agent automatically knows what another agent assumed, decided or was told.
The same isolation is why conflicts show up. On the exam they usually take one of three forms:
1. Divergent assumptions. Two agents answer the same question using different definitions, time windows or scopes, because the constraint the user stated was never passed to both. 2. Contradictory actions. A later agent acts without knowing what an earlier agent already decided. For example, one agent approves a refund while another, unaware of it, ships a replacement. 3. Mismatched subject. Agents personalise or authorise against different identities or different slices of stored state.
In every case the models are working as designed. Each produced a reasonable output from the context it was given. So the question this subdomain asks is never "which agent is wrong?" It is "what context did these agents need to share, and which propagation path was missing?"
Checkpoint 1 of 6· Exam question
A trip-planning multi-agent app has an orchestrator that routes requests to a Flights sub-agent and a Hotels sub-agent. The Flights sub-agent selects travel dates and confirms them. When the orchestrator next calls the Hotels sub-agent, it passes only the user's original request, not the Flights sub-agent's confirmed dates. The Hotels sub-agent then proposes hotel dates that don't overlap with the confirmed flights, creating a conflicting itinerary. Which context propagation change would most likely prevent this conflict?
Correct answer: A — Include the Flights sub-agent's confirmed dates in the context sent to the Hotels sub-agent
- A. Correct. Propagating the Flights sub-agent's confirmed output into the Hotels sub-agent's context lets it choose dates consistent with the already-confirmed flights, directly closing the information gap that caused the conflict.
- B. Incorrect. Bypassing the orchestrator changes the coordination architecture rather than propagating context, and introduces tighter coupling and routing complexity without guaranteeing the Hotels sub-agent sees the confirmed dates.
- C. Incorrect. A better tool description improves how the orchestrator selects which sub-agent to call, but it does not give the Hotels sub-agent visibility into the Flights sub-agent's output once it is invoked.
- D. Incorrect. A larger context window increases capacity but does not ensure the relevant flight dates are actually included in what is sent to the Hotels sub-agent.
- E. Incorrect. Human approval could catch the conflict after the fact, but it does not prevent the Hotels sub-agent from generating a conflicting proposal in the first place.
Sources1
2.Propagate shared constraints down from the orchestrator
The first propagation path runs from the orchestrator to each sub-agent. In the Databricks Apps orchestrator pattern, every sub-agent is exposed to the orchestrator as a tool. The orchestrator decides where a request goes based on its own instructions and each sub-agent's description. If those descriptions are vague, or two of them overlap, the same kind of question can be routed to different specialists on different turns. Users then get inconsistent answers to what looks like the same question. That is a context problem: the orchestrator lacks the information it needs to route consistently.
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."
),Routing is only half of it. When the orchestrator dispatches work, the request it sends is everything the sub-agent knows about the task. If the user said "fiscal year, EMEA only" three turns ago and the orchestrator forwards only "what was Q3 revenue?", each specialist will supply its own default. The preventive change is to carry the binding constraints (definitions, scope, units, time window) explicitly in every dispatch that depends on them. Restate them; don't assume the sub-agent will infer them.
Notice the template's last line: when it is unsure, the orchestrator asks the user instead of guessing. An ambiguity resolved once at the top, and then propagated, cannot turn into two different guesses lower down.
Checkpoint 2 of 6· Check yourself
Users of a Databricks Apps orchestrator report that similar questions sometimes come back from the knowledge assistant and sometimes from the Genie agent, with contradictory answers. Which change most directly prevents this?
The orchestrator chooses a sub-agent from the descriptions and instructions it is given, so ambiguous descriptions cause inconsistent routing. A comparison agent only resolves the conflict after it happens, a bigger model doesn't fix ambiguous input, and dumping the transcript adds load without telling the orchestrator which agent owns which question.
“Description quality is directly related to how well the orchestrator can route requests to the correct subagent”Source: docs.databricks.com
Sources2
3.Share decisions and state across agents
The second path runs sideways and forward in time. Contradictory actions happen when agent B acts without knowing what agent A already decided. To prevent them, the decision has to become part of B's context before B acts. You can do that by passing A's result into B's dispatch, or by putting the decision in state that both agents read.
Databricks offers two managed stores, both backed by Lakebase, and they differ in scope. A session holds the working state of one interaction: the ordered transcript of messages, tool calls and results. Persisting it lets an agent rebuild full context on a follow-up, so an earlier decision is still visible in a later turn. Memory holds durable facts, preferences and decisions about a subject. It is retrieved in later, separate conversations, and the documentation lists sharing knowledge across agents as one of its uses. Match the store to the conflict. A decision that only matters within this task belongs in session state. A fact every agent must agree on in future conversations belongs in memory.
Checkpoint 3 of 6· Match them up
Match each Databricks construct to the context it propagates
Tap a term, then the definition that fits it.
Sessions are scoped to one interaction; memory is scoped to a subject and outlives any single conversation. actor_id is the field that partitions both stores by owner.
“Memories are scoped to a subject, not an interaction”Source: docs.databricks.com
Make the returns agent's decision part of the shipping agent's context before it acts. Either the orchestrator passes the rejection into the shipping dispatch, or both agents read the decision from the same persisted session state. Adding a reviewer agent afterwards only catches the conflict; propagating the decision prevents it.
Checkpoint 4 of 6· Exam question
In a multi-agent financial assistant, a Budget sub-agent tells the user that the Q3 marketing budget was just increased from $50K to $75K. Later in the same conversation, the orchestrator routes a related question to a separate Marketing sub-agent, which still calculates its recommendation using the original $50K figure because that update was never shared with it. Which context propagation change would most likely prevent this conflict?
Correct answer: A — Propagate the updated $75K budget fact into the context available to the Marketing sub-agent
- A. Correct. Sharing the updated budget fact through the context passed to the Marketing sub-agent ensures both sub-agents operate on the same up-to-date figure, directly preventing the contradiction.
- B. Incorrect. Giving the sub-agent its own lookup tool could eventually surface the correct number, but it adds a new capability rather than propagating the fact that was already established earlier in the conversation.
- C. Incorrect. A general assumption about frequent changes does not supply the actual updated figure, so the Marketing sub-agent could still reason from stale or guessed numbers.
- D. Incorrect. Restricting which sub-agent handles budget questions changes routing behavior but does not address the Marketing sub-agent's need for the current figure when it answers related questions.
- E. Incorrect. Polling for status updates does not guarantee the specific budget fact is included in what is sent to the Marketing sub-agent.
4.Picking the change that prevents the conflict
Exam scenarios in this subdomain offer several plausible fixes, and only one of them changes what context flows. A useful procedure:
- Name the missing context. Is it a definition or constraint, an earlier agent's decision, or the subject's identity? - Name the path. Constraints go down from the orchestrator in each dispatch. Decisions go across through passed results or shared session state. Durable facts go through shared memory. Identity is set by trusted application code. - Prefer prevention to reconciliation. A judge agent, a vote or a final merge step resolves conflicts that have already happened. The objective asks what would prevent them. - Propagate the minimum. Forwarding the entire transcript to every sub-agent is not the fix. It bloats every context without guaranteeing that the critical constraint is noticed.
Identity deserves its own warning. If agents personalise against different users, or one agent reads another user's stored preferences, the fix is not a better prompt. The documentation is explicit that the owner of a memory is set in trusted application code from the verified end-user identity, and that the model must never pick it. Propagating identity deterministically means every agent in the system works against the same subject.
Finally, Supervisor Agent manages delegation and result synthesis for you. You can still shape its coordination with natural-language feedback and guidelines from subject-matter experts. That is the managed-product equivalent of tightening the orchestrator instructions shown earlier.
Checkpoint 5 of 6· Check yourself
A multi-agent support system sometimes greets a user with another customer's saved preferences. The memory tool currently lets the agent pass the actor_id it believes is correct. Which change prevents this?
Identity is context that must be propagated deterministically, not inferred by a model. Binding actor_id in trusted code ensures every agent reads and writes memory for the same subject. A prompt instruction still leaves the model choosing, and a reviewer agent only catches the mistake afterwards.
“Set the actor_id in trusted application code from the verified end-user identity.”Source: docs.databricks.com
Checkpoint 6 of 6· Exam question
A document-QA system uses a Retrieval sub-agent to fetch source passages and a separate Verifier sub-agent to check the final answer for accuracy. The orchestrator sends the Verifier sub-agent only the draft answer, not the passages the Retrieval sub-agent fetched. As a result, the Verifier approves an answer that actually contradicts one of the retrieved passages. Which context propagation change would most likely prevent this conflict?
Correct answer: A — Include the Retrieval sub-agent's passages in the context sent to the Verifier sub-agent
- A. Correct. Giving the Verifier sub-agent the same retrieved passages the answer was drafted from lets it check the answer against the actual source evidence, directly closing the gap that let the contradiction through.
- B. Incorrect. Removing the verification step eliminates the check entirely rather than fixing the missing context, and loses the intended accuracy benefit of the verifier pattern.
- C. Incorrect. Adjusting temperature changes how the Verifier generates text but does not give it access to the evidence needed to detect a factual contradiction.
- D. Incorrect. Having the Verifier redo retrieval could work but risks retrieving different passages than the ones the answer was based on, rather than propagating the specific context already used.
- E. Incorrect. A forced-disagreement rule produces arbitrary pushback unrelated to the actual evidence and does not address the missing passage context.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Inconsistent routing between sub-agents is best fixed by adding another agent to arbitrate their answers.Why is that wrong?
Routing follows the orchestrator's instructions and the sub-agent descriptions. Making them specific prevents the inconsistency; an arbiter only resolves it after both agents have answered.
Covered in Propagate shared constraints down from the orchestrator
2.Session history is the right place to keep facts that every agent must agree on in future conversations.Why is that wrong?
Sessions cover one interaction. Durable facts and decisions that must stay consistent across separate conversations belong in memory, which is scoped to a subject.
Covered in Share decisions and state across agents
3.A clearer prompt is enough to stop agents from reading or writing the wrong user's memory.Why is that wrong?
Identity has to be propagated by trusted code, not left to the model. The owner of a memory is set from the verified end-user identity.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Each agent has its own domain or task expertise, context, and potentially distinct tool sets.”
↩︎ Why sub-agents disagree in the first place“Each agent has its own domain or task expertise, context, and potentially distinct tool sets.”
↩︎ Key concept - 2.
“The orchestrator treats each subagent as a tool and uses its instructions to route requests to the right one.”
↩︎ Propagate shared constraints down from the orchestrator“The more specific the orchestrator instructions, the more accurately it routes requests.”
↩︎ Exam trap 1“Description quality is directly related to how well the orchestrator can route requests to the correct subagent”
↩︎ Checkpoint - 3.
“Reconstruct full context (including tool calls and reasoning) on a follow-up message.”
↩︎ Share decisions and state across agents - 4.
“Share accumulated knowledge across agents and projects.”
↩︎ Share decisions and state across agents“Set the actor_id in trusted application code from the verified end-user identity.”
↩︎ Picking the change that prevents the conflict“Never let the model choose whose memory to read or write.”
↩︎ Exam trap 3 - 5.
“Sessions are scoped to one interaction: the working state the agent replays to continue that interaction, such as its conversation transcript.”
↩︎ Share decisions and state across agents“Memories are scoped to a subject, not an interaction”
↩︎ Exam trap 2“Memories are scoped to a subject, not an interaction”
↩︎ Checkpoint - 6.
“Supervisor Agent uses advanced AI orchestration patterns to manage agent interactions, task delegation, and result synthesis to deliver comprehensive solutions.”
↩︎ Picking the change that prevents the conflict