AI Engineer · Published 2026-09-09

The Universal Remote Control for AI — Alex Hancock, Block

privateReview: unreviewedConfidence: high
ACPMCPagentprotocoljson-rpcinteroperabilityagent-client-protocolagent-harnesstransport-agnosticpermission-requests
Open on YouTube ↗

Summary

Overview

  • Speaker: Alex Hancock
  • Channel: AI Engineer
  • Main topic: Agent Client Protocol (ACP) as a universal interface/standard for AI client applications and agent harnesses.
  • Purpose: To introduce the Agent Client Protocol (ACP) as an open standard for client-agent communication, explain its architecture, demonstrate its flexibility across local and remote transports, and encourage community adoption to avoid vendor lock-in and improve AI user experience. Alex Hancock discusses the fragmentation in AI harness interfaces, noting that bespoke 1-to-1 client-to-harness connections limit ecosystem growth. While Model Context Protocol (MCP) successfully standardized agent tool execution, there is a lack of a standard for client software controlling agents. To address this, he introduces the Agent Client Protocol (ACP)—a joint standard created by JetBrains and Zed editors—that decouples editors from specific agent harnesses and enables bidirectional communication via JSON-RPC, supporting both local (stdio) and remote (HTTP/WS) transports.

Topic Map

The Problem with Harness Interfaces

  • Explanation: AI engineering ecosystems feature numerous great agent harnesses and tool protocols, but their interfaces to client applications are often custom or bespoke, sometimes restricted to a single 1-to-1 client application.
  • Key claims:
    • Harness interfaces are frequently custom or bespoke.
    • Many harnesses rely on a 1-to-1 client application relationship.
    • Analogy to the web: using one single browser protocol per website would fail; we need an open standard like the open web.
  • Examples:
    • Different labs and companies building custom clients for proprietary harnesses.
  • Terminology:
    • harness
    • bespoke interface
    • 1-to-1 client
  • Why it matters: Without standards, client-harness fragmentation hinders ecosystem growth and prevents users from swapping editors or tools freely.

The Success of Model Context Protocol (MCP)

  • Explanation: MCP successfully standardized how AI agents go out and do things (calling tools, reading resources and data in other systems). Everyone in the community benefits from MCP because thousands of servers exist and agents can connect to them universally.
  • Key claims:
    • MCP provides a good standard for agent tool execution and resource reading.
    • The most powerful aspect of MCP is widespread community adoption.
    • Thousands of servers exist for agents to connect to universally.
  • Examples:
    • Agents calling tools and taking actions across external systems via MCP.
  • Terminology:
    • MCP
    • Model Context Protocol
    • tool execution
  • Why it matters: Demonstrates that open standards create thriving ecosystems and markets in AI tooling.

Introducing Agent Client Protocol (ACP)

  • Explanation: ACP is an open standard proposed by Zed and JetBrains to solve the missing standard for client software telling agents what to do (giving tasks, setting work, and receiving updates).
  • Key claims:
    • ACP stands for Agent Client Protocol.
    • It was created in collaboration between editor companies like Zed and JetBrains.
    • Allows a single high-quality client implementation in an editor to control any agent harness.
  • Examples:
    • Writing a single client implementation in Zed or IntelliJ to control Goose, Codex, and other harnesses.
  • Terminology:
    • ACP
    • Agent Client Protocol
    • client implementation
  • Why it matters: It decouples editor implementations from specific agent architectures, allowing broader utility across neutral agent systems.

ACP Design and Capabilities

  • Explanation: ACP uses JSON-RPC to establish sessions between clients and agent harnesses, supporting user message transmission, agent responses, tool call notifications, permission requests, and custom extensible methods.
  • Key claims:
    • Establishes connections between clients and agent harnesses with associated capabilities.
    • Supports creating sessions, sending user messages (text, image, audio), and agent responses.
    • Handles tool call notifications and permission requests.
    • Built on JSON-RPC and is fully extensible with custom methods prefixed by underscores.
  • Examples:
    • A client asking the user 'Should I do this tool call? Yes or no'.
  • Terminology:
    • JSON-RPC
    • sessions
    • tool call notification
    • permission request
    • extensible
  • Why it matters: Extensibility and a common protocol allow different team implementations (Goose, Codex, etc.) to align on common methods.

