Agentic AI workflows in a real business: what they need to not go wrong

An agentic AI workflow needs five guards before it runs unattended: a bounded scope, a gate that can fail its output, a heartbeat that detects a stall, a mandatory final artefact, and a scheduled re-audit of what shipped. We run five such agents on a two-day cycle; the one without a timeout hung silently for 5 hours 14 minutes and published nothing.

At a glance — the five-guard chain:

• Scope: the agent writes to one directory and publishes to one destination.
• Gate: a separate reviewer can fail the output; nothing self-reviews.
• Heartbeat: liveness read from the filesystem, abort at 45 minutes of silence.
• Artefact: success means the final file exists — not that the process exited 0.
• Re-audit: a rotating sweep of what already shipped, because the gate is not perfect.

What do agentic AI workflows need in place to not go wrong?

An agentic workflow is a model that plans, calls tools and acts over multiple steps without a human approving each one. The failure to design for is not a wrong sentence — it is a run that acts unattended and tells you nothing. Every guard below exists because we hit the failure it prevents.

A guard that only runs when somebody remembers to run it is not a guard — it is a habit, and habits do not survive an unattended 1am run.

How do I set up an agentic AI workflow in my business? Seven steps

1. Day one: write the finish state as a filename. Before you choose a model, a framework or a vendor, name the single artefact that proves a run worked — a report, a row in a table, a booked appointment with an ID. “It ran” is not a finish state. “This file exists and contains these fields” is.
2. Pick one job with a fixed input and a countable output. Good first candidates have a queue at the front and a number at the back: enquiries to be contacted, invoices to be matched, records to be enriched. Avoid anything whose output is judged rather than counted.
3. Bound what it can touch. Separate credentials, one destination, no write access to anything you cannot restore. Scope is cheaper than supervision.
4. Build the gate before the agent is any good. A second process — another model, a script of hard checks, or a person for the first fortnight — that reads the output against a written standard and can mark it failed. If the same agent judges its own work, you have no gate.
5. Add the heartbeat and the timeout. Have the agent touch a file as it makes progress, and have something outside the agent watch that file. Liveness must be time-relative and private to the run, for the reason set out below.
6. Make the retry condition the artefact, not the exit code. One condition, checked after the run: is the artefact there? If not, retry once, then alert a human by name.
7. Schedule the sweep. Put a recurring audit of already-shipped output in the calendar, with a recorded rotation position so it resumes where it stopped instead of re-checking the easy first entries.

You are finished when a run can fail at 2am without anyone watching, and the day still ends with either the artefact or a recorded, retried, attributed failure. Until that is true you do not have an agentic workflow, you have a script with an audience.

What actually goes wrong: three failure modes from our own runs

The silent hang. One of our unattended content runs did about 46 minutes of real work, then hung for 5 hours 14 minutes until a hard timeout killed it with exit code 124. Nothing published that day. Because the runner buffered output until exit, a killed run wrote one line to a six-hour log — the most expensive failure mode produced the least evidence. It was the third silent death that month. The existing retry only fired on “exit 0 and no report”, which is to say it handled the cheap failure and ignored the expensive one. If your retry logic reads the exit code, it is not covering the failure that will actually cost you a day.

The watchdog that would have watched the wrong thing. The first design of our liveness check asked whether anything in the run’s working folder was recent. Those folders are reused by later runs, so a check that walks the folder reads a span of days rather than the run in front of it — one of ours reports a 2,841-minute gap that no run ever actually sat through. We caught that while building the watchdog rather than in production, which is the only reason it is a note here and not a second lost day. The fix was to make liveness time-relative and private to the run: each run watches only files created after the moment it started. A monitor that reads shared state is not watching your run, it is watching your disk.

