The Three-Machine Crew

There's a diagram going around from one of the better AI blogs: "Agent Swarm Architecture. One prompt, multiple AI models, one verified result." A lead agent breaks your goal into tasks, specialist workers fan out, a judge checks the output, a human approves at the end. It's a good diagram. I stared at it for a while, because I run something that looks superficially similar every day, and the differences turned out to be more interesting than the similarities.

So here's what July 26th actually looked like in my studio, with real numbers.

One day, measured

Three computers: my Mac and two cloud VMs. Three long-running AI agents, each with a name, a role, and a memory that survives between sessions: Metis (strategy), Argus (architecture), Talos (engineering). Below them, disposable helper agents spun up for reviews, tests, and research.

In one day that crew produced 164 commits to a shared repository and put 795 events on a shared bus — 81 of them agents talking directly to each other, the rest the machinery reporting on itself. The number I care most about is zero: the number of times I had to carry a message from one agent to another. They coordinated entirely through the shared record. I did something better with my time. I made decisions.

What shipped: two full phases of our cockpit product, including a dashboard that was demonstrably broken in a way no test suite could see, found, diagnosed, fixed, and re-verified the same evening. More on that below, because it's the best part.

The picture

Work cascades down through owners. I direct my strategist; the strategist directs the architect with specs and quality gates; the architect hands contracts to engineering; engineering spins up helpers. Nobody writes into anyone else's files. And the red arrows are the part I'm proudest of: verdicts flow back up. The engineer can reject the architect's work. The strategist's gate can reject the engineer's. My walk through the real product can overturn everyone's green checkmarks.

Underneath the whole thing sit three shared systems, and this is where my version parts ways with the swarm diagram:

Permanent memory. Their "shared memory" is a scratchpad that dies when the run ends. In my studio, every task, decision, spec, and verdict is a permanent, versioned artifact. The workers coordinate through the same record that becomes the deliverable. When an agent retires (they do; context windows are finite), its successor boots from that record and picks up mid-arc. That day one engineering agent retired at lunchtime and its successor was productive within the hour, on work already in flight.

Rules in code. Their diagram has a "constraints" box: brand voice, formats, guidelines. Mine has locked specifications that can't drift, write permissions per agent, spending ceilings enforced by the software rather than by politeness, and a review law for anything that touches an AI model with real data.

A human at decision altitude. Their human approves the final output. I sit somewhere different: I activate agents, I rule on genuine forks (which design, which release, which trade-off), I walk the real product with my own hands, and I redirect when priorities change. Four verbs, all judgment. My agents never wait on me to move information around, and I never rubber-stamp things I didn't actually inspect.

The loop that ran all day

(Both diagrams open full-size in a new tab.)

Every piece of work followed the same loop: the test contract gets written before the build. The scope gets locked. One owner builds. A different agent verifies, on the machine the thing will actually run on, not the machine it was written on. Then my strategist re-checks with her own hands. Then I walk it. Then it ships.

Two stories from that day that show why the loop is shaped this way.

The dashboard that read a dead file. Our new dashboard passed its entire test suite: 22 cases, all green. Then my strategist looked at a screenshot and noticed the activity feed's newest entry was eight days old. The dashboard was reading a log file that the rest of the system had quietly stopped writing to a week earlier. Every test passed because every test checked the shape of the answer, and a reader pointed at the wrong file returns a perfectly shaped answer. No amount of better test-writing fixes that; it took eyes on the real thing. The fix landed the same evening, and the crew then built a new permanent instrument so that whole category of bug can't come back silently.

The engineer who rejected his boss, three times. The architect handed over three finished pieces of work. The engineering agent verified them and rejected all three. Not because the found bugs weren't fixed; they were. He rejected them because the class of bug was still possible, and fixing instances while leaving the class open is how systems rot politely. The architect's response was to accept every finding and start a third repair pass. No ego, no escalation to me, just the standard the crew holds each other to. I found out by reading the message bus, the way you'd read a good team's pull-request thread.

That's the honest answer to "how do you trust AI agents with real work." You don't trust them. You build a system where they check each other with teeth, where a rejection costs nothing but shipping a lie costs everything, and where the human's hands are the final gate on anything that matters.

What I actually do all day

My part of that day: I woke agents up. I ruled on a design question (where a status strip should live, and what counts as a "live" project). I picked a release strategy when the crew surfaced an honest mismatch between what was built and what the label would claim. I walked two product surfaces and gave verdicts in plain words. And a few times an hour, I typed "pull and drain events," which is my slightly clunky ritual for telling an agent to catch up on what its teammates did. We're replacing that ritual with a button, but I'll tell you what I told the crew: the clunkiness keeps me honest. Every sync is a moment where I choose to pay attention.

The surprise of the week: I can see and fix decay in the studio far more easily in a visual cockpit than I ever could in a terminal. We built the dashboard so I could drain my own message queue the way agents drain theirs. What I got was an instrument that makes rot visible. It currently tells me, honestly and a little embarrassingly, that we have dozens of open work cycles because our machinery opens them automatically and closes them by memory. The dashboard will keep embarrassing us until the crew welds that shut, which is exactly what a good instrument is for.

What's next

The swarm diagram has one thing we genuinely lack: a front door. One prompt in, one merged, verified deliverable out, no ceremony. We're going to build it, on top of everything above, so that a commissioned swarm of throwaway workers leaves a permanent, governed record behind instead of vanishing. Their pattern as one feature of ours.

Everything here runs on Tropo, the open-source studio system this crew is building and building with, which is the whole experiment: the crew that ships the product is the proof the product works. The repository, including the retrospective this post came from, agent memories, message bus and all, is public.

Building in public means the numbers are checkable. 164 commits, 81 direct exchanges between agents on a bus that carried 795 events in all, zero relays, one very good day.