Demos: Local (stdio) and Remote (HTTP/WS) Transports

  • Explanation: Demonstrates local stdio communication between Zed and Goose and between Foolside AI terminal client and Goose, followed by a remote HTTP/Websocket transport demo showcasing location-agnostic agent execution.
  • Key claims:
    • Local stdio demo shows multiple clients (Zed, Foolside AI) communicating with the same local agent harness.
    • Remote transport adds HTTP version and WebSocket upgrades to the same protocol semantics.
    • Enables moving client, harness, model, and tools freely across different machines or cloud containers.
  • Examples:
    • Typing 'Tell me about this project' in Zed using Goose agent.
    • Using Foolside AI terminal client to query the same Goose agent.
    • Connecting remotely via HTTP/WebSocket to execute 'Write a poem'.
  • Terminology:
    • stdio
    • WebSocket
    • HTTP transport
    • Foolside AI
    • Zed
  • Why it matters: Proves that the agent client protocol is transport-agnostic, supporting local development and remote cloud agent workloads equally well.

Key Points

Ecosystem Fragmentation in Harness Interfaces

  • Explanation: Many existing AI agent harnesses require custom, bespoke, or single-client interfaces, mirroring the early web if every website required its own custom browser.
  • Evidence: Observed variety of lab-specific and company-specific harness UIs.
  • Practical implication: Developers are locked into specific harnesses or forced to build custom client integrations.

ACP as the Counterpart to MCP

  • Explanation: While Model Context Protocol (MCP) standardized how agents access tools and data, Agent Client Protocol (ACP) standardizes how clients instruct agents.
  • Evidence: Collaboration between Zed and JetBrains editors.
  • Practical implication: Editor developers can write one ACP client implementation to control any compliant agent.

Transport Agnosticism and Flexibility

  • Explanation: ACP uses JSON-RPC and supports both local stdio and remote HTTP/WebSocket transports without changing message semantics.
  • Evidence: Live demos switching between Zed (stdio), Foolside AI terminal (stdio), and remote HTTP/WS clients.
  • Practical implication: Agents can run locally in containers or remotely in the cloud while interacting with any client seamlessly.

Frameworks, Models & Processes

Agentic Stack Components

  • How it works: Deconstructs agentic architecture into four interoperable pieces that can be distributed across machines or networks.
  • Components:
    • Client (user app / headless app)
    • Harness (tool calling loop program)
    • Tools (MCP / tool execution)
    • Model (AI provider endpoints)
  • When to use: When designing distributed, decoupled agent systems and establishing interface standards.

Examples & Case Studies

Alex demonstrates querying project structure in Zed editor using Goose via ACP over stdio.

  • Illustrates: Local interop between an editor client and an agent harness.
  • Lesson: Editors can seamlessly integrate AI agents without tight coupling.

Alex demonstrates switching to Foolside AI terminal client talking to the same Goose agent locally.

  • Illustrates: Client-agnostic agent control.
  • Lesson: Any client can control any agent harness that implements ACP.

Alex demonstrates a remote client connecting via HTTP/WebSocket to generate a poem using a remote agent.

  • Illustrates: Remote transport support in ACP.
  • Lesson: Agents running in cloud containers or remote servers use the exact same protocol semantics as local instances.

Actionable Takeaways

  • Immediate:
    • Explore the Agent Client Protocol (ACP) repository and documentation via the provided QR code.
    • Experiment with supporting ACP in your own client applications or agent harnesses.
  • Strategic:
    • Standardizing client-agent interfaces prevents vendor lock-in and fosters vibrant ecosystems.
    • Separating clients, harnesses, models, and tools enables flexible deployment architectures.
  • Questions to investigate:
    • How will editor adoption of ACP scale across major IDEs?
    • What security and permission paradigms will become standard for remote agent execution?

Claims Worth Verifying

  • ACP was created jointly by Zed and JetBrains text editor teams. (Factual)
  • ACP uses JSON-RPC messages and supports stdio, HTTP, and WebSocket transports. (Technical Architecture)

Notable Quotes

"The most powerful thing about MCP is not anything about MCP itself, but it's that everyone uses MCP." "ACP, agent client protocol, is the name of this project, and it came from the editor companies."

