DEVELOPMENT DOCUMENTATION / ACP

A remote conversation with a local CLI agent.

Agent Client Protocol connects a host application to an agent. Agent Uplink carries those conversations to an allowlisted agent supervised by the enrolled device.

Connection flow

initialize -> connection ID
open connection event stream
session/new -> session ID
open session event stream
session/prompt -> updates and eventual result
permission request -> host decision -> agent response
DELETE connection -> cleanup

HTTP binding

The device/service endpoint has the form:

/v1/devices/{device_id}/services/{service_id}/acp

What has evidence

The pinned official Rust client has driven initialize, sessions, prompt updates, permission callbacks and DELETE against the bridge. Local cluster evidence covers a declared subset of rotation, ownership, revocation and tenant-isolation behavior. The full ACP milestone is not complete.

Important limits

• The public profile follows the selected ACP HTTP draft. It is not a generic WebSocket agent gateway.
• Batch requests are refused by the selected profile even though the pinned upstream SDK has batch support.
• Browser CORS/Origin access is a separate acceptance gate.
• Peer-key rotation and simultaneous saturation of both forwarding segments remain outside completed acceptance.
• The caller cannot supply an arbitrary executable or shell command.
• Lost prompts are not automatically replayed, and child restarts must not silently repeat work.

Permissions and workspace

Connection/session ownership includes principal, tenant, device, service and policy revision. Permission callbacks go to the host and do not widen local grants. An agent-visible working directory is scoped to its configured export, not an invitation to disclose arbitrary host paths.