What you will be able to do
- Tell static (fixed) retrieval apart from dynamic (query-time) retrieval by asking whether developer code or the LLM decides when retrieval runs
- Weigh the predictability, latency and auditability of static retrieval against its rigidity
- Weigh the adaptability of dynamic retrieval against its tool-call risks and the guardrails it needs
- Match an agent architecture to the retrieval style it implies
Key concept
Static vs. dynamic retrieval — In static retrieval, developer code fixes what gets retrieved and when, and the same steps run on every request. In dynamic retrieval, the LLM decides at query time whether to retrieve, what to ask for, and when to stop.
1.One question separates the two: who decides?
Every agent that keeps state in Lakebase has to decide how that state gets back into the model's context. There are two broad ways to do it, and the difference has nothing to do with the database or the search algorithm. It comes down to who makes the decision.
Static (fixed) retrieval means developer code sets the retrieval step: what to fetch, with which parameters, and at what point in the flow. The Databricks design-pattern guide calls this a deterministic chain: the developer chooses which tools or models are called, in what order, and with which parameters, and "the LLM does not make decisions about which tools to call or in what order." Every request follows the same path.
Dynamic (query-time) retrieval hands that decision to the model. In a tool-calling agent, "the LLM adaptively decides which tools to use, when to make more LLM calls, and when to stop." Retrieval becomes one more tool the model can call, or skip.
Both styles show up in Lakebase-backed agents. Managed agent sessions follow the fixed style: the agent reads the session "at the start of a turn and appends to it as the interaction runs", whatever the user asked. Managed agent memory can be used either way. Application code can call its search operation directly, or you can wrap that operation as a tool so the agent decides when to recall.
Checkpoint 1 of 5· Check yourself
A RAG pipeline always pulls the top-k results for the user's message and then calls the LLM once. Which description fits it?
Different queries return different results, but the retrieval step itself is fixed by the developer. That is what makes it a deterministic chain.
“Deterministic chains augment AI models with tool calling, but the developer defines which tools or models are called, in what order, and with which parameters.”Source: docs.databricks.com
2.Static retrieval: predictable, auditable, and rigid
The standard example of fixed retrieval is a deterministic RAG chain. For every request it retrieves, then augments, then generates. The model never chooses whether to look something up. It always receives whatever the retrieval step returned.
The docs list the benefits plainly. Because nothing about the flow is left to the model, you get the "highest predictability and auditability." Because no LLM call is spent deciding what to do next, a chain has "typically lower latency (fewer LLM calls for orchestration)." And because every request takes the same path, it is "easier to test and validate." The guide recommends this pattern when consistency and auditing come first, and "when you want to minimize latency by avoiding multiple LLM calls for orchestration decisions."
The cost is rigidity. Fixed retrieval has "limited flexibility for handling diverse or unexpected requests." If one kind of query needs different context, someone has to add a branch to the code. As those branches pile up, the chain "can become complex and difficult to maintain", and new capabilities "can require significant refactoring." In the design-pattern table, deterministic chains are "inflexible" and "require code changes to adapt."
Checkpoint 2 of 5· Put it in order
Put the steps of a deterministic RAG chain in the order they run for every request.
- 1.Retrieve top-k results from a vector index for the user's request
- 2.Generate a response by sending the augmented prompt to an LLM
- 3.Augment the prompt by combining the request with the retrieved context
A deterministic chain always runs retrieve, then augment, then generate. The fixed sequence is what makes it static.
“Retrieve top-k results from a vector index to find context relevant to a user request.”Source: docs.databricks.com
Checkpoint 3 of 5· Exam question
A warehouse agent answers questions about item availability that changes every few seconds as orders are placed. The team currently fetches inventory counts from Lakebase once when the session starts and reuses that snapshot for the whole conversation, causing the agent to quote sold-out items as available. What change best fixes this?
Correct answer: A — Query Lakebase for current counts at the time of each relevant request instead of once per session
- A. Correct: inventory changes on a timescale far shorter than a session, so dynamic, query-time retrieval from Lakebase for each relevant request is needed to reflect current counts.
- B. Incorrect: a larger context window only lets more of the same stale snapshot persist; it does not refresh the underlying inventory data.
- C. Incorrect: few-shot examples shape response style and format, not the freshness of the underlying data the agent is drawing from.
- D. Incorrect: summarizing a stale snapshot more aggressively still leaves the agent working from outdated counts, just in shorter form.
Sources1
3.Dynamic retrieval: adaptive, and in need of guardrails
A single-agent system turns retrieval into a choice the model makes. The design-pattern guide gives a help desk example. For a simple returns-policy question, the agent might answer directly without calling anything. For an order-status question, it calls lookup_order(customer_id, order_id). If that call returns "invalid order number", the agent can retry or ask the user for the correct ID. That is the main benefit: "The agent can adapt to new or unexpected queries by choosing which (if any) tools to call." Questions that need no context skip the lookup, and questions that need several lookups get them.
The guide also names the price: "More agentic approaches offer greater flexibility and potential, but they come with the cost of extra complexity and potential latency." A chain always makes the same calls. An agent can make the wrong ones. "Compared to a hard-coded chain, you must guard against repeated or invalid tool calls," and because "infinite loops can occur in any tool-calling scenario," you need to set iteration limits or timeouts. Prompts matter more too: "You still need carefully designed prompts and constraints to keep the agent focused and relevant."
The guide calls the single-agent pattern "often the sweet spot for enterprise use cases": simpler to debug than multi-agent setups, while still allowing dynamic logic and limited autonomy.
Checkpoint 4 of 5· Check yourself
A team replaces a fixed retrieval step with an agent that calls a memory search tool when it judges recall is needed. Which new safeguard do the docs say they need?
Once the model controls tool calls, it can repeat them or loop. The docs prescribe iteration limits or timeouts.
“Infinite loops can occur in any tool-calling scenario, so set iteration limits or timeouts.”Source: docs.databricks.com
Sources1
4.Reading retrieval style off the architecture
Exam scenarios usually describe an architecture and ask which retrieval approach fits it. The design-pattern table maps one onto the other directly, because each pattern already settles who controls tool calls. Its overall advice: "When building any AI-powered application, start simple," and add agentic behavior only when you really need the flexibility. The guide also says "agency is a continuum", and in practice most production systems carefully limit how much autonomy the agent gets.
| Design pattern | Who decides retrieval | When to use | Main tradeoff |
|---|---|---|---|
| LLM + prompt | No retrieval; custom instructions or embedded data go in the system prompt | Generic Q&A, quick prototypes | Very simple, minimal customization |
| Deterministic chain | Developer code (static) | Well-defined tasks, static pipelines such as basic RAG, no need for on-the-fly decisions | Predictable and easy to audit, but inflexible and requires code changes to adapt |
| Single-agent system | The LLM, through tool calls (dynamic) | Moderate to complex queries in one domain that need some dynamic decisions | Flexible, but must guard against repeated or incorrect tool calls |
| Multi-agent system | Each specialized agent, with its own context and tools, routed by a supervisor | Large or cross-functional domains | Highly modular, but complex to orchestrate and harder to trace and debug |
Checkpoint 5 of 5· Match them up
Match each requirement to the design pattern the docs recommend for it.
Tap a term, then the definition that fits it.
The design-pattern guide gives each of these as a 'when to use' condition for the matching pattern.
“Certain queries or conditions can warrant tool usage such as deciding when to fetch customer data.”Source: docs.databricks.com
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Static retrieval is the slower choice because it retrieves on every request.Why is that wrong?
A deterministic chain usually has lower latency, because it spends no LLM calls deciding which tools to call.
Covered in Static retrieval: predictable, auditable, and rigid
2.Letting the agent decide when to retrieve is strictly better, because it only fetches what it needs.Why is that wrong?
Agent-controlled tool calls can repeat, be invalid, or loop, so dynamic retrieval needs iteration limits, timeouts and careful prompting that a fixed chain does not.
Covered in Dynamic retrieval: adaptive, and in need of guardrails
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“The LLM adaptively decides which tools to use, when to make more LLM calls, and when to stop.”
↩︎ One question separates the two: who decides?“Can require significant refactoring to accommodate new capabilities.”
↩︎ Static retrieval: predictable, auditable, and rigid“When you want to minimize latency by avoiding multiple LLM calls for orchestration decisions.”
↩︎ Static retrieval: predictable, auditable, and rigid“The agent can adapt to new or unexpected queries by choosing which (if any) tools to call.”
↩︎ Dynamic retrieval: adaptive, and in need of guardrails“More agentic approaches offer greater flexibility and potential, but they come with the cost of extra complexity and potential latency.”
↩︎ Dynamic retrieval: adaptive, and in need of guardrails“Agency is a continuum; the more freedom you provide models to control the behavior of the system, the more agentic the application becomes.”
↩︎ Reading retrieval style off the architecture“The LLM does not make decisions about which tools to call or in what order.”
↩︎ Key concept“Typically lower latency (fewer LLM calls for orchestration).”
↩︎ Exam trap 1“Compared to a hard-coded chain, you must guard against repeated or invalid tool calls.”
↩︎ Exam trap 2“Deterministic chains augment AI models with tool calling, but the developer defines which tools or models are called, in what order, and with which parameters.”
↩︎ Checkpoint“Retrieve top-k results from a vector index to find context relevant to a user request.”
↩︎ Checkpoint“Infinite loops can occur in any tool-calling scenario, so set iteration limits or timeouts.”
↩︎ Checkpoint“Certain queries or conditions can warrant tool usage such as deciding when to fetch customer data.”
↩︎ Checkpoint - 2.
“The agent reads it at the start of a turn and appends to it as the interaction runs.”
↩︎ One question separates the two: who decides?
Also cited
“To let an agent decide when to save and recall memory, wrap the client operations as tools”
↩︎ Prediction