Compressed Summary

  • Agent harnesses suffer from bespoke, 1-to-1 client interface fragmentation.
  • Model Context Protocol (MCP) successfully standardized agent tool execution.
  • Agent Client Protocol (ACP), created by Zed and JetBrains, standardizes client-to-agent communication.
  • ACP uses JSON-RPC and supports both local stdio and remote HTTP/WebSocket transports.
  • Decoupling clients, harnesses, models, and tools drives ecosystem quality and prevents lock-in.
  • Keywords: acp, mcp, agent, protocol, json-rpc, interoperability
  • Core insight: Standardizing agent-to-client communication with the Agent Client Protocol (ACP) decouples AI editors from specific harnesses, mirroring the openness of MCP and enabling a flexible, interoperable agent ecosystem.

Core insights

6
Architecturemedium noveltystrong evidence

Agent systems need two complementary protocol seams: one for agent-to-world tool access (MCP) and one for client-to-agent control (ACP). Standardizing only the former leaves users locked into bespoke client-harness interfaces.

Why it matters

This exposes a missing abstraction boundary in agent stacks: an agent's outward-facing tools are interoperable, but the inward-facing client control plane is still proprietary. Treating control as a protocol rather than an implementation detail enables swap-ability and ecosystem growth on both sides of the harness.

Generalization

Mature agent infrastructure will be layered: client-control protocols on top, tool/access protocols underneath, with the harness as an independently replaceable reasoning loop.

While Model Context Protocol (MCP) successfully standardized agent tool execution, there is a lack of a standard for client software controlling agents.
Open source video
Architecturemedium noveltystrong evidence

ACP's core architectural move is to decouple client applications from specific agent harnesses: one client layer in an editor can drive multiple harnesses, and users can keep their UI/tooling while changing the underlying agent.

Why it matters

For engineering teams, this changes where integration effort goes: instead of a bespoke 1-to-1 client for every harness, you invest once in a protocol client and get access to any compliant harness. It also makes harness selection a runtime choice rather than a product lock-in.

Generalization

Pluggable client/harness protocols reduce switching costs and turn agent backends into infrastructure rather than product boundaries.

Allows a single high-quality client implementation in an editor to control any agent harness.
Open source video
Writing a single client implementation in Zed or IntelliJ to control Goose, Codex, and other harnesses.
Open source video
Architecturemedium noveltystrong evidence

Having the same protocol semantics over stdio, HTTP, and WebSocket makes agent execution location a deployment detail: the client, harness, model, and tools can each run on different machines or in cloud containers without a different integration.

Why it matters

This separates the transport question from the interaction model. Teams can prototype locally over stdio and move to remote cloud execution by changing a connection layer, enabling distrbuted agent deployments without redesigning messages or state flow.

Generalization

Transport-agnostic control protocols turn command execution topology into configuration, which is a prerequisite for agents as hosted/cloud workloads.

Enables moving client, harness, model, and tools freely across different machines or cloud containers.
Open source video
ACP uses JSON-RPC and supports both local stdio and remote HTTP/WebSocket transports without changing message semantics.
Open source video
Mechanismmedium noveltymoderate evidence

ACP exposes permission requests and tool-call notifications as first-class protocol messages, meaning human-in-the-loop approval can become a client-side, UI-agnostic responsibility rather than a harness-specific UI feature.

Why it matters

When approval flows are serialized in the protocol, any ACP client—editor, terminal, or web app—can render a consistent consent UI. This is important for safety and auditability because mandatory permission gates can be implemented independently of the model or tool provider.

Generalization

Safety-critical control points like consent should be first-class protocol primitives, not incidental UI callbacks inside one harness.

Handles tool call notifications and permission requests.
Open source video
A client asking the user 'Should I do this tool call? Yes or no'.
Open source video
Mechanismmedium noveltymoderate evidence

ACP's extension mechanism reserves a naming convention—custom methods prefixed with underscores—so vendors can add capabilities without waiting for central standardization, while still making proprietary extensions unambiguous.

Why it matters

Protocols that cannot evolve tend to die. The underscore prefix gives harnesses a place to innovate without forking or breaking the common method set, and it gives clients a way to recognize and ignore or use non-standard features.

Generalization

A general-purpose protocol should provide both a stable core and a clearly marked extension surface to balance compatibility with evolution.

Built on JSON-RPC and is fully extensible with custom methods prefixed by underscores.
Open source video
Mental Modelmedium noveltymoderate evidence

The summary frames standards adoption, not protocol mechanics, as the primary source of ecosystem value: MCP succeeded because thousands of servers made it universally useful, and ACP is seeking the same network effect on the client-control side.

Why it matters

