The Agent Interchange Layer: You Can Now Swap Coding Agents Like Models

October 30, 2026·12 min read

The changelog entry for fx is three paragraphs long. The last one is the news: “fx joins Claude Code, Cline, Codex, Cursor, Deep Agents, Grok Build, OpenCode, and Pi in the list of supported harnesses.”

Nine coding agents now sit behind one JavaScript interface called HarnessAgent. You import the adapter, you pass a prompt, you get a stream back. Swapping Claude Code for Pi becomes a one-line change, the same way you swap openai('gpt-5.5') for an Anthropic model today. Vercel’s pitch is model-swapping moved up a level: “AI SDK has always let you switch models without rewriting your agent. Now you can switch the harness the same way.”

What interests me is a different sentence on a different changelog page, where the same vendor says that route costs you fidelity.

What a harness is

The AI SDK team defines the term better than I can: harnesses manage “the components above a model call, including skills, sandboxes, sessions, permission flows, compaction, runtime configuration, and sub-agents.”

That list is the difference between a model and something you can hand a bug report to. A raw model call has no filesystem, no permission model, no way to compact a conversation that outgrew its context. Everything developers fight with lives in that layer, and until recently each vendor’s harness was its own world. The Agent Client Protocol’s own introduction describes the result: “Each editor must build custom integrations for every agent they want to support, and agents must implement editor-specific APIs to reach users.”

AI SDK normalizes access to the layer. What it normalizes against is a protocol with its own governance.

Three protocols, one acronym, and I have contributed to the problem

If “ACP” means nothing to you, good. If it means the Agent Connect Protocol, that is a different thing, and I wrote about it in September.

The ACP here is the Agent Client Protocol, from Zed: a standard for “communication between code editors/IDEs and coding agents,” for local and remote scenarios. Local agents run as subprocesses of the editor and talk JSON-RPC over stdio. Remote ones go over HTTP or WebSocket, though full remote support is still listed as a work in progress.

Our archive has used those three letters for other projects. The September piece on AGNTCY covered the Agent Connect Protocol, an OpenAPI-style interface for invoking remote agents, archived read-only on 11 April 2026. The A2A post mentions OpenAI’s Agent Commerce Protocol, which concerns agent payments. The acronym is useless on its own now, and I am part of why.

The three protocols sit at different layers. MCP standardizes how an agent reaches a tool. A2A standardizes how agents reach each other. The Agent Client Protocol standardizes the seam where a developer actually sits, between the editor and the agent. Our protocol coverage stops one layer short of the developer.

The milestones are dated rather than promised. The registry shipped 9 March 2026, giving clients “a standard way to discover, install, and configure compatible agents without inventing custom integration metadata.” The Rust and TypeScript SDKs hit 1.0.0 on 25 June. Sergey Ignatov of JetBrains became a lead maintainer in February, which the project described as reflecting “the growing collaboration between Zed and JetBrains around ACP.” A v2 baseline has been in draft since July, and tool call names stabilized in September.

The editor-to-agent seam now has a versioned specification and a maintainer roster drawn from two competing editors.

The vendor says the generic path is the worse one

On a separate changelog page, Vercel explains why @ai-sdk/harness-acp differs from the adapters before it. The earlier ones each wrapped one runtime. This one “wraps the protocol instead. It is a meta adapter: rather than adapting a single harness, it lets you build an adapter for any harness that ships an ACP-compatible package.”

Then, four paragraphs later:

Not every harness supports ACP, and for some, ACP limits or changes how well they expose their internal behaviors, so a direct adapter can produce a tighter integration.

The instruction that follows: “For Claude Code and Codex, prefer the direct @ai-sdk/harness-claude-code and @ai-sdk/harness-codex adapters over an ACP-based implementation; reach for @ai-sdk/harness-acp when a harness has no direct adapter but ships an ACP-compatible package.”

Read those together and you have the shape of the interchange layer. The protocol is the fallback for harnesses nobody wrote an adapter for, and the two harnesses Vercel names in that instruction get the bespoke integration instead.

I do not read that as cynical. An adapter built on an abstraction you do not control can only expose what the abstraction carries, and a direct adapter can reach harness internals the wire format never touched. Saying so in the changelog before anyone files the issue is unusually direct.

That does make the promise conditional. “Swap coding agents like models” holds for the harnesses that have a direct adapter. For the rest you are swapping through a protocol, and how much of that agent’s behavior survives the trip depends on the agent.

One detail makes the grading visible. fx did not get a direct adapter. Its changelog says @ai-sdk/harness-fx “connects to fx over the Agent Client Protocol (ACP) using @ai-sdk/harness-acp.” Vercel’s own agent entered its own registry through the generic path, while the two harnesses the changelog tells you to wire directly, Claude Code and Codex, did not. The changelog does not say why the work landed in that order, and I do not know. I can only see where it landed, which is not on the newest project.

Two projects, two different ideas of a reusable module

fx is the artifact worth looking at from the last month. Written in Zig, one native binary, 5.97 MiB at v0.0.16 according to its changelog, with a CI rule that fails a pull request if any benchmarked command such as fx help takes longer than 2 ms on Linux. It is explicit about intent: “fx is meant to be embedded and extended.” Scripts call it with fx ask, editors connect over ACP, JavaScript applications drive the same core through libfx.

Small describes the packaging, not the feature set. The README calls it “a minimal coding agent CLI that still comes with batteries included,” and the batteries are the things the harness layer exists to normalize: built-in file, shell, web and subagent tools, a permission model with three modes, sessions saved under ~/.fx/sessions/ with compaction, skills, MCP servers, project instructions. fx is small the way a compiled binary is small. It carries plenty of state. It just does not need a runtime to carry it.

