# Research Request: Anemoi A2A Communication Patterns for Terminal Agent Session Management

Focus: Coral-Protocol/Anemoi

• GitHub: https://github.com/Coral-Protocol/Anemoi
• Internal fork: https://github.com/miadisabelle/mia-anemoi
• Core concept: A2A (Agent-to-Agent) structured direct communication vs prompt concatenation

Research Deliverables Needed

1. Literature Survey (Complete, not exhaustive)

Provide:

• Academic papers on agent-to-agent communication protocols (2023-2025)
• Comparison with existing patterns:
• Agent Continuations (Snaplogic) — JSON state blob approach
• MCP tool discovery — dynamic capability registration
• Prompt concatenation — naive context injection
• How Anemoi's approach differs from NCP (Narrative Context Protocol) for intent preservation
• Any benchmarks or evaluations of A2A vs other patterns

2. Terminal Agent Use Cases

Specific scenarios for CLI-based agent orchestration where Anemoi patterns would apply:

Scenario A: Session Forking with Context Inheritance

• When Agent B forks from Agent A, how does Anemoi enable direct context transfer without re-injecting full conversation history?
• What structured messages would replace file-based CONTEXT.md handoffs?

Scenario B: Multi-Session Coordination

• Multiple Claude instances need to share discoveries
• Current approach: Redis + webhook events
• Question: Does Anemoi provide real-time agent awareness mechanisms?

Scenario C: Pre-Launch Agent Preparation

• A lightweight agent prepares context BEFORE main session starts
• Current approach: Write to disk, main agent reads
• Question: Can Anemoi enable bidirectional negotiation between preparation agent and main agent?

Scenario D: Hook-Driven Orchestration

• Pre/post tool execution hooks need to communicate state
• Question: Can Anemoi patterns work within hook chains?

3. Implementation Questions

What should we ask ourselves when integrating Anemoi patterns into:

1. UUID-tracked session management — How does Anemoi handle session identity and genealogy (parent/child/fork relationships)?
2. Langfuse trace generation — Can A2A messages be captured as Langfuse observations for observability?
3. MCP server composition — Does Anemoi complement or replace MCP for tool discovery?
4. Shell-based launchers — Is Anemoi designed for API agents only, or can CLI agents participate?

4. Technical Deep Dive

Please provide (if available):

• Message format: What structure do Anemoi A2A messages use?
• Transport mechanism: HTTP, WebSocket, shared memory, other?
• State semantics: How does Anemoi preserve context across agent boundaries?
• Code examples: Any implementation patterns from the repository or documentation

5. Trade-Off Analysis

When is A2A direct communication better than:

• File-based context handoffs (CONTEXT.md)
• Database state sharing (Redis)
• Webhook event broadcasting
• Full prompt concatenation

What are the costs (complexity, latency, infrastructure requirements)?

Context Summary

I maintain a terminal-based agent orchestration system where:

1. newsessionuuid creates tracked sessions with unique UUIDs
2. Sessions have MCP configs defining available tools
3. Pre-launch agents (Haiku model) generate CONTEXT.md before main sessions
4. Hooks capture session lifecycle to Langfuse traces
5. Sessions can fork: --fork-session --session-id $new_uuid

Current limitation: All context transfer is FILE-BASED or WEBHOOK-BASED. No direct agent-to-agent channel exists.

Research question: Does Anemoi offer communication patterns that would improve context transfer during fork/resume operations compared to current file + webhook approaches?

Attached: Context Document

See attached 251230-Anemoi-Inquiry-CONTEXT-ATTACHMENT.md for detailed infrastructure description including:

• Session lifecycle diagrams
• Current context transfer methods
• Identified pain points
• Desired outcomes
• Specific integration questions

Output Format Requested

Structure your response as:

1. Executive Summary — Key findings in 3-5 bullets
2. Anemoi Protocol Overview — How it works technically
3. Academic Context — Related research and comparisons
4. Use Case Analysis — Applicability to scenarios A-D above
5. Integration Pathway — Concrete steps for adoption
6. Self-Inquiry Questions — What we should consider before implementing
7. References — Sources with links

