Knowledge Retrieval and Genie Configuration · Topic 1 of 4
Task Context Elements and Retrieval Timing
Databricks Context Engineer: pick the context elements a task needs and choose pre-inference retrieval or just-in-time agentic retrieval by tool call.
- 5 min
- Required context elements are the task, scope, constraints, grounding facts, tools and output format.
- Include a source only if it changes the answer; extra sources cause context confusion.
- Pre-inference retrieval loads chunks before the model call: one round, predictable cost, best for static documents.
What it is
Every agent task needs a small set of context elements: the goal, the scope, the constraints, the facts it must use and the tools it may call. If one is missing the agent guesses; if many extra ones are present the agent gets confused or distracted.
Retrieval timing decides when those facts arrive. Pre-inference retrieval loads chunks into the prompt before the model call, usually by embedding search. Just-in-time (agentic) retrieval lets the agent call a retrieval tool mid-run, such as an AI Search tool, a Genie space or a SQL query on a Delta table, only when a step needs it.
How it works
Choosing the context elements
Read the task and ask what the agent cannot do correctly without. The exam usually gives you a list of data sources and asks which ones belong in context.
| Element | Purpose | Example |
|---|---|---|
| Task and success criteria | What done looks like | "Draft a renewal quote under list price" |
| Scope | Which customer, region, period | Customer ID and current fiscal quarter |
| Constraints and policies | Hard rules the output must obey | Maximum discount of 15% without approval |
| Grounding facts | Data the answer depends on | Current contract terms and usage table |
| Tools | Actions or lookups the task needs | Pricing function, order lookup |
| Output format | How the result is consumed | JSON for a downstream system |
A source that does not change the answer does not belong. A full product catalog, last year's archived contracts and unrelated tools all add tokens and risk context confusion without helping this task.
Scope is easy to miss. An agent asked for "open incidents" with no team or time window picks its own scope, which looks like a model failure in the trace.
Pre-inference retrieval
The application embeds the user question, searches an index, and places the top chunks in the prompt before the first model call. It is one retrieval round with predictable latency and cost.
It fits when the question itself says what to look up, the knowledge base is mostly static documents, and one retrieval round is enough, such as a policy question and answer bot.
Its weakness is that it guesses up front. If the needed fact depends on an intermediate result or on fresh table rows, the pre-loaded chunks miss it.
Just-in-time agentic retrieval
The agent gets retrieval tools and decides during the run what to fetch. It can query a Delta table for today's numbers, call a Genie space for a structured answer, or search AI Search with a query it wrote after reading a prior result.
It fits multi-step tasks, data that changes often, and cases where most runs need only a small part of a large knowledge base. The trade-off is extra model turns, more latency and the risk that the agent forgets to call the tool or calls the wrong one.
Comparing the two
| Need in the scenario | Better strategy |
|---|---|
| Static FAQ, one lookup per question | Pre-inference |
| Lowest and most predictable latency | Pre-inference |
| Next lookup depends on an earlier result | Just-in-time |
| Live figures from a frequently updated Delta table | Just-in-time (SQL or Genie tool) |
| Large corpus, each run uses a small slice | Just-in-time |
| Reduce context window pressure in long sessions | Just-in-time with scoped tool results |
A small worked budget
An agent pre-loads 20 chunks of 400 tokens, 8,000 tokens per request, yet traces show most answers use one or two chunks. A retrieval tool returning 3 chunks only when needed uses about 1,200 tokens on runs that call it and none on the rest, for one extra model turn.
How the exam asks about this
- "The agent drafts quotes but sometimes exceeds the allowed discount." The missing element is the discount policy constraint, not more product data.
- "Answers about inventory are hours out of date; the index syncs nightly from the inventory table." Use just-in-time retrieval, a tool that queries the Delta table or a Genie space at run time.
- "A help bot answers single questions from a stable manual and must respond quickly." Pre-inference retrieval with a small top-k is the simplest fit.
What to remember for the exam
- Required context elements are the task, scope, constraints, grounding facts, tools and output format.
- Include a source only if it changes the answer; extra sources cause context confusion.
- Pre-inference retrieval loads chunks before the model call: one round, predictable cost, best for static documents.
- Just-in-time retrieval uses tool calls during the run: best for multi-step tasks and changing data.
- Dynamic Delta table queries and Genie tools return current rows; an index is only as fresh as its last sync.
- Mixing both is common: pre-load what every run needs, fetch the rest on demand.
Do not pick just-in-time retrieval for everything. When a single lookup answers every question and latency matters, the extra tool turns add cost and failure points with no gain.
Common mistakes
Adding every available source. More data feels safer, but unneeded tables and tools are exactly what context confusion describes. Pick the sources that change the answer for this task.
Forgetting the constraint. Many scenarios describe an output that is factually grounded but breaks a business rule. That points to a missing policy or constraint element, not a retrieval problem.
Treating an index as live data. A pre-inference search over a synced index cannot return rows written after the last sync. When the scenario stresses current values, the answer is a run-time query.
Check yourself
Which context element is missing when an agent returns the right kind of data for the wrong region and time period?
The scope, because the agent was not told which region and period the task covers, so it chose its own.
When is pre-inference retrieval the better choice?
When the question alone says what to look up, the knowledge is mostly static, and one fast, predictable retrieval round answers it.
Why does just-in-time retrieval suit a task whose second lookup depends on the first result?
Because the agent can read the first result and then call a tool with a new query, which an up-front load cannot anticipate.
Topic 1 of 4 in Knowledge Retrieval and Genie Configuration
Test yourself on Knowledge Retrieval and Genie Configuration
The full Databricks Context Engineer Associate question bank has 600 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Databricks. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.