The Agent That Runs the Other Agents

The agent that runs the agents is the only one that matters

Most of what AI does for me now isn't a single answer to a single question. It's a small set of recurring jobs that notice each other, share what changed, and stop at the boundary where I actually need to decide something. One of those jobs is to wake the others up. That's the agent that matters. The one that runs the others.

I've been building operating companies for thirty years. Every one of them eventually hit the same wall: not enough hours, too many recurring decisions, and a leadership team carrying the cognitive load of remembering what changed since last Tuesday. AI agents don't fix that problem by being smart. They fix it by being organised. The smartest agent in your stack is worth nothing if it doesn't know which other agent should hear about what it just found.

So this piece is about the layer above the agents. The control pattern. The thing that makes ten agents add up to more than ten agents.

What's actually the unit of work here?

Most people frame this wrong. They treat AI like a search box. Ask one question, get one answer, close the tab. Same thing again next week. The prompt was never the job.

The job is the recurring situation that produced the prompt. The school trip is the job. The packing list is one output. Knowing the trip is happening, finding the email, checking the weather, comparing against what the kid already owns, deciding what to buy , that's the job. A prompt covers one slice of it. A loop covers the whole recurring sequence with memory.

So the unit of work isn't the question. It's the loop. A loop is a recurring job with state. It knows what happened last time. It knows what you already own, what you already decided, what's pending, what's blocked. It runs when its trigger fires, not when you remember to open the chat window.

That distinction changes what you're building. You're not building a smarter assistant. You're building small remembered workflows. Most of the operator's work goes into deciding which workflows are worth remembering, and which ones should fire each other.

Where do apps fit, and why are they not enough?

Apps give you pieces of loops. Never the loop itself.

Your email holds the school confirmation. The school portal has the schedule change. The weather app has the forecast. The grocery app has the list. Your calendar has the meeting that just got conflicted by the new pickup time. Every piece of the loop lives somewhere. The wiring between the pieces lives in your head.

That wiring has been the user's job for twenty years. It's why software-as-a-service hit a ceiling. SaaS sold you the database and the dashboard. It never sold you the loop. The loop was always free labour you provided on top.

The first agent worth building isn't another app in a box. It's the thing that sits across the loop, carrying the wiring. The first agent worth building twice is the one that sits across multiple loops and decides which one wakes up when something changes.

This is also why I keep telling regulated mid-market firms to stop counting tool licences and start counting loops. A firm with eighteen AI subscriptions and no remembered workflows has eighteen new places where context can leak and zero new throughput. Agent count is a vanity metric. Loop count is the operating metric.

How does a loop of loops actually behave?

Take the school trip again. A loop detects the trigger. The trigger fires several loops at once.

The packing loop checks what the kid already owns. The weather loop sees rain. The schedule loop sees pickup moved an hour earlier. The calendar loop sees that new pickup time conflicts with a 4pm meeting. The message loop drafts a note to the other parent. And then it stops. It doesn't send. You see the draft. You decide.

That last beat is the whole game. The loop of loops self-organises around context. It hands off cleanly. It collapses five separate mental tabs into one decision point. And it stops at the boundary where judgment matters.

The control pattern has four moving parts. A world state the agent engages with. A set of reasonable choices it can reason through. An action it can take safely. A loop back to do it again next time, with what it learned.

Before you let a loop run, it needs to answer a handful of questions. What can it do safely on its own. What should it surface for a human. What record does it leave behind so the next pass is smarter. How does it get smarter. And, the one most people skip: which other loop should hear about what it just found.

That last one is the loops-of-loops question. If the trip loop finds rain, who else needs to know? If the hiring loop finds a candidate, who needs to know? If the finance loop sees a charge tagged travel, should the trip loop be told? Most of the value compounds at those handoff points. The handoffs are where the use lives.

What's a good first one to build?

Start where the downside is funny, not catastrophic. If the loop runs off the rails and you can live with the result and laugh about it, that's a candidate. If a misfire creates a real cleanup, pick something else.

Bad first choice: anything that touches money movement, regulated communication, or anyone you can't easily call back.

Good first choice: something tedious but contained. My own first useful loop of loops was research. Every Monday I want the top fifty signals from AI Twitter, organised by theme. That's one loop. The loop of loops version pulls from Twitter, from search via Codex or Claude, from a handful of newsletters I already trust, aggregates them, dedupes, and surfaces what actually changed since last Monday. It doesn't send anything to anyone. It produces a brief, on a schedule, in a place I already look. If it misses a story, the only cost is that I miss a story too.

Around that I have loops that evaluate whether the brief is rigorous enough, loops for deep research on specific topics, loops that ask whether I'm reading enough opposing views on a position I'm forming. None of them act outside the research surface. All of them feed each other.

A second pattern I'd recommend for an operator: take a recurring administrative process you actually run. Writing use cases for your product. Loading them as Linear tickets. Feeding those tickets into a loop that drafts a first-pass PRD. The downside of a bad draft is a bad draft. The upside is you stop being the manual conveyor belt between three tools that should have been talking to each other from day one.

What changes when you start thinking in loops?

The questions you ask about your own work change. You stop asking where the pain is. You start asking what you're willing to hand off from a process perspective, in a shape you feel safe handing off.

Pain is a useful signal for individual loops. Pain tells you where the recurring tax is. But a loop of loops isn't a pain question. It's a delegation question. Getting the kids ready for summer camp isn't one pain point. It's a process. Closing the books for the month isn't one pain point. It's a process. Onboarding a new client at a mid-market firm isn't one pain point. It's a process. The question is which of those processes you're prepared to let an organised set of agents run, with you at the boundary points only.

That reframing is the thing most operators miss. They keep hunting for the killer prompt. The killer prompt doesn't exist. There is only the killer process you're willing to delegate, broken into loops, with one loop above them deciding when each one wakes up.

Building that is mostly not technical work. It's the work of describing your recurring processes in enough detail that they can be acted on. Same work any decent operator has been quietly doing for thirty years, in their head, where it never compounded for anyone else.

This is the part that interests me. The agents get more capable every quarter. The loops get easier to wire. The bottleneck is now the operator's clarity about what their own recurring jobs actually are. Firms that figure that out will pull away from the ones still buying more agents and waiting for one of them to be smart enough to organise itself.

The agent that runs the other agents is the only one that compounds. Everything else is a feature.