Build Agents That Amplify You

The system is designed from the ground up with the agentic layer in it. You don't take an existing tool, workflow or security process and add models to it afterwards. You reimagine the system with models as a foundational part of it — deciding where they belong, and where they don't, as part of the design itself.

In practice, this comes down to where you start. Most people start with the system they already have and ask where a model could fit into it. This principle says: don't. Start with a blank page instead. Ask what the system should look like if models had been available when it was first designed. Then build that.

The difference shows up everywhere. Some steps that a person used to do become steps a model does. Some steps disappear, because they only existed to help a person cope with volume. And some steps are new — a check on the model's output, a point where the agent pauses for a human decision. None of those exist in the old system, so you can't get them by adding a model to it. You only get them by designing with the model in mind from the start.

You can tell when this principle has been broken. It looks like a tool you already know, with a model added in one place — a chat box, an "explain this alert" button, a summary at the top of the page. The tool works exactly as it did before, and the model sits on top of it. That's the opposite of what this principle asks for.

This is not automated security. The analyst stays in the loop; the agentic layer plugs in at specific points as a force multiplier — extending what an analyst can do, sometimes past their own ceiling, and scaling it. The goal is a sharper analyst, not an absent one.

In practice, this is a question you ask about every place a model does work: is the analyst still making the decisions here, or has the model quietly taken them over? The model can read the evidence, do the first pass, sort what's worth a look from what isn't, and draft the write-up. All of that makes one analyst able to do far more. But the call on what it means, and what to do about it, stays with the analyst.

The reason is accountability. When something goes wrong — a real intrusion missed, or a false alarm that shut down a production system — someone has to be able to say why the decision was made. A model can't do that. It can explain its reasoning, but it can't answer for it. So the person stays in the loop not because the model is weak, but because somebody has to own the outcome.

You can tell when this principle has been broken. Look at where the human ends up. In an alert pipeline where the human's only job is review, they arrive right at the end, after every machine step has run. That's what happens when you automate without thinking about it: the person gets pushed to the edge and handed whatever the machines couldn't finish. If your design has the analyst doing nothing but approving what the model already decided, you've automated them, not amplified them.

Humans, deterministic code, and now the agentic layer are three distinct systems, each with strengths and weaknesses. Not every problem needs an agent — most of the work stays deterministic code. The craft is engineering the system so the agent is used only where it earns its place, and its weaknesses are contained everywhere else.

In practice, this means every job in the system gets given to one of three workers, and you choose which one deliberately. A person has judgment, and judgment doesn't scale. A model can reason, but it's probabilistic — sometimes confidently wrong — and it can't act on your system by itself. The third worker is ordinary code. It can't reason at all, but it's fast, free, testable, and gives the same answer every time.

So you match the job to the worker. Adding up a million rows is a job for code. Deciding what an unusual pattern means is a job for the model. Deciding whether an incident is real is a job for a person. Get any of those wrong and the system is worse than it needed to be: a model doing arithmetic is slow and unreliable, code trying to interpret is impossible, and a person reading raw logs is the problem we're trying to solve.

You can tell when this principle has been broken, because it almost always breaks in the same direction: too much model. The agent is the interesting part, so it gets reached for first, and ends up doing jobs that code could have done faster and more reliably. Most of the work in these systems is plain code, and should stay that way. The model has to earn each job it gets.

These three — collaboration by design, amplify not automate, and the right system for the right job — are the principles I use to decide how the whole system should work.