Orchestrating with Antigravity: A Crescendo of Agents (Part 2)

Parallel Coding with Git Worktrees, Conductor++, and Agostina

Alexis said ‘This is the year of Agent orchestration’: I couldn’t agree more with him! If 2025 was the year of the AI agent, 2026 is definitely the year of… AI Agents!

If you read Part 1 of this series, you know my confession: I’m a CLI guy. I don’t do UIs. But when I tried to orchestrate a team of parallel subagents to build a simple clock game (orologia.io), my terminal babysitting workflow completely broke down. Juggling tmux panes, file checkouts, and Apple Stickies stuck to terminal windows to track active runs was a cognitive nightmare.

I capitulated and opened the Antigravity 2.0 UI/Desktop app to manage the visual feedback loop of comparing my Flutter code with a 10x better, 20-second vibecoded JS prototype. It saved my sanity.

But once you have a visual harness that works, the immediate developer question is: how far can we scale this?

This concept of using a multi-agent harness to build apps in parallel was inspired by Richard Seroter’s recent article One prompt, four subagents and ninety seconds to get a working app, where he demonstrated spawning four parallel developer agents to construct a working application in under two minutes. I read Richard’s piece when it came out but had to wait a bit before getting my hands on the new Antigravity 2.0 UI harness. Yesterday (June 16), I finally sat down to play with it, and this second article is what came out of that session.

If Part 1 was a soloist sandbox and a simple clock game, Part 2 is about heavy-duty parallel engineering. Today, we’ll see how we took the Antigravity Desktop app and scaled it up to a massive 12-track SRE simulation (Project Benjamin) using Git Worktrees, a Rails-like orchestrator called Conductor++, and a concierge agent named Agostina.

💡 Looking for Part 1? Read Orchestrating with Antigravity: A Crescendo of Agents (Part 1) to learn about stateful remote sandboxes and Python SDK orchestration.

The problem: scaling past the CLI

When you scale from a soloist agent to a crescendo of parallel agents—where a coordinator agent spawns subagents, manages branch checkouts, and handles human-in-the-loop approval requests—the CLI simply stops scaling cognitively. You can’t track it all in a flat scrollback buffer.

Then last weekend I read this article from my Seroter namesake and thought: OMG, this is exactly what I need. I need a visual harness to manage my concurrent agents, and Antigravity 2.0 is the best at this!

This clean interface has it all:

• 📁 My personal Project 1
  • 🧵 Improve UI by adding blue login button with hidden password
  • 🧵 Add /checkout/ to backend
• 📁 My work Project 2
  • 🧵 Add documentation to doc/PRD.md
  • 🧵 Add security tests after later omg/1234.

As you can see, all your unrelated work is nicely grouped by project (basically, a folder) and then all threads are aligned there, sorted by the most recent one you worked on (and yes, you can ARCHIVE them, otherwise they’ll survive my wife’s sadistic reboot).

When it hit me

As I was saying, I was reading Richard’s magic prompt on my throne and thinking: I just want to do this, plus a few things!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

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 [..] to 'architecture.md'.
2. **Backend Engineer**: Build an API based on [..] .
3. **Frontend Engineer**: Build a web UI [..] to interact with the API [..].

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

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

Let’s unpack this prompt. It contains:

1. What you want (a hotel booking app).
2. Your team of 3 sub-agents.
3. How these sub-agents interact (what time / which way).
4. What happens when they’re done (spin up and let the human-not-so-much-in-the-loop take a look).
5. Important. the common file state here is the common artifact: architecture.md.

Brilliant. This is meta-programming at its best: you don’t prompt the code you want, you’re prompting the TEAM of workers you want coding your thing! Another step into emergence and you’re prompting… scion!

In the past few months, all I wanted to do was GHI-triggered multi-agent implementation!

• GitHub Issue Integration. Every subagent should work on an issue, if its defined.
• As a Ruby on Rails developer, I know the value of having your code on Rails. The Rails for AI imho is the Conductor extension by my buddy Keith. I use it for all my serious projects.
  • Let’s be honest, not always a GHI has what it takes for an agent to go and do things. Sometimes you need a HITL to answer the hard questions. This prevents the implementation for being sloppy (“of course I meant just for authenticated users!!!”)