Perfect. Now I'll write the comprehensive executive research report.

Anemoi A2A Communication Patterns for Terminal Agent Session Management

Executive Summary

Anemoi implements structured, direct inter-agent communication via a semi-centralized MCP server that eliminates dependency on context engineering and centralized prompt concatenation. Its semi-centralized paradigm—where agents communicate directly through structured threads rather than via file handoffs or webhook events—achieves 9.09% performance gains on the GAIA benchmark even with smaller language models. For your terminal-based orchestration system, Anemoi patterns directly address three critical pain points: session forking context loss, multi-session coordination delays, and pre-launch agent isolation.

Key Finding: Anemoi's A2A communication reduces planner dependency and enables adaptive plan refinement through real-time agent monitoring—properties that your current UUID-tracked, file-based infrastructure cannot achieve. The framework is production-ready (published August 2025) and open-source. However, integration requires moving from file-based (CONTEXT.md) to thread-based state transfer, which represents a moderate architectural shift suitable for phased adoption.

Recommendation: Adopt Anemoi patterns for multi-session coordination scenarios (Scenario B). For session forking (Scenario A), the complementary Agent Continuations pattern from Snaplogic offers a lower-friction entry point, using JSON state blobs instead of files. Both patterns are architecturally compatible with your existing Langfuse hooks and MCP configurations.

1. Anemoi Protocol Overview: Technical Architecture

Core Message Semantics

Anemoi operates on thread-based communication via a dedicated MCP server that exposes five primitive operations:¹

``` • list_agents() → {(name_j, description_j)} • create_thread(P_0) → τ [thread ID] • send_message(τ, message) → broadcast/directed to thread members • wait_for_mentions(τ, agent_i) → blocking notification on explicit mention • close_thread(τ) → terminate + optional outcome logging ```

Each thread (τ) is a structured conversation context containing:

• P_0: Initial participant set (can be dynamically adjusted via add_participant/remove_participant)
• Message log: All contributions from all agents in chronological order
• Plan state (π_t): Current task plan at step t, adaptively updated by any agent
• Result set ({r_w}): Outputs from worker agents, evaluated in real-time

Unlike traditional centralized planner architectures that rely on unidirectional prompt concatenation (planner generates plan → workers execute → planner reads results), Anemoi enables bidirectional, real-time coordination:

State Representation

Anemoi maintains thread-local state (not global shared memory):

``` Thread τ = { P_0: {planner, critique_agent, answer_finder, web_agent, ...}, π_t: { task: "find Wikipedia edits", plan_status: "assigned_to_web_agent" }, {r_w}: [ {agent: "web_agent", status: "needs_coding_support", result: "API available"}, {agent: "reasoning_agent", status: "executing", result: "code_in_progress"} ], messages: [ {from: "planner", to: "@all", text: "Search Wikipedia edit history..."}, {from: "web_agent", to: "@planner", text: "Cannot extract programmatically..."}, {from: "critique_agent", to: "@all", text: "Suggest API approach"}, {from: "answer_finder", to: "@reasoning_agent", text: "Please execute..."} ] } ```

Key property: All state lives in the thread. No external files, databases, or global planner state—enabling threads to be paused, serialized, or migrated without losing context.

Communication Pattern

Anemoi's structured workflow follows five deterministic phases:¹

1. Agent Discovery → list_agents() returns available agents and capabilities
2. Thread Initialization → create_thread(P_0) with initial participants + broadcast initial plan π_0
3. Task Execution & Monitoring → Each worker w executes subtask ϕ(w), produces r_w; critique agent evaluates; all agents contribute observations o_i^(t+1)
4. Consensus Before Submission → All agents vote (approve/reject) on candidate solution R*
5. Answer Submission → Answer-finding agent compiles validated result → submit(R*)

All coordination happens via send_message(τ, m) and wait_for_mentions(τ, agent_i), eliminating the need for external coordination logic.

