The DOE Blueprint

Say your agent gets each step right 9 times out of 10. That sounds like a system you can trust. The number is lying to you.

One step at 90% is fine. Real workflows are chains. Read the email, classify it, extract the amount, update the tracker, notify someone. Chain five steps that are each right 90% of the time and the whole run comes out right 59% of the time. Your agent never made a big mistake anywhere, and 4 out of 10 results are still wrong.

This lesson is the architecture that stops the rot. It has 3 layers and one rule, and by the end you will have a DOE map of your own workflow: what is written down, what the AI decides, what code executes.

The math that kills naive agents

Errors multiply. 90% of 90% is 81%, and it keeps going down from there:

Steps in a row     1     2     3     4     5
Comes out right    90%   81%   73%   66%   59%

Run 100 emails through a 5-step chain and about 41 come out wrong somewhere. Not wrong in the same place, either. Step 2 mislabels one, step 4 pulls the wrong number on another. The failures scatter, so you cannot even predict where to check.

The instinct is to reach for a better model. That helps less than you would hope, because it only raises the base. Move every step from 90% to 95% and five chained steps still lose 23 of every 100 items. You paid more per call to fail a little less often.

The architecture answer changes the exponent instead: cut the probabilistic steps down to one. One decision at 90% stays at 90%. Everything before and after it runs as code, and code does the same thing every time, at 3am, on the 4,000th email, without getting creative.

Three layers, one judgment call

The architecture is called DOE: Directives, Orchestration, Execution.

Directives. Written rules in a plain text file. What the categories are, what happens to each one, what wins when two apply. This is the exact file you wrote in lesson 3. Nothing clever about it. It reads like an employee handbook page, because that is what it is.

Orchestration. The model. It reads the directive, looks at what came in, and makes the one decision. Which category. Which lead. Which numbers changed enough to mention. That is its entire job.

Execution. Deterministic code does the doing. Adds the row, sends the forward, applies the label. Same inputs, same result, every single run. No judgment lives here on purpose.

If this smells like lesson 1's three boxes, it should. The trigger and the action both live in Execution. The agent box is Orchestration. The directive is the new piece: it is the boss's written instructions that the middle box reads before deciding anything.

One rule holds the whole thing together: the AI never touches business logic directly. It does not calculate the total. It does not write to the tracker. It does not send anything to anyone. It reads the rules, makes the call, and hands a decision to code.

Run the 5-step chain from earlier through this lens. Fetching the email is Execution. Extracting the amount, updating the tracker, and sending the notification are Execution too. The only step that ever needed judgment was the classification. Five probabilistic steps collapse into one decision plus four operations that cannot drift, and 90% stays 90%.

Edit text, not code

Here is why this architecture matters more to operators than to developers.

Say the triage agent from lesson 1 needs a fifth category. Job applications have started landing in the inbox and they keep getting labeled needs_reply, so a person reads every one. In a tangled mega-prompt, adding a category means rewriting one giant instruction and hoping nothing else shifts. In a DOE system it is 3 new lines in the directive:

Categories: urgent, needs_reply, newsletter, invoice, job_application
Priority when two apply: urgent > invoice > job_application > needs_reply
Example: "Re: Ops Manager role, resume attached" -> job_application

That is the whole change on the decision side. The switch downstream gets one new exit that files applications into the hiring folder, which in a visual builder like n8n is a 2-minute click. No developer. No deploy. The business rule changed because someone edited a text file, and that someone can be you.

This is the operator superpower the whole course is built on. The system's behavior lives in a document you can read, and changing the document changes the system.

Keep the old version when you edit. If Thursday's emails start landing in the wrong folder, you can see exactly which 3 lines changed on Wednesday and put them back. Try doing that with a prompt someone rewrote from memory.

The mistake, and the fix

Lesson 1's mistake was a lazy prompt. This one is worse, because it looks like it works.

The mega-prompt asks the model to decide and to act in one breath:

Read this email. Decide what it is. If it is an invoice, add a row to the
tracker with amount and due date, forward it to bookkeeping, then archive
the email. Confirm when done.

The reply comes back confident:

Done. I classified the email as an invoice for $1,840 due July 25, added
the row to the tracker, forwarded it to bookkeeping@, and archived the
original.

A specific amount, a specific date, a tidy confirmation. Now the reality check:

Tracker rows before: 14
Tracker rows after:  14
Bookkeeping inbox:   empty
The email:           still unread

The model described three actions and performed zero. That is not a bug and it is not bad luck. A model produces text. It can only produce text that sounds like it acted, and it is extremely good at that sound.

The fix is the blueprint. Shrink the model's job to the decision, and make its output something code can act on:

{"category": "invoice", "amount": 1840, "due": "2026-07-25"}

Then Execution takes over, and Execution keeps receipts:

add_row   ok   tracker rows 14 -> 15
forward   ok   message id logged
archive   ok

Same email, same model. The difference is that nothing in this log is a claim. Each line is an operation that either ran or errored, and you can verify every one of them.

Recap

Errors compound. Five steps at 90% each is 59% end to end, and a better model only raises the base. Architecture changes the exponent by cutting the probabilistic steps to one. Directives hold the written rules. Orchestration makes the single decision. Execution does everything else the same way every time, and it logs what it did. When an output claims it acted, trust the log, not the sentence.

Next lesson you build all of this for real: the email triage agent, in n8n, running on your own inbox.