Context management research findings 2026

Purpose

This document is the research dossier for turning Vox context handling into a state-of-the-art system across:

• multi-session chat,
• zero-shot and retrieval-gated task execution,
• agent-to-agent handoff,
• MENs and Populi federation,
• search-tool selection and corrective retrieval,
• context conflict resolution, lineage, and observability.

It is a synthesis document, not a claim that every recommended behavior is already shipped.

Executive summary

Vox already has a stronger context foundation than many agent stacks:

• vox-mcp persists session-scoped chat history and retrieval envelopes.
• vox-orchestrator can attach session retrieval context or run native shared retrieval.
• vox-search already unifies lexical, vector, hybrid, verification, Tantivy, and Qdrant paths.
• vox-populi already provides durable remote A2A delivery, lease semantics, and remote task envelopes.
• Socrates already provides a risk-aware gate with citation, contradiction, and evidence-quality signals.

The main gap is not absence of parts. It is absence of a single canonical context contract and a single policy plane deciding:

1. what context exists,
2. which context should be injected now,
3. when search should run instead of trusting memory,
4. how remote agents should receive context safely,
5. how conflicts should merge or escalate,
6. how the entire lifecycle should be observed and evaluated.

The recommendation of this research pass is to introduce a canonical ContextEnvelope contract, treat session, retrieval, task, and handoff data as variants of that contract, and then centralize search, compaction, conflict-resolution, and telemetry policy around it.

Current Vox baseline

Context-bearing surfaces in the current repo

Baseline code-grounded observations

1. vox-mcp stores session retrieval evidence under retrieval_envelope:{session_id} and chat history under chat_history:{session_id}. This is the current bridge between chat context and task context.
2. vox-orchestrator tries attach_session_retrieval_envelope_if_present(...) first, then falls back to attach_goal_search_context_with_retrieval(...), and finally to heuristic-only search hints when no DB-backed retrieval is available.
3. vox-search already supports a richer retrieval model than the rest of the platform currently exposes. In practice, context quality is limited more by policy and handoff shape than by retriever capability.
4. vox-populi has durable A2A and lease semantics, but the remote wire contract still treats context as opaque payload text. That prevents safe, structured interoperability for multi-turn or multi-agent context sharing.
5. Socrates already has the beginnings of a useful evidence gate, but the gate consumes multiple upstream envelope shapes instead of a single normalized context artifact.

Second-pass critique of the initial blueprint

The first version of this program was directionally correct, but several assumptions were still too optimistic or too compressed.

Pressure-tested assumptions

Code-backed hazards the blueprint must account for

1. Remote relay ordering hazard: in crates/vox-orchestrator/src/orchestrator/task_dispatch/submit/task_submit.rs, remote lease/relay flow is constructed before attach_session_retrieval_envelope_if_present(...) or attach_goal_search_context_with_retrieval(...) runs. That means remote workers cannot currently rely on retrieval context being present merely because the local task later acquires it.
2. Handoff continuity gap: crates/vox-orchestrator/src/handoff.rs and crates/vox-orchestrator/src/orchestrator/agent_lifecycle.rs do not model session_id, thread_id, or retrieval-envelope references as first-class handoff invariants.
3. Policy duplication gap: crates/vox-search/src/bundle.rs, crates/vox-orchestrator/src/mcp_tools/memory/retrieval.rs, and orchestrator submit paths share concepts but still keep parallel trigger and envelope mapping logic.
4. Compaction surface ambiguity: the repo has memory and transcript systems, but no single clear runtime owner for long-horizon conversation compaction and reinjection.
5. Explicit retrieval asymmetry: crates/vox-orchestrator/src/mcp_tools/tools/task_tools.rs only attaches explicit retrieval after submit when the caller provided it, so the local MCP submission path is less unified than the first blueprint implied.

Corrections to the program shape

The improved version of this program should therefore prefer:

1. shared contract before shared crate,
2. ordering fixes before remote feature expansion,
3. handoff identity work before remote enforce,
4. minimal conflict vocabulary early, full conflict engine later,
5. compaction ownership design before compaction implementation,
6. explicit scope tags for deferred work such as web corpus execution.

External research synthesis

Production context-engineering patterns

The strongest recurring guidance from Anthropic, OpenAI, LangGraph, LlamaIndex, MemGPT, and related literature is consistent:

• treat context as a scarce working-memory resource, not a dump of everything available,
• maintain a hierarchy of short-term, episodic, semantic, and procedural memory,
• prefer just-in-time retrieval over loading everything eagerly,
• compact or summarize long histories aggressively but with lineage,
• isolate sub-agents so they return distilled findings instead of raw exploration traces,
• add corrective retrieval when evidence is weak, contradictory, or stale,
• instrument the whole context lifecycle so context bugs can be debugged like distributed systems bugs.

