What you will be able to do
- Break a business request into knowledge-gathering steps, reasoning steps and action steps
- Say who fixes the tool order in each pattern: deterministic chain, single-agent system or multi-agent system
- Pick the least complex pattern that meets a requirement, and name the safeguards each pattern needs
- Explain how a supervisor coordinates specialised subagents
Key concept
Tool orchestration continuum — In a multi-stage agent, tools either gather knowledge or take actions. The main design decision is who sets the order those tools run in. In a deterministic chain the developer fixes it in code. In a single agent the LLM chooses it at runtime. In a multi-agent system a supervisor routes work between specialised agents.
1.Anatomy of a multi-stage request
Databricks describes agents as systems that combine an AI model with tools, and those tools do two jobs. Some gather knowledge: they query an order database or retrieve a policy document. Others take actions: they start a return or generate a shipping label. Multi-stage reasoning means alternating between these jobs. The LLM reasons about what it knows so far, a tool fills in what is missing, and the LLM reasons again before the next step.
The Databricks call-center example runs like this. The agent first plans: look up the recent order and check the return policy. Then it gathers knowledge: the agent queries the order database to retrieve the relevant order and references a policy document. Next it reasons over what it found, checking whether the order is inside the return window. It can also escalate to a human if the item is in a special category or outside the window. Only after that does it act: it triggers the return process and generates a shipping label. Finally it reasons once more to write the reply to the customer.
This order is what makes the answer correct. Knowledge tools run before the decision. The action tool runs only after the decision has passed. If the label were generated before the return-window check, the agent would be acting on facts it had not yet confirmed.
Checkpoint 1 of 6· Put it in order
Put the call-center agent's stages in the order Databricks describes
- 1.Plan: look up the recent order and check the return policy
- 2.Action: trigger the return process and generate a shipping label
- 3.Reason: check whether the order fits in the return window
- 4.Reason: generate the response to the customer
- 5.Find information: query the order database and reference the policy document
Knowledge gathering comes before the eligibility decision, and the action comes only after that decision. A final reasoning step then writes the reply.
“The agent checks whether that order fits in the return window.”Source: docs.databricks.com
Sources1
2.Deterministic chains: the developer fixes the order
The simplest way to order tools is to write the order down in code. In a deterministic chain the developer defines which tools or models are called, in what order, and with which parameters. Every request follows the same workflow. A deterministic RAG chain always retrieves the top-k results from a vector index, then adds that context to the prompt, then sends the augmented prompt to an LLM to generate a response.
Use a chain for well-defined tasks where consistency and auditing matter most, or where you want to avoid spending extra LLM calls on orchestration decisions so latency stays low. The cost is flexibility. A chain handles unexpected requests poorly, gets harder to maintain as branches multiply, and can need significant refactoring before it can take on new capabilities. Databricks advises starting simple and adding agentic behaviour only when you truly need it.
| Design pattern | When to use | Main drawback |
|---|---|---|
| LLM + prompt | Generic question and answer; quick prototype | Minimal customization |
| Deterministic chain | Well-defined tasks; static pipelines such as basic RAG | Inflexible; requires code changes to adapt |
| Single-agent system | Moderate to complex queries in the same domain | Less predictable; must guard against repeated or incorrect tool calls |
| Multi-agent system | Large or cross-functional domains with multiple expert agents | Complex to orchestrate; harder to trace and debug |
Checkpoint 2 of 6· Put it in order
Put the steps of a deterministic RAG chain in order
- 1.Augment a prompt by combining the user request with the retrieved context
- 2.Retrieve top-k results from a vector index
- 3.Generate a response by sending the augmented prompt to an LLM
The chain always runs retrieve, then augment, then generate. The developer fixed that order, and it is the same for every request.
“Augment a prompt by combining the user request with the retrieved context.”Source: docs.databricks.com
Checkpoint 3 of 6· Exam question
A generative AI engineer is building a tool-calling agent for a claims-processing use case. The agent has three tools: `lookup_claim_details`, `check_policy_coverage`, and `issue_payment`. Payments must never be issued for claims that fail coverage verification. How should the engineer define and order these tools for the agent's multi-stage reasoning loop?
Correct answer: A — Constrain `issue_payment` so it only runs after `check_policy_coverage` approves the claim, and write tool descriptions that lead the agent to call lookup, then coverage check, then payment in that order.
- A. Constraining the payment tool to run only after coverage approval, and describing the tools so the agent naturally sequences lookup, then verification, then action, matches Databricks guidance that consequential actions in a multi-stage reasoning loop should be gated behind the verification step they depend on. This prevents the model from reaching an irreversible action tool before the required check has succeeded.
- B. Calling the payment tool before verifying coverage defeats the purpose of the coverage check, since the payment would already be issued by the time the audit-log calls run. This ordering allows an unapproved claim to be paid, which is exactly the failure mode the design must prevent.
- C. Identical generic tool descriptions remove the signal the agent needs to reason about which tool serves which purpose, and running the payment and coverage-check tools in parallel means the payment can complete before the coverage result is even known. This creates a race condition that can pay out non-covered claims.
- D. Removing the coverage-check tool eliminates the automated gate entirely, so every claim would be paid regardless of eligibility, with correctness pushed onto a reviewer who only sees the claim after money has already moved. This does not satisfy the requirement that payments never occur for claims failing verification.
Sources1
3.Single-agent systems: the LLM chooses the order
In a single-agent system the order is no longer fixed. One LLM runs one coordinated flow of logic and adaptively decides which tools to use, when to make more LLM calls, and when to stop. It can loop, calling the LLM or tools repeatedly until it reaches its goal or meets a condition such as getting valid data or resolving an error. It then folds the tool outputs back into the conversation.
Take the help-desk example. A simple returns-policy question may be answered directly, with no tool call. An order-status question triggers lookup_order(customer_id, order_id). If that call returns an invalid order number, the agent can retry or ask the user for the right ID. The tool sequence depends on what each call returned, which a fixed chain cannot do. Databricks calls this pattern the sweet spot for many enterprise use cases: it is easier to debug than multi-agent setups and still allows dynamic logic.
Checkpoint 4 of 6· Check yourself
A team moves from a deterministic chain to a single-agent system. Which new safeguard does the Databricks guidance call for?
Once the LLM decides when to call tools and when to stop, it can loop. Iteration limits or timeouts are the guard Databricks names.
“Infinite loops can occur in any tool-calling scenario, so set iteration limits or timeouts.”Source: docs.databricks.com
Sources1
4.Multi-agent systems: a supervisor routes between specialists
A single agent can become unwieldy when one application covers very different sub-domains, such as finance, devops and marketing. A multi-agent system splits the work across specialised agents. Each has its own expertise, context and possibly its own tool set. A coordinator, or AI supervisor, sends each request to the right agent or decides when one agent should hand off to another. The supervisor can be another LLM or a rule-based router. In the Databricks example, a customer assistant's supervisor delegates to a shopping assistant and to a customer-support agent that handles returns and shipping.
Choose this pattern when you have so many tools that fitting them all into one agent's schema is impractical, so each agent can own a subset. It also fits when you want agents to critique each other, for example one agent generating an answer and another verifying it. The costs are routing logic, tracing across several endpoints, and the risk that agents pass a task back and forth indefinitely.
You supply the subagents it coordinates, such as Genie Agents, Knowledge Assistant agent endpoints, model serving endpoints and Unity Catalog functions. You also grant end users explicit access to each one. Without that access, the supervisor cannot return helpful responses from a subagent.
Checkpoint 5 of 6· Check yourself
A retailer's assistant now spans product search, returns, payments and inventory, and has far more tools than fit comfortably in one agent. What does the Databricks guidance suggest?
Too many tools for one schema is one of the stated reasons to use multiple agents. A supervisor then routes each request to the agent that owns the right tools.
“each agent can own a subset.”Source: docs.databricks.com
Checkpoint 6 of 6· Exam question
A team supports three very different request types through one chat entry point: HR policy questions, IT ticket creation, and sales forecast lookups, each needing its own distinct set of tools. Which design best fits this multi-stage reasoning scenario?
Correct answer: A — Add a coordinator agent that routes each request to a specialized subagent for HR, IT, or sales, so every subagent keeps a focused, domain-specific tool set instead of one shared list.
- A. A coordinator or supervisor pattern is the recommended approach when a system spans several distinct domains, because it lets a routing layer hand each request to the subagent whose focused tool set matches the domain, rather than forcing one model to reason over every tool at once. This keeps tool selection accurate as the number of domains grows.
- B. Giving a single agent every tool from every domain increases the chance the model selects the wrong tool, since it must distinguish among a much larger and less cohesive set of options at every reasoning step. This approach scales poorly as more domains are added, which is the exact problem the coordinator pattern is designed to avoid.
- C. Requiring the end user to manually choose among three separate chat endpoints pushes the routing decision that a coordinator would normally automate onto the user, which defeats the purpose of having one unified entry point. It also does not implement multi-stage reasoning across domains at all.
- D. A fixed chain that always executes HR, then IT, then sales tools in the same order regardless of the request's actual domain wastes tool calls on irrelevant tools for every single request. Deterministic chains work well when the same steps are always needed, which is not the case when requests belong to only one of several unrelated domains.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.In a RAG chain, the LLM decides whether to retrieve before generating.Why is that wrong?
In a deterministic chain the developer hard-codes which tools run, in what order and with which parameters. The LLM makes no tool-ordering decisions.
Covered in Deterministic chains: the developer fixes the order
2.A multi-agent supervisor is the best default for any agent that calls tools.Why is that wrong?
Databricks advises starting simple. It treats the single-agent system as a good default and keeps multi-agent designs for large or cross-functional domains.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Agents rely heavily on tools for gathering information and taking external actions.”
↩︎ Anatomy of a multi-stage request“The agent triggers the return process and generates a shipping label.”
↩︎ Anatomy of a multi-stage request“When you want to minimize latency by avoiding multiple LLM calls for orchestration decisions.”
↩︎ Deterministic chains: the developer fixes the order“The LLM adaptively decides which tools to use, when to make more LLM calls, and when to stop.”
↩︎ Single-agent systems: the LLM chooses the order“requiring human approval for risky actions”
↩︎ Single-agent systems: the LLM chooses the order“The supervisor can be another LLM or a rule-based router.”
↩︎ Multi-agent systems: a supervisor routes between specialists“Design patterns for agent systems form a continuum of complexity and autonomy, from deterministic chains, through single-agent systems that can make dynamic decisions”
↩︎ Key concept“the developer defines which tools or models are called, in what order, and with which parameters.”
↩︎ Exam trap 1“When building any AI-powered application, start simple.”
↩︎ Exam trap 2“The agent checks whether that order fits in the return window.”
↩︎ Checkpoint“The LLM does not make decisions about which tools to call or in what order.”
↩︎ Prediction“Augment a prompt by combining the user request with the retrieved context.”
↩︎ Checkpoint“Infinite loops can occur in any tool-calling scenario, so set iteration limits or timeouts.”
↩︎ Checkpoint“each agent can own a subset.”
↩︎ Checkpoint - 2.
“When creating a supervisor, you must provide subagents for it to coordinate and grant end users explicit access to each one.”
↩︎ Multi-agent systems: a supervisor routes between specialists“Without explicit access, the supervisor cannot return helpful responses from a subagent.”
↩︎ Multi-agent systems: a supervisor routes between specialists