Against the first value of the Agentic Engineering Manifesto

The Agentic Engineering Manifesto opens with six values, each phrased as a preference. The first one is this:

Iterative steering and alignment over rigid upfront specifications.

I had spent three days doing the opposite, and it shipped. So this one is not an audit like the others in this series. It is a disagreement, and I want to be precise about how far it goes.

What I did instead

I wrote a 1,153-line specification and then ran it with a single execution prompt. Writing it took longer than the build did. The result is a live price index across three markets, 57 commits, 110 unit tests, 43 end-to-end tests, twelve routes.

The rules I held to while writing it were narrow. Every number measured rather than preferred. Every decision carrying its reason, because a reason survives into the code where a bare instruction does not. Lines like this one, which look absurd without context:

One historical dataset flags 38,620 of 46,589 rows as
CPU-only. Without that filter the median is zero.

That is not a specification of behaviour. It is a specification of a fact about the world that the agent cannot discover from inside the task, and it is the kind of thing steering would have surfaced eventually, one wrong median at a time.

The two principles that pull against each other

Value one prefers steering to upfront specification. Principle seven says context is engineered like code.

Taken seriously, the second one eats the first. A 1,153-line brief is engineered context. Engineering it in advance is exactly what removes the need to steer, because most steering is not correction of the agent's judgement. It is the delivery, one message at a time, of context that could have been delivered once.

That is the claim I would defend. Steering is context engineering performed late, under time pressure, in the least reviewable format available, which is a chat log.

It is also the claim with an obvious limit, so here it is. My brief was not a first draft. It was assembled from a research phase that ran before a line of it was written, which is why it could contain a number like 38,620. Someone writing their first brief for an unfamiliar domain has nothing to front-load, and for them the manifesto's ordering is simply correct. The preference is not wrong; it is a statement about which phase you are in.

What the twelve got right about my build

Several principles describe things the plan did without naming them.

• Right-size the swarm to the task. Investigation was delegated widely, fifteen written reports across thirteen domains. Implementation stayed single-threaded, because parallel agents editing the same files produce a merge nobody can review. That is principle four and the third value at once, and it was a deliberate choice against the more impressive-sounding option.
• Accountability requires visibility. Those fifteen reports are the artefact. Not a claim that review happened, but the review, in a file, with a verdict per rule.
• Optimize the economics of intelligence. The whole build ran on a free preview model, which is either shrewd or the reason it kept timing out, depending on which day you ask.
• Outcomes are the unit of work. The brief specified measured outcomes rather than tasks, which is the difference between "add a rate limiter" and "600 requests a minute per client, keyed on a header the caller cannot set".

The one that broke

Principle eight: evaluations are the contract.

They were. That is exactly the problem. The end-to-end suite was the contract, and it declared no dependency on the application it tests, so the task runner skipped the work and reported success. It went green on a broken chart and green again on the commit that fixed it.

A contract is only as good as the counterparty's honesty, and an evaluation that cannot fail is a counterparty that agrees with everything. I have written about that suite at length in the post on evidence that lies, so I will not repeat the diagnosis here. What matters for the manifesto is that principle eight and principle nine are stated separately, and they should not be. Observability that covers reasoning is worth nothing if the thing being observed is a cached verdict from last Tuesday.

Where the manifesto is doing something the others are not

Of the sources in this series, this is the only one that names its tradeoffs as tradeoffs. The six values are all "X over Y" rather than "do X", and Y is never a straw man. That format is borrowed from the Agile Manifesto and it is the right one, because it survives disagreement: I can say I bought the right-hand side of value one without saying the value is wrong.

Compare that to a list of eight requirements, which has no vocabulary for the case where two of its items conflict.

Next

My honest position after running the experiment: front-load everything you can already justify with a measurement, and steer only what the front-loading could not have known. In my build that ratio was heavily on the first side, and I think that is a property of having built the same thing once before rather than a general law.

The next and last source in this series is Databricks' pattern catalogue, whose continuum ends at multi-agent architectures. I built deliberately short of the end of it, for the reason in principle four, and the post about running that plan has the numbers.

If you want a test for your own work: look at your last twenty steering messages and mark each one as either a correction of judgement or a delivery of context. If most are the second kind, your next brief is longer than your last one, and it will save you the twenty messages.