• git worktree. This is what prevents 2+ agents for making a mess out of your repo (been there done that).
  • If you have N agents pushing Pull Requests to remote branches, it makes sense to have a “Git concierge” to resolve the code to main. He should be configured to have a more conservative approach to the repo. While agent X wants to implement feature X as instructed, this Concierge will be unfazeable as a British Alfred (turns out only GURPS players know what this means) and act as a ’last defense’ for your repo consistency (maybe the code is great, but forgot to run tests, or to update the CHANGELOG… nothing’s better than a fresh context window to catch these errors).

🛠️ Equip Your Agents with the condutree Skill

To make this entire multi-agent git-worktree workflow reusable for any codebase, I packaged these exact rules and automations into an open-source agent skill called condutree (technically, conductor-worktree-hitl).

Why did I build this as an external skill rather than dumping all the git/worktree commands into the main coordinator prompt?

1. Conflating the Logic: It consolidates all the low-level workspace provisioning, symlinking, and git excludes in a single, maintainable script.
2. Manageable Coordinator Prompts: It keeps the prompt given to the main coordinator agent small, clean, and focused entirely on the high-level main-to-subagent delegation workflow and reentrant question resolution. The agent doesn’t need to get bogged down in git syntax; it simply delegates that execution to the skill.
3. Reusability: Other developers can instantly plug this skill into their own repositories and agent harnesses to gain safe, conflict-free parallel agent executions without rewriting the integration scripts.

You can find the code and details in my public gemini-cli-custom-commands repository (and be sure to star the new devrel-cli repository where I’m centralizing all my developer advocacy automation tools!).

Equipping your Antigravity coordinator and subagents with this skill teaches them:

1. Worktree Provisioning: How to safely check out independent git worktrees for concurrent tasks.
2. Git Hygiene: Symlinking the shared Conductor metadata folders while excluding them locally so git status remains clean.
3. HITL Polling: The dual reentrant protocol for posting issue comments, reading local registries, and polling answers without exhausting API quota limit ranges.
4. Local Commits & Notes: Standardizing local branch commits and signing off details via Git Notes without direct remote pushes.

⚠️ v1.0 Limitations & Looking Ahead to v2.0

While condutree v1.0 is a solid foundation, it still has a few manual edges that we plan to streamline in v2.0:

• Automatic Symlinking: Fully automate the symlinking of .env configurations and shared runtime files alongside the main conductor/ folder.
• Streamlined Helpers: Replace ad-hoc shell commands with a clean Python or Ruby helper script to handle weird worktree git states robustly.
• justfile Integration: Package this script under conductor/bin/git-status-patched.sh and expose it via a clean recipe (e.g., just git-status-condutree) so developers can view patched git status of active worktrees instantly.

While the clock game taught us that multi-agent systems require a visual feedback loop to align code with user expectations, we needed to see how this workflow behaves under heavy SRE workloads. Enter Project Benjamin…

Scaling Up: Conductor++ Multi-Worktree Multi-Agent Dev Flow

To see how far we could push this parallel execution model, we built Project Benjamin—a complex, real-world SRE automation and incident command simulator. We weren’t just testing toy apps; we wanted to run a multi-agent system that could audit cloud environments and coordinate incidents across multiple isolated workspaces at the same time.

Here is how we designed and optimized this parallel dev flow:

1. The Preparation: Setting Up for Great Work

Before we could run this without file collisions and merge chaos, we had to solve some tricky git hygiene and naming issues:

• Preventing Git Worktree Symlink Pollution: In our Conductor++ setup, each parallel agent gets its own Git Worktree (e.g., .worktrees/telegram_incident_creation/). Because subagents need to communicate metadata back to the parent coordinator, we symlink the root conductor/ directory into each worktree:

  1	ln -s ../../conductor conductor

  However, Git ordinarily sees a symlinked tracked folder inside a subdirectory as both a deleted folder and a new untracked file. To prevent this working-tree pollution:

  • We configured the local repository’s .gitignore to explicitly ignore conductor/questions.json and track-specific question folders.
  • We updated the Conductor orchestration prompt to run a dynamic Git exclude command within each worktree:

    1	echo "conductor" >> $(git rev-parse --git-dir)/info/exclude

    This instructs Git to dynamically ignore the symlink inside that specific worktree, keeping working trees 100% clean.

