What You Are Actually Deploying

People buy a model and think they bought the system. The model is one layer of four, it is the layer you have the least control over, and it is almost never the layer that fails.

Every one of these systems, from a one line script to something running unattended across a company, has the same four layers. Being able to name them is worth more than it sounds, because it turns a vague failure into a specific one.

Model

The reasoning engine. It reads what you put in front of it and produces text, which may include a decision to use a tool. Everyone argues about this layer. You have the least leverage over it, because you did not build it and you can swap it in an afternoon.

What matters here is narrower than the discourse suggests. Is it good enough at your task, what does it cost per run, where does the data go, and can you change your mind later. That last one is worth designing for now. Write your system so the model is a line of configuration rather than an assumption baked into a hundred places.

Environment

Everything the system can reach. Files, databases, APIs, email, the calendar, the internet. This is the layer that decides what the system is capable of and therefore what it is capable of doing wrong. It is the governance layer, though it rarely gets called that, and it is where the question from chapter two actually lives.

Two properties of the environment matter more than anything else about it. What is reachable, and what is writable. Those are different questions and they deserve different answers, which is the whole of chapter seven.

Feedback

How the system finds out whether what it just did worked. A command returns an error. A file appears where one was expected. A validation check fails. A person clicks approve.

This is the layer people skip, and skipping it is the single most common reason an automation is quietly abandoned. Without feedback, the system cannot tell success from failure, so it reports success either way. A system that always reports success is worse than no system. Now a person has to check everything, and has been told they do not need to.

Flow

What happens in what order, what runs at the same time, what waits for a person, and what happens when a step fails. In a fixed workflow you wrote the flow. In an agent, the model proposes the flow and your fence constrains it.

Flow is also where approvals live. An approval gate is not a policy sitting in a document. It is a place in the flow where the system stops and cannot proceed. Chapter thirteen is largely about moving rules out of documents and into this layer.

How they nest

The layers are not peers. Each one bounds the ones inside it, which is why failures propagate the way they do.

• Flow bounds what can happen at all.
• Environment bounds what can be touched inside that.
• Feedback bounds what can be known about what happened.
• Model decides within all three.

The practical consequence: you cannot fix an outer layer problem by changing the model. If the system deleted something it should not have, a better model reduces the odds and changes nothing about the exposure. If it cannot tell whether it succeeded, no model fixes that. Most of the frustration people have with these systems comes from tuning the one layer they rent while the broken layer is one they own.

Where to start when you are building

In the order that saves the most rework:

1. Environment first. Decide what it can reach before you decide anything else. This is cheap now and expensive later, and it is the decision an executive will ask you about first.
2. Feedback second. Decide how you will know it worked. If you cannot answer this, you are not ready to build, whatever the demo looked like.
3. Flow third. Sequence, approvals, and what happens on failure.
4. Model last. Start with whatever is cheapest and adequate. You will change it within a year regardless.

This order is close to the reverse of how most projects run, which is a reasonable summary of why most projects have to be rebuilt.