How do you version and audit compacted memory across long-running multi-agent workflows?

Versioning and auditing compacted memory means recording exactly which source events, agent decisions, and validation results produced each shortened working context—and which version every agent actually consumed. This makes long-running multi-agent workflows reproducible, debuggable, and recoverable when an important detail disappears or a later output is disputed.

A compacted summary is a *derived view*, not the authoritative record. Keep the source events and artifacts available according to approved retention policies, and store an immutable audit record for each candidate and activation.

Beginner-friendly example: API test generation

A LangGraph workflow uses a requirements agent, test generator, security reviewer, and publisher. Each agent contributes facts about POST /payments, including OAuth scopes, generated test IDs, unresolved bugs, and approval outcomes.

After 80 messages, a compactor creates a short summary. Three days later, someone asks why the publisher omitted a 401 Unauthorized test.

Without version history, the team sees only the latest summary and cannot tell whether the original requirement was missing, the compactor removed it, or the downstream generator ignored it. With an audit trail, the team can reconstruct the source revision → compacted summary → validation → active version → consuming agent → published artifact.

Record source lineage → Build immutable summary candidate → Validate → Atomically activate → Log which version agents read → Reproduce or roll back when required

Numerical example

Suppose a workflow has 240 committed events.

1. Summary S1 includes events 1–100, created using compactor version c1.
2. Summary S2 includes events 1–180, created using version c2 after 80 additional events were committed.
3. Summary S3 includes events 1–220, created using version c2 and a revised validation rubric.
4. The active working context is S3 + events 221–240. It must not silently lose the 20-event uncompacted tail.
5. The publisher's audit entry shows it read S3, saw the tail through event 240, and produced artifact T57.
6. If the security reviewer later discovers an omitted scope, the audit trace identifies the summary and exact source event IDs needed to compare the original requirement against the context consumed by the publisher.

A summary's coverage watermark is not the same as the canonical event revision. A summary through event 220 is still useful when event 240 exists, but readers must include relevant later events or use a freshness guard.

What metadata should each compacted version contain?

1. Identity: Tenant ID, workflow/thread ID, immutable summary ID, creation time, and producing compaction job ID.
2. Source lineage: Canonical source revision or event range, content/artifact references, and any excluded categories of ephemeral data.
3. Compactor configuration: Model identifier, prompt/template version, algorithm version, token budget, and relevant tool or schema version.
4. Validation record: Validator version, mandatory-field coverage, groundedness checks, open-issue preservation, and pass/fail reasons.
5. Content integrity: Hash of a canonical serialized summary plus a record of where the summary is stored.
6. Lifecycle status: CANDIDATE, VALIDATED, ACTIVE, SUPERSEDED, REJECTED, or QUARANTINED, as appropriate.
7. Activation details: Actor/worker, exact time, prior active version, accepted source revision, and successful conditional-write result.
8. Consumer trace: Which agent run and model call used which summary ID, event-tail watermark, and source references.

Keep secrets and personal data out of ordinary audit logs; use scoped references and cryptographic hashes with suitable access controls.

Simple example of a versioned summary record

JSON
{
  "tenant_id": "tenant-7",
  "workflow_id": "api-tests-42",
  "summary_id": "S3",
  "source_event_watermark": 220,
  "compactor_version": "c2",
  "validator_version": "rules-5",
  "status": "VALIDATED",
  "summary_hash": "sha256:...",
  "source_refs": ["spec-v7", "review-19"],
  "pending_approval_ids": ["approval-12"]
}

The digest is illustrative. In production, generate it from the actual canonical bytes; never write a placeholder hash into a real integrity check.

Candidate version versus active version

Treat these separately:

• Candidate: A newly generated summary that may be incomplete or unsupported.
• Validated version: A candidate that passes integrity, completeness, and safety checks.
• Active version: The validated summary selected by an atomic pointer update for authorized readers.

A database transaction or compare-and-swap should activate the correct summary while checking the expected current revision. A worker completing late must not replace a newer version. Keep activation and rejection history append-only so later incident analysis can see what happened.

If an event-watermark design is used, allow a validated summary covering an older watermark while ensuring readers append the missing event tail. If strict read-after-write consistency is needed, require a reader's consumed revision to be at least the revision it just committed.

How do you audit an unexpected output?

Imagine the published test suite omitted an authorization test.

1. Find the published artifact ID and its agent execution ID.
2. Read the consumer trace to identify the exact summary version and event-tail watermark.
3. Compare the original API specification with the committed requirements events.
4. Check whether those facts existed in the compacted summary or the consumed tail.
5. Inspect the compactor's validation results and any waived checks.
6. Distinguish source extraction failure, compaction omission, retrieval/assembly failure, and downstream reasoning failure.
7. Re-run the workflow in a controlled environment using the preserved inputs, compatible model/tool versions, and the recorded prompt configuration.

Reproduction is best-effort: Model services, nondeterministic generation, and changing external APIs may prevent bit-for-bit identical outputs, even when the lineage is complete. Store snapshots of external tool results where policy permits.

Retention and privacy trade-offs

Auditability does not mean retaining every raw message forever. Apply approved retention periods to full transcripts, tool inputs, and summaries; store minimal provenance for longer where lawful and useful. Honor deletion obligations across source and derived records, and explain when a historical replay is no longer possible because source content was legitimately deleted.

When a memory is purged, update indexes and references so agents do not keep retrieving it from an old compacted summary. A hash can support integrity but does not prove that the summary is factually correct.

LangGraph and Celery implementation

In LangGraph, record graph release version, thread/checkpoint identifier, and summary ID together in the execution trace. A checkpoint helps restore state, but the model-facing context may be a selected summary plus recent messages; log exactly what was supplied. If a thread resumes after an upgrade, ensure the summary schema and source references remain compatible.

In Celery, use durable, idempotent compaction jobs keyed by tenant/workflow/source revision. Log task attempt IDs and record validation and activation outcomes separately. Redelivered or older tasks may finish after a newer summary is active: conditionally reject stale activation instead of rewriting history.

Useful operational metrics

Track summary versions per workflow, active-summary age, unconsumed event-tail length, stale activation attempts, validation failures, unexplained source gaps, audit-trace completeness, and time to reconstruct a faulty output. Establish explicit alerts for missing provenance or consumers using an unvalidated summary.

Difference from previous lessons

• Q227: Builds a compact working context.
• Q228: Preserves critical information during compaction.
• Q229: Measures compaction quality.
• Q230: Determines when compaction is triggered.
• Q231: Coordinates concurrent updates.
• Q232: Recovers from compaction failures.
• This lesson: Establishes immutable version history and end-to-end lineage so a team can explain, compare, and audit what agents actually saw.

In short

Version every compacted summary, connect it to exact source events and validation results, and record which version each agent used. Use atomic activation and permission-aware retention so compacted memory remains both operationally efficient and auditable.