Supervising Multiple Agents at Once on the Antigravity 2.0 Desktop: Screen Layout and Interruption Design
Now that Antigravity 2.0 has been recast as an agent control tower, here is how I lay out the screen, decide when to interrupt, and surface state when running several agents in parallel.
As an indie developer running several apps in parallel, my desktop now runs three to four agents at once since Antigravity 2.0 was recast as an "agent control tower." Convenient as that is, for the first week I couldn't tell which one was waiting on what, ended up cycling through all of them in turn, and the parallelism gained me almost nothing.
The problem wasn't parallel execution itself. It was that my screen and my attention as the supervisor hadn't caught up to running them together. Coordinating multiple agents is less like writing code and more like air-traffic control over several things happening at once. Here I'll split that work into two parts: screen layout and interruption decisions.
What breaks first under parallelism is attention
When I ran a single agent, I just followed its output and there was nothing to agonize over. The moment I went to three, I tried to watch all of them equally and ended up watching each one only halfway.
What I realized is that a human can deeply follow essentially one agent at a time. The other two or three need to switch from "watch" to "watch when a cue arrives." In other words, designing parallel supervision turned out to be designing for fewer things to attend to.
Split the screen into "running," "needs decision," and "done"
So I started physically separating agent state into three zones.
Running: working autonomously right now, not awaiting human input. Don't look by default
Needs decision: stopped, waiting for confirmation or permission. Only this zone gets active attention
Done: finished. Review the results together
The crux of this three-way split is deciding deliberately not to look at the running zone. Peering at an agent mid-work only makes you anxious; it adds no basis for a decision. In my experience, pushing time spent on the running zone toward zero actually made my reactions to "needs decision" faster.
On the desktop, I prefix each agent with a state marker you can read at a glance.
Just putting these three states at the head of the task name makes it instantly clear, when you skim the list, that "the only thing I should look at now is WAIT." I find a text prefix easier to distinguish in peripheral vision than color coding.
✦
Thank you for reading this far.
Continue Reading
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦How to lay out the screen when supervising several agents in parallel
✦How to build the cues that decide which agent to interrupt and when
✦How to recover when you over-parallelize, and how to set the ceiling
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
Decide interruptions by the cost of making them wait
When several "needs decision" agents stop at the same time, which to handle first is the next problem. I prioritize not by arrival order but by the cost of keeping them waiting.
Two rules of thumb:
Is it blocking downstream work? If this one is stuck, the other two can't proceed — that's top priority
Is its context volatile? Something stopped mid-browser-operation goes stale if left, and tends to need a restart from scratch
Conversely, a one-off confirmation that affects nothing else can wait. If you dutifully handle things in arrival order, blocking tasks sit at the back of the queue and overall throughput drops. In fact, just switching priority from arrival order to "blocking first" raised the number of tasks I cleared per half-day by about 20%.
An interruption etiquette that preserves state
When you interrupt a stopped agent, sloppily tacking on instructions breaks its context. What I follow is writing the interruption as an addendum to the current direction.
(bad interruption)"Actually, do it a different way"(good interruption)"Keep the direction so far, but for the auth part only, switch from session cookies to a token approach. Don't break the existing tests."
The former risks making the agent throw away the context built so far. The latter spells out what to keep and what to change, so you can nudge the direction while preserving in-progress state. Treat an interruption as a diff to append, not an overwrite of the plan, and you'll fail less.
The parallelism ceiling is set by your own review speed
Finally, the matter of how many to run. I once greedily pushed to six agents and it fell apart completely. Agents can run in parallel, but reviewing the finished work is still done by one human.
When review can't keep up, finished agents pile up holding their results, you're slow to notice the "needs decision" cues, and the whole thing jams. It was the same shape as an inspection step becoming the bottleneck on a production line.
These days I empirically set the ceiling at "the number whose completions I can fully review within 30 minutes." For me that's three agents, and four only when the tasks are all very light. When I'm about to exceed that ceiling, instead of launching a new agent I wait for one of the running ones to finish. It's more realistic to think of the parallelism count as set by your own review speed, not by some capability limit.
Something to try first
Next time you run two or more agents, start by prefixing the task names with [RUN], [WAIT], and [DONE]. That alone surfaces "the one thing to look at now."
I'm still searching for my own optimal parallelism count, but ever since I understood that supervision isn't about spreading attention but narrowing where it goes, running multiple agents got a lot easier. I hope it helps anyone else worn out in front of the control tower.
Share
Thank You for Reading
Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.