Parallel Coding Agents With Git Worktrees, Conductor and Antigravity 2.0

From terminal juggling to a visual harness

If 2025 was the year of the AI agent, 2026 looks like the year of many agents working together, and a Google engineer predicted early on that this would be the year of agent orchestration. The trouble shows up quickly for anyone who lives in a terminal. Trying to coordinate a team of parallel subagents building a small clock game, with tmux panes, repository checkouts and paper stickies on the monitor to remember which run was doing what, turned into a cognitive mess.

The photo shows several macOS desktops full of agy terminals with sticky notes, a good picture of what managing parallel agent workspaces looks like without proper tooling.

The idea of building apps with a multi-agent harness came from a June 2026 post that showed one prompt spawning four parallel developer agents and producing a working application in under two minutes. Opinionated CLI helpers are great for single-threaded jobs, but several concurrent agent streams, each with its own branch, checkout and coordinator feedback loop, don't fit in a flat scrollback buffer. That's why the next step was moving to the Antigravity 2.0 desktop app.

The app groups everything by project, basically a folder, and lists threads under each one, newest first. A personal project might hold a thread for adding a blue login button with a hidden password and another for adding a /checkout/ backend route, while a work project holds threads for writing doc/PRD.md and adding security tests. Threads can be archived, so they survive a reboot, and nobody needs physical sticky notes any more.

Once a visual harness works, the next question is scale. A lone sandbox and a toy game are simple. This setup stretches the desktop app to a 12-track SRE simulation using Git worktrees, a Rails-flavored orchestrator named Conductor++ and a concierge agent called Agostina.

The illustration shows a developer trying to keep a pile of worktree subagents under control, panettone in hand.

The prompt that sparked it

The inspiration was a compact prompt for building a hotel room booking app with a small team of agents.

Let's build a hotel room booking app [..].

First, launch the Engineering Manager agent to ... into an artifact called 'architecture.md'.

Once the design is ready, launch three agents in parallel:
1. Test Manager: Write <SPECS> to 'architecture.md'.
2. Backend Engineer: Build an API based on <SPECS> .
3. Frontend Engineer: Build a web UI based on <SPECS>  to interact with the API <details>.

[..] How to sync the 3 sub-agents [..]

Finally, spin up both components and a browser so I can test the live app.

Reading it closely shows what's in it:

1. a description of the product wanted, here a hotel booking app
2. a team of three subagents
3. the order and timing of their interaction
4. what happens at the end, when the system is spun up for a human who isn't in the loop very tightly to inspect
5. the one thing that matters most, a shared file state: the common artifact architecture.md

The diagram traces how the agents interact in that example. It's meta-programming in a pure form. The prompt doesn't describe the code, it describes the team that will write the code. And the agents talk to each other through a Markdown artifact, which means the specs themselves are the communication channel.

A wish list for a parallel setup went further: implementation triggered by GitHub Issues (GHI), so each subagent picks up a real ticket.

Ingredients of the workflow

Several pieces make up the setup.

• Issue integration. Every subagent should work on an issue when one exists.
• Rails for AI. The Conductor extension gives agent work some "rails", meaning opinionated boundaries. An issue alone doesn't always hold enough for an agent to act on, and sometimes a human in the loop (HITL) has to answer the hard questions, which stops implementations from getting sloppy, as in "of course I meant only authenticated users."
• git worktree. Worktrees stop two or more agents from wrecking the same repository. With N agents opening pull requests on remote branches, it also makes sense to have a git concierge that resolves code into main. That role should be conservative. Where agent X is trying to ship feature X, the concierge is unfazeable, the last line of defense for consistency, since code can be fine yet ship without tests run or the changelog updated, and a fresh context window is good at noticing that.

To reuse the whole arrangement across codebases, the rules and automation were packed into an open-source agent skill, conductor-worktree-hitl, nicknamed condutree. Its core components are:

• git worktree for asynchronous implementation, with one subagent per worktree and one Conductor track
• GitHub Issues plus Conductor for opinionated implementation boundaries
• Antigravity 2.0 as the visual harness
• state kept on disk, so agent context carries across runs, compatible with Conductor but adding file-based state for issue linking and an experimental subagent question-and-answer framework
• optionally, a plugin supplying a using-git-worktrees skill to automate worktree isolation