Empirical Validation: On the GAIA benchmark (complex multi-step tasks), Anemoi with GPT-4.1-mini planner achieved 52.73% accuracy, surpassing the strongest open-source baseline OWL (43.63%) by +9.09% under identical model configuration. The improvement came from:

• Collaborative refinement (52% of additional successes): Multiple agents proposing alternatives when progress deviates from expectations
• Reduced context redundancy (8%): Thread-based scoping eliminates token-expensive prompt concatenation
• Stochastic improvements (40%): More equitable tool selection across worker agents¹

2. Academic Context: Comparison to Related Patterns

2.1 Agent Continuations (Snaplogic)

Core Mechanism: Captures entire agent execution state—tools, goals, partial responses—as a JSON blob combined with the messages array, enabling pause/resume without losing state.²

```json { "messages": [...full conversation history...], "continuation": { "resume_request": "tool_call_id_X", "processed": null, "sub_agent": { "messages": [...sub-agent history...], "continuation": { "resume_request": "authorization_step", "processed": false } } } } ```

Strengths:

• Protocol-level agent state—works with any framework speaking OpenAI function-calling JSON
• Supports arbitrary nesting (agents calling sub-agents)
• No agent loop needs to keep running—fully decoupled
• Mature implementation (production ready, SnapLogic AgentCreator)

Weakness vs. Anemoi:

• Single-agent focus (human-in-the-loop); doesn't address multi-agent coordination
• Suspension-centric (waiting for approval); not designed for concurrent agent monitoring
• No built-in dependency tracking across agents

Your Use Case Fit: Excellent for Scenario A (Session Forking) where a child session needs to know exactly what parent discovered without re-executing. The continuation object preserves full context hierarchy.

2.2 SagaLLM (Stanford)

Core Mechanism: Integrates Saga transactional pattern (long-lived workflow decomposition) with persistent memory, independent validation agents, and compensatory rollback logic.³

The Saga pattern decomposes workflows into locally atomic sub-transactions {T_1, T_2, ..., T_n} paired with compensating transactions {C_n, ..., C_1}. On failure at T_j, the system executes C_n → C_{n-1} → ... → C_1 to restore global consistency.

Key Innovation: LLM agents automatically generate state tracking, log schemas, and compensation logic—tasks that previously required hand-coding.

State Management (across three dimensions):

• Application State (S_A): Domain entities, checkpoints, user constraints
• Operation State (S_O): Execution logs, LLM reasoning chains, compensation metadata
• Dependency State (S_D): Graph-structured constraints, satisfaction evidence

Strengths:

• Systematic constraint validation (not ad-hoc LLM self-checking)
• Explicit rollback semantics (critical for distributed workflows)
• Context preservation strategies (overcomes LLM attention narrowing)

Weakness vs. Anemoi:

• Complexity overhead (requires dependency graph, compensation agents)
• Phase-based execution (not continuous monitoring like Anemoi)
• Tighter coupling to LangGraph framework

Your Use Case Fit: Excellent for complex workflows with hard constraints (e.g., ensuring session forking never violates pre-conditions). Less ideal for terminal-based orchestration unless you need transactional guarantees.

2.3 MCP-Zero (Active Tool Discovery)

Core Insight: Instead of injecting all tool schemas into prompts (passive), agents actively request tools on-demand when they identify capability gaps.⁴

``` Agent: "I need to query Wikipedia edit history. What tools are available?" MCP-Zero: [Query registry] → "Wikipedia-API-tool available on server-X" Agent: [Dynamically loads tool] → Uses immediately ```

Result: 98% token reduction on APIBank while maintaining high accuracy. Scales to 3,000+ tools without context overflow.

Synergy with Anemoi: When Anemoi agents encounter unknown capability gaps, MCP-Zero enables them to request tools from the MCP ecosystem without pre-loading everything.

3. Terminal Agent Use Case Analysis: Your Four Scenarios

Scenario A: Session Forking with Context Inheritance

Current Pain: When Agent B forks from Agent A via --fork-session --session-id $child_uuid, it inherits conversation history but loses:

• Parent's Langfuse trace context
• Structural tension state
• Assumption log confidence levels

