ACP in the Research-Verification Loop

Agent Client Protocol as a Universal Substrate for neXus Layer 3

Author
Affiliation

SSCCS Foundation

SSCCS Foundation

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

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.

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.

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