Visualizing Coding Agents Across Providers

Visualizing Coding Agents Across Providers

# ai# showdev# productivity# webdev
Visualizing Coding Agents Across ProvidersOdd Essentials

Four agents were working for me on a Tuesday night. One was rewriting a database layer, one was...

Four agents were working for me on a Tuesday night. One was rewriting a database layer, one was chasing a flaky test, one was drafting docs, and one was doing something to the build that I had stopped following an hour earlier.

At 11:40 the fourth one went quiet.

Was it finished? Stuck? Sitting on a permission prompt, politely waiting for me to type "yes" while I was in another window? The screen had simply stopped moving.

That silence is why I built Agent Guild, a local page that runs every coding agent CLI side by side and draws what each one is doing. This post is about the drawing: how you visualize agents from five vendors who each describe their work differently, and where the picture has to admit it can't see.

A terminal is a river of characters

A terminal does not label anything. Nothing on the screen says "this is a shell command" or "this is the agent asking for help". If the screen is all you have, you are guessing from the shape of the text, and the guess breaks every time a vendor changes a spinner.

So the screen can't be the source of truth. Every modern coding agent has hooks: a way to run a small program when something happens, such as a turn starting, a command running, a helper agent being spawned, or a permission being requested. Agent Guild installs a small reporter into each tool's hooks at launch. The reporter turns each event into a short message to a local manager: "session 12 ran a shell command", "session 12 is waiting on permission", "session 12's helper finished".

The screen becomes the fallback. The only thing taken from it is whether output is still flowing: a card says Working while it is, and drops back when it stops. That is an inference, and the page treats it as one.

Layer one: the board

The first picture is a board of cards. One card per tool at the top, with its account, usage left and model grades. One card per session below, with the model in use, the working folder, and the session's helper agents as lettered circles.

The board: one card per tool, one card per running session, helper agents as lettered circles

Look at the Antigravity session in the bottom left. Its agents row says reporting off, with a Why? beside it. That is the most important pixel on the page. A blank row would look like "no helpers running". Saying "I can't see this" is the difference between a dashboard you can trust and one that quietly lies.

Five crews, five dialects

The board is only as good as what each tool will tell it, and the tools disagree a lot. Here is what each one reports today:

What the board can show Claude Code Codex CLI Grok Build Docker Agent Antigravity CLI
Model in use Yes Yes Yes Yes, from 1.100.0 Yes
Helper agents Yes Yes Yes Yes No
Shell commands Yes Yes Yes Only the ones it asks about No
Waiting on your permission Yes Yes, but not refusals No No No
Turn ended by an error or a cancel Yes Cancel only Yes No No
Usage left Yes Yes No No No

A few of those cells took real digging:

  • Codex CLI reports a permission request but never says the command was refused, so a command it asked about is closed at the end of its turn instead of sitting on the board forever.
  • Grok Build lists a good set of events, but the exact message shapes weren't in its public docs; I read them out of the program itself. It never reports a permission request, so a command waiting for approval looks the same as one still running.
  • Docker Agent fires no pre-tool hook for commands it runs without asking, so in autonomous mode its shell commands are invisible to hooks.
  • Antigravity CLI reports the model, its conversation and each turn's answer, and nothing about helpers or commands.

None of this fails loudly. The card for a Grok session simply shows less than the card for a Claude session, and a reasonable person assumes the app is broken rather than the tool being quiet. Half the work went into making the gaps visible instead of empty.

Layer two: the Yard

Cards are good for reading. They are bad for glancing. With six sessions open, I wanted to know who needed me without reading any text at all.

So the same facts are also drawn as a place. In the Yard, each tool is a hall, each session is a character working outside its hall, and each helper agent is a smaller figure that works, waits, idles or finishes. The roster and an inspector sit beside it, and double-clicking a character opens its terminal.

The Living Grove: two Claude Code sessions as foxes working outside their treehouse

Each world draws the same sessions differently. In Goblinville Works it's a smithy crew on a boardwalk; on Orbital Station it's a crew outside domed pods.

Goblinville Works: the same sessions as goblin smiths outside steaming workshops

Orbital Station: the same sessions outside domed pods on a space platform

The Yard reads the same reports as the board. It doesn't know anything more. A Grok character has nothing to show for a permission wait, for the same reason the Grok card doesn't. What changes is how fast your eye finds the one that stopped moving.

The Yard also fits places a board doesn't: there's a VS Code extension that shows it in a small view beside your code, and the whole page works from a phone over Tailscale. The sessions run in a background manager rather than the browser, so closing the tab, or walking away with your phone, doesn't stop anything.

Quiet is not done

Suppose every tool reported perfectly. You still wouldn't know if the work was finished.

Every hook that sounds like "finished" means something smaller. A stop event fires at the end of every turn, not the end of the job. A session-end event is a cleanup signal that doesn't fire if the process crashes. Even the final result record of a headless run only tells you the agent stopped talking.

The people running agents unattended have all landed on the same answer, and it isn't a hook. It's evidence: the tests pass, the pull request exists, the CI run is green, a second reviewer found nothing. The controller decides what done means, never the agent.

That reframed what a visualization is for. It can't tell you the work is finished. It can tell you, as honestly as each vendor allows, what every crew is doing and which one just went quiet, so you open the right door at the right moment. The checking is still yours.

Try it

With Node.js 22 or newer, on Windows, macOS or Linux:

npm install -g @oddessentials/agent-guild
agent-guild
Enter fullscreen mode Exit fullscreen mode

Or try the demo in your browser, simulated with nothing installed.

I'd love to hear how you keep track of agents from several vendors, and which gaps in that table bite you most. If you know a hook I've missed, tell me in the comments.