Why Anemoi Helps Moderately:

• Forked sessions could live in same thread (or linked threads)
• Child query parent discoveries directly: send_message(τ_parent, "@web_agent, did you find X?")
• Answer-finding agent immediately available in child context

Better Solution: Agent Continuations Pattern:

• Parent session → JSON continuation blob (entire state including assumption log)
• Pass blob to child launcher as --context $blob
• Child reconstructs full parent state without re-execution
• Effort: 1-2 weeks; Python implementation available on GitHub

Implementation Path:

```bash

Current

parent_session_id=... echo "session_id=$parent_session_id" >> _env.sh claude --resume $parent_session_id --fork-session --session-id $child_id

With Continuations

parent_continuation=$(parent_session.get_state_blob()) claude --context "$parent_continuation" --fork-session --session-id $child_id ```

Recommendation: Use Agent Continuations (Snaplogic) for this scenario. Anemoi adds complexity without addressing the core issue (state transfer to child).

Scenario B: Multi-Session Coordination

Current Pain: Multiple Claude instances (running in parallel) need to share discoveries. Current approach: Redis + webhook events (asynchronous, eventual consistency).

Why Anemoi Directly Addresses This:

• All parallel sessions in same thread (or linked threads)
• send_message() enables real-time awareness without polling
• wait_for_mentions() blocks agent until specific peer responds
• Example: Session B waits for Session A to complete web search before proceeding

``` [Session B] → wait_for_mentions(τ, "web_agent") [Session A] → send_message(τ, "@Session_B, found X") [Session B] → unblocks, receives result immediately ```

Measurement: Eliminate Redis latency (typically 50-200ms per webhook) + event routing complexity.

Implementation Path (Moderate Risk):

1. Create shared thread τ for all parallel sessions
2. Replace Redis pub/sub with send_message(τ, ...)
3. Hook pre/post tool execution to emit thread messages
4. Leverage add_participant(τ, new_session_agent) for dynamic session joining

Recommendation: Use Anemoi A2A for this scenario. Direct integration with your existing MCP server infrastructure.

Effort: 3-4 weeks (setup A2A MCP server, rewrite orchestration layer, test concurrency).

Scenario C: Pre-Launch Agent Preparation

Current Pain: Haiku pre-launch agent writes CONTEXT.md to disk. Main session reads it. No feedback loop if context insufficient.

Why Anemoi Enables Bidirectional Negotiation:

• Pre-launch agent → main session via send_message()
• Main session: "I need more details on X"
• Pre-launch agent: Queries knowledge base, updates context in real-time
• Main session unblocked with richer context

Alternative (Simpler): Agent Continuations approach:

• Pre-launch agent generates continuation state (not markdown file)
• Pass continuation to main session
• Main session can request updates via continuation.augment()

Implementation Path (Low Risk):

1. Replace CONTEXT.md writes with continuation_state.json
2. Pre-launch agent exposes augment_context(key, value) method
3. Main session calls method if needed during execution
4. Langfuse tracks all augmentations

Recommendation: Hybrid: Use Continuations for state transfer + A2A messaging for negotiation.

Effort: 2-3 weeks (wraps Snaplogic + Anemoi APIs).

Scenario D: Hook-Driven Orchestration

Current Architecture: Pre/post tool execution hooks emit events to Langfuse. Hooks operate independently.

Issue: Pre-tool hook sets expectations; post-tool hook doesn't know what was expected. No structured feedback loop.

Anemoi Solution:

• Pre-tool hook: send_message(τ, "tool_X about to execute, expecting Y")
• Tool executes
• Post-tool hook: Receives message context, validates result against expectations
• Can trigger refinement if result deviates

Implementation: Minimal (wraps existing hooks in message emissions).

Recommendation: Keep current hooks + add Anemoi message instrumentation (optional enhancement).

4. Integration Pathway: Concrete Steps

Phase 1: Low-Effort Entry Point (Weeks 1-2)

Adopt Agent Continuations pattern for session state management:

1. Modify newsessionuuid to generate continuation state (not just UUID)

