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.

Agentic attacks demand defense that can act at the same speed. Automate the tactical work, and put the defender's expertise into designing, evaluating and improving the system that performs it.

Defense that can keep up

When an attack moves at agentic speed, a defense that waits for a person at every step cannot keep pace. Tactical defense—the moment-to-moment detection, investigation and response—needs to operate at that speed too. Our systems must be able to act within the authority we have given them.

That authority is a design decision. We decide which actions can run automatically, what evidence they require, and when the system must escalate to a person. We test those choices before relying on them and review what happens in operation. Human approval belongs where the decision needs it; making it mandatory for every response creates a bottleneck.

The defender becomes the builder

As that work becomes automated, the defender's role shifts toward engineering the defense. You design the processes, write the skills that guide investigations, define the tools and permissions, and decide what a good result looks like. Your understanding of security becomes part of how the system operates.

That work continues after deployment. You review failures, follow research and emerging attacks, test new approaches, and turn what you learn into stronger defenses. An improvement you make can shape every subsequent investigation or response. That is how automation amplifies the defender: it gives their expertise a reach beyond the cases they could handle personally.

Accountability stays with the people who build and operate the system. They need to be able to inspect its decisions, change its authority and intervene when necessary. Owning those responsibilities does not require approving every individual action.

You can tell when this principle has been missed by looking at the defender's role. If every response waits for their approval, the system still runs at human speed. If nobody evaluates or improves the automated processes, the system has lost the expertise it needs to stay effective. The aim is a defender who can keep building a better defense while that defense is already at work.

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 choosing deliberately between human expertise, deterministic code and model reasoning. People bring knowledge of the organization, set priorities and own the system's design. Models can interpret unfamiliar evidence, but their judgments can be wrong. Ordinary code handles well-defined operations reliably and enforces the rules under which models can act.

So you match the work to the system. Aggregating a million log records belongs in code. Interpreting an unfamiliar pattern may benefit from a model. Setting the response policy and evaluating whether it works belong to the people engineering the defense. An automated response can combine all three: human-defined policy, model assessment and code that checks permission before carrying out an action.

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.

Together, these principles give us a way to build: design the collaboration from the start, automate the work so the defender can improve the defense, and give each part to the system best suited to it. Becoming a builder means turning your security expertise into processes that can keep working beyond your own attention. The value is in how well you design, test and strengthen that defense over time.