• Personifying the Coordinator: To give our DevFlow an approachable, unflappable personality, we named our Lead Git Concierge coordinator Agostina. Agostina behaves like a calm, organized Italian concierge running on espresso, ensuring that parallel subagents (Mario, Luigi, etc.) remain in sync without stepping on each other’s toes.

• The Amanuense Scribe Agent: To maintain a high-resolution, real-time chronicle of all parallel development events, we introduced a dedicated scribe agent called Amanuense. Amanuense continually logs directory creation, code changes, and agent interactions with precise timestamps, outputting them to a central audit file so developers can audit exactly who did what, when, and in which worktree.

2. The Logic: Parallelism Without the Chaos

Running multiple AI agents coding in parallel on the exact same repository requires strict isolation and a race-free way to communicate.

• Subagent Git Hygiene (No Direct Remote Pushes): If multiple subagents attempt to run git push concurrently, they will trigger lock collisions on remote refs and introduce untested code into production. Subagents commit exclusively to their local feature branches (feature/<track_id>) and write summarizing git notes. Only the coordinator (Agostina) is permitted to run git push, checkout the validation branch, and merge feature branches.

• Dual Reentrant Question Protocol: Instead of using a single global questions.json file (which introduces write races when multiple subagents ask questions concurrently), we designed a dual reentrant protocol:

  1. Isolated Local State: Subagents write questions to their private track folder (conductor/tracks/<track_id>/metadata.json). This is 100% race-free.
  2. GitHub GHI Comments: Subagents post the question as an issue comment with a unique tracking signature: [conductree:<track_id>:<question_id>].
  3. Smart Polling: Agostina runs a polling script that first checks if any local track is in "awaiting_human" status. If none are, it skips the GitHub API poll entirely (saving 95%+ of API quota). When it finds a matching comment answer on GitHub, it updates the local metadata to "answered", waking up the subagent.

• Cascading Conflict Loop Resolution: In a parallel multi-worktree execution flow, merging the completed feature branches one-by-one can create a “cascading conflict” scenario. Imagine Mario’s branch is merged cleanly into the validation branch, but Luigi’s branch has merge conflicts.
  If the human developer resolves Luigi’s conflict directly on the validation branch, Luigi’s original feature branch in .worktrees/telegram_incident_creation/ is still conflicting and out-of-date. To prevent this drift, Agostina automatically cherry-picks or merges the conflict resolution back into Luigi’s feature branch. This ensures that the subagent’s isolated worktree remains up-to-date and syntactically aligned with the validated codebase.

• Pushing to Pull Requests (PRs) & Visualization: Instead of having the coordinator push the merged validation branch directly to main (which bypasses code review gates), we route the final integration through a Pull Request (PR).

  1. The Flow: Subagents commit locally. Agostina pulls, validates, and merges the branches locally. Once all integration tests pass, Agostina pushes the unified integration branch to remote and invokes the gh CLI to create a Pull Request:

     1	gh pr create --title "feat: unified parallel implementation" --body "..."

  2. PR Visualization: The human operator reviewer can visually inspect diffs, review CI checks, and interact with the code using GitHub’s native UI. To make this process fully transparent, Agostina updates the Conductor registry’s metadata.json with the created PR URL and displays active PR status locally using gh pr list and gh pr status.

• Conceptual Incompatibility & Subagent Termination: Parallel execution can also lead to conceptual conflicts or logical incompatibilities between two tracks (e.g., track A implements a feature that track B refactors in an incompatible way). If Agostina detects such irregularities, she is authorized to immediately terminate one of the conflicting subagents. The cancellation must be documented directly on the GHI (GitHub Issue) for the terminated agent’s task, and the issue must be blocked/linked against the other active agent’s GHI to preserve clear decision ancestry.

3. The Execution: Orchestration Lifecycle

The orchestrator lifecycle is defined as follows:

