JetBrains Air in IDEs Opens EAP, but Orchestration Is the Real Bet

JetBrains has opened JetBrains Air in IDEs to early access, bringing five supported coding agents into a workspace built for parallel tasks. The move is less about adding another chatbot and more about deciding where developers will supervise AI-generated code.

Air supports Codex, Gemini, GitHub Copilot, Claude Agent, and JetBrains’ own Junie out of the box. It can also connect other compatible tools through the Agent Client Protocol, or ACP, a common interface between coding agents and development environments.

That puts JetBrains against a model-centered view of software development. In that model, developers follow whichever agent currently produces the best results. JetBrains is betting that the durable product is the environment that supplies context, tracks concurrent work, and helps humans review every change.

The early headline described an EAP reaching five IDEs. JetBrains’ current documentation now states that the plugin supports its IDE lineup except Android Studio, making the eventual scope broader than that initial framing. The more important number remains five agents, because Air treats them as interchangeable workers inside one control surface.

JetBrains is not asking developers to abandon Codex, Claude, Gemini, Copilot, or Cursor. It wants those systems to work inside JetBrains products. That distinction turns JetBrains Air EAP into a test of whether the IDE can remain the center of software development when agents perform more of the implementation.

JetBrains Air in IDEs Separates the Workspace From the Model

JetBrains Air in IDEs is an orchestration layer, not a new model or a replacement name for AI Assistant.

JetBrains launched the EAP in early October through the Marketplace and the 2026.3 EAP builds of its IDEs. The company’s Air EAP announcement says the plugin arrives without an agent installed and does not act as an AI provider.

That design matters because it separates three products that users often encounter as one bundled experience. The model generates or interprets text. The coding agent plans tasks, operates tools, edits files, and runs commands. Air organizes those agents and their work inside the IDE.

Developers can connect agents they already use, subject to each provider’s authentication rules. They do not need a JetBrains AI subscription merely to run a compatible third-party agent. Air can detect local agent installations, offer agents through a registry, and reuse supported authorization methods.

Five agents receive explicit first-class support: Codex, Gemini, GitHub Copilot, Claude Agent, and Junie. Cursor and other tools can enter through ACP compatibility, although the exact interface and authorization path can differ by agent.

The product organizes work around sessions rather than a single continuous chat. Each session represents a task, its agent, its context, its progress, and the changes it produces. Developers can view active work across projects, identify sessions awaiting input, and open completed changes for review.

Air also supports presets. A preset stores an agent, model selection, reasoning effort, access level, and other launch settings. That lets a team create different configurations for routine fixes, larger refactors, reviews, or experiments.

This structure turns the IDE into a dispatcher. A developer might send a failing test to Codex, assign documentation changes to Gemini, and ask Junie to inspect a performance problem. Air does not claim those agents will cooperate as one collective intelligence. It gives each task a visible place and keeps their outputs within a review workflow.

The distinction prevents an important misunderstanding about the phrase “runs five AI agents.” Air supports five named agents out of the box, but it does not require all five to run together. It also does not guarantee that simultaneous agents will produce compatible code.

JetBrains’ current Air documentation says local agents run on the developer’s machine. Air communicates with ACP-compatible agents through the protocol, while command-line agents can retain their terminal interfaces inside the IDE.

The plugin is installable for 2026.2 versions and bundled with 2026.3 EAP builds. JetBrains now documents support across its IDEs except Android Studio. Availability, agent authorization, and cloud execution can still depend on the user’s product version and organization settings.

Those details make this more than a distribution update. JetBrains is reorganizing its AI interface around delegated work, while keeping its existing editor, debugger, inspections, navigation, and version-control tools close to the result.

Why JetBrains Is Moving Beyond the AI Chat Panel

The pressure on JetBrains comes from a change in developer behavior, not simply from stronger language models.

The first generation of IDE-based AI features centered on autocomplete and chat. A developer selected code, asked a question, received an answer, and decided what to paste or apply. That interaction fitted comfortably inside a side panel.

Coding agents create a different management problem. They can read several files, form a plan, execute commands, modify a repository, and run tests before returning control. A developer can also start another task while the first agent remains active.

JetBrains says it tried placing more agents inside its existing AI Assistant chat. The company concluded that supervising concurrent tasks required a product organized around work state rather than conversation history.

That conclusion explains why Air and AI Assistant remain separate during the EAP. AI Assistant continues to provide chat, completion, code insights, next-edit suggestions, and agent access within the established IDE experience. Air treats agents and sessions as the main units of work.