Engineers evaluating ACP should weigh adoption momentum as heavily as its technical design. A technically clean protocol without a broad installed base creates little practical value, while widespread adoption can make even an imperfect standard the default integration layer.

Generalization

For interoperability protocols, the network effect is a feature; design decisions should be judged by whether they maximize universal connectability.

The most powerful aspect of MCP is widespread community adoption.
Open source video
Thousands of servers exist for agents to connect to universally.
Open source video

Deep dives

4

The Missing Client-to-Agent Control Plane in Agent Stacks

Research question

How should client-facing control (ACP) and agent-facing tool access (MCP) be separated so both layers stay independently replaceable without duplicating session state, context, or capabilities?

Why

MCP has opened up what agents can do, but the client-to-harness boundary is still bespoke. Teams that invest only in tool-level standards are left with fragmented editor/harness integrations and hidden switching costs.

While Model Context Protocol (MCP) successfully standardized agent tool execution, there is a lack of a standard for client software controlling agents.
Open source video
Source video

Trust Boundaries for Remote Agent Control Protocols

Research question

What authentication, authorization, session isolation, and audit model are required before ACP over HTTP/WebSocket becomes safe for multi-tenant cloud-hosted agent execution?

Why

A network-exposed agent-control endpoint is effectively a remote code execution interface. ACP's transport-agnostic design makes cloud deployment easy, but without a clear trust model it may create dangerous or unauditable agent endpoints.

enables bidirectional communication via JSON-RPC, supporting both local (stdio) and remote (HTTP/WS) transports.
Open source video
Source video

Governance of Underscore-Prefixed Protocol Extensions

Research question

Do underscore-prefixed ACP methods converge into a shared de facto feature set or fragment into vendor-specific capabilities, and what governance process should promote useful extensions into the core protocol?

Why

The extension mechanism trades protocol stability against ecosystem cohesion. If extensions become de facto required methods, the standard can fragment even while every implementation claims ACP compliance.

Built on JSON-RPC and is fully extensible with custom methods prefixed by underscores.
Open source video
Source video

Permission Decisions as First-Class Protocol Events

Research question

What state machine and message schema make ACP permission requests expressive enough to handle one-off consent, long-lived policies, revocations, context drift, and audit logging?

Why

When permission requests are protocol events, consent can be built once at the client layer and reused across all compliant harnesses. Getting this model wrong would force safety-critical decisions back into proprietary harness UI.

Handles tool call notifications and permission requests.
Open source video
Source video

Article ideas

4

The Missing Half of MCP: Why Agent Clients Need Their Own Standard

MCP standardized what agents do, but without an open protocol for what clients tell agents to do, the client-harness layer remains fragmented and no amount of tool interoperability fixes it.

Angle

Protocol boundary between tool access and control; argues that ACP/MCP layering is the real architecture behind portable agent stacks.

Source video

Your Agent Harness Should Be Swappable Infrastructure

Once an editor or client talks ACP, users should be able to change agent harnesses without changing their UI, so integration effort shifts from bespoke per-harness clients to protocol conformance.

Angle

A market-structure argument: standardizing the client-control interface creates network effects and reduces vendor lock-in for agent backends.

Source video

Permission Requests Belong on the Wire, Not in One Harness's UI

Tool-call consent is a security control boundary, not a UI callback; when approval flows are protocol messages, every client and audit tool can enforce them uniformly across all harnesses.

Angle

AI safety and auditability from a protocol perspective: one consent implementation, reusable across editors, terminals, and remote agent endpoints.

Source video

Going Remote Should Not Mean Rewriting Your Agent Stack

If client and harness share the same protocol semantics over stdio and HTTP/WebSocket, moving execution to containers or remote machines is a transport choice rather than a re-architecture.

Angle

Engineering pattern for distributed agent workloads: local development first, cloud deployment later, without changing message models or client integrations.

Source video

Project ideas

4

ACP Consent Gate

gatehouse

A client-side ACP middleware can intercept every permission request from any compliant harness and return allow/deny responses via a uniform policy and audit store, with no harness-specific code and 100% capture.

Proof of concept

Build a middleware that reads ACP tool-call notifications and permission-request messages, presents a generic user prompt, and returns permission responses; then run two different ACP-compatible harnesses through identical tool-call prompts.

Measurement

Proportion of permission requests captured per harness, decision-log schema consistency across harnesses, and end-to-end approval latency.

Source video

ACP Remote Execution Bridge

new

