Pimp My IDE / garage dispatch
Back to garage
September 28, 2026 | agents / team automation / control

Shared automation needs a recall path.

When an agent workflow outlives its author, the team inherits its triggers, credentials, cost, and mistakes.

Reuse the workflow only after its owner, exact revision, reach, and shutdown test can travel with it.

The personal prompt is becoming team infrastructure.

JetBrains introduced Air Teams today as a shared workspace for agent work. Its Automations can start from repository events, Jira activity, webhooks, or schedules. Team projects can supply shared environments, connectors, service accounts, and credits.[1]

That solves a real waste problem. A working setup should not stay trapped on one laptop. JetBrains also says a project automation can keep running under the project account after its creator leaves.[1] That durability changes the object. The workflow is no longer a personal shortcut. It is a maintained team dependency.

Persistence without recall is abandoned machinery with a timer.

A trigger contains three decisions.

Air's trigger documentation separates the start condition, checked-out branch, and change handling. A run can report without changing code, push to the source branch, push a new branch, or open a pull request.[2] Those are different authority levels. A label that starts analysis is not the same control as a label that produces commits.

Incoming webhooks can also place a JSON payload into the task context. Event filters matter because a broad trigger can multiply runs, spend, and output. Record the exact event action and destination with the automation. "Runs on pull requests" is too vague to review.

Shared tools widen the inheritance.

JetBrains Air connectors make external service tools available to cloud tasks and automations. Project connectors use a shared account. The documentation says the GitHub connector is available for every cloud run on a GitHub repository and cannot be disabled. It also warns that defining the same service through a connector and mcp.json can give the agent duplicate tools.[3]

A reusable automation therefore needs more than good instructions. Its recall card should name every connector, repository, secret class, network destination, run budget, and output route. A template that omits reach teaches the next team to copy authority without inspecting it.

Validation is the first check, not the last.

GitHub's managed Copilot settings provide a useful adjacent lesson. GitHub validates configuration files and reports the affected file and JSON path. Its setup guide then tells administrators to confirm that supported clients received the expected settings.[4] A valid file and an observed effect are separate checks.

That product does not verify Air Automations. The lesson transfers at the control level. Validate the definition, observe one real run, exercise the stop path, and save the result. A template should not graduate because its JSON parses or its first pull request looks plausible.

Ship the recall card with the template.

  1. Owner. Name the team that approves edits, receives failures, and pays for runs.
  2. Revision. Pin the automation definition, environment setup, model choice, and connector list.
  3. Reach. Record triggers, repositories, branches, credentials, tools, network access, and change handling.
  4. Recall. Test disable, token revocation, queued-run cancellation, branch cleanup, and notification delivery.

Reuse is earned when the next team can inspect the automation, bound its authority, and stop it without finding the original author.

Interactive makeover / shared automation service panel

Recall board

Traditional purpose replaced: one reusable-template toggle. Better version: choose the reuse radius, connect four maintenance lines to one recall handle, and copy the missing evidence fields. This board drafts a review card. It does not control a live automation.

Set the reuse radius

The native radio and checkbox controls own the state. The physical board mirrors the review card structure.

Who can inherit this automation?

Teaching proxy. Connected lines show selected card sections, not live control coverage.

Sections to include in the recall card
No recall section is selectedThe project radius is set. Choose the fields this review card must request.
Copyable automation recall card

Record what survives the author

Replace every required field with evidence from the real platform and run.

What this component proves. It keeps ownership, revision, reach, and recall in one adoption card. It does not inspect an automation, revoke credentials, cancel runs, or verify a platform control.

Sources and limits

Open the source log
  1. JetBrains, "Air Teams: Bring Your Best Agentic Workflows to the Whole Team", published and read September 28, 2026. The vendor announcement describes shared Automations, environments, project roles, credits, service accounts, run records, and pull-request review.
  2. JetBrains Air documentation, "Automation triggers", updated September 16, 2026 and read September 28, 2026. The page defines start conditions, branch choice, event filters, webhook payloads, and change-handling options.
  3. JetBrains Air documentation, "MCP Connectors", updated September 21, 2026 and read September 28, 2026. The page documents personal and project connectors, network reach, the automatic GitHub connector, and duplicate-tool risk.
  4. GitHub Docs, "Getting started with enterprise-managed settings", read September 28, 2026. This is an adjacent control example. It separates repository validation from checking delivered settings on supported clients.
  5. GitHub Changelog, "Enterprise managed settings in-product validator", published September 25, 2026 and read September 28, 2026. GitHub says its validator detects malformed JSON, unsupported configurations, invalid team mappings, and related errors.

Evidence boundary. We confirmed that the Air web app, announcement, and documentation pages resolve. We did not have a JetBrains business project, so we did not create or stop an Air Automation. GitHub's validator is an adjacent design example, not evidence about JetBrains Air. The recall board is a planning aid. Selected sections request evidence; they do not prove that a control works.