What you will be able to do
- Explain why context pressure builds in a long-running agent task and name the two basic responses: trimming and compaction
- Identify relevance patterns where a hard-coded trimming heuristic such as a fixed recent-turn window is enough
- Recognise relevance patterns where trimming silently drops information the task still needs, so a compaction approach is required
- Use a start-simple, evidence-driven process to decide when to move from trimming to compaction
Key concept
Information relevance pattern — The way the usefulness of earlier context changes as a task goes on. It might fade with age, stay important for the whole task, or turn up again unpredictably. A trimming heuristic only works when the content it drops is content the task will never need again.
1.Why context pressure builds, and the two ways to relieve it
A long-running agent works in a loop. It reasons, calls a tool, reads the result, and reasons again. Every pass adds messages, tool calls and tool outputs to the transcript, and the model has to read that transcript on the next turn. Databricks describes this cost directly for Genie Code: each turn re-sends the whole chat's context to the model, so consumption grows with both the length of a chat and the amount of context it carries. So context pressure isn't a rare edge case. It is what happens by default to any agent that runs long enough.
That one sentence names the tools this lesson compares. Trimming (truncation) drops content outright, usually by a hard-coded rule such as "keep the last N turns" or "drop tool outputs older than X". It is cheap, deterministic and easy to reason about, but whatever it drops is gone. Compaction uses a summarization step to rewrite the older history into a shorter version, and the agent carries on from that compressed state. It costs an extra model call and adds a layer that can make mistakes, but it can keep facts from early in the task that a positional rule would throw away. The certification frames the skill as choosing between these so agents run efficiently without losing essential information. This subdomain is about how to make that choice for a particular task.
Checkpoint 1 of 6· Check yourself
Why does a long agentic chat get more expensive per turn as it grows, even when each new user message is short?
The cost comes from the context, not the new message. Every turn sends the full accumulated chat, so later turns cost more than early ones.
“Each turn re-sends the whole chat's context to the model”Source: docs.databricks.com
2.When a hard-coded trimming heuristic is enough
Trimming is enough when relevance is recency-dominant. In that pattern, what matters for the next step is almost entirely in the last few turns, and older turns are either finished or replaced by newer ones. Examples are a chat assistant answering independent questions one after another, a polling or monitoring loop where only the latest status counts, or a check that only cares about recent behaviour. In these tasks a fixed window drops nothing the agent will need again, and you get trimming's predictability and low cost with no loss of quality.
Databricks gives a concrete example of this design choice in a different setting: multi-turn LLM-as-a-judge service policies. The judge doesn't read the full conversation. It reads a bounded window of recent messages, and the guidance is to size that window to the pattern being detected. That is exactly the reasoning you apply to an agent's trimming rule. The window has to be wide enough to hold the longest-range dependency the task actually has, and no wider.
Checkpoint 2 of 6· Exam question
What is the fundamental difference between trimming and compaction as strategies for managing a long-running agent's context window?
Correct answer: A — Trimming discards older or lower-priority turns outright, while compaction summarizes them into a condensed form that is kept in context.
- A. Correct. Trimming is a hard-coded heuristic that drops turns outright (e.g., oldest-first), whereas compaction summarizes the discarded material and retains the condensed summary in context.
- B. Incorrect. This reverses the two strategies: trimming is the one that discards content outright, while compaction is the one that summarizes and retains a condensed version.
- C. Incorrect. Compaction does not discard content outright; it produces and retains a summarized version, which is the key distinction from trimming.
- D. Incorrect. Neither strategy is restricted to a single message type; both can be applied across tool outputs, user turns, and assistant turns depending on configuration.
Sources3
3.When the relevance pattern defeats trimming
Nothing. The policy documentation says plainly that multi-turn evaluation is windowed, not stateful: the evaluator can't use information that has dropped out of the request or keep a running score across requests. This is the core weakness of any trimming heuristic. Dropped content leaves no trace, so the model can't even tell that something is missing.
Long agent tasks often have relevance patterns that a positional rule can't handle. Persistent constraints: a requirement stated in the first turn ("only touch the staging schema", "the budget is capped") applies to every later step but sits in the oldest message, which is the first thing a recency window drops. Load-bearing tool results: an ID, a table name or a validated value fetched early is needed again much later. If it is trimmed, the agent re-runs the tool or guesses. Accumulated decisions: the agent ruled out an approach twenty steps ago, and dropping that reasoning invites it to try the same thing again. Dispersed relevance: the important facts are scattered through the history instead of grouped at the end. In all of these, the relevant information doesn't line up with recency, so any rule based on position, age or size will eventually discard something the task still needs. These patterns call for compaction, where a summarization step decides what to carry forward based on content, not position.
The idea of keeping what lasts and letting the rest go already shows up in Databricks' agent memory design. As a session accumulates, the agent or application distills the durable facts out of it and writes them to memory, while the session itself can later be cleared. Compaction applies the same principle inside a single task: pull out what still matters, then shrink the rest.
Checkpoint 3 of 6· Check yourself
A data-pipeline agent is told in turn 1 never to write to production tables. By turn 40, a keep-the-last-10-turns trimming rule is active. What is the main risk?
A trimmed turn is simply absent from what the model reads. A persistent constraint stated early is exactly the kind of information a recency window throws away, which is why this relevance pattern needs content-aware compaction or pinning.
“it can't use information that has dropped out of the request or maintain a running score across requests”Source: docs.databricks.com
Checkpoint 4 of 6· Exam question
A Databricks agent continuously polls a streaming pipeline's status every few seconds over a multi-hour run. Only the most recent one or two poll results are ever referenced by the agent's next action; results older than a few turns are never revisited. As context window pressure builds, which approach best fits this task's information relevance pattern?
Correct answer: A — Apply hard-coded trimming to drop the oldest poll turns, since relevance decays predictably and uniformly with recency here.
- A. Correct. When relevance decays monotonically and predictably with recency, a hard-coded trimming heuristic that drops the oldest turns is sufficient and avoids the extra cost of summarization.
- B. Incorrect. Since old poll data is never revisited by this task, summarizing it provides no benefit and only adds unnecessary latency and cost.
- C. Incorrect. Letting the context window grow unmanaged guarantees eventual failure and ignores the fact that a simple, low-cost mitigation is available.
- D. Incorrect. Restricting compaction to reasoning turns while ignoring the actual relevance pattern of the poll data does not match the described task's needs.
4.Making the call: start simple, escalate on evidence
Use the same approach Databricks recommends for agent design in general: start simple, and add complexity only when you actually need it. Deterministic designs give predictable, rule-based behaviour. More agentic designs give flexibility but cost extra complexity and latency. A trimming rule is the deterministic option. A compaction step is the more agentic one: it adds a model call, it can make mistakes of its own, and it is harder to audit.
Evaluate with evidence, not intuition. MLflow Tracing records the inputs, outputs, latency, token usage and cost of every intermediate step, so you can watch context grow across a run and find the point where a trimming rule starts dropping things. Signs that trimming isn't enough include: the agent calling a tool again for data it already fetched, asking the user again for something they already said, breaking a constraint stated early, or contradicting a decision it made before the trim point. If traces show none of these and relevance really is recency-dominant, keep the simple heuristic. If they do, the task's relevance pattern needs compaction.
Shrinking the prompt doesn't have to mean losing the record. Managed agent sessions keep the full ordered history, items are immutable after they are appended, and you can reconstruct full context, including tool calls and reasoning, later on. Whatever you trim or compact in the working context, the original transcript can still be stored for audit or to re-derive a summary.
No. Relevance here is recency-dominant and the traces show no sign of lost context. Compaction would add an extra model call, cost and a new way to fail without improving anything. Start simple and escalate only when the evidence calls for it.
Checkpoint 5 of 6· Check yourself
Which Databricks design principle best supports keeping a hard-coded trimming rule until there is evidence it is failing?
Databricks recommends starting simple because more agentic approaches add complexity and latency. Compaction is the more complex option, so it needs a demonstrated need behind it.
“When building any AI-powered application, start simple.”Source: docs.databricks.com
Checkpoint 6 of 6· Exam question
A long-running Databricks agent performs a multi-step data migration. In an early turn, the user specifies a target schema that every later transformation step must conform to. By turn 150, context pressure triggers a hard-coded trimming heuristic that drops the oldest 50 turns, including the one containing the schema definition. The agent then produces a transformation that violates the schema. What does this failure indicate about the task's information relevance pattern?
Correct answer: A — The pattern is non-monotonic: a fact stated early stays critical throughout, so recency-only trimming misses it and compaction is needed here.
- A. Correct. The schema fact remains critical long after it ages out of recency-based trimming, showing the relevance pattern is not purely recency-driven and requires compaction to preserve durable facts.
- B. Incorrect. If the pattern were purely recency-based, dropping the schema turn would not have caused a downstream failure; the observed failure demonstrates the opposite.
- C. Incorrect. This assumes all older turns are equally safe to discard, which is exactly the assumption the failure disproves for this task.
- D. Incorrect. The scenario states context pressure did trigger trimming; the failure is about what was dropped, not whether pressure existed.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Turning on Supervisor Agent long-running task mode ("long_task": true) handles context window pressure for long tasks.Why is that wrong?
Long-running task mode splits work across request/response cycles to avoid API timeouts. It is about wall-clock limits, not about shrinking or summarizing the context the model reads.
Covered in When the relevance pattern defeats trimming
2.A trimmed window still keeps an implicit memory of what was dropped, so trimming is safe for any task.Why is that wrong?
A windowed design is not stateful. Information outside the window is simply unavailable, which is why tasks with early, persistent constraints need compaction rather than a positional cut.
Covered in When the relevance pattern defeats trimming
3.The safest fix for context loss is to stop trimming and always send the whole conversation.Why is that wrong?
Sending everything has real costs and can exceed the model's context window. The guidance is to size a bounded window to the pattern you need, not to remove the bound.
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, and the two ways to relieve it“Genie Code automatically summarizes, compacts, and truncates long context, but only a new chat clears it completely.”
↩︎ Why context pressure builds, and the two ways to relieve it“The goal is to keep each chat's context relevant to the task at hand.”
↩︎ Key concept“Each turn re-sends the whole chat's context to the model”
↩︎ Checkpoint - 2.https://www.databricks.com/blog/databricks-context-engineer-associate-industrys-first-certification-reliable-ai-agent-systemsSecondary source
“Candidates must understand how to apply compaction and trimming strategies so that agents can operate efficiently without losing essential information.”
↩︎ Why context pressure builds, and the two ways to relieve it - 3.https://docs.databricks.com/aws/en/data-governance/unity-catalog/service-policies/policy-examplesOfficial docs
“Prefer a bounded numeric window large enough to capture the pattern you're checking for”
↩︎ When a hard-coded trimming heuristic is enough“it can't use information that has dropped out of the request or maintain a running score across requests”
↩︎ When the relevance pattern defeats trimming“Multi-turn evaluation is windowed, not stateful.”
↩︎ Exam trap 2“A larger window also adds token cost and latency.”
↩︎ Exam trap 3 - 4.
“As a session accumulates, an agent (or your application) distills the durable facts out of it and writes them to memory.”
↩︎ When the relevance pattern defeats trimming - 5.
“Deterministic chains offer predictable, rule-based flows for well-defined tasks.”
↩︎ Making the call: start simple, escalate on evidence“When building any AI-powered application, start simple.”
↩︎ Checkpoint - 6.
“Tracing records the inputs, outputs, latency, token usage, and cost of every intermediate step”
↩︎ Making the call: start simple, escalate on evidence - 7.
“Items are immutable after they are appended.”
↩︎ Making the call: start simple, escalate on evidence
Also cited
- https://docs.databricks.com/aws/en/agents/agent-bricks/multi-agent-supervisor-long-running-tasksOfficial docs
“which automatically breaks long tasks into multiple request/response cycles so the agent can continue working without timing out.”
↩︎ Exam trap 1