A single ACP client can drive the same stdio-connected harness remotely by swapping only the transport layer; local and remote runs will show the same JSON-RPC method types and ordering and comparable task success rates.

Proof of concept

Implement a bridge process that exposes an ACP harness over HTTP/WebSocket and forwards to a child stdio harness; run a fixed task against a local connection and against the bridge while capturing all JSON-RPC traffic.

Measurement

JSON-RPC method-name and ordering match ratio between local and remote sessions over 20 runs, task success rate, and median latency overhead.

Source video

ACP Interop Matrix

beyond-evals

A session-level conformance corpus will detect cross-client/cross-harness capability-negotiation mismatches that single-implementation tests miss; running N clients against N harnesses will yield reproducible mismatch categories.

Proof of concept

Encode ACP sessions covering session creation, user messages, tool-call notifications, permission responses, and capability negotiation as versioned YAML scenarios; run every client-harness pair and record protocol-level failures.

Measurement

Cross-product pass/fail counts, mismatch categories, and number of methods not supported or improperly negotiated.

Source video

ACP Extension Landscape Analyzer

beyond-evals

Underscore-prefixed extension usage is either highly concentrated in a few shared methods, indicating convergence, or long-tailed, indicating fragmentation, and this pattern can be measured from observable JSON-RPC traffic.

Proof of concept

Collect JSON-RPC method usage logs from a small set of ACP clients and harnesses; classify standard methods versus underscore-prefixed extension methods; cluster method names by implementation.

Measurement

Share of underscore method calls, top-five method concentration ratio, and number of implementations per custom method.

Source video

Architectural implications

4

Harness interfaces are often custom, bespoke, or tied to a single 1-to-1 client application.

Before

Client teams had to build and maintain per-harness integrations; users could not freely switch harnesses from their preferred editor or terminal.

After

With ACP, a client implements one protocol and communicates with any ACP-compliant harness.

Consequence

Editors, terminals, and other front-end tools become independent from agent harness providers, letting users mix and match while reducing maintenance burden for client vendors.

Source video

MCP standardized agent-to-tool communication, but not agent-to-client control.

Before

Agent stacks were glued together by one-off client-harness protocols even when tools were standardized via MCP.

After

ACP creates a clean client↔harness boundary while MCP remains the outward tools boundary, forming a layered, standard-based architecture.

Consequence

Client software, agent reasoning loops, and tool ecosystems can be upgraded or swapped independently, and protocol responsibility is clearly delineated.

Source video

The same ACP semantics are used for local stdio and remote HTTP/WebSocket transports.

Before

Local and remote agent deployments typically required separate integration and transport-specific message handling.

After

Switching between a local process and a remote cloud harness is just a transport choice; the session and message model remains consistent.

Consequence

Organizations can start with local development and graduate to cloud-hosted agents without rewriting client code, reducing architectural risk.

Source video

Tool-call notifications and permission requests are part of the ACP session protocol.

Before

Permission and tool-status UX was commonly implemented inside a single harness's user experience.

After

Any client can present tool activity and request user consent uniformly across harnesses.

Consequence

Human approval workflows—including audit logging and policy enforcement—can be built once at the client layer and reused for all compliant harnesses.

Source video

Tradeoffs and failure modes

4

Remote HTTP/WebSocket transport vs trust boundary

Benefit

Enables cloud/container agent execution and location-agnostic client connections, which is a key ACP advantage.

Cost or risk

Exposing an agent control endpoint over HTTP/WS creates a network trust surface; the summary demonstrates remote operation but does not describe authentication, authorization, or session-isolation controls.

Connecting remotely via HTTP/WebSocket to execute 'Write a poem'.
Open source video
Source video

Underscore-prefixed custom methods

Benefit

Lets teams extend ACP without waiting for official protocol releases, addressing varying harness needs.

Cost or risk

If clients do not implement custom methods, advanced features silently degrade or become de facto vendor-specific extensions, recreating fragmentation under a standard-covered surface.

Built on JSON-RPC and is fully extensible with custom methods prefixed by underscores.
Open source video
Source video

Standardized client-to-harness control vs harness provider differentiation

Benefit

Avoids vendor lock-in and allows high-quality clients to work with neutral agent systems.

Cost or risk

A shared control protocol may push unique harness affordances to the extension surface, making differentiating features less discoverable and more likely to become proprietary.

It decouples editor implementations from specific agent architectures, allowing broader utility across neutral agent systems.
Open source video
Source video