Webcmd, released by AgentR on 9 October, is Apache-2.0 as well, and its product is a memory rather than an agent. “Webcmd learns the navigational context of websites as agents use them, then turns that knowledge into local memory for faster, cheaper, more reliable browser automation,” targeting up to 90% less token spend. It ships two layers: live browser control for sites it has never seen, and a sitemap memory for sites it has. Installation puts exactly one skill into whichever harness you already run.

They disagree about what a reusable module is for, and about who opens it. fx is horizontal: one general agent core with four documented surfaces, and the README puts the interactive one first. You cd your-project, run fx, and “Type what you want done and press Enter.” After that come fx ask for one request from a script or CI job, fx acp for editors and other ACP clients, and libfx for JavaScript applications, all of them the same binary.

Webcmd is vertical: one narrow capability that improves at a specific class of task the more you run it, and its documented entry point faces another agent. Installation puts a single skill, webcmd-browser, into whichever harness you already run, and the usage examples are prompts to that harness (“Use webcmd to research…”). You describe an outcome to your agent; webcmd is what the agent reaches for. It is a capability you add to an agent you already have rather than an agent you start.

Both also keep a hosted surface next to the open core. Webcmd’s README says Webcmd Cloud “can run supported commands and browser sessions on hosted infrastructure,” and that it is “in active development and is not yet stable.” fx offers a browser demo at fx.sh/try. I am comparing the open modules here, not the hosted surfaces around them.

The dates are worth getting straight, because the secondhand versions blur them. fx tagged v0.0.1 on 17 August and has shipped steadily since. Webcmd arrived 53 days later, on 9 October. The 22 October InfoQ piece on fx came thirteen days after Webcmd’s release, which is the closest thing to simultaneity in the record, and it was coverage rather than a launch. The dates are all I have. Two projects from unrelated vendors, one horizontal and one vertical, landed in the same season, and nothing I read says either was built in response to the other. I cannot tell you what either team knew when the work started.

What the numbers do not support

I went looking for something to check these claims against and mostly did not find it.

No independent benchmark of fx exists. InfoQ reported a 6.3 MiB binary and a 10-microsecond cold start, and was careful to label them “figures Vercel states rather than independently verified benchmarks.” The changelog already reports 5.97 MiB, so the vendor’s own number has moved. Use the changelog figure, attribute it to Vercel, and do not call it a result.

Webcmd’s benchmark is more tangled and the announcement around it is worse. The release sits on a Business Insider subdomain and closes with “Editorial Teams were not involved in the creation of this post.” It is a paid press release. The repository is more forthcoming: “All tools used the same Pi controller, controller model, Codex gpt-5.4 judge, and CloakBrowser engine,” which differs from the official runner, whose current setup uses Gemini 2.5 Flash. Holding the controller fixed across competitors is methodologically reasonable. It also means the 67 of 100 is a number from AgentR’s comparison, not a ranking on the benchmark everyone else cites. That comparison also ran on V1 tasks, and the benchmark repository now advertises V2.1 with 200 tasks.

Star counts measure attention. fx has 3.7k, Webcmd has 2.8k, and neither tells you who runs the thing. The Agent Client Protocol’s install base beyond stars, SDK count and a registry that exists is unmeasured, which cuts hardest against my own framing: I can show you that the interface exists, not that anyone is using it at scale. The one large number here is AI SDK’s, “over 16 million weekly downloads,” which is a property of a real dependency rather than a press release.

The layer itself is experimental

The harness layer ships on the canary release, and Vercel attaches a warning to it: “Harness packages are experimental. Expect breaking changes between releases as this early API gets further refined.”

fx has shipped sixteen tagged releases in seventy-three days, v0.0.1 on 17 August to v0.0.16 on 29 October. Release notes for the latest warn that “libfx 0.0.15 cannot reopen saved turns containing the new context updates,” which is a migration for anyone embedding it. The README carries a status line reading “Experimental. Use at your own risk.” The name also collides with the long-established fx terminal JSON viewer that holds the Homebrew formula, with packaging coexistence still under review.

None of that argues for staying away. It argues for writing against the interface rather than against fx or Claude Code specifically, with a clear idea of what that buys. I cannot tell you the interface survives a breaking change. Vercel’s own note says the harness packages are experimental and that the API will move.

Both halves of that trade appear in the ACP changelog. A direct adapter can produce a tighter integration, which is the stated reason for preferring the bespoke route where one exists. ACP “limits or changes how well they expose their internal behaviors,” so the protocol hands you less of the agent. What follows for maintenance is my expectation, not the page’s: an adapter that exposes more of a harness is the one I would expect to feel a harness change harder. Neither changelog describes what an upgrade costs either route.

That is the case I would make for this layer, and it is narrower than the case the vendors make. The useful change is smaller than interchangeability: your code talks to an adapter instead of to one harness, and the adapter is a package you can swap. I am describing a direction, not a saving anyone has measured. Nobody has published a migration figure, the packages carry a breaking-change warning in their own documentation, and which parts of a given agent survive the adapter is exactly what Vercel says the abstraction can distort.

If you are choosing today, I expect the direct adapters to keep arriving, since Vercel’s stated reason for the split is how much of a harness each route can expose, not which route is newer. Which harnesses get one is a question about Vercel’s roadmap. The module boundary will keep moving too. Both argue for the same thing: write against the adapter, not against one harness.

The stack is separating into layers, and I made that argument in August with less evidence that anyone was building the interchange. There is a package name behind it now, and a version number, which is the difference between an architecture diagram and something you can install. I am more convinced by the interface than by the slogan, mostly because the people selling it told me where it leaks.