What you will be able to do
- Name the categories of information a compaction summary must keep for a long-running agent to stay coherent, and the categories it can safely drop
- Map a post-compaction coherence failure (repeated tool calls, contradictions, constraint violations, wrong identifiers, early completion) to the category that was lost
- Choose the compaction prompt revision that restores the lost category with a short, targeted instruction instead of a large increase in summary size
- Use the full session transcript and trace token data to check that a revision brings back fidelity without a large rise in cost
Key concept
Category-targeted compaction — Compaction swaps an agent's long history for a summary, so every coherence failure afterwards comes from a category of information the summary left out. The fix is to name that category in the compaction prompt and ask for it in a compact, structured form. Keeping more of everything is the wrong fix.
1.What compaction acts on, and why it can break an agent
A long-running agent builds up history with every turn. Its session state is the conversation so far: what the user asked, every tool call, every tool result, and the agent's reasoning between them. When that history gets close to the context-window limit, the harness summarizes it and the agent continues from the summary. From then on the agent can only use what the summary kept. If a fact was left out, the agent has no way to know it ever existed.
A generic summarizer keeps the story and drops the bookkeeping. It tends to write a few fluent sentences about what the agent was doing and leave out the details later steps rely on: the exact table name the user said not to touch, the ID of the job already launched, the approach tried and rejected at step 14, the three sub-tasks still open. Databricks describes a similar step for long-term memory, where an agent or application distills durable facts out of a session. Compaction faces the same choice inside a single task: what is worth keeping? The basic example below shows the default behavior. A one-line summarization template with no guidance about what matters.
prompt_v1 = mlflow.genai.register_prompt(
name=PROMPT_NAME,
template="Summarize this text: {{content}}",
commit_message="v1: Basic summarization prompt"
)A compaction summary has two kinds of content. The must-keep set: (1) the goal and hard constraints, (2) decisions and their short rationale, including rejected alternatives, (3) completed actions with their identifiers, especially actions with side effects, (4) the specific facts pulled from tool outputs, such as IDs, values, paths and error messages, and (5) open items still to do. The safe-to-drop set: superseded reasoning, raw tool output whose useful facts are already extracted, and the step-by-step detail of finished sub-tasks.
Checkpoint 1 of 5· Check yourself
In the Databricks description of agent session state, what does the conversation history being compacted actually contain?
Session state includes tool calls and their results, not just chat messages. That is why compaction can lose operational state, such as which actions were already done, and not only conversational content.
“the ordered transcript of messages, tool calls, and results”Source: docs.databricks.com
2.Reading the symptom: which category was discarded?
Compaction failures show up later. The summary looks reasonable, and the agent goes wrong several steps afterwards. To diagnose one, work backwards: look at what the agent did wrong, then ask which piece of information would have stopped it. Each must-keep category has its own symptom, and exam scenarios are written so that only one category fits.
The record of completed actions and their identifiers. The summary said roughly what the agent was doing but not that the call had happened or what it returned. Repeated or wasted tool calls are already a known risk of agent loops, and compaction makes it worse by erasing the evidence that the work is done. A long-running harness has to know where it stopped so it can resume there instead of starting over.
Decisions and their rationale, plus the marking of which option was superseded. The summary either dropped the decision or kept both the old and new positions without saying which one is current.
The goal and hard constraints. Early instructions are the most likely to be squeezed out, because they sit furthest back and read like setup.
Specific facts extracted from tool outputs. The summary paraphrased the result ("found the relevant orders") and dropped the exact values later steps needed.
A fifth pattern is the agent saying it is finished while sub-tasks are still open. That points to lost open items. The summary described completed work well but never listed what was left. Two other patterns can look similar but don't count as compaction failures: an agent that was already inconsistent before compaction, and an error that comes from a bad tool response. Before you blame compaction, confirm that the failure first appears after the compaction boundary.
Checkpoint 2 of 5· Exam question
A data-engineering agent has been running for over an hour, executing many diagnostic SQL queries against a Delta table to find the source of a null-value bug. A compaction event condenses the growing history into a narrative summary ("agent investigated several possible causes of the null values"). Immediately after, the agent reruns two diagnostic queries it had already executed and already had results for. Which category of information was incorrectly discarded, and which compaction prompt revision fixes this without materially increasing summary length?
Correct answer: A — The log of already-executed tool calls and their results was discarded; retain a compact list of completed actions and outcomes
- A. Correct. The agent re-ran queries it had already completed, which is the signature symptom of a compaction summary that dropped the record of which actions were already taken and what they returned. Adding a compact completed-actions log to the compaction prompt preserves this without re-including full query outputs.
- B. Incorrect. The bug ticket text being missing would cause the agent to lose sight of the reported symptom, not to redundantly repeat queries it already ran; the trace shows repetition of specific completed work, not confusion about the original ask.
- C. Incorrect. Re-embedding the entire schema every summary would raise token cost significantly and doesn't address the actual symptom, which is not knowing what was already tried.
- D. Incorrect. Stakeholder contact details are unrelated to the agent repeating diagnostic queries; this option doesn't address the observed failure at all.
3.Selecting the revision: preserve the category, not the volume
Once you know which category was lost, the second half of the objective is choosing the fix. Answer options tend to fall into two groups. Broad options keep more of everything: keep the last N turns verbatim, keep all tool outputs, raise the summary length cap, compact less often. Each might restore the missing fact, but by inflating the summarized context, which defeats the purpose of compacting. Targeted options add one specific instruction for the lost category and ask for it in a terse, structured format.
Databricks has no dedicated compaction setting to learn here. This is prompt design. The closest Databricks pattern is the system-prompt guidance for managed agent memory, which tells the agent what to keep and what to drop when it writes durable memory. Its rules carry over to compaction prompts. When something changes, replace the old version instead of keeping both. Write each entry so it stands on its own out of context. Leave out the agent's own suggestions or guesses, passing chatter, secrets, and anything scoped to this chat. The MLflow prompt-versioning example shows the same move in a general summarizer: its improved version adds explicit guidance such as "Include ALL core facts and key findings" instead of simply allowing a longer output.
Applied to each category, a good revision is one short clause. For lost progress state: "List every completed tool action with side effects as one line: action, target, returned ID." For lost constraints: "Restate the user's original goal and hard constraints verbatim at the top." For lost facts: "Keep exact identifiers, values and paths extracted from tool outputs; drop the raw output." For lost open items: "End with a checklist of unfinished sub-tasks." Each one adds a few lines to the summary and does not bring the transcript back. Some also let the summarizer drop more raw output, which partly pays for the new lines.
Checkpoint 3 of 5· Check yourself
After a compaction, an agent mixes a decision the user revised mid-task with the original version. Which compaction prompt revision best matches Databricks' guidance on handling information that changes?
Keeping both versions is what causes the contradiction. Replacing the old version with the new one fixes it and keeps the summary small.
“update or replace it rather than keeping both”Source: docs.databricks.com
Checkpoint 4 of 5· Exam question
While configuring a Genie space, an agent is explicitly told by the user to exclude the deprecated table "sales_2019_legacy" from the space. Several turns later, a compaction step summarizes the session as "configured Genie space with the relevant sales tables." On the next turn, the agent adds "sales_2019_legacy" back into the space's table list. Which category of information was incorrectly discarded during compaction?
Correct answer: A — The explicit exclusion decision the user gave was discarded, rather than being carried forward as a standing constraint
- A. Correct. A specific user decision ("exclude sales_2019_legacy") was reduced to a vague narrative phrase ("relevant sales tables") that no longer encodes the exclusion, so the agent re-added the table. Decisions and their rationale need to survive compaction as explicit, standing constraints, not paraphrased narrative.
- B. Incorrect. Nothing in the scenario suggests the warehouse type was lost or caused the observed behavior; the failure is specifically about a table being re-added, tied to a decision, not a configuration detail like warehouse type.
- C. Incorrect. Row counts are reference statistics unrelated to which table was excluded; losing them would not explain the agent re-adding a specifically excluded table.
- D. Incorrect. The display name has no bearing on which tables are included in the space, so its loss would not produce this symptom.
4.Confirming the fix: fidelity restored, cost contained
A diagnosis is only a guess until you check it against evidence. On Databricks, two kinds of evidence are available. First, compaction changes what the model sees, but the full session record can still be kept. Managed agent sessions let you rebuild full context, including tool calls and reasoning, from the stored history. Compare the compacted summary with that transcript to confirm the missing category really was in the original and really is gone from the summary. Second, MLflow Tracing records token usage and cost for every step. You can measure how many tokens the revised summary adds and confirm the increase is small.
Last, rerun the failing scenario with the revised prompt. The original symptom should be gone: no repeated call, no contradiction, constraints followed. Summary size should stay about the same. If the symptom remains, the diagnosis may have been wrong. Go back to the transcript and check whether a different category was lost. Long conversations that hit token limits are a recognized problem area on Databricks, so this check-and-compare loop is part of normal work, not a one-off fix.
Checkpoint 5 of 5· Exam question
Early in a session, a user tells an agent, "Only write results to the dev catalog, never to prod." Many turns later, after a compaction event summarizes the conversation as "agent has been writing pipeline outputs to Unity Catalog tables," the agent writes its next output directly to a table in the production catalog. Which category of information was incorrectly discarded during compaction?
Correct answer: A — The user's explicit dev-only write constraint was discarded, rather than being pinned as a standing rule
- A. Correct. A hard user-given constraint ("never write to prod") was collapsed into a generic phrase about writing to Unity Catalog, losing the restriction entirely. Constraints like this need to persist through compaction as pinned rules, not folded into vague narrative.
- B. Incorrect. Runtime duration has no bearing on which catalog the agent writes to, so its loss would not explain a prod write.
- C. Incorrect. Collaborator names are irrelevant to a catalog-write restriction and would not cause this specific violation.
- D. Incorrect. A dashboard color preference has nothing to do with which catalog receives writes.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.The right fix for post-compaction forgetting is to compact less often or keep more raw history in context.Why is that wrong?
Compaction exists so the model is not overwhelmed as context grows. Keeping more raw history gives up that purpose and raises token cost. The objective rewards a targeted instruction that preserves only the lost category.
Covered in Selecting the revision: preserve the category, not the volume
2.When an agent repeats tool calls after compaction, the fix is to add iteration limits or timeouts.Why is that wrong?
Iteration limits are a general guard against runaway loops. They stop the damage but don't restore the lost record of completed actions. The cause, a summary missing completed actions and their IDs, has to be fixed in the compaction prompt.
Covered in Reading the symptom: which category was discarded?
3.For completeness, a compaction summary should keep both the original and the revised version of a decision.Why is that wrong?
Keeping superseded information next to current information is what causes contradictions after compaction. The current version should replace the old one, with at most a one-line note of what was rejected.
Covered in Selecting the revision: preserve the category, not the volume
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“the ordered transcript of messages, tool calls, and results”
↩︎ What compaction acts on, and why it can break an agent“an agent (or your application) distills the durable facts out of it and writes them to memory”
↩︎ What compaction acts on, and why it can break an agent - 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.”
↩︎ What compaction acts on, and why it can break an agent“As conversations grow longer, the harness decides what stays active and what gets summarized, a process known as context compaction.”
↩︎ Key concept“trimming older parts of the conversation so the model does not become overwhelmed as the context grows”
↩︎ Exam trap 1 - 3.
“Must guard against repeated or incorrect tool calls”
↩︎ Reading the symptom: which category was discarded?“Infinite loops can occur in any tool-calling scenario, so set iteration limits or timeouts.”
↩︎ Exam trap 2 - 4.https://docs.databricks.com/aws/en/agents/agent-bricks/multi-agent-supervisor-long-running-tasksOfficial docs
“The supervisor picks up where it left off and continues working.”
↩︎ Reading the symptom: which category was discarded? - 5.
“update or replace it rather than keeping both”
↩︎ Selecting the revision: preserve the category, not the volume“Write each memory so it stands on its own out of context”
↩︎ Selecting the revision: preserve the category, not the volume“your own suggestions or guesses, passing chatter, secrets, or anything scoped to this chat”
↩︎ Selecting the revision: preserve the category, not the volume“update or replace it rather than keeping both”
↩︎ Exam trap 3 - 6.https://docs.databricks.com/aws/en/mlflow3/genai/prompt-version-mgmt/prompt-registry/evaluate-promptsOfficial docs
“Include ALL core facts and key findings”
↩︎ Selecting the revision: preserve the category, not the volume - 7.
“Reconstruct full context (including tool calls and reasoning) on a follow-up message.”
↩︎ Confirming the fix: fidelity restored, cost contained - 8.
“Tracing records the inputs, outputs, latency, token usage, and cost of every intermediate step”
↩︎ Confirming the fix: fidelity restored, cost contained - 9.
“token-limit truncation in long conversations”
↩︎ Confirming the fix: fidelity restored, cost contained