agentic engineering
An operating model for building software with AI agents — specification-driven and human-gated.
- origin
- designed 2025 · adopted organisation-wide 2026
- scope
- product · design · architecture · engineering · quality · documentation
- method
- eight artifacts · six human gates · guardrails per assignment
- status
- in production
01What it is
Specify, then generate. Not the other way around.
A way of working in which the specification is the interface to the machine, and the human effort sits before implementation rather than inside it. Roughly 80% specification, architecture and validation; 20% agent-executed implementation.
Specification as the interface
Numbered capabilities, each one implementable and acceptable on its own, with acceptance criteria a machine can fail rather than interpret generously.
Gates that can refuse
Six of the eight steps stop until a person decides. Nothing commits itself and nothing publishes itself.
Guardrails around what must not move
Protected legacy zones are declared per assignment. An agent that reaches one hands control back instead of improvising.
Agent output is a hypothesis
Review findings are re-checked, individually and with refutation as the default, before any of them reach a person.
Knowledge as a completion condition
Decision records for decisions, incident reports for bugfixes, the implementation plan filed next to the code it produced. A missing one is a finding, not a gap.
Depth matched to the task
Work is classified at intake by type and size, and the classification decides how much of the chain runs. A two-line fix does not pay for a new capability's ceremony.
02My role
I started it, and the hard part was not the technology
What I started. In June 2025, together with a colleague from engineering, I designed the operating model — before there was a mandate, a budget line, or a platform. A mid-size software vendor was maintaining a core product built since 2001 while running its successor in parallel, with one team. The problem was never that we should be faster. It was that the arithmetic did not close.
What I own inside the model. Problem definition, product requirements, the prototype that tests an assumption before it becomes a commitment, architecture approval before implementation, and validation at the end. What I do not do is type the implementation.
Method before platform. The practice ran organisation-wide for ten months before any tooling existed to support it: alpha team in September 2025, whole organisation in January 2026, platform in April 2026. That order was not strategy at the time. It is the reason the results cannot be attributed to a vendor.
What made it hard. Not the agents. Four developers in a pilot correct each other in conversation; six teams across six roles do not. Everything that looks like apparatus in this model is the cost of the word organisation-wide — and it had to reach product, design and quality, not only engineering. A practice that changes engineering alone has moved the bottleneck rather than removed it.
What I state carefully. The pilot compared measured effort against an estimate of the conventional path. That baseline was never executed, and I say so rather than rounding it away. The lane model that scales process depth to task size is the least finished part of the system.
03Written up
I am publishing the method in full, including the parts that did not work.
Part 1 — The work got faster. That was the easy part.
Where this started, what the pilot showed, and what stopped being protected by slowness.
Part 2 — A human would have asked.
A developer repairs an ambiguous specification silently. An agent interpolates and ships. Why the artifacts had to change shape.
Part 3 — Four developers was easy. Six teams was not.
Why the standard has to become an object, and why it could not stop at engineering.