JetBrains expects Air to become its primary agentic interface over time, but it has not announced the removal of AI Assistant. Users can keep AI Assistant installed, although installing Air through an AI Assistant notification disables the older plugin to prevent both interfaces from running simultaneously. It can be enabled again through the plugin settings.

The deeper competitive issue is ownership of the developer’s attention. Agent-first editors and command-line tools can pull work away from the traditional IDE. If developers spend most of their time issuing prompts and reviewing patches elsewhere, the IDE risks becoming a secondary place used only for difficult debugging.

Air attempts to reverse that flow. Instead of forcing developers to choose between JetBrains and an external agent, it invites the external agent into the JetBrains environment. The agent supplies planning and generation, while the IDE supplies repository context and verification tools.

That approach also addresses model turnover. The leading coding model can change faster than an organization changes its development environment. A company may prefer one agent for Java migrations, another for interface work, and an internal agent for repositories containing restricted code.

JetBrains does not need Junie to win every comparison if Air remains the place where these systems are managed. The company can benefit from stronger third-party agents because those agents make the shared workspace more useful.

This is why ACP plays a central role. The ACP contract defines a common connection between a client, such as an IDE, and an agent. The agent retains its own model selection, tools, authentication, and planning behavior.

JetBrains compares that boundary to the role of the Language Server Protocol. An editor does not need a separate private integration for every compatible language server. ACP aims to reduce the need for a bespoke plugin between every agent and every development environment.

The analogy has limits. Coding agents can execute commands and change large portions of a repository, so their permissions and side effects carry greater risk. Still, a common connection layer reduces integration work and makes switching agents less disruptive.

For JetBrains, that creates a strategic opening. Cursor, Codex, Claude, Copilot, and Gemini do not have to be defeated at the model layer. They can become choices inside a JetBrains multi-agent IDE.

The IDE Becomes the Control Plane for Agent Work

Air’s central bet is that verification becomes more valuable as code generation becomes easier.

Generating a patch is only one part of software development. Someone must determine whether the patch matches the requirement, preserves architecture, passes tests, respects security boundaries, and behaves correctly under real conditions.

JetBrains already owns many tools used for that work. Its IDEs understand symbols, types, references, project structure, test runners, version control, databases, debuggers, and performance profiles. Air connects agent activity to those existing surfaces.

An agent can receive files, commits, screenshots, and reusable instructions as context. The developer can inspect changed files, compare diffs, navigate related code, and run the project without transferring the result into another application.

This connection can reduce duplicated exploration. A coding agent often spends tokens listing directories, opening configuration files, and locating relevant symbols. IDE-supplied context can direct it toward the correct code earlier, although the savings will vary by agent and task.

Air also gives supported agents access to IDE skills for activities such as debugging, profiling, database exploration, and semantic code search. JetBrains says those tools can improve results for some tasks, but the claim still needs broad testing across repositories and languages.

The agent session becomes the container for this workflow. It records the selected agent, conversation, activity, changed files, commits, and reported cost. Sessions can remain visible across multiple projects, which helps a developer spot work that has completed or requires intervention.

This model is different from opening five chat tabs. A chat tab mainly preserves a conversation. An Air session links the conversation to repository state and review actions.

Consider a developer responsible for a service with a failing integration test. One session can investigate the failure. A second can update a related dependency in an isolated branch. A third can inspect documentation affected by the change.

The developer can continue working in the main checkout while these sessions progress. When one finishes, the IDE becomes the place for reviewing the diff, running inspections, checking tests, and deciding whether the result belongs in the target branch.

That process fits a broader shift in engineering work. Developers increasingly coordinate generated changes instead of typing every implementation directly. Their responsibility does not disappear. It moves toward specifying tasks, supplying context, examining evidence, and resolving conflicts.

JetBrains is positioning the IDE as the control plane for those responsibilities. The term means a surface that coordinates workers and state without being the worker itself. Air does not need to generate the best patch to become valuable if it makes several agents easier to supervise.

The model also preserves user choice. A developer can connect an existing subscription when the provider permits it, select JetBrains AI, or use a locally configured ACP agent. Air itself does not provide a proprietary model.

That flexibility is strategically important. A closed workspace tied to one model inherits that model’s weaknesses and commercial changes. A multi-agent workspace can let developers replace the agent while preserving project habits and review tools.

Teams already building searchable engineering context may recognize the same pattern. The durable asset is not a single answer but the structure connecting code, decisions, documents, and review. A technical knowledge base can complement agent sessions by preserving information that should survive beyond one coding task.

