# ACP in the Research-Verification Loop

Agent Client Protocol as a Universal Substrate for neXus Layer 3

Author

Affiliation

SSCCS Foundation [](mailto:contact@ssccs.org)

[SSCCS Foundation](https://ssccs.org)

Published

June, 2026

Abstract

This report analyses the Agent Client Protocol (ACP) — an open, provider-agnostic protocol for structured LLM interaction — as a universal communication substrate for the neXus Agentic Research Loop (Layer 3). ACP decouples agent logic from LLM backend choice, enables multi-model concurrent hypothesis validation, and standardises tool execution across heterogeneous execution contexts. Zed’s agent implementation serves as the representative reference for ACP integration.

Other Formats

[LLMs](https://docs.ssccs.org/projects/nexus/notes/acp_nexus.llms.md)

## Introduction

The neXus Agentic Research Loop (Layer 3) decomposes research questions, invokes tools, grounds hypotheses in evidence, and produces contract-compliant reports. The loop currently defines a Planner-Executor-Verifier-Generator pipeline. Expansion toward multi-backend GraphRAG benchmarking, concurrent hypothesis validation, and cross-reality experiment orchestration creates requirements that a single-pipeline architecture cannot easily satisfy:

- **Concurrent exploration.** Multiple hypotheses should be investigated in parallel rather than sequentially.
- **Specialised execution contexts.** Compiler analysis, physics simulation, and hardware-in-the-loop experiments each require different toolchains, environment variables, and network policies.
- **Graceful degradation.** A single long-running experiment should not block the entire research loop.

The Agent Client Protocol (ACP) is an open, provider-agnostic protocol designed to address these requirements at the communication layer. Unlike agent frameworks that assume a single orchestrator managing all tool calls, ACP defines a standardised interface between any LLM backend and any agent runtime. Any tool registered via ACP can be called by any LLM through any ACP-compliant client, and any agent can be backed by any LLM without custom adapters.

This report reviews ACP’s architecture against neXus’s Layer 3 requirements, assesses its role in enabling multi-model concurrent validation, and proposes an integration strategy.

## ACP Protocol Architecture

### Protocol Overview

ACP consists of two primary layers:

| Layer | Responsibility |
|----|----|
| **Transport** | JSON-RPC over WebSocket/HTTP/stdio, streaming response support, structured error reporting |
| **Schema** | Standardised tool definitions (input/output schemas), provider capability negotiation, context window management |

ACP does not prescribe a runtime topology. A single process may host both the ACP client and the LLM provider; or the client may connect to a remote provider. This flexibility allows neXus to deploy agents in whatever execution environment suits each task — container, serverless function, or direct process — while maintaining a uniform communication interface.

### Key Protocol Features

**Provider-agnostic tool definitions.** Tools are defined in JSON Schema and registered with the ACP-compliant LLM. Tool calls, responses, and errors follow a standardised format regardless of which LLM backend is in use. For neXus, a `search_kg` tool registered once works with any ACP-compliant provider — local quantised, cloud API, or code-specialised model — without per-provider adapter code.

**Streaming and partial responses.** ACP supports incremental response delivery, allowing agents to begin processing intermediate results before the full response arrives. This is critical for long-running research tasks where waiting for a complete LLM response would add unnecessary latency.

**Structured error propagation.** Errors carry provider-specific detail within a standardised envelope. An LLM context overflow, a tool execution timeout, or an authentication failure are all reported uniformly to the agent, which can then decide whether to retry, fall back to another provider, or report partial failure.

### Protocol Design: The Subprocess Model

ACP’s stdio transport — spawning an agent server as a subprocess and communicating via piped stdin/stdout with JSON-RPC 2.0 — is the protocol’s most consequential design decision. It yields three properties directly relevant to neXus:

**Containerisability without container coupling.** An ACP agent server is any executable that reads JSON-RPC on stdin and writes JSON-RPC to stdout. This is the simplest possible process contract. The agent can run as a bare process, inside a Docker container, or as a systemd service — the host makes no distinction. For neXus, agent isolation can start simple (subprocess per agent) and scale to container-level isolation when needed, with no change to the ACP communication layer.

**Persistence via process supervision.** Because the host spawns the agent, the host owns the lifecycle. If an agent process exits, the host detects the exit and can restart, fall back to another backend, or report partial failure. This inverts the reliability model of API-based agents: instead of trusting a remote service to stay up, the runtime treats agent processes as managed children with explicit failure semantics.

**Identical framing to MCP.** ACP uses the same JSON-RPC 2.0 framing as the Model Context Protocol (MCP). A neXus agent process can run both an MCP client (for tool access) and an ACP client (for LLM communication) over the same transport layer, sharing framing logic. The protocol separation — MCP for tool to agent, ACP for agent to LLM — is a clean architectural boundary.

### Relationship to Existing neXus Components

ACP does not replace any existing neXus component. It sits as a thin communication layer between the agent runtime and the LLM provider:

| Component | Role | ACP Relation |
|----|----|----|
| **Local LLM backend** | On-device inference | ACP-compatible via adapter or native support |
| **Agent runtime** | Tool execution, context management | Uses ACP to communicate with LLM; uses MCP for tool-to-agent communication |
| **R2 / KV mapping** | Persistence | Unchanged; agents write results regardless of which LLM backend served them |
| **Knowledge graph backends** | Tool-accessible via MCP | MCP handles tool to agent; ACP handles agent to LLM; protocol separation is cost-free |

### Reference Implementation: Zed

Zed’s agent panel serves as the primary reference implementation for ACP in a practical editing environment. Key architectural facts from the Zed codebase:

- Agent servers are native binaries spawned as child processes via `std::process::Command` with piped stdin/stdout/stderr. They are NOT Wasm extensions.
- ACP transport is line-delimited JSON-RPC over stdio. The `AcpConnection::stdio()` method in `crates/agent_servers/src/acp.rs` spawns the binary, wraps stdout and stdin in bidirectional JSON-RPC streams.
- The `AgentServer` trait (`crates/agent_servers/src/agent_servers.rs`) is the interface between Zed’s UI and any agent. `CustomAgentServer` handles external binaries registered in settings.
- The `AgentConnection` trait (`crates/acp_thread/src/connection.rs`) defines the session lifecycle: `new_session` to `prompt` to `cancel` to `close_session`.
- Zed already handles streaming text, tool calls, file edits, terminal execution, git checkpoints, and sub-agent spawning. The bridge only translates between ACP and FIH; all complex flow control stays in Zed.

This confirms that ACP is a genuine process-level protocol, not an in-process API. Any ACP-compliant binary can serve as a neXus agent runtime.

## Integrated Architecture

### ACP as neXus Agent Communication Backbone

Rather than replacing neXus Layer 3, ACP serves as the communication layer for all agent-LLM interactions. Each agent — whether a knowledge-base scout, a document synthesis researcher, or a simulation runner — communicates with its assigned LLM backend through ACP. This is not a Zed-specific design; any neXus peer uses ACP to connect to its LLM backend.

![](acp_nexus_files/figure-html/cell-6-output-1.svg)

### Agent Roles

| neXus Tool | Agent Role | ACP Communication Pattern |
|----|----|----|
| `search_kg` | Scout Agent | ACP tool call to LLM; LLM returns structured KG query result |
| `crawl_external` | Scout Agent | ACP streaming response for progressive URL fetch updates |
| `run_python` | Research Agent | ACP tool call; tool output returned as structured evidence |
| `generate_hypothesis_step` | Research Agent + Planner | ACP tool call proposing hypothesis links; Planner selects via contract |
| `feedback` | Synthesis Agent | ACP tool call for cross-validation; multiple evidence packets aggregated |

### Dispatch Model

The Planner produces a dispatch graph — a directed graph of agent assignments with dependency edges and LLM backend selection. The Planner is trained via Flow-GRPO, with an action space that includes backend assignment.

![](acp_nexus_files/figure-html/cell-7-output-1.svg)

The Planner’s action space expands from selecting individual tools to constructing dispatch graphs with backend assignment. This is a richer action space that the RL policy can learn to optimise over time — routing computationally cheap tasks to local models and complex synthesis to cloud backends.

## Validation Strategy

A multi-experiment campaign to validate ACP-based integration, each building on the previous.

### Experiment 1: Baseline Integration

**Objective:** Verify that an ACP-compatible agent can execute a neXus tool chain via stdio-based ACP and produce a valid evidence packet.

**Procedure:**

1.  Implement a minimal ACP host that connects via subprocess with piped stdin/stdout
2.  Host sends session/initialize to session/configure with a search_kg tool definition
3.  Host dispatches a knowledge-graph query task
4.  Agent writes result to the FIH blackboard as a Fact with provenance metadata
5.  neXus Verifier reads the Fact, computes support score

**Success criteria:**

- ACP handshake completes (capability negotiation verified)
- Agent executes tool call and writes valid Fact to the blackboard
- Fact schema matches Verifier’s expected format
- Round-trip time under 5 minutes

### Experiment 2: Multi-Backend Routing

**Objective:** Validate backend-agnostic routing: the same ACP host dispatches tasks to different LLM backends based on task type, without host-side code changes.

**Procedure:**

1.  Configure two ACP-compatible LLM backends: one local quantised, one cloud frontier
2.  Planner decomposes a research question into sub-tasks with backend hints
3.  KG query dispatched to local backend (low latency)
4.  Document synthesis dispatched to cloud backend (high quality)
5.  Compare evidence quality and latency between backends

**Metrics:**

| Metric | Target |
|----|----|
| Backend switch overhead | \< 500ms (capability negotiation) |
| Evidence quality parity | 80% agreement between local and cloud for KG queries |
| Latency reduction | Local backend serves KG queries 2x faster than cloud |
| ACP host code delta | Zero host-side changes when switching backend assignment |

### Experiment 3: Concurrent Multi-Agent

**Objective:** Validate that multiple ACP agent subprocesses communicate with different LLM backends concurrently, each via independent stdio pipes.

**Procedure:**

1.  Spawn 3 ACP agent subprocesses simultaneously with independent stdin/stdout pipes:
    - Agent A: KG queries (local backend)
    - Agent B: document synthesis (cloud backend)
    - Agent C: analysis (custom agent, compute-bound)
2.  The ACP host manages 3 concurrent JSON-RPC sessions
3.  Planner dispatches sub-tasks concurrently
4.  All agents write results to the FIH blackboard

**Success criteria:**

- All three agents produce valid Facts within expected time windows
- No JSON-RPC message cross-talk
- Total wall-clock time less than sum of sequential execution times

### Experiment 4: Failure Resilience

**Objective:** Demonstrate that ACP’s provider-agnostic design enables graceful fallback when one LLM backend fails.

**Procedure:**

1.  Configure agent with primary (cloud) and fallback (local) backends
2.  Inject simulated cloud API failure mid-request
3.  Agent detects failure via ACP error envelope, retries on fallback backend
4.  Record fallback latency overhead

**Metrics:**

| Metric | Target |
|----|----|
| Failure detection time | \< 2 seconds (ACP structured error propagation) |
| Fallback success rate | 90% of failed requests succeed on fallback |
| Evidence packet degradation | 90% of fallback-served packets contain complete results |

The evidence packet fields defined in the Agent Roles section (agent_id, llm_backend, latency_ms, token_cost, status) allow the Verifier to compare results across backends and proceed with partial data when a single backend fails.

## Production Readiness Assessment

### Strengths

**Protocol-level abstraction is proven at scale.** ACP follows the same architectural pattern as MCP but focuses on the agent-to-LLM interface rather than the tool-to-agent interface. This separation of concerns is independently implementable.

**Provider diversity without code changes.** Because ACP is provider-agnostic, neXus can mix LLM backends within a single research session: a local quantised model for quick KG retrievals, a cloud model for complex synthesis, and a specialised code model for compiler analysis — all through the same ACP interface.

**Tool schema standardisation.** JSON Schema-based tool definitions mean that any environment with JSON Schema tooling can author and validate tool definitions before deployment.

### Risks and Mitigations

| Risk | Impact on neXus | Mitigation |
|----|----|----|
| **Protocol version drift** | Agent-LLM communication may break if client and provider support different ACP versions | Pin ACP version in agent container image; negotiate capabilities at startup |
| **Streaming reliability under load** | Long-running synthesis tasks may lose partial responses | Local buffering with retry; evidence packets include `status: partial` if streaming was interrupted |
| **Provider-specific error semantics** | Inconsistent agent behaviour when switching providers | Define neXus-specific error classification layer mapping provider errors to standardised agent actions (retry, fallback, report) |
| **No SLA guarantees** | No inherent reliability guarantee for the communication channel | Deploy local backends for baseline reliability; cloud providers used for burst capacity |

### Assessment for neXus Context

ACP does not solve every infrastructure problem. It does not manage container lifecycle, handle storage, or orchestrate multi-agent workflows. But as a communication layer, it provides the standardised interface that makes the rest of the architecture provider-independent. The ability to route the same query to different LLM backends through a uniform protocol and compare results at the evidence packet level is a direct enabler of comparative analysis.

## Discussion

### Protocol Over Provider Lock-In

The central design choice behind ACP-based integration is that neXus should never be dependent on a single LLM provider. A research infrastructure that can only validate hypotheses through one model family inherits that provider’s biases, failure modes, and cost structure. ACP breaks this dependency at the protocol level: any ACP-compatible backend can serve any agent at any time, and the evidence packet schema captures the backend identity so that downstream analysis can account for provider-specific effects.

This is not merely a convenience feature. For neXus’s stated goal of boundaryless research validation, provider independence is a correctness requirement. A hypothesis validated only through one LLM family has unknown generalisability to other models. Multi-backend validation through ACP ensures that evidence packets carry provenance metadata enabling cross-model comparison.

### ACP vs. MCP: Protocol Roles

| Protocol | Direction | Role |
|----|----|----|
| **MCP** (Model Context Protocol) | Tool to Agent | Agent queries knowledge bases, executes code, accesses file systems |
| **ACP** (Agent Client Protocol) | Agent to LLM / Editor | Agent sends tool definitions to LLM, LLM returns tool calls, agent streams progress back |

Both protocols share the same wire format (JSON-RPC 2.0), making the implementation surface minimal. A neXus agent process runs both an MCP client (to access tools) and an ACP client (to connect to its LLM or editor).

### When ACP Adds Value

- Environments where multiple LLM backends are used interchangeably
- Agent implementations that need to be portable across runtime environments
- Experiments comparing model families on identical tool chains
- Deployments where agents run persistently on servers
- Any scenario where provider-agnostic tool definitions reduce integration overhead

### When ACP Is Unnecessary

- Tightly coupled single-backend prototypes (direct API calls suffice)
- Static deployments where the LLM backend never changes
- Initial development of the neXus Planner (can be trained on simulated trajectories without real LLM interaction)

### Relationship to Existing neXus Infrastructure

The proposed integration does not require changes to existing neXus components:

- **R2 bucket** remains the single source of truth; agents write results there
- **Sync worker** is unaffected; agent outputs are text artifacts like any other
- **Knowledge graph backends** continue as the primary retrieval layer; agents query them via MCP
- **Flow-GRPO** training pipeline ingests agent trajectories as additional training data; the `llm_backend` field enables per-backend reward analysis

The only new component is the ACP client library integrated into each agent runtime. No new infrastructure services are required.

## Conclusion

ACP offers a protocol-level abstraction for agent-LLM communication whose key property — provider independence — aligns directly with neXus’s requirements for multi-backend concurrent hypothesis validation. The key findings are:

1.  **Protocol-level abstraction decouples agent logic from LLM backend.** Tools defined once in JSON Schema work with any ACP-compatible provider, enabling neXus to mix local and cloud backends within a single research session.
2.  **Provider independence is a correctness requirement, not a convenience feature.** Multi-backend validation through ACP ensures evidence packets carry provenance metadata, enabling cross-model comparison and reducing provider-specific bias in research outcomes.
3.  **The integration surface is minimal.** ACP client library integration is the only new component; all existing neXus infrastructure remains unchanged.
4.  **Zed’s agent implementation serves as the reference** for how ACP operates in practice — a process-level protocol over stdio JSON-RPC, with full session lifecycle and bidirectional streaming.

The recommended next step is implementing an ACP client in a single agent runtime, connecting to a local LLM backend, and measuring whether the evidence packet protocol produces valid Verifier input.

------------------------------------------------------------------------

### References

- `agent-client-protocol` crate: <https://crates.io/crates/agent-client-protocol>
- Zed Agent Server extensions: <https://zed.dev/docs/extensions/agent-servers>
- AgentFlow: In-the-Flow Agentic System Optimization. arXiv:2510.05592
- HypoChainer: LLM + KG + Human Collaborative Hypothesis Generation. arXiv:2507.17209