{"slug": "building-a-paseo-product-adapter-for-google-s-official-antigravity-acp-kernel", "title": "Building a Paseo product adapter for Google's official Antigravity ACP kernel", "summary": "Developer Tiezbro released version 2.3.0 of paseo-agy-acp, an open-source adapter that lets the Paseo controller use Google's official Antigravity ACP kernel as a multi-agent provider. The adapter acts as a thin NDJSON proxy, handling product-level concerns such as agent identity, mode mapping, MCP rewrite, and blank-turn detection while leaving authentication and inference to the proprietary kernel. The project is community-maintained and not officially supported by Paseo or Google.", "body_md": "I maintain [paseo-agy-acp](https://github.com/tiezbro/paseo-agy-acp), a community adapter that lets Paseo use Google's official Antigravity ACP kernel as a real multi-agent provider.\n\nVersion 2.3.0 is now on npm, so the open-source adapter can be launched directly with npx:\n\n```\nexport PASEO_AGY_ACP_OFFICIAL_BIN=\"/absolute/path/to/agy-acp-server-wrapper-or.par\"\nnpx -y paseo-agy-acp@2.3.0 --login\n```\n\nThat one command is useful, but the interesting part of the project is the boundary behind it.\n\n**Important disclosure:** I maintain this project. It is not official Paseo support and not official Google support. The npm package contains only the Apache-2.0 proxy. It does not contain or download Google's proprietary Antigravity kernel. You still need Paseo, Node.js 22+, a locally installed official kernel, and an Antigravity account that can complete the kernel's OAuth flow.\n\nACP gives us the wire protocol: initialize a connection, create a session, send prompts, cancel work, stream assistant output, report tool calls, and expose modes or configuration.\n\nThat is necessary, but a generic protocol connection does not automatically define product behavior.\n\nPaseo is a controller that can create and delegate to several agents across different workspaces. The official Antigravity kernel owns authentication, inference, models, tools, and MCP behavior. Connecting those two systems exposes questions that do not belong in either raw JSON-RPC message shape:\n\npaseo-agy-acp is deliberately a thin NDJSON proxy that answers those product questions while leaving provider responsibilities in the official kernel.\n\nThe execution path is:\n\n``` php\nPaseo / Generic ACP client\n  -> paseo-agy-acp\n       identity | daemon context | mode map | MCP rewrite\n       skill hints | blank-turn guard | optional Admission fence\n  -> official agy_acp_server (ACP v1 over NDJSON)\n       OAuth | models | tools | MCP | inference\n```\n\nThe official kernel remains responsible for:\n\nThe adapter is responsible only for the Paseo-facing integration layer. That keeps the open-source surface inspectable and avoids reimplementing or redistributing a proprietary provider.\n\nPaseo supplies agent identity and working-directory information to provider processes. It can also append daemon-side instructions that agents need in order to operate correctly inside a workspace.\n\nThe adapter carries that context into the official session prompt when PASEO_AGENT_ID is present. Without this bridge, a session may technically run while missing the controller's operating context.\n\nThis is a small transformation with a large behavioral impact: protocol success is not the same as a correctly contextualized agent.\n\nProduct mode names do not line up automatically. The current mapping is:\n\n| Paseo or legacy id | Official live mode |\n|---|---|\n| default | default |\n| accept-edits | auto_edit |\n| dangerously-skip-permissions | yolo |\n| plan | default |\n\nThe official live kernel has no plan mode, so the adapter maps plan to default rather than claiming a capability that is not there. Legacy kernel selection also fails closed; the official kernel is the only execution path.\n\nPaseo commonly describes an MCP endpoint as an HTTP server with a header map. The official Antigravity kernel expects the equivalent declaration as SSE with headers represented as name/value entries.\n\nThe adapter rewrites that structure during session/new. This keeps product-specific conversion in one place instead of requiring every Paseo configuration or MCP server to understand the kernel's exact representation.\n\nAn official end_turn with no visible assistant output or tool activity should not look like a successful answer in Paseo.\n\nThe adapter tracks visible activity during the turn. If the kernel ends without any, the proxy returns an explicit JSON-RPC error. A visible failure is much easier to diagnose, retry, and monitor than a blank assistant message recorded as success.\n\nThis was the largest operational issue.\n\nPaseo can delegate several agents at once. If every connector immediately writes a prompt to the same account, neighboring starts can produce empty turns, hangs, or internal ACP failures. Serializing the whole controller would throw away useful concurrency, so the adapter instead fences only the provider-facing prompt write.\n\nAdmission is a durable, account-wide queue. Each turn takes a seat before its official session/prompt write and releases it on completion, failure, or cancellation. Extra turns wait rather than striking the kernel simultaneously.\n\nThe tested defaults are:\n\nThese are tested operating defaults, **not a Google product limit**. Operators can tune them. When Admission is enabled, invalid configuration, missing identity, or unsafe state-directory permissions fail closed instead of silently running without the fence.\n\nThe state is shared across connector processes, so starting more local processes does not accidentally multiply account concurrency.\n\nThe newest release adds a second integration layer: local slash-command hints from SKILL.md metadata.\n\nThe adapter discovers user-invocable skills from configured and default Gemini, Agents, Codex, and workspace roots, then merges them with native command updates from the official kernel.\n\nThe merge rules matter:\n\nThat last pair prevents command metadata from one workspace appearing in another session. Version 2.3.0 also parses common quoted and multiline frontmatter forms.\n\nThe release was validated with 37 test files: 216 passed and 1 skipped. Architecture and secret checks passed, and a live official-kernel canary confirmed that native commands remained present, a visible workspace skill appeared, and a non-invocable skill stayed hidden.\n\nFor a single-agent smoke test:\n\n```\nexport PASEO_AGY_ACP_OFFICIAL_BIN=\"/absolute/path/to/agy-acp-server-wrapper-or.par\"\nnpx -y paseo-agy-acp@2.3.0 --login\n```\n\nFor multi-agent use, prepare one owner-only Admission state directory per Antigravity account:\n\n```\nexport AGY_ACP_STATE_DIR=\"$HOME/.local/state/paseo-agy-acp/account-name\"\ninstall -d -m 700 \"$AGY_ACP_STATE_DIR\"\n\nnpx -y --package=paseo-agy-acp@2.3.0   agy-acp-prepare-state \"$AGY_ACP_STATE_DIR\"\n```\n\nThen configure a Paseo Generic ACP provider:\n\n```\n{\n  \"providers\": {\n    \"antigravity\": {\n      \"type\": \"acp\",\n      \"command\": [\"npx\", \"-y\", \"paseo-agy-acp@2.3.0\"],\n      \"env\": {\n        \"PASEO_AGY_ACP_OFFICIAL_BIN\": \"/absolute/path/to/agy-acp-server-wrapper-or.par\",\n        \"AGY_ACP_ADMISSION_ENABLED\": \"true\",\n        \"AGY_ACP_STATE_DIR\": \"/home/YOU/.local/state/paseo-agy-acp/account-name\"\n      }\n    }\n  }\n}\n```\n\nRestart Paseo after changing the provider command or environment, create an agent with the antigravity provider, and send a simple prompt.\n\nnpx starts the stdio ACP adapter for Paseo. It is not a standalone chat app, and it installs only the proxy. The official kernel must already exist locally. The first npm run may also need a C++ toolchain to compile better-sqlite3.\n\nThe unmodified official ACP path uses the Gemini-family models exposed through the signed-in account. Accounts entitled to Claude 4.6 or GPT-OSS 120B can use the project's explicit local compatibility runbook.\n\nThat remains the same official kernel and Google backend. The repository does not vendor or replace either one.\n\nI am looking for concrete reports from people running real multi-agent workloads:\n\nRepository: [github.com/tiezbro/paseo-agy-acp](https://github.com/tiezbro/paseo-agy-acp)\n\nnpm: [paseo-agy-acp@2.3.0](https://www.npmjs.com/package/paseo-agy-acp)\n\nThe design goal is narrow: keep Google's official kernel responsible for provider behavior, keep Paseo responsible for orchestration, and make the boundary between them explicit, observable, and stable under multi-agent load.", "url": "https://wpnews.pro/news/building-a-paseo-product-adapter-for-google-s-official-antigravity-acp-kernel", "canonical_source": "https://dev.to/tiezbro/building-a-paseo-product-adapter-for-googles-official-antigravity-acp-kernel-2lcn", "published_at": "2026-08-30 04:23:20+00:00", "updated_at": "2026-08-30 04:52:45.788044+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["Paseo", "Google", "Antigravity", "paseo-agy-acp", "Tiezbro", "ACP", "npm"], "alternates": {"html": "https://wpnews.pro/news/building-a-paseo-product-adapter-for-google-s-official-antigravity-acp-kernel", "markdown": "https://wpnews.pro/news/building-a-paseo-product-adapter-for-google-s-official-antigravity-acp-kernel.md", "text": "https://wpnews.pro/news/building-a-paseo-product-adapter-for-google-s-official-antigravity-acp-kernel.txt", "jsonld": "https://wpnews.pro/news/building-a-paseo-product-adapter-for-google-s-official-antigravity-acp-kernel.jsonld"}}