The AI Workflow Teardown

The interesting question about an agent is not what it can do. It is what it can do without asking, at three in the morning, while nobody is watching. Everything else on this list is a detail if this part is wrong.

1. Write down every action it can take without a human saying yes. Which of those cannot be undone?

   Bad answer: Nobody has the list, and the answer arrives as "well, it has the email tool". The blast radius of an agent is the worst single item on that list — if you cannot recite it, you did not choose it, you inherited it from whoever wired up the tools.

2. When it does ask for approval, can the approver see why?

   Bad answer: "Agent wants to issue a refund of $840. Approve / Reject." Without the inputs it read and the reasoning that got it there, the human is a rubber stamp carrying the liability — and by the tenth one they are approving on sight.

3. Is there an undo for every write it makes?

   Bad answer: Reversal exists for the actions somebody was already nervous about, usually payments. The Slack message, the overwritten CRM field and the closed ticket have no undo — and those are the ones it does a hundred times a day.

4. How do you stop it inside a minute, and who is allowed to?

   Bad answer: Stopping it means a redeploy, and only the person who built it can do that. If the kill switch runs through one engineer's laptop, it is not a kill switch, it is a bus factor.

Models fail differently from software. Software throws; a model returns something plausible and wrong, in the right shape, at the right time, and everything downstream believes it. Design for that failure, not for exceptions.

1. What does it do when the model provider is down or rate-limiting you?

   Bad answer: Nobody has tested it. There are only three real behaviours — queue, fail loudly, or silently skip — and the default in most hand-wired workflows is the third: the run reports success and did nothing.

2. If a run is retried, does anything happen twice?

   Bad answer: Retries were added for reliability and nobody checked the tail of the run: the retry sends the email again, files the second ticket, posts the second refund. Idempotency has to be a key on the action, not an assumption about timeouts.

3. Who finds out when it stops running — and who finds out when it keeps running badly?

   Bad answer: The first has an alert and the second has nobody. A workflow that crashes is a good day. The expensive failure runs on schedule, produces confident output, and has been quietly wrong since someone edited the prompt three weeks ago.

4. What do you run before changing a prompt or moving to a new model version?

   Bad answer: Someone tries two examples in a playground and ships it. A prompt is production code with no type system and no compiler — without a held-out set of cases and expected outputs, every edit is a silent regression waiting for a customer to find it.

Per-token pricing hides the shape of the bill the same way per-second warehouse pricing does: trivial per unit, unbounded per loop. The number that matters is not the monthly invoice — it is the cost of one run, and the ceiling on it.

1. What does a single run cost, and what is the cap?

   Bad answer: You know last month's total and nothing else. Without a per-run number you cannot say whether the automation is cheaper than the work it replaced, and without a cap one unusual input is an open tab.

2. What stops an agent that decides to loop?

   Bad answer: Nothing but the context window. Max steps, max tool calls and max spend per run are a few lines of code that turn a runaway agent from an incident into a log line.

3. How long would it take to move this to a different model provider?

   Bad answer: Nobody knows, because nobody has tried. If the prompts are tuned to one vendor's quirks and the calls are made from forty places in the codebase, your position on the next price change is prayer.

4. What happens the day this model version is deprecated?

   Bad answer: It is treated as hypothetical. Providers retire versions on months of notice as routine housekeeping — a workflow tuned against one snapshot and never re-evaluated will change behaviour on a date somebody else picked.

An LLM workflow is a system that takes untrusted text, turns it into instructions, and executes them holding your credentials. Every question in this section follows from that one sentence.

1. What credentials does it hold, and what could it reach with them?

   Bad answer: It runs as an admin service account "for now", because scoping the token properly was going to be a whole thing. The agent's permissions are its real blast radius, whatever the prompt says it is supposed to do.

2. What personal or customer data ends up in a prompt to a third-party API?

   Bad answer: Whatever happened to be in the row. Nobody has read the provider's retention terms and nobody can produce the list of fields that leave your infrastructure — which is the first thing you are asked for when a customer, or a regulator, asks.

3. Where does untrusted text reach the instructions?

   Bad answer: Emails, support tickets, PDFs and scraped pages go straight into the prompt. Anything that can write text into your inputs can write instructions to an agent holding your credentials. Treat it like SQL injection: assume the input is hostile, keep instructions and data apart, and gate what a stranger can trigger.

4. Is the model output validated before anything downstream consumes it?

   Bad answer: It is parsed and used. A schema check, a range check and a "does this already exist" check catch most of what actually goes wrong — which is not gibberish, it is a well-formed, confident, wrong value.

5. Can you reconstruct one specific run six months later?

   Bad answer: The logs kept the output and not the inputs, or they rolled over after thirty days. When somebody asks why the agent did that on the 14th of March, "the model decided" is not an answer that survives an audit, a dispute, or a customer.