The Support-System Doctrine

In 2022 I wrote a manifesto for a company I was running called Agentsmith. It had a line in it I’ve quoted to myself more times than anything else I’ve ever written:

“An Agentsmith makes support systems for humans, not replacements for them.”

At the time I wrote that, I couldn’t have told you exactly why it mattered so much beyond it feeling true. Four years and a real production system later, I can point to the actual code that came out of taking that sentence seriously, and I can also point to the specific ways I’ve watched other people’s projects fail by not taking it seriously. This is the doctrine, and this is the evidence.

Replacement-framing produces brittle automation

Here’s the pattern I’ve watched repeat, in my own early mistakes and in other people’s systems: someone builds an agent, frames it internally as “this replaces the person who used to do X,” and ships it. Two things go wrong, and they go wrong in a specific order.

First, technically: a system built to replace a human has no natural place for the human to intervene, because intervention wasn’t part of the design brief — the whole point was that the human wasn’t supposed to be there anymore. So when the agent does something wrong, which it eventually will, there’s no seam in the architecture where a person can grab the wheel. You end up bolting on an emergency stop after the fact, which is a worse version of a feature you should have designed in from the start.

Second, organizationally: the humans whose job the thing is supposedly replacing correctly identify the threat and either quietly sabotage the rollout or just don’t use it. This isn’t irrational. It’s the predictable response to being told your job is the target of the project. I’ve seen good automation die in adoption, not in engineering, because the framing made every stakeholder in the room an opponent instead of a beneficiary.

Replacement-framing doesn’t just risk backlash. It produces worse systems, because “no human ever needs to touch this” is a design constraint that removes your best failure-recovery mechanism before you’ve even shipped.

Support-framing produces adoption — and better architecture

The alternative isn’t a compromise position, it’s a better engineering choice that happens to also solve the political problem. If the agent is explicitly built as a support system — something that makes the human faster, better-informed, less exhausted, not something that makes the human unnecessary — then human touchpoints aren’t a retrofit. They’re load-bearing from day one.

This is where the doctrine stops being a nice sentence and becomes code. In the media-buying system I run against live ad spend, every action that touches money routes through a write-approval gate: a human has to sign off before the action executes. That gate isn’t a leftover from an earlier, less-trusted version of the system that I’m planning to strip out once the model proves itself. It’s the architecture. It’s the same idea as the manifesto line, just compiled.

Build a system on “the human is being replaced” and an approval gate looks like an admission of failure — a concession you make until the automation is good enough to stand alone. Build it on “the human is being supported” and the same gate looks like exactly what it is: the actual product feature, the reason the system is trustworthy enough to run against real money at all. Same code, opposite meaning, depending on which doctrine you started from. I didn’t discover the approval-gate pattern by accident. I built it because I already believed the sentence I wrote in 2022, and the sentence told me where the seam had to go.

”Agentsmiths are brave enough to be updated.”

There’s a second line from the same manifesto that matters just as much, and it’s less quoted because it’s less obviously about the humans on the other end of your system — it’s about the Agentsmith:

“Agentsmiths are brave enough to be updated.”

I read this now as the other half of the same doctrine, aimed inward instead of outward. If you build support systems instead of replacements, you’re implicitly saying your own judgment isn’t final — that the system should surface disagreement, catch your mistakes, and change your mind when it’s right and you’re wrong. That only works if you’ve actually built yourself to be updatable, not just the system. A support system built by someone who can’t tolerate being contradicted by their own tooling will quietly get its warnings ignored, its gates rubber-stamped, its circuit breakers overridden out of impatience. The brave part isn’t building the guardrail. It’s respecting it at 2am when it’s inconvenient and you’re sure you’re right.

The honest test

Here’s the test I use now, on my own systems and other people’s, to tell replacement-framing from support-framing without having to ask anyone what they intended: turn the agent off. Not gracefully, not with a migration plan — just off. Can the human still do the job?

If the answer is no — if the process has atrophied around the automation to the point where nobody remembers how the manual version worked, where the knowledge lived in the agent and nowhere else — that’s a replacement, whatever the marketing called it, and it’s fragile in exactly the way replacement-framed systems are always fragile. If the answer is yes — slower, less informed, more tedious, but the job still gets done because the human never stopped being the one who actually does it — that’s a support system, and that’s the only kind I’ll ship anymore.

A good agent makes the human more capable. Not unnecessary. More capable. That’s the whole doctrine, and I wrote it down before I had any idea what it would actually cost to build correctly. It’s still the test I trust most.