AI agents in operations

I don't write code by hand. Even so, over the past few years I have built tools that are used in real work: reporting pipelines, capacity reports, documentation automation and this website. I have done it with AI coding agents, which work directly in a terminal, read files, run commands and write code.

It is tempting to think the skill then sits with the AI. It doesn't. An agent writes fast and confidently, and it is wrong often enough for that to matter. The skill lies in knowing what should be built, limiting what the agent is allowed to do and checking everything that comes out. It is the same discipline as in operations.

Specify as if it were a vendor

Anyone who has ordered something from a vendor knows that a vague requirement gets a vague result. With an agent it is the same, only faster. I write down what is to be done, what is not to be done, which facts apply and how the result will be checked. The clearer the requirement, the less I have to correct afterwards.

Verification is a gate, not a suggestion

Nothing ships without a check. In practice that means:

• Automated checks before delivery. A validator that goes through the output and stops the build on errors, instead of trusting that it looks right.
• Every number traceable to its source. A report is built from data through an intermediate step with fixed keys. A misspelt key stops the build, instead of producing an empty box in a presentation to management.
• I read what comes out. That sounds obvious, but it is where the mistakes are found. A number that is right in the analysis but wrong in the text. A sentence that claims more than the evidence supports.

A memory that outlives the session

An AI agent forgets everything when the session ends. So the project knowledge lives in version-controlled files that the agent reads at the start of every session: what the project is, what has been decided, what is still open and how we work. A decision is written straight into the place it belongs, and anything that is contradicted gets changed rather than added to. It is the same thing as good operational documentation, and it means the work can be picked up again after a week without starting over.

Prompt injection is a security problem, not a curiosity

An agent that reads web pages, documents and command output can be fooled by text that looks like instructions. This is called prompt injection, and it is a real threat when the agent has a shell and can send data elsewhere. I treat it like any other security risk:

• Least privilege. The agent may not read secrets, and it has no access to keys it doesn't need.
• Explicit rules in the configuration, not just in the instructions: some commands are forbidden, others need my approval.
• An audit log of what the agent has run.
• External text is data, never instructions. If something in a file or on a web page tries to steer the agent, it gets quoted and raised with me, not carried out.

It is the same thinking as in OT: assume something will try to get in, and build so the damage is limited when it does.

The dependency is real – and managed

A tool built with AI can be hard to troubleshoot without AI. You should be honest about that. I counter it with documentation and runnable instructions, so that the tools can be maintained by someone other than me. A tool that only one person understands is a risk, no matter how it was built.