ACP bridge
Any ACP client. One persistent cloud agent.
The AgentSky ACP bridge lets any ACP-compatible client drive a persistent cloud agent over stdio. ACP clients rotate short-lived sessions freely; the bridge maps every rotation to the same durable agent conversation, so memory and context survive across restarts.
Protocol
What ACP is.
Agent Client Protocol is a JSON-RPC over stdio standard for driving agents from orchestration clients. Clients like block/buzz's buzz-acp harness support custom harness commands, which is how the AgentSky bridge plugs in.
The problem with local harnesses
ACP clients like buzz-acp start a new process for each channel session and rotate them freely. A local harness loses all memory on every rotation — there is no persistent state.
What the bridge provides
The bridge maps every ACP session — however many the client creates — onto one persistent AgentSky session. The cloud agent keeps its conversation, files, and context intact across all of them.
Setup
One environment variable.
Install the bridge globally, export your API token, and point the ACP client at it. No AgentSky-specific configuration lives inside the client.
Install
npm install -g @agentsky/acpConfigure
Set your API token and point the ACP client at the bridge with your agent slug. Get a token at Settings → Tokens.
export SKY_API_TOKEN=ast_…
export BUZZ_ACP_AGENT_COMMAND=agentsky-acp
export BUZZ_ACP_AGENT_ARGS=<your-agent-slug>Or use a custom harness config
For buzz desktop, add a custom harness JSON instead of environment variables.
custom_harnesses/agentsky.json
{
"name": "AgentSky",
"command": "agentsky-acp",
"args": ["<your-agent-slug>"],
"env": { "SKY_API_TOKEN": "ast_…" }
}Audience
Teams with existing orchestration.
If your team already uses an ACP-compatible client and you want persistent memory without migrating to a new API, the bridge is the fastest path — it adds zero new client dependencies.
Good fit
Teams running buzz-acp today who want their agent to keep memory across sessions without changing the client setup.
Direct API instead
If you are building a new integration from scratch, the AgentSky API gives you more control — sessions, streaming events, and token scopes — without the ACP layer.
FAQ
Common questions about the ACP bridge.
What is ACP and why does the bridge exist?
Agent Client Protocol (ACP) is a JSON-RPC over stdio standard used by clients like block/buzz's buzz-acp harness to drive local agents. Those harnesses start a new process per channel session and rotate them freely — meaning a local harness loses memory every rotation. The AgentSky bridge maps every short-lived ACP session to one persistent cloud agent, so memory and session state survive freely across restarts.
Which ACP clients work with this bridge?
Any client that speaks ACP JSON-RPC over stdio and supports a custom harness command. The bridge was built for and tested with block/buzz's buzz-acp harness, which supports a BUZZ_ACP_AGENT_COMMAND environment variable or a custom_harnesses JSON config. Other ACP-compatible clients that use the same protocol version should work, though only buzz-acp has been verified.
Does the bridge work with any AgentSky agent or only specific harnesses?
The bridge works with any agent spec slug you create in AgentSky. You choose the harness and model when you create the agent; the bridge itself is harness-agnostic and simply relays turns to your agent's session over the AgentSky public API.
What does the bridge not do that a local harness would?
The bridge does not give the cloud agent access to the buzz CLI or Nostr relay. It injects a note into each prompt telling the agent that buzz commands are unavailable in its environment and that it should write plain response text, which the bridge posts to the correct channel. The agent cannot call buzz commands directly.
Persistent memory for your ACP client.
One bridge, one cloud agent, zero session loss. Start with a $3 credit — no card required.