What you will be able to do
- Explain why context pressure builds on every turn and why compaction is a reactive fallback, not a design strategy
- Identify when an agent design should cut its tool set, disconnect unused MCP servers, or replace many narrow tools with code execution
- Recognize when splitting tools across specialized agents relieves a single agent's context
- Spot standing context such as instructions, metadata and examples that should be trimmed because it loads with every message
Key concept
Per-turn context cost — An agent's model sees the whole accumulated context again on every turn, and an agentic task takes several turns. Anything you place in context, such as tool schemas, instructions or retrieved data, is paid for repeatedly. So the cheapest token is the one you never load.
1.Why context pressure builds before compaction kicks in
Databricks documents its own agentic assistant, Genie Code, in a way that shows the pressure plainly. Each turn re-sends the whole chat's context to the model, and an agentic task runs several turns to plan, act and check its work. The docs state that consumption grows with both the length of a chat and the amount of context it carries, so the twentieth message costs more than the first. The same holds for any agent you design. Everything the agent carries, whether tool definitions, instructions or the output of earlier tool calls, is re-read on every later turn.
Compaction is the harness's reactive answer. Databricks' AI harness article describes how, as conversations grow longer, the harness decides what stays active and what gets summarized. In practice that means trimming older parts of the conversation so the model is not overwhelmed. Genie Code works the same way: it automatically summarizes, compacts and truncates long context. But compaction only kicks in after the context has already filled up, and the summary can lose detail. Proactive strategies work on the inputs instead. They decide what enters the context at all, when it enters, and how large it is. This subdomain covers three of them: minimal tool sets, just-in-time retrieval and tool result scoping. This page covers the first, along with the related habit of keeping standing context lean.
Checkpoint 1 of 4· Check yourself
An agent design relies entirely on the harness's automatic summarization to handle long sessions. What is the main weakness of this approach?
Compaction is the harness trimming and summarizing context after it grows. Proactive design limits what is loaded in the first place, and that matters because the whole context is re-sent every turn.
“As conversations grow longer, the harness decides what stays active and what gets summarized, a process known as context compaction.”Source: www.databricks.com
2.Minimal tool sets
The Databricks agent system design guidance is direct about tools. Choose your tool approach during design, and give the agent only what the task requires. Every tool the agent can call has a definition, and the agent carries that definition whether or not it ever uses the tool.
Genie Code's guidance applies this to MCP: disable MCP servers you aren't using, and turn off the ones a chat doesn't need. Translated into design terms, the set of servers and tools attached to an agent should match its task, not every API the organization exposes. The design-pattern doc frames the same idea as provide only the tools and context your agent requires, rather than an unbounded set of APIs or large irrelevant context. It also notes that each additional LLM or tool call increases token usage and response time.
A second route to a small tool surface appears in the AI harness article. Developers are moving away from large collections of narrowly defined tools and instead giving agents a general-purpose ability to write and execute code, so the model builds workflows on the fly. One general capability replaces many narrow schemas. Because agent-generated code is risky, the article pairs this with a sandbox, an isolated workspace for running it. The design-pattern doc likewise points to Unity Catalog functions for sandboxed execution in production.
Checkpoint 2 of 4· Exam question
A team is building a customer-support agent that must remember details from a user's earlier conversation even after the user closes the chat and returns days later. The team wants this memory to survive process restarts and be queryable with low latency at inference time. Which tool should they use to store this cross-session agent state?
Correct answer: A — Lakebase, as a Postgres-backed state store the agent reads and writes at inference time
- A. Correct. Lakebase is a fully managed Postgres database designed to serve as a low-latency, durable state store for AI agents, exactly the persistent, cross-session memory need described.
- B. Incorrect. MLflow 3 tracing is an observability tool for logging and inspecting what an agent did; traces are not designed to be queried as a live application state store.
- C. Incorrect. MCP servers expose tools and resources to an agent, but they are not themselves a persistence layer for agent-owned conversational memory.
- D. Incorrect. Unity Catalog functions execute governed logic as agent tools; they don't provide durable, queryable storage for session state.
3.Partitioning tools across specialized agents
Sometimes the task really does need a large tool set. Then trimming is not enough, and the design-pattern doc offers a structural answer. In a multi-agent system, each agent has its own domain or task expertise, its own context, and potentially its own tool set. A coordinator or AI supervisor routes each request to the right agent. One of the listed reasons to choose this pattern is that there are too many tools to fit into one agent's schema. The doc also warns that a single agent spanning very different sub-domains, such as finance, devops and marketing, can become unwieldy or overloaded.
The split has costs. You need a routing strategy, plus extra logging, tracing and debugging across endpoints. Deciding which agent gets which data or APIs gets complicated as agents and tools multiply. The doc's guidance is to start simple and add complexity only as needed. Consider multi-agent when you have clearly distinct domains, multiple conversation contexts, or a large tool set.
Checkpoint 3 of 4· Check yourself
A single agent's tool schema has grown so large that it is impractical to keep every tool in one agent. Its tools fall cleanly into support, shopping and billing groups. Which design change targets the context problem most directly?
Splitting the tools across specialized agents means each agent carries only its own subset. Iteration limits guard against loops, not context size, and compaction trims conversation rather than shrinking the tool surface.
“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
Sources3
4.Keeping standing context lean
Tools are not the only thing loaded on every turn. Instructions, schema metadata and few-shot examples are standing context too. They load whether or not the current question needs them. Genie Code's guidance warns that because instructions load with every message, you should keep them lean. The design-pattern doc gives the quality reason: keep prompts clear and minimal to avoid contradictory instructions and distracting information, and to reduce hallucinations.
Genie Agents make the limit concrete. Text instructions and metadata are converted into tokens, and a warning appears as the agent nears its token limit. Near that limit, Genie uses context filtering to prioritize what it considers most relevant, and quality may drop if important context is filtered out. Once the limit is exceeded, no messages can be sent or received. The documented fixes are all trims made at design time, before filtering has to happen:
| Practice | What it removes |
|---|---|
| Remove unnecessary columns (views, or hiding columns) | Redundant or non-essential fields from raw tables |
| Streamline column descriptions | Descriptions that repeat what the column name already says |
| Prune example SQL queries | Overlapping or redundant examples, while keeping a diverse range |
| Simplify instructions | Unnecessary words in instructions |
Checkpoint 4 of 4· Check yourself
A Genie Agent shows a token-limit warning. Responses still generate, but quality has dropped. Which change addresses the cause rather than the symptom?
The warning means Genie is filtering context, and quality can suffer if important context is dropped. Removing unneeded columns and redundant examples shrinks the standing context so less has to be filtered.
“Remove unnecessary columns: Unnecessary columns in your tables can significantly contribute to token usage.”Source: docs.databricks.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Connected but unused MCP servers or tools are free, because they only cost tokens when called.Why is that wrong?
A connected server's tools sit in the agent's context whether or not they are called. Disconnecting servers the task doesn't need is a proactive reduction.
Covered in Minimal tool sets
2.Automatic compaction makes it unnecessary to limit what goes into context at design time.Why is that wrong?
Compaction trims and summarizes only after context has grown, and only clearing the context removes it completely. Limiting inputs up front stops the pressure from building in the first place.
Covered in Why context pressure builds before compaction kicks in
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Consumption grows with both the length of a chat and the amount of context it carries”
↩︎ Why context pressure builds before compaction kicks in“Disable MCP servers you aren't using.”
↩︎ Minimal tool sets“Because instructions load with every message, keep them lean.”
↩︎ Keeping standing context lean“Each turn re-sends the whole chat's context to the model”
↩︎ Key concept“Each connected MCP server adds its tools to what Genie Code carries in context.”
↩︎ Exam trap 1“Genie Code automatically summarizes, compacts, and truncates long context, but only a new chat clears it completely.”
↩︎ Exam trap 2“Each connected MCP server adds its tools to what Genie Code carries in context.”
↩︎ Prediction - 2.https://www.databricks.com/blog/ai-harnessSecondary source
“As conversations grow longer, the harness decides what stays active and what gets summarized, a process known as context compaction.”
↩︎ Why context pressure builds before compaction kicks in“Developers are moving away from large collections of narrowly defined tools.”
↩︎ Minimal tool sets - 3.
“Provide only the tools and context your agent requires, rather than an unbounded set of APIs or large irrelevant context.”
↩︎ Minimal tool sets“Each additional LLM or tool call increases token usage and response time.”
↩︎ Minimal tool sets“Each agent has its own domain or task expertise, context, and potentially distinct tool sets.”
↩︎ Partitioning tools across specialized agents“If you have clearly distinct domains or tasks, multiple conversation contexts, or a large tool set, then consider a multi-agent system.”
↩︎ Partitioning tools across specialized agents“Keep prompts clear and minimal to avoid contradictory instructions, distracting information and reduce hallucinations.”
↩︎ Keeping standing context lean“You have so many tools that fitting them all into one agent's schema is impractical; each agent can own a subset.”
↩︎ Checkpoint - 4.
“quality may be reduced if important context is filtered out”
↩︎ Keeping standing context lean“Remove unnecessary columns: Unnecessary columns in your tables can significantly contribute to token usage.”
↩︎ Checkpoint