Packaging it as an external skill, and not pasting git commands into the coordinator prompt, has three reasons. First, it puts all low-level workspace setup, symlinking and git excludes in one maintainable script. Second, the coordinator's prompt stays short and focused on delegating from main to subagents and resolving questions, so the agent doesn't have to wrestle with git syntax. Third, other developers can drop the skill into their own repositories and harnesses and get conflict-free parallel runs without rewriting integration scripts.

An agent equipped with the skill learns four things:

1. how to check out independent worktrees for concurrent tasks
2. git hygiene, namely symlinking the shared Conductor metadata folders and excluding them locally so git status stays clean
3. a dual reentrant HITL protocol for posting issue comments, reading local registries and polling for answers without burning through API quota
4. how to commit locally and record sign-offs as Git Notes, with no direct remote pushes

Version 1.0 is a solid base, and a 2.0 is planned with automatic configuration symlinking and richer helper scripts.

This AI-generated illustration plays on "too many cooks in the kitchen": a crowd of coding subagents making a mess of one branch when there's no worktree isolation.

Stress test: an SRE incident simulator

To see how far parallel execution can be pushed, the model was applied to a realistic SRE automation and incident-command simulator. The goal wasn't toy apps. It was a multi-agent system that audits cloud environments and coordinates incident handling across several isolated workspaces at the same time. Before that ran without collisions, some git hygiene and naming questions had to be settled.

• Symlink pollution. In the Conductor++ setup, each parallel agent gets its own worktree, for example .worktrees/telegram_incident_creation/. Because subagents report metadata back to the coordinator, the root conductor/ directory is symlinked into every worktree with ln -s ../../conductor conductor. Everything except that folder differs per worktree, and since each track lives in its own conductor subfolder, merge trouble is very unlikely.
• The coordinator. The lead git concierge is called Agostina, a calm, organized Italian character running on espresso, who keeps parallel subagents such as Mario and Luigi in sync without letting them step on one another. She's Italian on purpose, and the name sounds a bit like Antigravity.
• The scribe. A dedicated agent named Amanuense, after the Latin word for a scribe, logs directory creation, code changes and agent interactions with exact timestamps into one central audit file, so you can see who did what, when and in which worktree. It was created to check how well subagent synchronization worked and to provide factual timestamps and logs for the write-up.

Running several AI agents on one repository demands strict isolation plus a race-free way to communicate.

Here Agostina resolves merges from Mario and Luigi, while a third, yellow subagent keeps tinkering in its own worktree.

Rules that keep the repository sane

Several design decisions carried most of the weight.

• No direct remote pushes. If many subagents run git push at once, they cause lock collisions on remote refs and can slip untested code into production. Subagents commit only to local feature/ branches and write summarizing git notes. Only the coordinator may push, check out the validation branch and merge feature branches.
• Dual reentrant question protocol. A single global questions.json would create write races when subagents ask questions concurrently. Instead, a subagent writes its question into its private track folder (conductor/tracks/<track>/metadata.json), which is completely race-free. It also posts the question as a GitHub issue comment carrying a unique tracking signature. Agostina's polling script first checks whether any local track has the status awaiting_human. If none does, the GitHub API call is skipped entirely, saving more than 95 percent of quota. When a matching answer appears on GitHub, the local metadata flips to answered, which wakes the subagent.
• A shared wiki-style memory. Rather than stuffing each subagent's context with the whole project history, the shared conductor/ directory acts as persistent memory, a structured local directory that agents read and write like a wiki page. It echoes a well-known gist on LLM memory from Andrej Karpathy, and it speaks to the common worry that poorly managed agent memory turns assistants into goldfish.
• Cascading conflict resolution. When completed feature branches are merged one by one, a cascade can appear. Mario's branch merges cleanly into the validation branch, but Luigi's conflicts. If a human fixes Luigi's conflict on the validation branch, Luigi's original feature branch in its worktree remains conflicting and stale. To prevent that drift, Agostina cherry-picks or merges the resolution back into Luigi's branch, keeping the isolated worktree aligned with the validated code.
• Pull requests instead of pushing to main. Pushing the merged validation branch straight to main would bypass review gates, so integration goes through a PR. Subagents commit locally, Agostina pulls, validates and merges locally, and once the integration tests pass she pushes the unified branch and runs gh pr create --title "feat: ..." --body "...". A human reviewer can then inspect diffs and CI checks in GitHub's own UI. Agostina records the PR URL in the registry's metadata.json and shows live status through gh pr list and gh pr status.
• Termination for conceptual conflicts. Two tracks can be logically incompatible, such as one implementing a feature that another refactors in an incompatible way. If Agostina spots this, she may terminate one of the conflicting subagents immediately. The cancellation must be written up on that agent's issue, and the issue must be blocked on, or linked to, the other agent's issue to preserve a clear decision trail. This has happened exactly once.