Standardization of permission requests

Benefit

Puts human-in-the-loop decisions on the protocol, which can improve consistency, safety review, and auditing.

Cost or risk

The protocol's permission model may not cover every approval modality (e.g., interactive editing vs. background tool calls), which could force unsafe fallbacks or additional ad-hoc methods.

Handles tool call notifications and permission requests.
Open source video
Source video

Open questions

5

How do ACP clients and harnesses negotiate capabilities at session establishment?

Why unresolved

The summary says connections are established 'with associated capabilities' but omits the negotiation mechanism, versioning rules, and what happens on mismatch.

Research direction

Inspect the ACP specification and test capability negotiation across multiple client and harness implementations.

Source video

What security and trust model does ACP assume for remote HTTP/WebSocket transports?

Why unresolved

Remote demos show functionality but do not mention authentication, encryption, or authorization, which are critical when moving harnesses into cloud containers.

Research direction

Define a transport security profile for ACP remote endpoints, including token-based auth, session scoping, and auditability of client commands.

Source video

Will underscore-prefixed custom methods foster innovation or lead to de facto fragmentation?

Why unresolved

An extension mechanism creates tension between open interoperability and vendor-specific capabilities, and the summary does not describe governance for promoting custom methods into the core.

Research direction

Analyze ACP repositories to see whether extension methods are being used for differentiation or are converging into a shared supplemental set.

Source video

Can ACP achieve adoption momentum comparable to MCP?

Why unresolved

MCP's value is attributed to 'thousands of servers,' but ACP is newer and the summary does not quantify client or harness implementations.

Research direction

Track the number of ACP-compatible editors, CI systems, and harnesses over time as an adoption-leading indicator.

Source video

How should permission requests be modeled to handle both tool-call-time consent and longer-lived policy decisions?

Why unresolved

The summary demonstrates a simple yes/no tool-call prompt but does not cover policy persistence, context drift, or overrides.

Research direction

Design a permission-request state machine suitable for multi-step approvals, policy caching, and replay-resistant audit logs.

Source video

Key claims

8
factualVerification needed

ACP is a joint standard created by JetBrains and Zed editors.

Evidence

a joint standard created by JetBrains and Zed editors

Question

Verify current ACP governance and founding contributor list in the public specification.

Source video
factualVerification needed

MCP has thousands of servers and is the successful standard for agent tool calling and data access.

Evidence

Thousands of servers exist for agents to connect to universally.

Question

Check MCP registry counts and server adoption metrics at time of the talk.

Source video
causalVerification needed

A single high-quality client implementation in an editor can control any ACP-compatible agent harness such as Goose or Codex.

Evidence

Writing a single client implementation in Zed or IntelliJ to control Goose, Codex, and other harnesses.

Question

Confirm that Goose and Codex both ship ACP-compatible server/harness implementations and that a single client can drive both without code changes.

Source video
factualVerification needed

ACP supports local (stdio) and remote (HTTP/WebSocket) transports with the same protocol semantics.

Evidence

ACP uses JSON-RPC and supports both local stdio and remote HTTP/WebSocket transports without changing message semantics.

Question

Read the ACP transport specification and run the reference stdio and WebSocket demos.

Source video
comparativeVerification needed

Many agent harness interfaces are bespoke and often limited to a single 1-to-1 client relationship.

Evidence

Harness interfaces are frequently custom or bespoke, sometimes restricted to a single 1-to-1 client application.

Question

Survey mainstream agent harnesses to classify which expose public JSON-RPC/ACP interfaces versus bespoke client integrations.

Source video
factualVerification needed

ACP supports user messages containing text, images, and audio.

Evidence

Supports creating sessions, sending user messages (text, image, audio), and agent responses.

Question

Verify whether multimodal message content is defined in ACP message schemas.

Source video
factualVerification needed

Custom ACP extension methods are prefixed with underscores.

Evidence

fully extensible with custom methods prefixed by underscores

Question

Confirm the underscore prefix convention in the ACP protocol documentation.

Source video
opinionVerification not requested

Without a standard client-facing interface, client-harness fragmentation will continue and hinder ecosystem growth.

Evidence

Without standards, client-harness fragmentation hinders ecosystem growth and prevents users from swapping editors or tools freely.

Source video

Connections

5

ACPMCP

Complements MCP by standardizing the client-to-harness control direction, while MCP standardizes harness-to-tool/action direction.

Source video