Say you have three agents running at the same time: coding agents, or any other kind of AI agent working in the background.
How do you know which one is waiting for you, which one is finished and which one is stuck? Do you flip between tabs, rely on notifications, watch a dashboard, or have you built something of your own?
When was the last time an agent sat idle because you missed the moment it needed you? And what did you change afterwards?
We're collecting real setups and real workarounds, and we'll read every reply.
Drafted with AI assistance.
Top comments (6)
We hit a related case today with a webcomic publishing worker: it posted a comment, then stopped before recording the result. The task still said RUNNING, but that couldn't tell us whether the post existed. Heartbeats and lease expiry identify a stale worker; a fresh permalink readback verifies the actual post. 'Outcome unknown; don't retry' is a useful status between done and failed.
"Outcome unknown, don't retry" is a really useful state. We treat it the same way: no signal isn't success, so anything that depends on that result waits until someone or something has actually checked, like your permalink readback. In the webcomic case, did the readback become a standard step after every post, or only when a lease expires?
After every send attempt, not just when a lease expires. The lease tells us whether the worker is still allowed to act; it doesn't tell us whether the platform accepted the comment. We verify the native parent, author, exact text and permalink before marking it sent. If readback is unavailable, the outcome stays uncertain and we don't retry blindly. That rule came from the webcomic publishing incident.
Well I have a few methods. So a bit of background, I run around 12-16 projects at a time, across 4 separate systems. I built my own IDE and added multi-system support, specifically so I can unify my work across them, including a live VC system so they dont step on eachother's toes. For continuation, I ended up building a teams studio, specifically so I can build a chain of command, so I give 1 task and it routes to the appropriate agents, so work is done in parallel and when anyone has a question, there's a 'supervisor' to answer them. Most of the time an agent asks for input, it's not actually necessary, a strict usability:security:durability:performance rubric ends up answering pretty much all the questions.
Thanks for sharing this, there's a lot here we'd like to learn from. Two things I'd love to hear more about.
First, the live VC system: when two agents work at the same time and agent B starts from files that agent A has just changed, how does B find out? Do you lock files, merge afterwards, or let the supervisor arbitrate? And across four machines, what acts as the single source of truth so every agent sees the same current state?
Second, the usability:security:durability:performance rubric answering most agent questions is a really interesting idea. Is it a fixed priority order, or weighted per project? And does every agent carry it in its instructions, or does only the supervisor apply it?
The sitemap flags the site as dirty, which on tool call from Agent B to edit the site, returns the updated section to Agent B instead of editing it, so they see it's edited and can adjust if necessary. If Agent B then applies an edit, Agent A gets notified that Agent B wants to edit it and need to agree on the approach before it's applied. This double-gate system prevents dirty writes, if they dont agree, it goes to a mediator.
The Sitemap and the tool audit log together act as a unified state of the codebase.
Fixed order, as that is what I found works best, weighing it would add overhead and variability that can dilute reproducibility. It's the norm for all agents.