The orchestration lifecycle

The human operator never talks to subagents directly. They run in complete isolation inside their worktrees, and the person speaks only to the coordinator at two points: launching the run and answering questions relayed by the HITL watcher.

The flow diagram shows the agent and subagent lifecycle in six steps:

1. Launch. The operator starts the run.
2. Read status. Agostina audits active GitHub issues and Conductor track states.
3. Provision. She creates isolated worktrees and spawns the parallel developer subagents.
4. HITL watcher. Blocking questions from subagents are routed to the human and the answers are routed back, keeping the feedback loop safe and asynchronous.
5. Cleanup. When subagents finish and open their PRs, Agostina removes the temporary worktree directories.
6. Merge to main. She integrates the changes and opens or merges the final PR, looping back to cleanup for any remaining tasks. It can turn into a bloodbath, but agents handle git merges better than people.

Answering questions is still highly experimental, and three approaches were tried. One is a Telegram sidecar bridge that runs as a background daemon, sends questions or database-mutation approvals to the developer's phone through a Telegram bot, and polls for replies.

The diagram shows that asynchronous Telegram flow. Its advantages are mobile-first answering and approvals, race-free parallelism because questions sit in per-track directories, which avoids file lock contention, and an audit trail, since each decision is kept in the repository as JSON. The simplest, talking to the main agent through questions.json, was dropped because it never unblocked automatically and had to be triggered by hand, though hooks or future releases could fix that.

Case study: twelve SRE tracks in five hours

The test bed was a web application built around an SRE extension. Plenty of its work could run in parallel: UI screens, backend endpoints, a chat assistant backed by an LLM, a Telegram bot, OpenTelemetry instrumentation and discovery of GCP resources.

The run took twelve complex SRE capabilities and split them into more than twenty concrete GitHub issues. Then the machine was let loose. In about five hours, mostly unsupervised, the Conductor++ pipeline built, tested and merged all of them into the main branch. The scope ran from setting up OpenTelemetry tracing in Cloud Run to writing interactive Telegram incident wizards and registries for approving pending mutations.

Integration and merge results

Under the parallel worktree orchestration, every feature track was developed, tested and integrated into main.

The table image gives the final status audit for the headline tracks. Eight more operational tracks were integrated too, covering incident status taxonomy, incident deletion and archival, wiki project cross-linking, multi-environment state management, graduating state to the cloud, a responsive wiki UI, live GCP connectors and pending mutations.

Two weeks after the run, the Conductor status can be checked with a single task-runner command that launches the inspector over the repository and prints the workspace summary.

$ just conductor-status
python3 conductor/bin/conductor-inspector . --open --short

🔍 Inspecting Conductor Workspace: /usr/local/google/home/ricc/git/adk-sre-benjamin
📦 Product: Initial Concept
STATUS      |  PROGRESS  | RATIO |  GHI  |   AGENT    |   CHANGED   | TRACK ID                                           |  🌳
==============================================================================================================================
NEW         | ░░░░░░░░░░ |  0/25 |  #23  |            |  💻 15days   | managed_agents_sandbox_20260616                    |
NOT_READY   | ░░░░░░░░░░ |  0/17 |  #22  |            |  💻 15days   | mcp_streamline_abilities_20260616                  |
NOT_READY   | ░░░░░░░░░░ |  0/11 |  #15  |            |  💻 15days   | migrate_tf_cb_logic_20260616                       |
NOT_READY   | ░░░░░░░░░░ |   0/9 |  #21  |            |  💻 15days   | ai_engineering_practices_20260616                  |
NOT_READY   | ░░░░░░░░░░ |   0/9 |  #19  |            |  💻 15days   | workspace_agent_installation_20260616              |
NEW         | ░░░░░░░░░░ |  0/15 |  #31  | antigravity|  🐙 16days   | disable_mock_fallback_dev_20260616                 |
==============================================================================================================================
TOTAL       |            |  0/86 |       |            |              | 0 completed, 6 open (6 total)                      | 0 🌳

