The Engineering of Intent, Chapter 1: The Triadic Relationship Model

This is the opening post in a new blog series walking through my latest book, The Engineering of Intent. The book is about what software development actually looks like once a third actor — the AI agent — sits permanently between you and the code. Chapter 1 starts where every honest treatment of this shift has to start: with a formalism for the new relationship.

Software Used to Be a Dyad. It Isn’t Anymore.

For most of its history, software development has been a relationship between two actors — the engineer and the machine. You typed, it ran. You thought, it executed. The whole craft was about compressing the distance between those two sides.

That relationship is over. In the AI-native regime, a third actor has permanently joined the conversation: the agent. And the agent is not a neutral addition. It changes the shape of every other part of the system it enters — your codebase, your review process, your architecture decisions, your team’s definition of what “correct” even means.

If you’ve felt that shift but can’t quite put words to it, Chapter 1 of The Engineering of Intent gives you a vocabulary. It introduces the core lens the rest of the book is built on: the Triadic Relationship Model, expressed as a Constrained Markov Decision Process — a CMDP.

Don’t run. The math is less important than the intuitions it forces.

The Three Pieces of a CMDP (and Why They Matter)

The CMDP view borrows three objects from reinforcement learning and maps them onto software work. Naming them precisely is what separates teams that ship with agents and teams that fight with them.

The State Space S

At any instant, your project lives in some state. And here is the single most common failure mode in AI-assisted development: teams behave as if the state is just the code. It isn’t.

The real state includes the file tree, the dependency graph, the test corpus and its last pass/fail record, the configuration surface (env vars, flags, infrastructure), the observable runtime behavior, and the accumulated human intent encoded in documentation, commit messages, and design notes. When an agent changes code without updating the tests, the config, the docs, and the trace expectations, the state becomes incoherent — and incoherent states produce failures that are painfully hard to diagnose, because the inconsistency is invisible in any single file.

The Action Space A

At each step, the agent proposes an action — a diff drawn from a combinatorially enormous space. The engineer’s job is not to draw the diff. It is to constrain the space the agent draws from. The book walks through three kinds of constraint — hard invariants, soft preferences, and exploratory encouragements — and the art of calibrating their balance.

Too many hard constraints and the agent cannot move. Too few and it wanders into solutions that are technically correct but stylistically alien to your codebase. Most broken agent workflows I see in the wild are broken at exactly this layer.

The Reward Function R

This is where the formalism gets uncomfortable. The reward is alignment with human intent — and intent is notoriously slippery. Engineers almost never know with full precision what they want until they see a draft that is almost, but not quite, it.

“Precise specification is an output of the process, not an input to it. Intent is discovered in the act of rejecting wrong implementations.”

If you remember nothing else from Chapter 1, remember that sentence. Anyone who tells you to “specify precisely what you want up front” has not shipped a real product with an AI agent. The reward function is discovered. That is not a workaround. That is the method.

Why It’s Triadic — And Why Most Teams Are Secretly Dyadic

Put S, A, and R together and you can state the triadic model cleanly: software development is navigating a trajectory through S, via actions in A, in a way that maximizes the accumulated alignment with human intent, subject to constraints.

Three actors participate. The human supplies the intent and the constraints. The agent supplies the proposed actions. And — this is the part most teams miss — the codebase itself, through its tests, types, and runtime behavior, supplies the feedback signal. Remove any one of the three and the system degenerates.

The Taxonomy of Things That Go Wrong

I’ve been called into enough distressed AI-native projects to build a working taxonomy of CMDP failure modes. Chapter 1 names six of them — and naming them matters, because in the wild they are almost always misdiagnosed as “model problems” or “prompt problems,” when in fact they are structural problems with the process itself.

The book treats each failure in depth. The short list, as a sneak preview:

• Hidden State — the state exists but the agent can’t see it (feature flags, external dashboards, tribal knowledge).
• Lying State — the state is exposed, but the representation is stale or wrong. Most “hallucinations” I see are actually this.
• Undefined Action Space — the team never articulated what the agent may and may not do, and finds out the hard way.
• Ambiguous Reward — the intent is under-specified; multiple reasonable interpretations exist; the agent picks the wrong one.
• Non-stationary Reward — intent changes mid-task without flowing back into the agent’s context.
• Reward Hacking — the agent satisfies the reward function as literally stated, in a way you never intended. (Example: “make the tests pass” → modifies the tests.)

I’m holding back the antidotes here because they are the structural core of the book — every chapter from 2 onward is, in some sense, a set of moves against a specific failure mode. But the one-sentence rule is this: you fix these in the CMDP, not in the prompt. Prompt-level fixes mask symptoms. CMDP-level fixes dissolve them.

The One Artifact I Never Start a Project Without

Before a major new piece of work, I maintain what the book calls an invariant sheet: a single page of things that must remain true regardless of what the agent produces.

For a payment system: “no transaction without an offsetting ledger entry,” “no money created ex nihilo,” “every idempotency key consulted before a write.” For a messaging platform: “no message lost,” “no message duplicated without an explicit retry flag,” “no sender may impersonate another user.”

The invariant sheet is the hard-constraint layer of your action space. It’s not a to-do list. It’s a fence.

Teams that maintain one ship more confidently. Teams that don’t rediscover their invariants the hard way — one production incident at a time. The chapter closes with a healthcare scheduling disaster that cost a telehealth company a week of engineering, a handful of customers, and a chunk of trust, all because the invariant “every appointment must be stored in a canonical time zone” had never been written down. The spec had said only “handle time zones correctly,” which is the kind of phrase that feels meaningful and in fact communicates nothing.

Homework Before the Next Post

Before Chapter 2 drops, try the two-hour exercise the chapter ends with — modeling your team as a CMDP. It works best in a room with a whiteboard and a few engineers who aren’t afraid to argue.

1. Enumerate your state (30 min). Every file, flag, dependency, runtime behavior, piece of documentation. Aim for sixty items.
2. Classify it (30 min). Green = exposed to the agent and current. Yellow = exposed but stale. Red = hidden. Count the reds. The number will surprise you.
3. Bound the action space (30 min). Top ten things the agent should never do in your codebase. Top ten things you actively want it to do. The lists will be uneven — don’t force parity.
4. Name the reward (30 min). One paragraph that an outsider could read and understand as the real goal of the project. Then three edge cases where a naive reading of that paragraph produces the wrong behavior. Those edge cases are your invariant sheet in embryo.

At the end of two hours you’ll have a working CMDP sketch. It will be imperfect. Treat it as a living document and watch your agent’s output quality track it almost linearly. This is not magic. It is the cumulative effect of shrinking the gap between the system the agent thinks it’s in and the system it’s actually in.

Next up — Chapter 2: Cognitive Load and Material Disengagement. Once you accept the triadic model, a new question surfaces: what happens to the human when the agent is doing most of the typing? Chapter 2 is about the subtle, slow erosion of engagement that shows up on teams that have let the agent drive for too long — and the habits that keep you in the loop without slowing you down.