Air does not solve that broader knowledge problem by itself. A session contains useful working context, but teams still need durable records for architecture decisions, incidents, and requirements. The IDE can coordinate implementation while shared knowledge systems preserve why the implementation exists.

Parallel Agents Create a Merge and Attention Problem

Running more agents increases throughput only when developers can review, reconcile, and trust their outputs.

Air lets developers start sessions from a branch and place work in a temporary Git worktree. A worktree is a separate working copy linked to the same repository history. It keeps an agent’s edits away from the developer’s current checkout.

This isolation is essential for parallel work. Two agents editing the same files in one workspace can overwrite assumptions or create changes that pass independently but fail together. Separate worktrees reduce direct interference.

Air can display the result and let the developer transfer selected commits back to the active project. Its documented session workflow supports reviewing changes before cherry-picking them into the target branch.

Isolation does not remove integration work. If five agents change connected areas, the developer may face five branches, duplicated edits, inconsistent abstractions, and merge conflicts. Each agent can produce a plausible local result while the combined system becomes less coherent.

The bottleneck then moves from code production to human attention. A developer must understand what each agent changed and why. They must also decide which tests provide meaningful evidence, rather than accepting a green summary generated by the same system that wrote the code.

Air’s session list helps expose that workload. It can show active sessions, unread updates, changed files, outgoing commits, and tasks awaiting input. That visibility is useful, but it cannot determine whether the underlying decisions are correct.

This is the core tradeoff behind the JetBrains Air EAP. Parallelism can shorten waiting time, yet it can also multiply review obligations. A team that launches agents faster than it can verify their work simply creates a larger queue of uncertain patches.

Presets introduce another governance concern. They make configuration repeatable, but teams must decide which models, permissions, and effort levels belong to each task class. A high-access agent suitable for a disposable test repository may be unacceptable for production infrastructure.

Authentication also remains uneven. JetBrains supports several routes, including provider-managed logins, third-party credentials, and JetBrains AI. However, a subscription usable in one interface may not authorize the same agent inside another surface.

Claude illustrates that complexity. JetBrains says a Claude subscription can be used through the terminal surface, while Claude Agent in structured chat requires JetBrains AI or an Anthropic API key with API billing. Developers should check the current authorization rules before treating Air as a universal subscription hub.

Cloud execution adds more boundaries. Local sessions run on the developer’s machine, but eligible organizations can send certain tasks to JetBrains infrastructure. Cloud runs can continue after the IDE closes, although availability depends on organization settings, repository hosting, and a JetBrains AI subscription.

Data handling therefore depends on the selected path. JetBrains says third-party agent data goes directly to that provider under the user’s existing agreement when a third-party subscription is used. JetBrains AI and cloud features operate under their applicable terms.

The EAP agreement also makes the maturity level explicit. Early-access software can contain errors, behave unexpectedly, and change during development. Teams should not treat the EAP label as a routine badge when agents can edit files and execute commands.

A cautious rollout would begin with noncritical repositories and narrow permissions. Teams should require human review, preserve recoverable branches, and run independent tests before merging. Sensitive code needs a clear provider and data-routing decision before any agent receives context.

These controls are not arguments against JetBrains Air in IDEs. They are the conditions under which its parallel model becomes useful. Orchestration creates leverage only when it makes responsibility more visible instead of hiding it behind activity dashboards.

JetBrains Is Turning Rivals Into Replaceable Components

Air challenges agent-first editors by absorbing their agents while preserving the JetBrains development environment.

The most important opponent is not one company. It is the idea that the coding agent should own the entire developer workspace.

An agent-first editor can optimize every interaction around one integrated system. That creates a focused experience, but it can also make the developer’s workflow dependent on that product’s model routing, interface decisions, and release schedule.

JetBrains takes the opposite position. The IDE remains stable while agents compete for tasks inside it. Developers can keep familiar navigation, refactoring, debugging, and inspection tools while changing the system that generates code.

ACP makes that proposition credible. Without a shared protocol, supporting many agents would require a growing collection of private integrations. Each provider update could break a connector or leave features inconsistent across products.

With ACP, the replaceable unit includes more than a model. An agent carries its planning logic, tools, permissions, model routing, and interface behavior. Air connects to that full package through a common client boundary.

This gives JetBrains a way to benefit from external innovation. If Codex improves at repository-scale changes, Air users can choose it. If Gemini becomes better for another workload, the workspace does not need to change. An internal ACP agent can serve restricted tasks.

