Beyond JSON-RPC: what Paseo needs from an Antigravity ACP adapter

I maintain paseo-agy-acp, a community adapter between Paseo and Google's official Antigravity ACP kernel.

The project started from a deceptively simple question: if Paseo already speaks Generic ACP and Antigravity already exposes an official ACP server, why is another layer useful?

Because ACP defines the wire protocol, but it does not define all of the product behavior a multi-agent controller needs.

The architecture stays deliberately thin:

Paseo -> paseo-agy-acp -> official agy_acp_server

OAuth, model discovery, inference, tools, MCP behavior, and streaming remain inside Google's official kernel. The Apache-2.0 adapter owns the Paseo-specific contract around it.

What the adapter adds today

1. Paseo context injection

Paseo can attach daemon, workspace, and agent context through appendSystemPrompt. The adapter carries that context into the official session without replacing the user's ACP-visible message.

2. Explicit mode and MCP normalization

Paseo and older integrations may use mode ids such as accept-edits, dangerously-skip-permissions, or plan. The official live modes are default, auto_edit, and yolo, with no native plan mode. The adapter maps these deliberately.

It also rewrites Paseo-style MCP HTTP declarations into the SSE and header shape expected by the official kernel.

3. Durable, account-wide Admission

A controller may delegate several agents at once. If every connector writes session/prompt concurrently, provider-facing startup pressure becomes difficult to reason about.

Admission is a shared SQLite-backed queue across connector processes. Each turn takes a seat before the prompt write, then releases it on success, failure, or cancellation. Startup recovery, owner death, queue timeout, and ambiguous dispatch have typed outcomes instead of being reported as successful empty turns.

The tested default is 8 active turns, 8 concurrent starts, and 2 seconds minimum start spacing. Those are operating defaults from testing, not a Google limit and not a claimed product ceiling.

4. Visible failure semantics

An output-free end_turn should not become a silent green result in Paseo. The adapter converts that case into an explicit JSON-RPC error so operators can see and diagnose it.

5. Optional compatibility for additional entitled models

The unmodified official ACP path uses the Gemini-family working set by default. For accounts already entitled to Claude 4.6 or GPT-OSS 120B, the project provides an explicit local prepare, verify, activate, rollback, and cleanup lifecycle.

This remains an opt-in local compatibility layer on the same official kernel and Google backend. The project does not redistribute Google's proprietary kernel.

What is new in v2.3.0

The latest release adds workspace-aware skill discovery.

The adapter now merges native ACP commands with user-invocable SKILL.md metadata from Gemini, Agents, Codex, configured roots, and the current workspace. Native commands win name collisions, workspace skills override global skills, and user-invocable: false skills stay hidden.

Discovery is scoped to each ACP session cwd, and concurrent session/new setup is serialized. That matters when one Paseo controller is operating across several workspaces: slash-command hints from one workspace must not leak into another.

v2.3.0 also adds npm Trusted Publishing through GitHub OIDC provenance. The release was validated with 37 test files, 216 passing tests, one skipped test, plus architecture, secret, official-kernel smoke, and live command-update checks.

The npx path

You can now run the adapter directly from npm:

npx -y paseo-agy-acp@2.3.0 --login

and configure Paseo with:

"command": ["npx", "-y", "paseo-agy-acp@2.3.0"]

One boundary is important: npx installs and starts only this Apache-2.0 proxy. You still need Paseo, Node.js 22+, and a locally installed and authenticated official Antigravity ACP kernel. PASEO_AGY_ACP_OFFICIAL_BIN should point to that local wrapper or .par.

I would value feedback from people running real ACP or multi-agent workloads:

- Which behaviors belong in ACP itself, and which should remain product-adapter policy?

- Do account-wide admission controls match the way you operate multiple agents?

- Are workspace skills as slash-command hints useful, or would you prefer a different discovery surface?

- Which failure states are still too easy for ACP clients to mistake for success?

Repository: https://github.com/tiezbro/paseo...

npm: https://www.npmjs.com/package/pa...

Disclosure: I am the maintainer. This is community-maintained and is not official support from Paseo or Google. AI assistance was used to draft and edit this post; the technical claims were checked against the v2.3.0 release documentation.