ACP: the quiet protocol that lets any agent live in any editor
The most important thing about Air is a protocol with a dull name you'll never see in the UI: the Agent Client Protocol, ACP. Nobody demos it.
If you've wired up MCP, you already grasp half of ACP by analogy. MCP standardized how an agent reaches its tools and data: a filesystem, a database, a search index. ACP standardizes the other side: how an agent talks to the editor or IDE it's living in. One is the agent reaching down to its tools; the other is the agent reaching out to the surface a human is watching. The two names behind it are JetBrains and Zed, which tells you it came from people who ship editors rather than a standards committee.
the proof is in the swap
Here's why I stopped rolling my eyes. In Air (I walked through it in the first look), I can point a task at OpenAI Codex, then at Claude Agent, then at Gemini CLI, then at JetBrains' own Junie, and the environment barely blinks. Same task surface, same review loop, a different brain underneath. That interchangeability is ACP quietly earning its keep: the editor doesn't need a bespoke integration for every agent vendor, and the agent doesn't need one for every editor. They meet in the middle, at the protocol.
Standards are dull right up until the day you swap one vendor for another and nothing else in your setup has to move.
the MCP rhyme
We've seen this film recently. Before MCP, every agent grew its own one-off connectors to every tool, and the combinatorics were miserable. MCP folded that into a single contract both sides implement. ACP is the same wager aimed at the editor boundary instead of the tool boundary, and if it lands the payoff rhymes with MCP's: less glue code, and fewer of the lock-in traps that come from hand-built integrations. I care about this for the same reason I care about designing agent tools well: the interfaces are where the edge comes from.
the skeptic's asterisk
I won't pretend this is settled. My first reaction to ACP was tired: another protocol, another spec, another thing to support that might be abandoned inside a year. I've watched enough standards die of plain indifference to keep a hand on my wallet. Two editors backing it is a start, not a promise, and a protocol is only as real as the count of agents and editors that actually implement it.
I changed my mind partway, not the whole way.
What moved me was using the thing, not reading about it. I watched four different agents drop into one environment without me writing a line of glue.
what it buys you
The reason to care, if you're not a protocol nerd, is a hedge against lock-in. For years your choice of editor quietly picked your agent for you, and switching meant relearning a whole workflow. A working agent-to-editor standard breaks that coupling, the same way open command-line agents loosened the vendor grip I wrote about in open CLI versus vendor. You get to choose the best agent for the task and the editor you actually enjoy, and let the protocol handle the handshake.
ACP won't trend on anyone's timeline, and that's exactly the point. The best plumbing is the kind you forget is running. If it catches on, the winners are the people who get to stop caring which agent lives in which editor; if it doesn't, we'll have learned something real about how much editor lock-in people were willing to swallow. Either way, Air argues the case better than any spec document could.