Barry Henry

The previous post mapped four cumulative layers of agentic engineering — prompt, context, intent, specification — and argued that the industry keeps miscounting them by confusing abstraction levels with tooling. This post goes deep on Layer 4: Specification Engineering.

Layer 4 is the least understood, the least implemented, and the most consequential. It is also the only layer where real production-grade tooling has shipped in 2026 — policy-as-code engines, formal agent contracts, and specification standards — which means the gap between what's possible and what teams are actually doing is now an engineering choice, not a capability limitation.

The industry keeps confusing the layers as each new one gets named. Prompt engineering, context engineering, intent engineering — these are not synonyms, not a progression where each replaces the last, and not marketing terms for the same activity. They are distinct engineering disciplines that operate at different levels of abstraction, answer different questions, and break in different ways when absent.

This post maps the layers as they actually exist in 2026, drawing on the academic formalisation, the practitioner evidence, and the production failures that clarify where each layer's jurisdiction begins and ends.

In the previous post, we mapped the core laws governing engineering teams: Conway, Brooks, Parkinson, Dunbar, Goodhart, and Ringelmann. Each one describes a force that operates on communication structures, coordination overhead, and cognitive limits.

Now introduce AI agents — systems that write code, execute tasks, and produce artefacts autonomously, at a pace no human engineer matches. Do the laws still hold?

Yes. But they don't hold in the same places.

The way you build teams is the way you build software. Not as a metaphor — as an empirical, observable, repeatable outcome. The laws governing how teams form, communicate, and decompose work have been documented since the sixties. They don't care about your best intentions. They operate whether you acknowledge them or not.

Here's the punchline up front: Conway explains where the architecture will fragment. Dunbar explains when. Brooks explains why the obvious fix makes things worse. Parkinson explains why the problem stays hidden. Goodhart explains why your metrics won't save you. And Ringelmann explains why even the people you already have contribute less as you add more. Taken together, they form a coupled system with predictable failure modes — and predictable design levers.

A note on terminology: none of these are laws in the physics sense. They're sociological observations and empirical regularities — patterns that have held up across enough organisations, over enough decades, to be treated as defaults rather than suggestions. They can be worked with, designed around, and occasionally overridden. But they can't be ignored.

This post maps the key laws, shows how they interconnect, and draws out the strategies that follow when you take all of them seriously at once.