I run a small team of AI agents that do real work for me. They’re built on Paperclip and Hermes, and they run on self-hosted models in my own lab rather than against a hosted API. One of them writes. One runs health checks across the lab and reports back without being asked.
When people hear that, the first question is always which model I’m using.
That is not where the work went. Almost none of it was model work. It was architecture: identity, scope, written context, and the specific points where an agent has to stop and ask a person.
The uncomfortable part is that I had already written the rules for this. In November 2015 I published a post about enterprise automation arguing that you earn visibility, then accountability, and only then are you allowed to automate anything. It was about Puppet and Ansible. I ended up following my own argument eleven years later, against a technology that didn’t exist when I wrote it.
So that’s the structure of this piece. Three stages, in order, and what each one actually costs.
What did I write in 2015?
Two rules, and I’d put both of them in a deck today without editing:
“If you do not completely understand the process do not automate it.”
“If you cannot validate do not automate.”
The usual objection is that agents are different because they exercise judgement, so rules written for configuration management don’t apply.
I think judgement makes those rules harder to satisfy, not easier to skip.
A script that runs unvalidated does the wrong thing identically every time, which is annoying and also the reason you eventually catch it. An agent does something slightly different each run. That variability is the entire reason you’d use one. So “did it run” stops being a useful validation. The question becomes whether you can see what it decided, and whether you can stop it.
That is a design problem, and it has to be solved before the agent does anything that matters.
Visibility: can the agent see the job, and can you see what it did?
My first real design decision was that context lives in documents, not in conversation.
Each agent has a written brief it reads before it works: what it does, who it serves, what it must never do, where the source material lives. The brief is a file. It’s versioned, I can edit it, and the agent re-reads it rather than remembering it. A chat history is not an architecture. It’s a transcript.
A thin brief doesn’t fail loudly. It fails fluently.
That’s the failure mode I’d expect most agent programmes to hit, and it isn’t the one everybody is braced for. The fear is that these systems invent things. The more common and more expensive failure is that a vague brief produces plausible output: internally consistent, confidently written, aimed at the wrong target. Nobody notices that plausible isn’t the same as correct until three other decisions are sitting on top of it.
Which is why a brief needs a named owner, not just an author. Somebody has to be accountable for whether it’s still true.
Most organisations have never written down how their own work actually works: who decides, what “done” means, which exceptions are real exceptions. That’s documentation debt, and it was free to carry right up until something started asking.
The other half of visibility is output. Everything my agents do lands somewhere a human reads: a task thread, a document, a comment on the work itself. Not a log file that nobody opens until there’s an incident.
Accountability: who was this acting as?
Every agent has its own identity and its own scoped credentials. None of them share a key.
That one decision answers the first question anybody asks after something goes wrong, which is not “what model was it” but “who was this acting as.” With a shared credential, that question has no answer, and revoking access becomes an outage instead of a control.
Scope follows from identity. Each agent gets the narrowest set of capabilities that still lets it finish its job, and nothing beyond it. The writing agent’s job is documents, so its access is to documents and the task it’s working on. It holds no credentials for the lab, because it has no need of them, and “it has never tried” is not a security posture.
And actions are recorded for accountability rather than for debugging. Those are different bars. A debug log is written for me, this week, while I still remember the context. An accountability record is written for someone who wasn’t there, reading it later, needing to reconstruct what happened and who authorised it. The second one is a harder design target, and it’s the one an auditor will ask for.
Automation: where does it have to stop?
This is the part that took the longest, and it’s the part I’d now build first.
An approval gate is a state in the workflow, not an email convention. The agent reaches a decision it isn’t allowed to make, stops, puts the question on the record, and waits. A person answers. The agent resumes with the answer attached to the work, where anyone can later see what was asked and who decided.
The distinction that matters is between an agent that is told not to do something and an agent that cannot. The first is a prompt. The second is architecture.
Here’s the counter-intuitive result, and it’s the thing I’d most want a sceptical executive to hear: the gates are what let me widen what the agents are allowed to do. I can hand one something consequential precisely because I know where it has to come back to me. Remove the gates and I’d have to shrink the job.
The cost is real, so I’ll name it. An agent that waits for a human is slower than one that doesn’t, and every gate is a person in a queue. Gate everything and you have built a slow intern. The skill is choosing gates by consequence rather than by comfort: gate the irreversible, let the rest run.
What changes at enterprise scale?
Less than people expect. Scale is a difference of degree, not kind. The same design decisions apply, with more at stake and no room to fix them by hand.
Four things I’d put in place before an agent touches a production system:
- Identity per agent, from day one. Retrofitting identity onto a fleet that shares a key is a migration, not a patch.
- A control point between your agents and the models. Mine is a LiteLLM gateway: no agent holds a provider endpoint, and which model answers a given call is a configuration decision rather than a code change. Without a control point you are not governing AI spend or data flow; you are surveying it after the fact.
- A written brief with a named owner. If nobody owns the context, the output drifts and nobody can say when it started.
- Gates chosen by consequence. Name the actions the agent is incapable of taking, and be able to show where that’s enforced.
The honest cost of all this: the expensive part is writing down how your own work works, and that’s the part nobody sells you. It isn’t a product, it doesn’t demo, and it’s the only reason any of the rest functions.
None of this is new
It’s the same sequence I argued for in 2015. See it. Be able to validate it. Then let it run.
The only thing that has changed is the penalty for skipping a step. An unvalidated script does the wrong thing the same way every time. An unvalidated agent does something new.
If you cannot validate, do not automate. I wrote that about configuration management, and I wouldn’t change a word of it for agents.
Happy automating.