The five named agents are therefore an opening roster, not a fixed ceiling. Codex, Gemini, GitHub Copilot, Claude Agent, and Junie give the EAP recognizable choices. The registry and custom configuration expand the possible set.

Cursor is a revealing example. It competes for developer attention as an AI-oriented coding environment, yet its agent can also connect to JetBrains products through ACP. JetBrains can turn a product associated with switching editors into an available worker inside its own IDE.

That does not guarantee users will stay. A native agent-first product can still offer a more coherent interface, faster feature delivery, or tighter integration with its preferred model. Protocol compatibility rarely makes every client experience identical.

Air must also justify the complexity of choice. Five agents with different permissions, subscriptions, modes, and strengths can become harder to manage than one familiar tool. The workspace needs clear status, predictable configuration, and trustworthy review information.

JetBrains’ own product lineup adds another risk. Users already encounter AI Assistant, Junie, Air, ACP agents, provider accounts, and JetBrains AI. Air creates a cleaner conceptual split, but the transition period can still feel fragmented.

The company is trying to resolve that problem by making Air the dedicated environment for agentic workflows while retaining AI Assistant for chat and inline assistance. Whether users understand and prefer that division will be a key EAP result.

JetBrains first presented the standalone Air environment as a place built around agents rather than an editor with AI attached. Its March public preview established concurrent delegation as the product’s central idea.

Bringing that experience into established IDEs changes the proposition. Developers no longer need to adopt a separate application to test the workflow. JetBrains can distribute Air through products already embedded in engineering teams.

That distribution advantage is meaningful, but adoption depends on daily utility. Developers will not keep another tool window merely because it recognizes several agents. Air must make concurrent work easier to understand, review, and merge than separate terminals or provider applications.

What to Watch After the JetBrains Air EAP

The next test is not how many agents Air lists, but whether teams complete real work with fewer context switches and manageable review costs.

The first signal is adoption across ordinary repositories. JetBrains needs evidence that developers continue using Air after the novelty of launching parallel sessions fades. Repeated use across debugging, maintenance, tests, and refactoring would support the orchestration thesis.

The useful metric is not the number of prompts. Teams should examine completed tasks, accepted changes, review time, reopened defects, and the amount of manual repair required after an agent finishes. High session volume can conceal low-quality output.

The second signal is the reliability of worktree-based integration. Air should make branch state, uncommitted changes, conflicts, and transfer targets obvious. A system designed for parallel agents must prevent developers from losing work or applying a correct patch to the wrong branch.

JetBrains documents safeguards and review controls, but the EAP will reveal how they behave under daily pressure. Large repositories, generated files, monorepos, and overlapping refactors will provide harder tests than isolated demonstrations.

The third signal is competitive response from agent providers and rival editors. Wider ACP adoption would strengthen JetBrains’ open-workspace strategy because developers could move agents among supporting clients. Providers may instead favor proprietary features that work best inside their own applications.

Support for common capabilities will matter as much as the agent count. Permissions, tool calls, context attachments, cost reporting, session resumption, and diff attribution need consistent behavior. A protocol that connects many agents but exposes only their lowest common features would limit Air’s advantage.

Organizations should also watch administrative controls. JetBrains says companies can disable Air through managed AI access, but its documentation notes that IDE Services management is not yet complete. Enterprise adoption requires clear policies for providers, credentials, cloud runs, data routing, and auditability.

The relationship between Air and AI Assistant is another concrete signal. JetBrains says AI Assistant will remain supported while Air becomes the preferred agentic experience. Future releases should show whether that division becomes simpler or produces overlapping interfaces.

A successful transition would leave developers with one clear place for delegated tasks and another for lightweight inline help. A confusing transition would force users to understand which plugin owns each agent, subscription, or chat mode.

The five supported agents will also expose whether specialization delivers practical value. Developers need observable reasons to select Codex for one task and Junie or Gemini for another. Otherwise, the selector becomes an administrative choice rather than a productivity feature.

JetBrains Air in IDEs ultimately rests on a defensible premise: generated code increases the value of context and review. The unresolved question is whether one IDE can organize enough agents without turning developers into full-time queue managers.

Try the EAP on a recoverable branch and give it a task that crosses several files, tests, and review steps. Then compare the complete workflow with your current agent setup. Did Air reduce context switching, make changes easier to inspect, and preserve control over the repository? Or did it simply collect five interfaces in one window? That answer, repeated across real teams, will determine whether JetBrains Air becomes the operating layer for agentic development or remains an interesting experiment.