Context Compression and Compaction · Topic 1 of 2
What Compaction Must Keep and What It Can Drop
Context Engineer exam: which information a compaction summary must keep, what is safe to drop from a trace, and how to fix a prompt that lost decisions.
- 6 min
- Includes a diagram
- Compaction keeps only what the prompt asks for; everything else is gone for the rest of the run.
- Decisions, constraints, rejected options, open tasks, identifiers and unresolved errors are high value and low token cost.
- Map the downstream symptom to the lost category, then add only that category to the prompt.
What it is
Compaction summarizes an agent's history with a model call and lets the agent continue from that summary plus the most recent items. It frees room in the context window, but everything not written into the summary is gone for the rest of the run.
The exam tests two sides of this: spotting which category a bad compaction discarded, and spotting which content in a trace can be removed without hurting later steps.
How it works
The categories a summary must keep
A summary of "key facts and findings" usually drops the parts that steer future actions. These categories are small in tokens and expensive to lose.
| Category | Example | Symptom when it is lost |
|---|---|---|
| Decisions and their reasons | "Use the EU policy set, because the client is in Germany" | The agent reverses or contradicts an earlier decision |
| User constraints, exclusions and preferences | "Exclude vendors under review", "answer in a table" | Output breaks a rule the user stated earlier |
| Rejected options with reasons | "Join on order_id failed, keys are not unique" | The agent retries an approach that already failed |
| Open tasks and the current plan | "Steps 1 to 3 done, step 4 pending" | Work is repeated or skipped |
| Exact identifiers later steps use | Table names, record IDs, file paths, thresholds | Wrong table queried, wrong value used |
| Unresolved errors | "Permission denied on sales.raw" | The agent assumes a failed step succeeded |
The fix for a lost category is to name that category in the compaction prompt as a short structured list. A deduplicated list of constraints or decisions costs a few hundred tokens, while the alternatives that also "keep it" cost far more.
Diagnosing the lost category from the symptom
Read the downstream failure and map it back to the table. Contradicting decisions points to lost decisions or constraints, repeated failed attempts points to lost rejected options, and wrong IDs point to lost identifiers.
Then pick the prompt revision that adds exactly that category. Revisions that add every user message word for word, every tool output, or the agent's full reasoning from each step also contain the missing information, but they rebuild most of the history you compacted away.
A worked number: a history of 90,000 tokens compacts to a 2,500 token findings summary. Adding a deduplicated list of 12 constraints and decisions adds roughly 400 tokens. Appending all tool outputs instead could add tens of thousands of tokens and defeat the purpose.
Content that is safe to remove
Content is safe to remove when no later step needs it, or when the agent can fetch it again on demand. In a typical Databricks agent trace, inspected with MLflow 3 tracing, these usually qualify:
| Usually safe to drop | Why |
|---|---|
| Raw tool results already consumed | The finding they produced is kept; the payload can be re-queried |
| Duplicate or repeated retrieved chunks | The same content appears elsewhere |
| Verbose logs and stack traces of fixed errors | Only the fact that it failed and why matters |
| Full schemas of tools no longer in use | The agent can reload a schema if it needs the tool |
| Superseded drafts and intermediate attempts | Keep the reason they were rejected, not the text |
| Greetings, acknowledgements and filler turns | No task content |
| Not safe to drop | Why |
|---|---|
| A user's stated exclusion, even from turn 2 | Later steps must still honor it |
| The value a later step will compute from | Recomputing may be impossible or costly |
| Why an option was rejected | Without it the agent may choose it again |
The test is always "would any remaining step behave differently without this?"
How the exam asks about this
- "After compaction the agent recommends a vendor the user excluded early in the session." The compaction lost user constraints and exclusions; add a deduplicated constraint list to the prompt.
- "After compaction the agent retries a join that already failed twice." Preserve rejected options with the reason they failed.
- "Which content in this trace is safe to remove?" Pick the raw tool payloads whose findings are already summarized, not the early user instruction.
What to remember for the exam
- Compaction keeps only what the prompt asks for; everything else is gone for the rest of the run.
- Decisions, constraints, rejected options, open tasks, identifiers and unresolved errors are high value and low token cost.
- Map the downstream symptom to the lost category, then add only that category to the prompt.
- Logging every user message, every tool output or the full chain of thought fixes the gap at a large token cost.
- Safe to drop: consumed raw tool output, duplicates, verbose logs, unused tool schemas, superseded drafts, filler.
- The safety test is downstream need, not age.
"Keep everything" options always resolve the coherence failure, which makes them tempting. When the question adds "without significantly increasing token cost", the answer is the targeted structured list, not a full log.
Common mistakes
Treating findings as the whole story. A summary of facts discovered can be accurate and still drop the decisions and constraints that tell the agent what to do next. Coherence failures after compaction usually come from this gap.
Dropping old content because it is old. An exclusion stated in the second turn is as binding at turn 80 as when it was said.
Keeping raw tool output to be safe. Large query results and retrieved documents are the bulk of most traces. Once their findings are summarized and the source can be queried again, the payload is the safest thing to remove.
Check yourself
A compacted agent starts contradicting decisions it made earlier; what category was lost?
Decisions with their reasons, and often the user constraints behind them. Revise the prompt to add a short deduplicated list of decisions and constraints.
Why is "include all tool outputs" a poor fix for a lost constraint?
It does contain the constraint, but it rebuilds most of the compacted history and sharply raises token cost, while a constraint list fixes the same gap cheaply.
Is a 40,000 token query result safe to drop after its key figures are summarized?
Yes, if later steps need only those figures and the agent can re-run the query when needed. The finding stays and the payload goes.
Topic 1 of 2 in Context Compression and Compaction
Test yourself on Context Compression and Compaction
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.