The instrument, not the result. For three reporting cycles we recorded a sharp fall in how often AI assistants cited our pages. The cause was our own measurement code: a change to how the sample rotated meant we were increasingly asking questions that had never been asked before, and a prompt never asked is a prompt never won. Re-polling the original fixed set of prompts on the same day put the rate back where the earlier months had it. Nothing had collapsed. When an agent’s numbers move sharply, suspect the instrument before the world, and never blend a rotating sample with a fixed one in the same headline figure. This is also why we publish the method behind our own measurements rather than only the outcome.

Which tasks can I hand to an agent, and which still need a human?

Autonomy is not a property of the model, it is a property of the worst thing that happens when the model is wrong. Rank tasks by reversibility, not by difficulty.

The third row is where most enterprise programmes stall, because it is the first row where the blast radius leaves the building. It is workable inside ordinary controls — consent state checked before contact, every interaction recorded, a human listen-back over a regular sample — which is the boundary our AI sales agents that run outbound contact and qualification operate in. The limits are set out in what AI voice agents can and cannot do and the outbound compliance checklist for enterprise teams.

How do I know the agentic workflow is working?

Accuracy on a test set tells you very little about an agent running unsupervised for months. Two numbers tell you more, and both are things you can compute this week.

Defect escape rate = defects found after publication ÷ items shipped in the same window. Assume yours is not zero, because a gate that never lets a defect through has almost certainly never been measured. The useful part is the trend and the time-to-detect: a defect found by a scheduled sweep costs an edit, the same defect found by a customer costs the relationship.

Stall threshold = 2 × the longest silence ever observed in a healthy run. Worked: our longest healthy gap between artefacts was 22 minutes, so the abort is set at 45 — roughly double, and seven times under the 314-minute hang it was written to catch. Set it from your own logs. A threshold copied from somebody else’s blog either kills good runs or sleeps through dead ones.

Track them weekly, next to whatever business number the workflow exists to move. If the workflow is contacting leads, that business number is qualified appointments actually booked, not messages sent.

What does it honestly cost to run agentic workflows properly?

The guard chain is more code than the agent, and it is written in the least glamorous order: after each failure, not before. The stall watchdog exists because of three silent deaths in one month. The publish-time guards exist because the first audit of already-published output found a defect class the gate had never been asked to check for, and every rotation of the sweep since has found more of it — a sample tells you a problem exists, not how much of it you have.

Budget for the parts nobody demos: a person who reads the daily report and acts on it, a written standard for the gate to check against, log storage, and the rebuild that comes when the tooling changes under you. The failure mode at volume is shared state — one agent is a script, five agents reusing the same directories is an estate, and our liveness check had to be designed around exactly that. If you are buying the workflow rather than building it, three questions separate a real system from a demo: what is your stall timeout, what can fail a run before it publishes, and how often do you audit what already shipped. A vendor who has never had a run die has never run one unattended.

Agentic AI workflow questions people actually ask

What is an agentic AI workflow, in plain terms?

A model that plans a multi-step job, calls tools to do it, and acts without a human approving each step. The boundary that matters is the last clause: if a person approves every action, you have assisted work, not an agentic workflow, and you do not need most of these guards.

Do I need a governance framework before I start?

You need a written standard for the gate to check against, which is a smaller thing. If you want an existing structure rather than inventing one, the US NIST AI Risk Management Framework, released on 26 January 2023 and voluntary, is the common reference, and Australia’s Voluntary AI Safety Standard consists of 10 voluntary guardrails that apply to all organisations throughout the AI supply chain. Both are voluntary and neither replaces your obligations under existing law.

How long before an agentic workflow is doing real work?

A single bounded job with a gate in front of it is a fortnight of work, most of it spent writing the standard the gate checks. The multi-month part is never the agent; it is the input data, the permissions and the exception path for the cases the queue does not fit.

What should an agent never do without human approval?

Anything you cannot undo: payments, contractual commitments, deletions, pricing changes and production configuration. The rule is reversibility, not risk appetite — if there is no undo, the agent proposes and a named person approves.

How many agentic workflows should I run at once?

One, until it has survived a failure and you have seen the guards fire. The guards are only proven by a bad run, and adding a second workflow before that doubles the surface area you cannot yet observe.