How do you handle memory compaction when multiple agents have different context requirements?

When multiple AI agents need different information, compact shared memory into a verified common core plus role-specific views instead of forcing every agent to consume one generic summary. A requirements extractor needs precise source rules, a test generator needs testable cases, and a security reviewer needs authorization controls and unresolved findings. The shared core preserves facts and handoff state; each agent's view emphasizes the evidence it needs.

A role-specific view is a *derived projection*, not a separate source of truth. All views should reference the same authoritative records and versions.

Beginner-friendly example: API test generation

A workflow uses four agents:

• Requirements agent: Needs endpoint paths, schemas, response codes, source sections, and open ambiguities.
• Test-generation agent: Needs acceptance criteria, valid/invalid input boundaries, existing test IDs, and coverage gaps.
• Security reviewer: Needs authentication scopes, permissions, tenant isolation rules, and unresolved vulnerabilities.
• Publisher: Needs verified artifacts, final approval status, destination, and idempotency key.

A generic 4,000-token summary might mention “OAuth2 required” but omit the exact pay:write scope. That may be acceptable background for some tasks, but not for security review or publication.

Persist canonical evidence → Define each agent's required fields → Create a shared core → Build role-specific projections → Validate and authorize each view → Assemble context at handoff

Step-by-step numerical example

Suppose the uncompacted shared history is 24,000 tokens. The pipeline makes one call to each of four agents, and each initially receives all 24,000 tokens.

1. Replayed context across the four calls totals 4 × 24,000 = 96,000 input tokens.
2. A validated 3,000-token common core retains workflow identity, source versions, decisions, and pending work.
3. The requirements view adds 5,000 tokens, the test-generator view 4,000, the security view 6,000, and the publisher view 2,000.
4. The four per-agent contexts become 8,000, 7,000, 9,000, and 5,000 tokens.
5. Total replayed context is 29,000 tokens, a reduction of 67,000 / 96,000 ≈ 69.8%.
6. This is not automatically the net cost saving. Add the tokens spent creating, validating, refreshing, and retrieving projections, and account for input/output pricing and caching.
7. If the security projection omits even one mandatory OAuth scope, reject that view despite the apparent 69.8% reduction.

These numbers are illustrative and assume the role-specific views contain all relevant information for the modeled calls.

Design a two-layer memory structure

Layer 1: authoritative shared core

Store workflow and tenant IDs, source-document versions, artifact IDs, committed decisions, critical global constraints, pending approvals, and the event watermark. This layer should be consistent across agents and should never depend on a free-form summary alone for authorization.

Layer 2: role-specific compact projections

Generate versioned views keyed by workflow_id + agent_role + source_revision + projection_version. For example, a security view references the source IDs for OAuth requirements, while the publisher view references approval and artifact IDs. Both can retrieve exact underlying evidence when needed.

A role-specific view should not invent a new “fact” that conflicts with the canonical core.

Practical implementation

1. Specify each agent's contract: Define mandatory fields, optional context, forbidden fields, freshness requirements, and output expectations.
2. Separate global from local facts: Keep hard constraints and cross-agent state in the shared core; include specialist details only where relevant.
3. Use structured projections: Prefer source IDs, requirement IDs, approvals, and status objects alongside concise natural-language explanations.
4. Validate role-specific completeness: Check requirements against each role's rubric. The test generator may require boundary conditions; the publisher must require verified approvals.
5. Enforce access controls before summarization: A projection must not aggregate records the consuming agent or tenant is not allowed to read. Redact restricted fields rather than relying only on prompting.
6. Track provenance and revisions: Each view records source watermark, compactor configuration, and validation result.
7. Assemble per-call context: Supply the common core, the current role view, selected recent messages, and on-demand source excerpts—not every view to every agent.
8. Invalidate on relevant changes: When a security requirement changes, refresh the security projection and any downstream view that depends on it.
9. Support safe fallback: If a needed fact is unavailable or stale, retrieve approved authoritative evidence or block the affected action rather than guessing.
10. Observe cost and quality: Measure projection size, refresh lag, missed requirements, extra retrievals, and task success per role.

Example of a safe security projection

JSON
{
  "role": "security_reviewer",
  "workflow_id": "api-tests-42",
  "source_revision": 18,
  "required_auth": {
    "scheme": "OAuth2",
    "scope": "pay:write",
    "source_ref": "api-spec-v7#payments-auth"
  },
  "unresolved_findings": ["F12"],
  "approval_status": "PENDING"
}

The security agent can use this compact structure while retrieving the exact specification section if a decision requires more detail. The publisher must independently confirm the final approval status from the authoritative source; it should not treat an old projection as approval.

How do you handle different context windows and budgets?

Agents may use models with different usable context capacities. Assign per-role budgets after reserving space for system instructions, tools, retrieved evidence, and output. If the security agent needs more evidence than its budget allows, prioritize required source excerpts and drop low-value conversational repetition. Never resolve a tight budget by silently removing mandatory constraints.

A role can also use a lightweight view for planning and a richer evidence view for a critical decision. The model-facing view is not the full durable memory.

Concurrent updates and version safety

Imagine the requirements agent commits a new permission rule at source revision 19 while the security projection still points to revision 18.

• The security reviewer must check the required source revision or retrieve the new authoritative rule.
• A compaction worker creating a projection from revision 18 must not overwrite a validated revision-19 projection.
• Use compare-and-swap or immutable versioned views and atomic pointers.
• For event-log designs, a view may cover an earlier watermark if the consuming agent also receives a complete, authorized event tail through the required read boundary.

Different context views must not become inconsistent copies of truth.

LangGraph and Celery integration

In LangGraph, keep durable workflow state and shared-memory records separate from the prompt assembled for each node. Each agent node can read the canonical core and its authorized role-specific projection, then retrieve exact evidence as needed. Store projection IDs and source revisions in traces for reproducibility.

With Celery, build projections as idempotent jobs keyed by tenant, workflow, role, and source revision. Coalesce duplicate rebuild requests, but validate revisions before activating results; an old retry must not replace a newer view. Ensure queue messages carry compatible role and version metadata.

Trade-offs and common mistakes

• Single summary for everyone: Simple, but it may hide details required by specialist agents.
• Independent summaries with no shared core: Flexible, but contradictory facts and approvals can appear across roles.
• Excessive specialization: Many projections increase storage, refresh cost, and invalidation complexity.
• Over-sharing: Sending every specialist view to all agents increases tokens and may violate least privilege.
• Trusting a stale projection: A compact view can be well-formed yet outdated; check authoritative revisions before critical actions.

A good baseline is one verified core and only the specialized projections that show measurable quality or efficiency benefits.

Difference from earlier lessons

• Q165: Explains context sharing between agents generally.
• Q227–230: Cover compaction implementation, preservation, evaluation, and triggers.
• Q231–234: Cover concurrent updates, failure recovery, audit/version history, and deletion.
• This lesson: Designs different authorized compact contexts for different agent roles, while retaining one authoritative shared core.

In short

Give every agent the context it needs—not all the context available. Maintain a verified common core, tailor compact projections by role, preserve exact evidence references, and enforce revision and permission checks before each critical handoff.