Air #
An agentic development environment
[Agentic AI](https://blog.jetbrains.com/air/category/agentic-ai/)
[AI](https://blog.jetbrains.com/air/category/ai/)
Today, we’re introducing JetBrains Air Teams – the team layer for agentic development. It gives humans and agents the shared context, environments, tools, and instructions they need to work effectively together across the full development lifecycle.
Air Teams is already available to JetBrains business customers, with plans to expand access to individual customers later.
The new chapter: From individual developers to teams #
We introduced the Air app several months ago as our first step into agentic development. Since then, we’ve learned a lot and seen real productivity gains for developers working with agents.
As we developed Air further, two things became increasingly clear. First, developers don’t need another standalone app – tools and agents should be integrated into the environment where they already work. Second, as individual developers became more productive with agents, the real bottleneck started shifting to the team level.
That’s why we’re expanding Air beyond a standalone desktop app into a broader system. Air now supports agentic development at three levels: individual developers, teams, and organizations. Let’s take a closer look at what Air Teams brings to engineering teams.
What is Air Teams? #
Air Teams is a shared workspace where engineering teams run coding agents and reuse what works. Today, most agentic work happens on individual laptops: Each developer has their own setup and prompts, and what works for one person doesn’t easily spread to the rest of the team. Air Teams brings your agentic workflows into one place: what one developer figures out, everyone can use.
Air Teams has four parts:
Automations handle recurring work on their own, such as code reviews, issue fixes, and dependency updates. An event or a schedule starts each run.
Shared cloud environments give agents the tools, dependencies, and credentials they need to build and test the code. The team sets an environment up once, and everyone reuses it.
Cloud tasks run in those environments, in parallel, without tying up anyone’s laptop. You can start and follow them from your IDE or browser, and soon also from your phone.
Projects tie it all together, with shared credits, clear roles, and Automations that don’t depend on any one person.
Let’s walk through each part.
Automations: No more babysitting agents #
Agents can work fast, but they still wait for humans to start tasks, provide instructions, and proceed to the next step. At some point, manually orchestrating every run becomes the bottleneck.
Air Automations are agentic workflows that run on their own, in the cloud, triggered by an event or a schedule instead of a person. They are shared team assets: One developer can build an automation, and the whole team can run, reuse, and improve it. What works well for one person can become part of how the entire team works. For example, an Automation can review every new pull request the moment it opens, or update dependencies twice a week.
How Automations work
Automations are for recurring work that follows a pattern: a pull request needs reviewing, a labeled issue needs investigating, or dependencies need checking every week.
You set up four things once, and the Automation reuses them on every run:
Instructions: what the agent should do.
Environment: where the agent runs.
Tools: what the agent can use, including Jira, Figma, and Linear through connectors.
Trigger: when the agent starts, whether that’s a GitHub or Jira event, a webhook, or a schedule, with more trigger types on the way.
Here’s an example: an Automation triggered by a label. When someone adds the Bug label, the Automation starts an agent. The agent reads the issue and the linked Jira ticket, finds the cause in the code, and opens a pull request with a proposed fix for an engineer to review.
Automations belong to a team project, so the whole team uses the same Automation instead of each person building their own. Once an Automation proves itself, it can go beyond the project: the team can reuse it on another repository or save it as a template that anyone in the organization can use as-is or adapt.
Automations examples
Here are three Automations we run on our own team:
Code reviews. When a pull request opens, an agent reads the relevant code and discussion, posts inline comments and a summary, and can approve the pull request or request changes. Each new commit starts another run: The agent reads its previous review and any replies, notes which issues were fixed and which remain, and collapses its old reviews so only the latest one stays visible. An AI agent should assist your workflow, not block it. When you decide to handle an issue in a separate pull request, the agent respects your choice and completes its check.
Issue fixes. When a teammate tags a small, well-scoped issue in YouTrack, an agent gathers context, attempts a fix, and opens a pull request for review. The same Automation also handles review feedback. When a pull request opened by an Automation gets review comments from a teammate or from the code review Automation, the agent picks them up and fixes them.
Dependency updates. Twice a week, an agent upgrades the project’s dependencies, skipping any that its instructions say to leave alone. It builds the project and runs the tests. When an upgrade breaks something, the agent fixes the affected code without changing its behavior, or reverts the upgrade if a fix can’t be found. It then opens a pull request listing which upgrades were applied, skipped, or reverted. If the previous pull request is still unmerged, the agent closes it, so the team always has one up-to-date pull request to merge when it’s ready.
We’ll cover more Automations in upcoming posts, including how we set up and use them.
Stay in control
A valid concern with AI agents is noise: comments nobody reads and pull requests nobody asked for. Automations keep the decisions with the team. Engineers choose what an agent works on, and its instructions can keep the output small, as in the examples above: one open pull request for dependency updates, one current review per pull request. Each run also keeps the agent’s full conversation and tool calls, so when a result looks wrong, the team can see why. Every code change arrives as a pull request, and an engineer decides whether to merge it.
Shared cloud environments: A setup your team and agents can reuse #
Every Automation, like every cloud task, runs in an environment, and an agent can perform only as well as its environment allows. Before it can build or test anything, it requires what a new engineer needs on day one: the right tools, dependencies, credentials, and network access. A small project may run on the defaults, but most codebases need more, such as a private package registry, pinned toolchain versions, or an internal issue tracker that the agent must reach. Someone has to set that up, and once should be enough.
In Air Teams, that setup lives in a shareable cloud environment. You create one for a repository in your team project. Pick the VM size, decide which domains the machine can reach, and add the variables and secrets the build needs. The setup itself lives in your repository at .air/cloud/startup.sh, so your team versions and reviews it with the rest of the code.
You can also hand the first pass to an agent. It inspects the repository, runs the real install and build, asks for any missing secrets, and commits a tested startup script to a separate branch. You review it like any other change.
When the environment is ready, Air saves it as a snapshot, and you share it with the team. Sharing the setup doesn’t mean sharing credentials. Shared secrets let your teammates and Automations use a value without seeing it, while personal secrets and repository access stay with each person.
From then on, teammates pick the environment for their cloud tasks, and the project’s Automations run on it. No agent spends time and tokens rediscovering how to build the repository. Every task starts on the actual work. Learn how to configure environments
Cloud tasks: Work from your IDE and any device #
With environments set up, you can start giving agents work. Choose an environment and an agent, then describe the task. If your repository doesn’t need a custom setup, use the default environment.
You can run a task locally or in the cloud. The right choice depends on the task, the setup it needs, and how closely you want to work with the agent.
| | Local agent | Cloud agent | | Getting started | An existing workspace is ready immediately. A new worktree or container may need to be set up first. | The environment has to start and copy the repository first. Configuring it in advance and saving it as a shareable environment with a cached state will shorten the wait. | | Machine resources | Builds and tests share your machine’s CPU and memory with your other work. | Builds and tests run on a cloud machine, preserving local resources. | | Files and tools | The agent works with your local tools and your working copy, including uncommitted changes. | The agent works from a remote branch, with the tools, dependencies, and credentials configured for the environment. | | Agents and accounts | You can use any supported or ACP-compatible agent you’ve installed, with an account it supports. | You can use the supported cloud agents your organization has enabled. | | Reusing the setup | Teammates can share setup scripts, but each person still prepares their own machine. | Teammates share one environment, and each task runs in its own copy of it. | | Following up | Your machine has to stay on. Remote access depends on your own tools. | The task keeps running even if your machine is off. You can follow up through Air in JetBrains IDEs or on the web, and soon also on mobile. |
The key difference is that cloud tasks aren’t tied to the device you started them on. You can start a task in your IDE and pick it up later on the web. The agent keeps working even after you close your laptop.
Team projects: Work that belongs to the team #
A team project is a shared home for a team’s agentic work. It brings together members, environments, connectors, and Automations.
Two roles define who can do what. Project admins manage membership, environments, connectors, and Automations. They can also let specific members edit an environment. Members use the shared environments, create their own Automations, and see the results of every run.
Automations don’t have to depend on the person who created them. Each project has its own service account and AI credits, and a project admin decides whether the project’s Automations spend those credits or their creators’ own. On project credits, Automations run under the project’s account and keep running after their creator leaves.
Learn about project roles and credits
Get started with Air Teams #
With Air Teams, agentic work becomes something the whole team shares. Automations handle recurring work, shared environments give every task the same setup, cloud tasks keep running after you close your laptop, and team projects make sure none of it depends on one person.
Try Air Teams at **air.jetbrains.cloud**. Everything above is built to be shared, so invite your teammates from the start.
For the full system of Air products, visit [jetbrains.com/air](https://jetbrains.com/air).