How do you coordinate memory compaction across concurrently running AI agents?

Coordinating memory compaction across concurrent AI agents means ensuring that a compacted summary represents a consistent set of agent updates, while no running agent loses work or sees partially published memory. Multiple agents may read the same working context, append observations, and complete branches in different orders. A compactor must not overwrite a newer result with an older summary.

A useful design is immutable source events + versioned candidate summaries + validation + atomic activation.

Beginner-friendly example: API test-generation agents

Four agents generate test suites from an API specification:

• A requirements agent adds endpoint constraints.
• A test generator adds completed test case IDs.
• A security reviewer adds authorization findings.
• A compaction worker condenses accumulated history before the next model call.

Suppose the compactor reads shared state at revision 12. While it summarizes, the reviewer records a critical failed authorization test, creating revision 13. If the compactor blindly saves its revision-12 summary as the latest context, the failed test disappears from the working memory.

Read consistent revision → Generate candidate summary → Validate all source updates → Atomically activate only if revision still matches → Retry or reconcile on conflict

Step-by-step numerical example

Imagine three agents write concurrently:

1. At revision 40, shared history contains 18,000 tokens.
2. The compactor begins creating a 5,000-token summary from revision 40.
3. The requirements agent adds 3 new constraints, and the reviewer adds 2 unresolved issues. The canonical revision advances to 42.
4. Compaction based on revision 40 is now stale. Publishing it without protection would omit 5 important updates.
5. The compactor performs a conditional update: activate summary where current_revision = 40.
6. Because the current revision is 42, the update affects 0 rows; the stale summary is rejected.
7. The compactor reads the five new updates, regenerates or safely extends the candidate, validates all 3 constraints and 2 issues, and attempts activation against revision 42.
8. If the revision still equals 42 and validation succeeds, the candidate becomes active. Otherwise, the worker repeats the conflict-handling procedure.

The exact summary length and agent count are illustrative; correct version checks matter more than the token savings.

Three useful coordination strategies

1. Optimistic concurrency (usually the first choice): Let agents work normally, build a summary for a specified source revision, then use a database transaction or compare-and-swap to activate it. On conflict, retry from the latest source. This avoids stopping every agent but can waste compaction work during heavy updates.
2. Short coordinated pause: Temporarily stop writes for a particular workflow at a safe handoff or checkpoint, collect an agreed snapshot, compact, validate, then resume. It is simpler to reason about but introduces coordination latency and must not freeze unrelated tenants or tasks.
3. Event-log/watermark compaction: Summarize an immutable sequence of updates through a known event watermark, such as events 1–250. New events 251 onward remain available as an unsummarized delta. Readers receive summary-through-250 + events-after-250. This is useful when continuous writes make a fully caught-up snapshot difficult.

A system can combine these strategies: compact a stable watermark, then atomically update a summary pointer after validating coverage.

How do you avoid lost or duplicated updates?

• Use stable event IDs: Deduplicate retried or redelivered updates before they enter the source log.
• Record per-event authorship: Store agent ID, workflow ID, tenant, source version, and event timestamp or sequence.
• Define merge rules: Independent sets of generated test IDs can be unioned with deduplication; an approval status cannot be merged with last-write-wins if it would overwrite an explicit rejection.
• Track exact coverage: Store the compacted source revision or event-watermark range. Each event must appear either in the validated summary or the uncompacted tail, not disappear between them.
• Treat read-after-write explicitly: An agent that just committed a critical update should see at least that revision, or read authoritative state rather than a lagging summary.
• Separate candidate creation from activation: A completed summarization call is only a candidate. A transactional pointer change makes it the active version.
• Keep an immutable recovery path: Preserve raw facts and audit events according to retention rules. Do not delete them merely because the short context was published.

A safe read model

Store:

• active_summary_id
• covered_through_revision
• canonical_revision
• pending_events
• validation_status

When a reader assembles model context, load one consistent active-summary version and append events after its covered revision through a captured read watermark. Check for gaps and duplicate event IDs. If the summary fails validation or critical events are missing, use the authoritative records or block the affected action.

A summary pointer swap can be atomic in one database transaction. Updating a summary and a separate vector index in two independent systems is not automatically atomic; use revision-aware indexing and make readers reject stale index entries.

Example: compare-and-swap activation

Illustrative SQL logic:

SQL
UPDATE workflow_memory
SET active_summary_id = :candidate_id,
    covered_through_revision = :candidate_revision
WHERE workflow_id = :workflow_id
  AND tenant_id = :tenant_id
  AND canonical_revision = :candidate_revision;

Activate only if the candidate has already passed validation and exactly one intended row changes. The summary document and its validation record should be durable before the pointer moves. If the update affects zero rows, discard or recompute the stale candidate rather than forcing the write.

In an event-watermark design, a summary need not cover every newest event at activation; however, the reader must include the uncompacted tail and enforce any freshness requirements.

What about parallel branches and checkpoints?

If the test generator and security reviewer finish in parallel, wait for the intended branch-join semantics or summarize through a durable event watermark that clearly identifies which branch updates are included. Preserve branch-specific pending work and failed approvals. A compaction triggered in the middle of a tool call should not detach a tool response from its corresponding request or mistake an uncommitted effect for a completed one.

For failed or retried work, distinguish the record of an attempt from a committed outcome. A retry must not duplicate published test suites or silently change approval state.

LangGraph and Celery implementation

In LangGraph, checkpointers persist thread-level graph state, while a long-term store can hold shared memory across threads. Use an application-level revision or event log to coordinate memory compaction across separate threads; a graph checkpoint alone is not a distributed lock for all agents. Preserve compatible reducers and checkpoint boundaries when parallel branches merge.

In Celery, put compaction into a retry-safe task keyed by workflow, tenant, and source revision. Use a lease or unique work key to reduce duplicate compaction cost, but enforce correctness with transactional revision checks because leases can expire and tasks can be retried. A stale worker completion must never replace a newer active summary.

Trade-offs and monitoring

Optimistic compaction minimizes pauses but may waste work under frequent writes. Paused compaction provides a stable snapshot but increases coordination latency. Watermark-based compaction keeps writers active but requires reliable gap-free event tracking.

Monitor CAS conflicts, stale candidate rejection, compaction retries, event-tail length, reader freshness lag, duplicate events, missing critical facts, and p95 context-build latency. If too many candidates become stale, compact at quiet checkpoints or switch to a watermark-based approach.

How is this different from earlier questions?

• Q194: General consistency of shared state across agents.
• Q227: How to construct and publish compact working context.
• Q228: How to prevent loss of important information.
• Q229: How to evaluate compacted-context quality.
• Q230: When to trigger compaction.
• This lesson: How concurrently executing agents coordinate *which events enter a summary and when that summary becomes visible*.

In short

Never let a compactor overwrite live agent updates. Snapshot a known revision or event watermark, retain new events, validate the candidate, activate it atomically, and assemble every reader's context from a consistent summary plus any uncovered updates.

Further reading

• LangGraph: Add and manage memory
• LangGraph: Persistence and checkpoints