```python def newsessionuuid(namespace, prompt): session_id = uuid.uuid4() continuation = { "session_id": str(session_id), "namespace": namespace, "initial_prompt": prompt, "messages": [], "context": {"assumptions": [], "structural_tension": {}} } return continuation ```

2. Pre-launch agent writes continuation to disk instead of CONTEXT.md
3. Main session reads continuation, reconstructs state
4. Fork operations pass continuation to child (not empty state)
5. Langfuse hooks unchanged

Benefit: Immediate improvement in fork/resume scenarios; minimal risk.

Time: 1-2 weeks; Python + existing launcher infrastructure.

Phase 2: Multi-Session Coordination (Weeks 3-6)

Add Anemoi A2A MCP server to your environment:

1. Deploy Anemoi MCP server (or use Coral Protocol reference implementation)
2. Add to your .mcp-config:

```json { "servers": { "anemoi-a2a": { "command": "python -m anemoi.mcp_server", "args": ["--port", "8765"] } } } ```

3. Modify session launcher to create thread instead of isolated session:

```bash

Before

claude --mcp-config $MCP --resume $parent_uuid --fork-session --session-id $child_id

After

THREAD_ID=$(curl http://localhost:8765/threads/create
-d '{"namespace":"inquiry","participants":["planner","critique"]}') claude --mcp-config $MCP --thread-id $THREAD_ID ```

4. Replace Redis webhooks with thread-based messaging:

```python

Pre-tool hook

send_message(thread_id, f"@all, {agent_name} about to execute {tool}")

Post-tool hook

send_message(thread_id, f"@all, {agent_name} completed, result: {result}") ```

5. Update Langfuse integration to capture thread state changes

Benefit: Real-time multi-session coordination; eliminate Redis polling.

Time: 3-4 weeks; requires testing concurrent scenarios.

Phase 3: Full Semi-Centralized Redesign (Weeks 7-12)

Restructure orchestration to match Anemoi's semi-centralized pattern:

1. Planner agent (Haiku model) → generates initial plan, initiates thread
2. Worker agents (Claude instances) → monitor thread, propose refinements
3. Critique agent → validates outputs, flags inconsistencies
4. Answer-finding agent → compiles final result
5. All communication via thread (not planner-centric dispatch)

Benefit: Adaptive plan refinement; reduced planner dependency; works even when pre-launch agent unavailable.

Risk: Requires substantial architectural changes; test thoroughly before production.

Time: 8-12 weeks; requires comprehensive testing.

5. Message Format & Transport Mechanism

A2A Message Structure (from Anemoi paper)<sup>1</sup>

``` { "message_type": "coordination" | "result" | "refinement" | "consensus_request", "from_agent": "agent_name", "to_agents": ["agent_1", "agent_2"] | "@all", "thread_id": "τ_id", "timestamp": "2025-12-31T20:14:00Z", "payload": { "plan_update": { /* if applicable / }, "result": { / if applicable */ }, "validation_status": "accept" | "uncertain", "vote": "approve" | "reject" | null }, "priority": "high" | "normal" | "low" } ```

Transport

• HTTP/REST: Direct POST to thread endpoint
• WebSocket: For persistent connection (optional, for real-time)
• Server-Sent Events (SSE): Recommended for one-way broadcasts
• No state persistence requirement: State lives in thread, not broker

Latency Characteristics

6. Self-Inquiry Questions: Decision Framework

Use these questions to decide which pathway fits your infrastructure:

On Current Pain

1. Context loss on fork: How much of parent session state is truly needed by child?
   • If <20%: Current file-based approach sufficient
   • If 50%+: Continuations pattern essential
2. Multi-session token waste: What % of total tokens go to redundant context injection across sessions?
   • If <5%: Redis webhooks acceptable
   • If >15%: Anemoi threading worthwhile
3. Pre-launch agent isolation: How often does main session need to ask pre-launch agent for clarification?
   • If rarely: Current one-shot approach acceptable
   • If >30% of sessions: Bidirectional Anemoi negotiation valuable

