Key takeaways
- Seven components carry every automated workflow: intake, the run record, the step executor, the model boundary, the approval queue, connectors and credentials, and observability. A system that disappoints is usually missing the fourth, fifth or seventh.
- The run record is the component everything else depends on. Without a durable record of where a run got to, a system cannot resume after a failure, cannot pause for approval, and cannot tell you afterwards what it did.
- An approval queue is only real if a run can wait in it for days without holding anything open. A gate implemented as a blocking pause is a gate that will be removed the first time it causes an outage.
- Keep the model boundary narrow and explicit. A step that calls a model needs a defined input and a checked output, or the variance leaks into every step downstream.
- Observability means a named person is told, not that a dashboard exists. Ask who received the alert for the last failure, and how long after it happened.
Why the anatomy matters if you are buying rather than building
The parent guide describes an automated process by who performs each step: fixed code, a model, or a person. That is the right lens for designing a process. It is the wrong lens for judging a system, because two products can split the steps identically and behave completely differently on the Tuesday one of them fails halfway through.
This page uses the other lens. Not who does the work, but what the machinery is made of. You will not build any of it, and you do not need to. What you need is the vocabulary to notice which part is thin, because a missing component never announces itself. It shows up as a run that vanished, an approval nobody can find, or a question about last month that nobody can answer.
The seven components
| Component | What it is for | What a weak version looks like | What that costs you |
|---|---|---|---|
| 1. Intake | Notices that work has arrived — a schedule, an email, a changed record — and decides whether this is genuinely new. | It polls on a timer and has no idea whether it has seen this item before. | The same invoice gets processed twice, and you find out from the supplier. |
| 2. The run record | A durable note of what this run is, which step it reached, and what each step produced. | State lives in memory for the duration of the run and disappears when it ends. | Nothing can resume after a crash, nothing can pause for a person, and nothing can be explained afterwards. |
| 3. The step executor | Carries out the steps in order, retries what is safe to retry, and stops cleanly on what is not. | Every failure is retried identically, including the ones that already had an effect. | A payment retried three times is a different kind of incident from a lookup retried three times. |
| 4. The model boundary | The one place judgment is called, with a defined input and an output that gets checked before anything downstream uses it. | A model is consulted at every step, and its output flows onward unexamined. | Model prices and model variance on arithmetic, and a wrong classification quietly corrupting five later steps. |
| 5. The approval queue | Where a run waits for a person, for as long as that takes, carrying enough context to decide. | Approval is a blocking pause, or an email with a link and no record of what was decided. | Gates get removed the first time one causes an outage, and nobody can reconstruct who agreed to what. |
| 6. Connectors and credentials | Reaching your actual systems, with scoped access that can be revoked without breaking everything else. | One shared account with broad permissions, often a real person's. | You cannot answer who did this, and an offboarding breaks production. |
| 7. Observability | Any past run can be opened and understood, and failures reach a named person. | A dashboard of green charts, and alerts into a shared mailbox. | You hear about the failure from the customer, three weeks after it started. |
Component two is the one everything else leans on, and the one most often thin. A durable run record is what makes the difference between a system that can resume, pause and explain itself and one that can only start again. Notice that components five and seven are impossible without it: a run cannot wait three days for an approval if its state evaporates, and nobody can inspect a run from last month that was never written down.
On component seven, Google's engineers are direct that monitoring exists so a human is told when something breaks or is about to, and they distinguish symptom-oriented monitoring, which reflects problems actually happening, from internal signals that predict them. Both are useful. Neither is a chart nobody looks at.
On component five, the EU AI Act's human oversight requirements expect an overseer to be able to interrupt a system through a stop button or equivalent procedure, and to stay alert to the pull of over-relying on its output. Those duties bind high-risk systems specifically, and most operations work sits well outside that. The architectural implication travels anyway: a system with no way to halt a run in progress has no gate, only a notification.
One run, traced through all seven
Components are easier to hold onto when you watch a single piece of work move through them. This is one supplier invoice, from arrival to filed.
- 01Intake notices an email with an attachmentTriggerIt checks whether this document has been seen before, using something stable from its contents rather than the filename. Duplicate suppressed here, or paid twice later.
- 02A run record is openedCodeA durable row exists now, before any work happens. Everything after this point writes to it, which is what makes the rest of the sequence recoverable.
- 03The executor starts the ordered stepsCodeFetch the purchase order, fetch the goods-received note. Both are safe to retry, so a network blip costs a second attempt and nothing else.
- 04The model boundary is crossed exactly onceAI judgmentThe invoice has no fixed layout, so a model extracts the fields and classifies the mismatch: price change, partial delivery, duplicate, wrong entity. The output is checked against the purchase order before anything downstream trusts it.
- 05The run enters the approval queue and waitsHuman approvalThe difference exceeds tolerance, so it stops. The run holds nothing open while it waits — no connection, no process — and can sit there over a weekend. The approver sees the invoice, the order, the gap and the model's reasoning, and their decision is written to the record with their name on it.
- 06Connectors write the result backCodeApproved, so the ledger is updated and the document filed, using credentials scoped to those two systems and nothing else.
- 07Observability closes the loopCodeThe run is inspectable from now on. Had the ledger write failed, the record would show exactly which step, and a named person would have been told rather than a colour changing on a dashboard.
The two design choices that separate these systems
Where the model sits. Some systems call a model to decide what to do at every step, on every run, forever. Others use one while learning the process and then settle the known steps into fixed code, keeping the model only where the input is genuinely open-ended. The first is faster to demonstrate. The second is what makes run five hundred cost roughly what run five hundred should cost, and it matters more the longer a process lives.
How waiting is implemented. A run that pauses for a person either holds something open or it does not. If it does, approvals are under pressure to be quick, and the gate becomes a formality or gets deleted after the first incident. If the run can be suspended to the record and resumed days later, an approval can take the time it needs. This single decision determines whether your permanent gates survive contact with a busy week, and it is almost never mentioned in a product comparison.
Both choices point the same way. Google's engineers describe automation as a progression whose value is consistency and a platform to build on, and both of these are platform decisions. They are cheap at the start and close doors quietly for years.
Limitations and when not to use this
- Seven components is a working model for judging systems, not a specification. Real products merge some and split others, and a system that names them differently is not thereby worse.
- This describes business-operations workflows: work spanning everyday tools at human timescales, where a run pausing for two days is normal. Systems built for high-throughput or low-latency work make different trade-offs, and several of the arguments here would be wrong there.
- Nothing here reports how any particular product is built. The components are what the work requires; how a given vendor implements them is a question for a demo, and the tools guide turns each row into something you can ask.
- Nothing here is legal or security advice. The credentials and audit questions touch obligations that depend on your jurisdiction, your industry and the data involved.
Sources
- Monitoring Distributed Systems — Google, Site Reliability Engineering Accessed 27 July 2026
- Automation: The Evolution of Automation at Google — Google, Site Reliability Engineering Accessed 27 July 2026
- Article 14: Human oversight — EU Artificial Intelligence Act Accessed 27 July 2026
Turn this into demo questions
The components here are only useful if you can test for them. The tools guide turns the same anatomy into six questions and a two-week evaluation you can run on one real process.
Turn this into demo questionsUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.