What you will be able to do
- Follow the documented order: find the cause before changing limits or configuration
- Pick the one targeted change that fits the element that is overconsuming context
- Decide when to prune a single agent and when splitting into specialized agents is justified, including what the split costs
1.Find the cause, then apply the one fix that matches it
Once you know which element is too large, the exam asks for the change most likely to improve focus. A common wrong answer applies every good practice at once, or changes a global setting without looking at what went wrong. Databricks' Genie consumption guide sets out a stricter discipline. Totals tell you when consumption rose and who drove it. They do not tell you why. Find the cause before you change limits, then give the affected user the single practice that addresses it.
Checkpoint 1 of 4· Put it in order
Put the documented steps for investigating an unexpected rise in Genie consumption in order.
- 1.Limit spend if a user or group still consistently exceeds what was approved
- 2.Find where consumption is concentrated (which workspaces, users, and dates)
- 3.Find out why by looking at what those users actually did and matching it to the common drivers
- 4.Fix the specific cause with the one practice that addresses it
The guide puts diagnosis before any change. Spending limits come last, and only if the targeted fix doesn't keep usage within what was approved.
“Find the cause before you change limits”Source: docs.databricks.com
The "why" step is the same skill this objective tests: compare the observed behaviour with known drivers such as marathon chats, circling without convergence, and overly broad exploration. Each driver has its own fix. Giving someone the whole list hides the change that actually matters.
Checkpoint 2 of 4· Check yourself
An investigation shows one user's spike comes from a single chat that covered five unrelated tasks. What should the admin do first?
The cause is a marathon chat, and the matching fix is a new chat per task. Budget changes come after the targeted fix, and the full list hides the one change that matters.
“Give the affected user the one practice that addresses what you found, rather than the whole list”Source: docs.databricks.com
Sources1
2.Matching each overconsuming element to its change
The documentation gives a specific fix for each element. Most of them remove or narrow something. Few of them add anything. The table pairs each element with its documented change.
| Element taking too much context | Change most likely to restore focus |
|---|---|
| Unused tool definitions from connected MCP servers | Disable MCP servers the chat doesn't need |
| Unnecessary table columns | Create views that exclude non-essential fields, or hide unneeded columns |
| Redundant column descriptions | Remove descriptions that repeat the column name |
| Overlapping or long example SQL | Remove redundant examples and shorten the rest; use trusted assets or views for complex queries |
| Irrelevant tables or instructions | Remove them to focus the agent |
| History from unrelated earlier tasks | Start a new chat for each task |
| Broad exploration of many assets | Reference the specific asset with @ and write a more precise prompt |
| Context restated in every prompt | Stop repeating schema or earlier results the agent can already see |
Several of these changes work by making the request more precise, so the agent has less to search through to work out what you mean. Vague prompts lead to broad exploration and extra rounds of follow-up. Pointing at an asset with @ replaces a search. A short example of the output you want carries the intent in fewer tokens than a long description. For a task the team repeats with the same shape, the guide suggests capturing it once in a skill so the agent doesn't re-plan it every run. If an agent starts circling, the guidance is to stop it early and add clarification rather than let it keep piling up context.
Checkpoint 3 of 4· Match them up
Match each observed symptom to the change the documentation pairs with it.
Tap a term, then the definition that fits it.
Each fix targets its specific driver: narrowing what gets explored, removing unneeded metadata, reusing a recorded procedure, and resolving ambiguity early.
“Broad exploration or heavy asset reads: reference assets with @ and write more precise prompts.”Source: docs.databricks.com
Retrieval has its own levers. The RAG quality guidance names settings on the chain side, such as transforming the user's query, the number of chunks retrieved, and re-ranking, along with data-pipeline choices like chunking. If a scenario shows retrieved passages crowding out the question, these settings decide how much content reaches the model.
3.When pruning is not enough: give each agent its own context
Sometimes nothing in the configuration is redundant. The agent simply has too many legitimate jobs. The agent design patterns documentation warns that a single agent covering very different sub-domains can become overloaded, and that you still need carefully designed prompts and constraints to keep it focused. When even well-pruned tools, instructions, and domain prompts can't fit together sensibly, the documented next step is a multi-agent system. In that design each specialized agent holds only its own domain's context and tools, and a supervisor routes requests to the right agent.
Checkpoint 4 of 4· Check yourself
A single agent serves finance, DevOps, and marketing users. Its tool list is already de-duplicated, but the combined schema is still too large to manage well. Which change does the design patterns guidance point to?
Very different sub-domains and a tool set too large for one schema are both listed reasons to use a multi-agent system. Each agent then holds only the context its domain needs.
“You have so many tools that fitting them all into one agent's schema is impractical; each agent can own a subset.”Source: docs.databricks.com
Splitting the agent is the most expensive change on this page, so the exam will expect you to know what it costs. The documentation lists routing strategy, extra logging, tracing, and debugging across several endpoints, the work of deciding which agent can access which data or APIs, and the risk that agents pass a task back and forth without resolving it. For an exam question, that sets the order of preference. If the excess is redundancy or unused content, prune it in place. Choose a split only when the scenario describes truly distinct domains or a tool set that one agent cannot reasonably hold.
No. The excess comes from redundancy within one domain (unused columns and overlapping examples), not from separate domains. Hiding the columns or using views and removing overlapping examples fixes the cause directly, without the routing and debugging overhead of a multi-agent system.
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.When consumption or quality worsens, the first step is to change limits or apply every best practice at once.Why is that wrong?
The documented order is to find the cause first, then apply the one practice that addresses it. Spending limits come last.
Covered in Find the cause, then apply the one fix that matches it
2.Restating the schema and earlier results in every prompt helps the agent stay focused.Why is that wrong?
The agent can already see the schema and the current chat, so repeating them adds tokens without adding information.
Covered in Matching each overconsuming element to its change
3.Splitting into multiple agents is a free way to reduce each agent's context.Why is that wrong?
Multi-agent systems add routing, logging, tracing, and debugging overhead, so they are justified for distinct domains or tool sets that can't fit in one agent, not for redundancy that pruning would fix.
Covered in When pruning is not enough: give each agent its own context
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Find the cause before you change limits”
↩︎ Find the cause, then apply the one fix that matches it“Give the affected user the one practice that addresses what you found, rather than the whole list”
↩︎ Find the cause, then apply the one fix that matches it“Vague prompts trigger broad exploration and follow-up rounds”
↩︎ Matching each overconsuming element to its change“conveys intent in fewer tokens than a long description.”
↩︎ Matching each overconsuming element to its change“capture the work once in a skill instead of reasoning it out from scratch every time.”
↩︎ Matching each overconsuming element to its change“Find the cause before you change limits”
↩︎ Exam trap 1“Don't repeat context Genie Code already has.”
↩︎ Exam trap 2“restating table names or earlier results in each prompt adds tokens without adding information.”
↩︎ Prediction“Broad exploration or heavy asset reads: reference assets with @ and write more precise prompts.”
↩︎ Checkpoint - 2.
“create views to exclude redundant or non-essential fields from your raw tables.”
↩︎ Matching each overconsuming element to its change“Use trusted assets or views to encapsulate complex queries.”
↩︎ Matching each overconsuming element to its change - 3.
“(for example, user query transformation, number of chunks retrieved, re-ranking)”
↩︎ Matching each overconsuming element to its change - 4.
“If your application spans radically different sub-domains (finance, devops, marketing, etc.), a single agent can become unwieldy or overloaded with functionality requirements.”
↩︎ When pruning is not enough: give each agent its own context“Each agent has its own domain or task expertise, context, and potentially distinct tool sets.”
↩︎ When pruning is not enough: give each agent its own context“Agents can bounce tasks indefinitely among themselves without resolution if not carefully constrained.”
↩︎ When pruning is not enough: give each agent its own context“Requires a strategy for routing between agents, plus overhead for logging, tracing, and debugging across multiple endpoints.”
↩︎ Exam trap 3“You have so many tools that fitting them all into one agent's schema is impractical; each agent can own a subset.”
↩︎ Checkpoint