JetBrains Air, ACP, and where MCP sits in the new stack

JetBrains announced Air today, September 22: an open system for agentic software development spanning the IDE, team delivery workflows, and governance, with Junie across all surfaces (JetBrains). The part with lasting consequences for a tool builder is the plumbing: the Agent Client Protocol, developed with Zed, carries the connection between IDE and agent. MCP, one layer down, keeps its job.

What is JetBrains Air, concretely?#

Three products, plus the agent. Air in JetBrains IDEs is a plugin: multiple projects stay open, each with its own agent sessions, and the tool tracks unread updates, changed files, and outgoing commits across all of them. Diffs open straight from an agent session, and you can leave a comment on a specific line for the agent to act on. Model access comes from an existing provider subscription, your API keys, or JetBrains AI credits billed at public API rates, and you can switch between them mid-session (unite.ai).

Air Teams, in early access, runs shared projects in dedicated cloud environments and delegates repeatable work, code review, release notes, fixes, to coding agents, with per-project controls for VM size, internet access, and secrets. Air Governance, formerly JetBrains Central, holds the organizational layer: rules for models and agents per organization, team, or person, AI spend limits, keys brought from Bedrock, OpenAI, or Anthropic, and usage analytics.

The announcement frames the shift plainly. JetBrains spent 26 years on the individual workbench. Air targets the wider system through which agentic work is "initiated, executed, coordinated, reviewed, and governed".

How ACP and MCP stack together#

The Agent Client Protocol standardizes what sits between an IDE and an agent's full harness: its planning, logic, tools, model routing, and observability. The ACP page describes a connection for "local, remote, or in-house AI agents without vendor lock-in", built by JetBrains and Zed (ACP). A registry lets an IDE discover and run compatible agents, and unite.ai's coverage lists Codex, Copilot, Gemini CLI, Cursor, OpenCode, and Cline among the agents speaking it, with Zed and Neovim as clients alongside JetBrains IDEs.

MCP is untouched by this and complements it. ACP connects the editor to the agent. MCP connects the agent to the world: search, fetches, databases, internal APIs. An agent that arrives in your IDE over ACP still reaches your tooling over MCP. For a builder of MCP servers the interesting line sits in Air Teams: MCP server connections configured once and shared by the whole team and its agents. A server like searxng-mcp-server, whose opt-in Streamable HTTP endpoint already serves remote clients, is the shape that travels into a shared cloud environment; a stdio-only server stays local to whoever spawned it.

Multi-vendor is the design principle, and JetBrains argues it in cost terms: rankings change every few months, teams inside one company already pick different models, and "no single model, agent, or service will be right for every developer, team, or task". Every added vendor otherwise "takes away a little more visibility" while context stops carrying over and spend stops being attributable. Governance across vendors is Air's answer, which lands next to this week's model-price cuts: cheaper tokens multiply the value of a single cost view.

Why the verification argument matters more than the agents#

The announcement's sharpest passage concerns the bottleneck. "Code becomes cheaper to generate but more expensive to verify." The hard failure is code that is almost right, plausible enough to pass a superficial check while carrying an assumption that surfaces late. And: "An agent will not get the call at 3:00 am when something breaks."

JetBrains pitches its deterministic code intelligence as the antidote, an economic one as much as technical: agents "spend time and money rediscovering information the codebase already contains", and an agent that retrieves that knowledge is cheaper and more accurate than one that reconstructs it. That argument generalizes past JetBrains. A support agent that reads its facts from tools instead of generating them, as the one on this site does, is the same trade: retrieval beats reconstruction, and the savings show up per run.

What to watch#

JetBrains promises a rolling release cadence with explicit what-works-now lists, mobile and remote surfaces later, and more work triggered by repository events and schedules instead of a prompt in an editor. Nothing in the announcement names the governance data model, and that is the part a small MCP author would need: whether usage analytics see through to individual MCP tool calls or stop at the model invoice. The registry and the shared-connection promise are checkable today. The cost view is the piece to verify before betting a team's tooling on it.

For the wider picture, I compared how Claude Code, Codex, and ZCode handle long, goal-driven tasks in goals and workflows.