graph TD
    A["Start: Define Tracks"] --> B["Agostina: Provision Git Worktrees"]
    B --> C["Symlink conductor/ & Configure info/exclude"]
    C --> D["Launch Subagents Mario, Luigi, etc."]
    D --> E{"Subagent Blocked?"}
    E -- Yes --> F["Post GHI Comment + Write Track JSON"]
    F --> G["Agostina: poll_ghi_questions.py"]
    G -- Answer Found --> H["Update Track JSON to answered"]
    H --> E
    E -- No / Completed --> I["Subagent: Local Commit + Git Notes"]
    I --> J["Agostina: Checkout Validation Branch"]
    J --> K["Agostina: Sequential Merging"]
    K -- Conflict? --> L["Human Resolves Conflict"]
    L --> M["Agostina: Update Subagent Branch with Resolution"]
    M --> N["All Merged & Validated"]
    K -- Clean --> N
    N --> O["Agostina: Push & Create PR with gh CLI"]

1. Provisioning: Agostina sets up the isolated worktrees and launches the subagents.
2. Execution & HITL: Subagents code independently, using the polling script to handle high-fidelity human-in-the-loop (HITL) questions.
3. Merge & PR: Agostina sequentially merges the code, driving conflict resolutions back to the source worktrees, pushes the final integrated branch to remote, and opens a unified Pull Request (PR) via the gh CLI for human review and final merge to main.

Case Study: Project Benjamin (Full Multi-Agent Speed Run)

To prove that our Conductor++ Multi-Worktree pipeline works in real production environments, we set up Project Benjamin as a stress test.

We went into full multi-agent mode. Instead of playing with one or two toy features, we took 12 complex, critical SRE capabilities and broke them down into more than 20 concrete GitHub Issues (GHIs).

Then, we let the machine rip.

In just 5 hours, the Conductor++ pipeline successfully built, tested, and merged all 20+ GHIs into the main branch!

The scope of implementation was massive: from setting up OpenTelemetry (OTEL) tracing in Cloud Run to writing interactive Telegram incident wizards and pending mutation approval registries.

Here are the operational facts and results of this live execution:

🚦 Integration & Merge Results

Using our parallel Git Worktree orchestration, all feature tracks were developed, tested, and fully integrated into the main branch. Below is the final status audit of the SRE features:

📸 The Workflow Timeline (Visual Audit)

Here is the step-by-step progression of the SRE Benjamin run, showing how the coordinator, scribe, and parallel subagents worked without stepping on each other’s toes:

Step 1: Initializing SRE Tracks & Worktrees

The parent coordinator initialized the workspaces on the host machine. The Conductor inspector CLI tracked active tracks and assigned subagents (e.g. grazia for Discord war-rooms, pinocchio for pending mutations queue).

To monitor the active tracks, branches, and agent statuses across all parallel workspaces, we run the Conductor Inspector CLI tool:

1

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

Here is the terminal console output captured during initialization:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

================================================================================
  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
================================================================================

Step 2: Parallel Worktree Isolations

Each agent checked out its own branch and worked in isolation. The Amanuense scribe logged precise file edits and workspace activity without file conflicts.

Step 3: Interactive Polling & Human Steering

When agents needed clarification (such as verifying Telegram token configuration), they posted issues that were parsed by poll_ghi_questions.py.

Step 4: The Final Green State

Once all feature branches were validation-checked and sequentially merged, Agostina created the Pull Request. The final audit output confirmed all 12 SRE tracks were fully merged into the production branch.

The coding Framework

I want to use:

• git worktree for async agent implementation
• GitHub Issues + Conductor “Railways” (someone would say boundaries) for implementation.
• The gemini-superpowers plugin, which provides the using-git-worktrees skill used to isolate our parallel subagents.
• “Antigravity 2.0” as harness, inspired by Richard’s article
• State on Disk, inspired by Paul article.

🛠️ Developer Note: This page is compiled and synced from an external repository.

• Do not edit this file here: Any changes made directly in this repository will be overwritten and lost.
• Deployment & Workspace Dependency: To learn how this page ended up here, see the RICCARDO_NOTES.md at the root of this repository.
• Redeployment Command: To edit the source drafts and redeploy, run:

  1	cd /usr/local/google/home/ricc/git/ricclife-with-gemini-pvt/work/articles/20260605-worktree-multiagent-dev-flow/ && just build && just copy-to-ricc-rocks