Retrieval-specific findings

The most relevant retrieval research for Vox is not generic “use RAG.” It is policy and correction:

• Self-RAG supports retrieval on demand rather than mandatory retrieval every turn.
• CRAG adds a retrieval evaluator and corrective fallback path when evidence quality is low.
• RRF / RAG-Fusion remains a robust default for merging lexical and vector evidence without brittle score normalization.
• Production systems consistently recommend hybrid lexical + vector retrieval because vectors miss exact identifiers and BM25 misses paraphrase and semantic intent.

Distributed agent findings

The most important interoperability takeaway is that MCP and A2A solve different layers:

• MCP is the agent-to-tool plane.
• A2A is the agent-to-agent plane.

Vox already has both layers. The missing piece is a contract that lets the same context object move cleanly between them.

Observability findings

OpenTelemetry GenAI conventions are converging around:

• explicit conversation IDs,
• agent IDs and agent names,
• tool invocation spans,
• retrieval spans,
• token accounting,
• model/provider metadata,
• optional capture of input messages, tool definitions, and system instructions.

For Vox, this means context should be instrumented as a lifecycle, not as disconnected log lines.

Design goals

1. No context bleed by default. Session, thread, workspace, agent, and node scope must be explicit.
2. Search only when justified. Retrieval should be policy-driven, not an accident of which surface was used.
3. Structured remote handoff. Cross-node and cross-agent context must survive transport boundaries.
4. Conflict safety. Contradictory context must merge deterministically or escalate.
5. Observability by construction. Every context decision must be explainable after the fact.
6. Backward-compatible rollout. New contracts must be additive and support adapters from current shapes.
7. Ordering correctness before capability growth. Context must be attached at the right time before it can be relied on remotely.
8. Avoid premature monoliths. Shared vocabulary and contracts come before centralizing all policy code into one module or crate.

Recommended canonical contract

ContextEnvelope

Machine-readable schema:

• contracts/communication/context-envelope.schema.json

The envelope is the recommended normalization layer for:

• chat turn carry-forward,
• compacted session summaries,
• retrieval evidence,
• task submit context,
• agent handoff context,
• remote execution context,
• policy hints and structured notes.

Required dimensions

Recommended envelope variants

Adapter mapping

Current shape -> target shape

Compatibility modes

1. Adapter-first mode: current producers keep emitting legacy payloads while new consumers normalize them.
2. Dual-write mode: producers emit both legacy payloads and ContextEnvelope.
3. Canonical-write mode: ContextEnvelope becomes source of truth; legacy forms become derived projections.

Session identity model

Canonical identity dimensions

Anti-bleed invariants

1. The system must never rely on "default" as a stable long-lived multi-window identity.
2. Task submission must carry or derive the current session_id whenever user-visible continuity is expected.
3. Handoffs must preserve both session_id and thread_id; otherwise they are context resets and should be labeled as such.
4. Remote execution payloads must include context lineage, not just task description text.
5. Compaction outputs must preserve the root session and thread identifiers.

Search decision policy

When to trust memory vs when to search

Recommended gating ladder

1. No retrieval for low-risk, purely local reasoning tasks.
2. Heuristic retrieval when intent suggests code navigation, repo structure, or factual lookup.
3. Verified retrieval when risk tier or evidence shape requires it.
4. Corrective retrieval when contradiction ratio is high, coverage is narrow, or evidence is stale.
5. Escalation or replan when corrective retrieval still leaves the task under-grounded.

Recommended policy signals

The retrieval policy engine should decide using:

• declared task risk tier,
• session age and compaction generation,
• evidence freshness,
• contradiction ratio,
• source diversity,
• whether remote execution or handoff is involved,
• whether the task claims facts about code, environment, or external systems.

Improvement over the first draft: remote context

The first blueprint treated a central retrieval-policy engine as mostly organizational work. The code review shows it is also a dependency and crate-boundary problem. The safer plan is:

1. define a shared policy contract,
2. preserve current call-site ownership temporarily,
3. add parity tests proving equivalent behavior across MCP and orchestrator,
4. only then extract common logic into a shared implementation surface.

Corrective retrieval loop

Vox should adopt a CRAG-style correction stage around the existing vox-search pipeline.

Proposed loop

flowchart LR
request[Request] --> plan[SearchPlan]
plan --> retrieve[HybridRetrieve]
retrieve --> assess[AssessEvidence]
assess -->|good| inject[InjectContext]
assess -->|weak_or_contradictory| rewrite[RewriteQueryOrCorpora]
rewrite --> retrieve2[CorrectiveRetrieve]
retrieve2 --> decide[GateOrEscalate]
decide --> inject
decide --> ask[AskOrReplan]

Trigger conditions

Run corrective retrieval when any of the following are true:

• contradiction_count > 0,
• source_diversity <= 1 for a high-risk task,
• evidence_quality < threshold,
• citation_coverage < threshold,
• recommended_next_action indicates retry, broaden, or verify.

MENs and Populi integration

Current role of MENs and Populi

Today MENs and Populi primarily contribute:

• visibility,
• remote durable A2A transport,
• inbox leases,
• remote execution lease support,
• routing hints and node metadata.

The missing part is context shape.

Improvement over the first draft: merge architecture

The first draft understated the degree of ordering and authority work required here. Remote context delivery is not just “add more fields to the envelope.” It requires:

• moving context assembly earlier in the submit path,
• deciding whether remote handoff uses embedded envelopes or durable artifact refs,
• defining who owns context freshness after relay,
• reconciling remote results with lease lineage and local task authority.

Recommended remote context rules

1. Remote A2A payloads should carry ContextEnvelope or a durable artifact reference to one.
2. Remote task envelopes should include session/thread/task lineage and evidence references, not just task description.
3. Lease holders must be recorded alongside context lineage so remote results can be reconciled to the same authority chain.
4. Remote workers should be allowed to send A2ARetrievalResponse back as first-class evidence, not only opaque task results.

Recommended remote retrieval flow

Conflict taxonomy and merge policy

Conflict classes

Merge strategy recommendations

Rust-native implementation options

Recommended crate posture

Recommendation

Do not rebuild the entire context system as a CRDT platform. Most Vox context is not collaborative text editing. The better split is:

• event sourcing for lineage and replay,
• precedence and confidence rules for merge semantics,
• selective CRDT use only where concurrent peer mutation truly exists,
• graph modeling for provenance and dependency traversal.

Improvement over the first draft

The earlier blueprint was correct to avoid a CRDT-everywhere design, but it did not emphasize enough that event sourcing and provenance should be introduced before sophisticated merge mechanics. For Vox, replayability and auditability are more urgent than peer-to-peer convergence on most paths.

Observability model

Required span and event families

OpenTelemetry alignment

The following OpenTelemetry GenAI fields are especially relevant:

• gen_ai.conversation.id,
• gen_ai.agent.id,
• gen_ai.agent.name,
• gen_ai.operation.name,
• gen_ai.request.model,
• gen_ai.usage.input_tokens,
• gen_ai.usage.output_tokens,
• retrieval and tool-execution spans associated with the same conversation.

Evaluation harness recommendations

Deterministic benchmark families

1. Session continuity: a fact introduced in one turn remains available after compaction.
2. Bleed prevention: two concurrent sessions do not cross-pollinate chat or retrieval context.
3. Search policy correctness: high-risk tasks search when they should and avoid unnecessary search when they should not.
4. Corrective retrieval: contradiction or weak evidence triggers retry, broaden, or escalation.
5. A2A integrity: sender and receiver share the same session/thread/task lineage after handoff.
6. Remote execution integrity: remote result correlates to the same context authority and lease lineage.

Minimum metrics

Recommended target architecture

flowchart LR
input[UserOrAgentInput] --> policy[ContextPolicyEngine]
policy --> sessionStore[SessionAndEnvelopeStore]
policy --> searchRouter[SearchDecisionPolicy]
searchRouter --> recall[MemoryRecall]
searchRouter --> hybrid[HybridSearch]
searchRouter --> corrective[CorrectiveRetrieval]
policy --> compactor[CompactionAndNotes]
policy --> orchestrator[OrchestratorTaskSubmit]
orchestrator --> handoff[HandoffAdapter]
handoff --> populi[PopuliA2ARelay]
populi --> remote[RemoteWorker]
remote --> response[EvidenceOrResultEnvelope]
response --> socrates[SocratesGate]
socrates --> execution[Execution]
execution --> telemetry[TelemetryAndEval]
telemetry --> policy

Architectural conclusion

The system should converge on:

• one canonical envelope,
• one session identity model,
• one shared context policy vocabulary,
• one retrieval decision ladder,
• one conflict-resolution taxonomy,
• one telemetry vocabulary.

The current Vox stack already has enough infrastructure to support this, but the code review shows that rollout must proceed in a stricter order than the first blueprint implied: contract -> identity -> ordering fixes -> telemetry -> shared policy parity -> remote expansion -> enforcement.

Related implementation documents

• Context management implementation blueprint
• Context management phase 1 backlog
• Plan adequacy (thin plans & telemetry)
• Mesh / Populi SSOT (CPU-first)
• Socrates protocol — single source of truth

External references

• Anthropic: Effective context engineering for AI agents
• OpenAI: Compaction and context management
• A2A and MCP: complementary protocols
• Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
• Corrective Retrieval Augmented Generation
• OpenTelemetry GenAI semantic conventions