How do you prevent information loss during memory compaction in multi-agent workflows?

Preventing information loss during memory compaction means proving that a shorter working context still contains every fact and decision needed to finish the workflow correctly. A readable summary is not enough: critical requirements, pending approvals, uncertainty, and references to original evidence must survive compression.

In long-running multi-agent systems, the safest pattern is to keep authoritative state and source artifacts durable, compact only what agents repeatedly read, and reject any compacted context that fails validation.

Beginner-friendly example: API test generation

A requirements agent extracts rules for POST /payments, a test-generation agent writes cases, and a security agent reviews them. The original history contains:

• POST /payments requires OAuth2 with the pay:write scope.
• A successful request returns 201.
• Missing authorization returns 401.
• An unresolved issue: whether duplicate requests need an idempotency key.
• The security reviewer has not approved the generated tests.
• Requirements originate from specification revision v7.

Unsafe summary: “Payment tests were generated; ready to publish.”

This loses the required scope, edge cases, unresolved issue, and approval status. A safe compact context preserves the exact constraints and keeps links to the original specification, test artifact IDs, and review records.

Identify protected facts → Construct compact context → Compare with source → Run invariant checks → Validate downstream behavior → Activate only if all gates pass

Step-by-step numerical example

Suppose a workflow has 30 requirements, 5 unresolved issues, and 2 pending approvals.

1. The original history occupies 24,000 tokens.
2. The proposed summary occupies 4,000 tokens: an 83.3% context reduction, calculated as (24,000 − 4,000) / 24,000 × 100.
3. Automated extraction checks find 29 of 30 requirements, 4 of 5 issues, and both approvals.
4. Requirement recall is 29 / 30 = 96.7%; open-issue recall is 4 / 5 = 80%.
5. If the omitted requirement is an authorization scope or the omitted issue could affect publication, the candidate must fail despite the attractive token savings.
6. A second summary includes all 30 requirements, 5 issues, and 2 pending approvals, with evidence links. It can proceed to semantic and end-to-end validation; coverage alone does not prove every retained statement is accurate.

These numbers are illustrative. For mandatory security constraints and workflow approval gates, aim for 100% verified preservation rather than averaging safety-critical omissions into an overall score.

Which information should never disappear silently?

1. User goal and acceptance criteria: Exact task scope, endpoints, constraints, and what constitutes completion.
2. Hard requirements: Authentication rules, numerical limits, contractual terms, security policies, and negative test expectations.
3. Decisions and ownership: Accepted choices, decision status, responsible agent, and next handoff.
4. Unresolved work: Open bugs, questions, failed tests, blocked steps, and pending human approvals.
5. Side-effect ledger: Tool calls, published artifacts, external write IDs, and idempotency keys needed to avoid duplicate actions.
6. Uncertainty: Whether facts are verified, inferred, disputed, or unknown; never convert “pending review” into “approved.”
7. Evidence: Stable record IDs, source versions, timestamps, and retrieval pointers allowing exact details to be reconstructed.
8. Security boundaries: Tenant IDs, permitted scopes, sensitive-data handling rules, and redaction requirements.

Keep these as structured fields when possible, not only free-form prose.

How do you validate a compacted memory?

• Schema checks: Require all mandatory keys and correct types.
• Coverage checks: Compare source requirements, issue IDs, decisions, and approvals against the compacted representation.
• Entailment checks: Verify that each summary claim is supported by a cited source. The summarizer should not invent evidence.
• Contradiction checks: Flag mismatched values such as 401 becoming 403, or PENDING becoming PASS.
• Golden-question tests: Ask known questions of both full and compacted contexts; compare exact constraints and supporting sources.
• Downstream regression tests: Generate representative test cases using each context and compare accepted coverage, unsafe omissions, and review outcomes.
• Retrieval fallback: Let agents fetch the full source section when a compact summary cannot answer a high-stakes question confidently.

No automated LLM evaluator is perfectly reliable. Combine deterministic field comparisons, representative end-to-end tests, and targeted human review for high-risk changes.

Avoid repeated summarization loss

Repeatedly summarizing a summary can gradually remove rare but important details. Keep the immutable original history or authoritative artifacts available. Build periodic summaries from source evidence, or merge new observations with a versioned structured state, rather than compressing only the latest shortened text indefinitely.

Use clear links such as source_doc_revision=v7, requirement_ids=[R1,...], and pending_approval_id=A2. A reference is useful only if the referenced artifact remains available and authorized.

What about concurrent multi-agent updates?

While a compactor reads revision 12, a reviewer may finish a decision and advance shared state to revision 13. Publishing the old summary unconditionally could erase the latest result.

Create the summary against a source revision, validate it, and update the active summary pointer only if that revision remains current. If the compare-and-swap fails, retry against the latest state or incorporate the new event. Keep previous validated versions for recovery.

LangGraph and Celery implementation

In LangGraph, the checkpointer can retain state across thread steps, while a node selects which messages or summary to supply to the model. Keep full evidence in durable state or an authorized store and maintain a separate validated summary. Be careful: deleting messages from persisted graph state is different from excluding them from one model call. Preserve valid model/tool-message boundaries if trimming.

With Celery, run summarization and verification as separate idempotent jobs keyed by workflow ID and source revision. Never promote a failed summary. A late retry from an older revision must not overwrite a newer validated compact context.

Difference from previous lessons

• Q73: Explains the general idea of consolidating repeated memories into reusable knowledge.
• Q227: Explains when and how to compact active context for cost and token efficiency.
• This lesson: Defines concrete preservation invariants, source-grounding checks, omission metrics, and release gates that stop a lossy compaction from changing multi-agent decisions.

In short

Treat compaction as a lossy transformation that must prove it has preserved what matters. Keep authoritative evidence, require complete coverage of critical fields and open work, test agent outcomes, and activate only revision-safe summaries that pass validation.

Further reading

• LangGraph: Add and manage memory
• LangMem: Managing long context with summarization
• LangGraph: Checkpointers