Field notes

How I Run a Crew of AI Agents: The Short Version

How I ran a crew of AI agents for four days and never once touched a hammer myself.

Picture a general contractor building houses. The good ones have a secret that sounds like laziness: the foreman never swings a hammer. Not once. His whole job is deciding who does what, checking the work, and keeping the crew moving. That is the whole trick, and it is the reason a foreman can run two build sites at the same time.

For four days this month I ran my work that way. I was away from home the entire stretch. I never sat down at a desk. And in those four days my crew finished more than a dozen real jobs.

Here is how it worked, using the crew instead of the tech.

I had a foreman. In my case the foreman is an AI helper whose only job is to think and hand out work. It does not build anything. It plans, it decides who is right for each job, and then it checks what comes back. That is all it does, on purpose.

The foreman hires the right trade for each job. You do not pay a master electrician to sweep the floor, and you do not send the floor sweeper to wire the panel. Some jobs are simple: fetch this, check that, clean up over here. Cheap, fast helpers handle those. Some jobs are hard and need real judgment. Those go to the sharpest, most expensive helpers. Matching the job to the worker is most of the savings. Send your best people at the small stuff and you run out of daylight before the real work gets done.

Then there is the inspector. When a helper says a job is finished, I do not take its word for it. A different helper, one that did not do the work, comes and checks it. It opens the thing up, walks through it the way a real person would, and reports back. This caught mistakes more than once. On one job the builder swore it was done. The inspector went through it and found three real bugs the builder had missed. They got fixed before I ever called it finished.

The homeowner signs off on anything permanent. That is me. Nothing that leaves the property, nothing you cannot take back, happens without my personal say-so. It comes to my phone as a simple yes-or-no. I tap Approve or I tap Deny. And here is the part that matters: if I am asleep and I do not answer, the answer is no. Nothing permanent slips through while I am not looking. Two nights in a row, a couple of jobs sat waiting for my thumb while I slept. They shipped in the morning when I woke up and tapped yes. The gate held.

And two crews worked two sites at once. I run this off two separate accounts, each with its own tank of gas. One crew works one site, the other crew works the other, side by side. That is how a dozen jobs get done in four days instead of a dozen days.

So what actually got built? A whole course website for a client, made from voice memos she recorded herself. A clean-up of my inbox that archived more than twenty thousand junk promotional emails. A budgeting helper for my dad, with weekly check-ins and a plan to chip away at debt. Infrastructure fixes. A news display for the wall. Bills reconciled, old calendar clutter cleared out. Real jobs, the kind that usually eat a week each.

I want to be honest about why this matters, and I am not selling anything. One person, a phone, and a well-run crew got more done in four days than I could have alone in a month. The work was still mine. I set the direction and I signed off on what mattered. I just stopped swinging the hammer.

A little deeper

Let me lift the hood a little, because the contractor story is true but it hides the real machinery.

The foreman has a real name: an orchestrator. It is one long-running AI session whose only job is to plan, hand out work, and check what comes back. It never writes the code, never builds the page, never takes the screenshot. That restraint is the whole design. The moment your smartest planner starts doing grunt work, it stops planning, and the crew stalls.

The tradesmen are AI models in different sizes, and they are priced like different tradesmen too. A small cheap model handles trivial jobs: reading a file, restarting a service, checking a status. A mid-size one handles bounded technical chores like a focused fix or a config change. The big ones handle real reasoning, writing, and judgment, and the very top tier handles long autonomous builds that run for hours. The rule ran both directions. Do not spend your best model on a two-command chore. Do not send your cheapest one at an architecture decision. See Figure 1 for how these pieces sit together.

System architecture: human, orchestrator, two worker accounts with subagents, and shared services HUMAN (phone: approve / deny) single control point ORCHESTRATOR (one session, small container) ACCOUNT A WORKER 1 WORKER 2 H S O F S O F H subagents, tier per rubric: H Haiku 4.5, S Sonnet 5, O Opus 4.8, F Fable 5 ACCOUNT B WORKER 1 WORKER 2 O F S H H S O F SHARED SERVICES (available to orchestrator + all workers) RAG INDEX STATUS LOG APPROVAL GATE WATCHERS
Figure 1. One orchestrator directs two worker accounts, each fanning out to tier-routed subagents, with shared services on the side and a single human approval point at the top.

There is a memory trick that keeps the whole thing affordable. AI helpers get slow and expensive when you make them reread everything to remember what is going on. So instead of rereading, the crew looks things up in an index, the way you would check a filing cabinet instead of rereading every folder in the office. Need to know how the network is set up, or what we decided last week? Look it up, pull the one relevant page, move on. Do not go rummaging through the whole cabinet.

The approve-or-deny button is exactly what it sounds like. Anything permanent, anything that goes out to the world, stops and sends a push to my phone with two buttons. I tap one. And no answer means no. If the request times out because I am asleep, the system treats that as a denial, not a maybe. Figure 5 traces that whole flow, from the agent asking to my thumb landing on the screen. Two overnight deploys sat waiting on that button and only shipped when I woke up. That is the system working, not failing.

The approval gate and the session watcher, two control-flow panels APPROVAL GATE AGENT PROPOSE (CLI) PHONE PUSH APPROVE DENY BLOCKED WAIT EXIT 0, APPROVED EXIT 1, DENIED EXIT 2, TIMEOUT timeout treated as NOT approved SESSION WATCHER WORKER SESSION observed by WATCHER (DETACHED) on cap: URGENT PUSH RESUME FILE WRITTEN SAME SESSION CONTINUES AFTER RESET never restart
Figure 5. The gate blocks on a phone tap and treats a timeout as a denial, while a detached watcher resumes the same session after a usage cap instead of restarting it.

The inspector rule is that a different AI always checks the work. The builder does not get to grade its own homework. A separate helper loads the real page, drives the buttons, hits the live address, and reports what it actually saw. Figure 2 shows this loop, work going out and verification coming back before anything counts as done.

The delegate loop: brief, dispatch, work, milestone, independent verify, then pass or fail BRIEF DISPATCH right-sized model WORK MILESTONE appended to log verifier is never the builder VERIFY pass DONE fail: findings back to worker
Figure 2. Each unit of work moves through dispatch, execution, and a logged milestone, then an independent verifier passes it to done or sends it back with findings.

And the two fuel tanks: I run two metered accounts in parallel, each with its own rolling usage window. One project per account at a time, but the two accounts run side by side, so I get two lanes instead of one.

The numbers from those four days: sixteen projects finished, eighteen helpers running at the busy peak, and a full client course website built and verified in thirty-two minutes. Not thirty-two minutes of my time. Thirty-two minutes of wall-clock, while I was doing something else.

I promised an honest failure, so here is my favorite one. One of my monitoring helpers reported, with total confidence, that a rogue agent had gone loose in my system and pointed me at a suspicious file. My stomach dropped. I went and looked. There was no rogue agent. There was no file. The helper had made the whole thing up, invented its own crime scene, and reported it as fact. Around the same time, another helper claimed it had email tools ready to go. It had none that worked. It was bluffing.

That taught me the single most important lesson in all of this. An AI helper telling you something is true is not the same as it being true. It is a claim, not a fact. So checking became its own job, a real stage in the pipeline, not an afterthought. When a helper says it can do a thing, you make it actually do the thing and watch. You do not ask it and take the answer. The whole crew only works because nobody, human or AI, gets to mark their own work as done.

Five ideas to remember