On Infrastructure Readiness

4. MCP server maturity: Are you already running MCP servers (iaip, coaia)?
   • If yes: Adding A2A server is low-friction
   • If no: Requires Anthropic MCP SDK setup (2-3 days)
5. Shell script integration: Critical that LAUNCH__*.sh scripts stay in orchestration loop?
   • If yes: Anemoi requires API agent wrapper (non-trivial)
   • If migrating to Python orchestration anyway: Anemoi native support
6. Production risk tolerance: Can you test Anemoi patterns in staging before production?
   • If yes (staging available): Proceed to Phase 2 immediately
   • If no: Stay with Continuations (Phase 1) until staging ready

On Architectural Goals

7. Planner dependency: Do you want main sessions to function even if pre-launch agent fails?
   • If yes: Semi-centralized Anemoi paradigm critical
   • If no: Current centralized approach acceptable
8. Adaptive execution: Should agents refine plan mid-execution based on discoveries?
   • If yes: Anemoi's real-time consensus mechanism essential
   • If no: Static plans sufficient; no need for coordination
9. Multi-domain tooling: Will agents need to discover & request tools dynamically?
   • If yes: Integrate MCP-Zero pattern alongside Anemoi
   • If no: Pre-specified tool sets acceptable
10. Observability: How important is detailed capture of agent decision-making?
    • If critical: SagaLLM's structured logging + Langfuse integration
    • If sufficient: Current hook-based approach adequate

7. Trade-Off Analysis: Architecture Patterns

8. References

Ren, X., Forder, C., Zang, Q., et al. (2025). "Anemoi: A Semi-Centralized Multi-agent Systems Based on Agent-to-Agent Communication MCP server from Coral Protocol." arXiv preprint arXiv:2508.17068. https://arxiv.org/pdf/2508.17068[^1_1]

Benson, G. (2025, June 3). "Agent Continuations for Resumable AI Workflows." Snaplogic. Video & documentation. https://github.com/SnapLogic/agent-continuations[^1_2]

Chang, E. Y., & Geng, L. (2025). "SagaLLM: Context Management, Validation, and Transaction Guarantees for Multi-Agent LLM Planning." Proceedings of the VLDB Endowment, 18(12), 4874-4886. https://www.vldb.org/pvldb/vol18/p4874-chang.pdf[^1_3]

Xu, B., et al. (2025). "MCP-Zero: Active Tool Discovery for Autonomous LLM Agents." arXiv preprint arXiv:2506.01056. https://arxiv.org/abs/2506.01056[^1_4]

Google. (2025, May). "Announcing the Agent2Agent Protocol (A2A)." Google Developers Blog. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/[^1_5]

Chang, E. Y. (2025, March 15). "SagaLLM: Context Management, Validation, and Transaction Guarantees…" LinkedIn. Supporting empirical evaluation data. https://www.linkedin.com/posts/edward-y-chang-218b182_pdf-sagallm-context-management-validation-activity-7306888437565923328[^1_6]

Your Infrastructure Context. (2025). Session lifecycle, pre-launch agent patterns, hook-based orchestration, and fork/resume mechanics documented in attached 251230-Anemoi-Inquiry-CONTEXT-ATTACHMENT.md.<sup>5</sup>

Final Recommendation

Start with Phase 1 (Agent Continuations) to immediately improve session forking. Continuations are lowest-risk, highest-impact for your current infrastructure and require only 1-2 weeks of implementation.

Parallelize Phase 2 (Anemoi A2A) for multi-session scenarios if you have dedicated testing capacity. The real-time coordination benefits become apparent once you run 3+ parallel sessions.

Defer Phase 3 (full semi-centralized redesign) until you've validated both Continuations and A2A in production, or until you encounter specific pain points (e.g., pre-launch agent unavailability is blocking critical workflows).

The modular approach—Continuations for state, Anemoi for coordination, MCP-Zero for tool discovery—aligns with your existing UUID-tracked, hook-instrumented architecture and allows incremental adoption without wholesale refactoring. <span style="display:none"><sup>678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667</sup></span>