The workflow timeline

A step-by-step look at the run shows how the coordinator, scribe and parallel subagents avoided stepping on each other.

Step 1: initializing tracks and worktrees

On the host machine, the parent coordinator prepared the workspaces. The Conductor inspector CLI then listed active tracks and handed them to named subagents, one covering Discord war-rooms and another covering pending mutations. A flag that includes all tracks lets the same tool show branches and agent statuses for every parallel workspace.

./scripts/conductor-inspector /Users/ricc/git/adk-sre-benjamin --all

The terminal output captured at initialization follows.

================================================================================
  CONDUCTOR++ ACTIVE WORKTREES & TRACKS INSPECTION
================================================================================
[Track: telegram_incident_creation_20260603]
  Worktree: .worktrees/issue-29-telegram-wizard
  Branch:   feature/issue-29
  Agent:    pinocchio
  Status:   AWAITING_HUMAN (Question: "Verify Telegram Token config?")
  GHI URL:  https://github.com/palladius/adk-sre-benjamin/issues/29

[Track: unified_incident_lifecycle_observability_20260607]
  Worktree: .worktrees/issue-18-discord-warrooms
  Branch:   feature/issue-18
  Agent:    grazia
  Status:   RUNNING
  GHI URL:  https://github.com/palladius/adk-sre-benjamin/issues/18
================================================================================

In that listing, the subagent handling pending mutations is blocked, waiting for a HITL answer.

A natural question is whether GitHub issues and Conductor tracks are the same thing. They're two stores that can drift. An agent was asked to detect drift between the two.

The screenshot shows the inspector overview of active worktrees, branches and subagent assignments. Reconciling the two takes a single prompt in either direction. One asks Conductor to create a new track for every issue, asking all the needed questions one track at a time. The other makes sure an issue exists for every Conductor track.

The detail view shows a pending HITL question waiting for input on GitHub Issues.

Step 2: parallel worktree isolation

Every agent worked on its own branch, and the scribe recorded exact file edits and workspace events with no conflicts.

This capture is the worktree file monitor during concurrent development.

The Antigravity thread tracker shows tracks in progress, the sort of sight that would have impressed the original one-prompt, four-subagent demo.

Step 3: polling and human steering

When agents needed clarification, they posted issues that a polling script, poll_ghi_questions.py, parsed. To make the human steering mobile-friendly, the questions went through the Telegram sidecar bridge. The operator didn't have to sit at a computer refreshing GitHub, because the bridge pushed each question to a phone for quick approvals on the go.

The screenshot shows the approval and diagnostics feedback loop in action.

Step 4: the final green state

After every feature branch passed validation and was merged in sequence, Agostina opened the pull request, and the final audit confirmed that all twelve SRE tracks were merged into the production branch. Were they all perfectly tested, including in how they interact? Not entirely, and that's a topic for follow-up work. A visualization tool called Conductor At Scale also turns a generic git history into an arcade-style animation, with Conductor tracks exploding across the screen in JavaScript.

Lessons from the run

The first lesson is to keep the conversation with a single agent where possible and hand sub-agents only simple, predetermined tasks that need no interaction. Two practices support that.

• Minimize waiting between agent and human. A /roastme command is a good way to surface hard questions up front so an agent can run uninterrupted, and Conductor is good at collecting questions offline. Instead of a 30-second question every five minutes, you answer everything in one 30-minute block, go for a bike ride and come back to a finished app.

That screenshot shows /roastme running inside Conductor, typos included.

• Keep the agent and sub-agent relationship lean. Industry talk points toward elaborate multi-agent hierarchies, but in 2026 the safer choice is simple, repeatable tasks that are heavy on implementation and light on ambiguity, which avoids needless orchestration overhead.

There's also an orchestration tax. Writing code is cheap, specification is what matters, and testing and accepting the results are the new bottleneck. Others in the field seem to agree. Teams can get ahead of that curve or get trampled by it.

For those wanting to try the approach, the starting point is the Antigravity 2.0 desktop app, which offers visual multi-track orchestration out of the box.