I was at a whiteboard the other day with a mate who's new to all this, sketching out a system with him. And he kept reaching for the same tool for every single box on the board: an agent. Ingest the data? Agent. Sort it? Agent. Move it from here to there on a timer? Agent.
That's the most common mistake I see, and it's worth saying out loud:
Most people reach for an agent when they need a process, and a process when they need judgement.
So before you build anything, you sort every box on the board into one of two piles.
Process or decision
Every step in a system is one of two things.
A process is deterministic. You already know the rule. Given the same input, you want the same output, every time. Pulling a price feed, moving a file, formatting a record, firing a webhook — you don't want creativity here. You want it boring and identical at 3am on a bank holiday.
A decision is ambiguous. The rule isn't fixed, the input is messy, and getting it right needs judgement. What is this thing? Where should it go? Am I sure? That's where intelligence earns its place.
The rule of thumb that falls out of this:
Don't pay for a brain where a rule will do.
Agents are the most expensive, least predictable tool in the box. Use one only where a genuine decision lives. Everywhere else, a script or a cron job is faster, cheaper, and won't surprise you.
The pipeline on the board
Here's the system we were drawing — a thing that takes in market data and does something useful with it. Walk it top to bottom (tap the nodes above to interrogate each one).
Data comes in — oil, an API, a stock feed. That's a process. Pull it on a schedule. A cron job. No agent anywhere near it.
Then it hits ingestion and classification. This is the fork. This is the one box on the whole board that's actually a decision — what is this, where does it belong, how confident am I? This is the only place the intelligence belongs.
Then it routes based on that confidence — to a human, or to auto.
That's the whole shape. One decision, surrounded by processes. Almost every system you'll ever build looks like this: a small amount of judgement wrapped in a lot of plumbing.
When the human stays in the loop
The fork is the interesting bit. Once you've classified something, you either let the system act on its own, or you put a human on it first. Here's how I decide.
Keep a human in the loop when:
- Being wrong is expensive. If a bad call costs real money, trust, or a relationship, a human checks it.
- Volume is low enough that a human can keep up. Ten a day? A person handles that. Ten thousand? They can't, and you'll need another answer.
- You're still learning the edges. This is the one people miss. Early on, you don't actually know the rules yet — so everything routes past a human. They're not a bottleneck. They're a teacher. Every correction they make is a labelled example.
Fire it to auto when:
- The pattern is stable. You've seen this case enough times to trust the classification.
- Errors are cheap to undo. If a mistake is recoverable, you don't need a human standing guard.
- Volume is high. At scale, auto isn't a nice-to-have — it's the only thing that works.
Living is learning
The title on the whiteboard was Living is Learning, and that's the actual point.
A good system doesn't start fully autonomous. It starts mostly human in the loop — slow, supervised, watched — and it earns its way to auto as the classifier gets things right often enough to be trusted. You don't design the autonomy in on day one. The system grows into it.
The dial moves one notch at a time. Confidence climbs, the human steps back, more of it runs on its own. And the bit the human still touches is always the newest, hardest, least-understood edge — which is exactly where a human should be.
So the whole game, in one breath:
Reach for the cheapest mechanism that survives contact with reality. Cron before script, script before agent. Put the human where being wrong is expensive and you're still learning — and take them out once the system has proven it doesn't need them.
That's it. That's system design.