A green tick is not a finished job

Your automation ran last night, and every step shows a green tick. That tells you nothing failed loudly; it does not tell you that the report was written, the record was updated or the customer got the right answer.

Most automation tools, and most AI agent platforms, judge a run by one question: did any step raise an error? If not, the run is marked as a success. That is a fair test for the machine. It is the wrong test for the business, because the business did not ask for "no errors". It asked for a result: a filled sheet, a sent reply, a summary in someone's inbox.

The gap between those two tests is where quiet failures live. A step can finish cleanly and hand nothing to the next step. A model can receive an error message from a tool and treat it as data. A scheduled job can fail to start, and a job that never ran cannot report that it failed. You find out later, from a customer, a colleague or a number that does not add up.

AI agents make this harder, not easier. A plain script that gets nothing back usually stops with a visible error. A language model that gets nothing back will often carry on and write something that sounds right. It fills the gap with fluent text, and fluent text looks like a result.

1. A tool call fails, and the agent continues. The tool returns a refusal. The step still counts as complete, and the model reads the refusal as an answer.
2. A step returns nothing. A search finds no rows, or a field is missing. The next step works with the empty value anyway.
3. The output has the wrong shape. The model returns a paragraph where a list was expected. Nothing breaks until another step or system tries to use it.
4. The run never starts. A trigger stops firing, or a credential expires. There is no failed run to look at, because there is no run.

The first three are failures inside a run. The fourth is a failure of absence, and it needs a different kind of check.

The fix starts before any choice of tool. For each job, write down the result it exists to produce. Not "process the new tickets", but "one line per new ticket, with its number and priority, posted before the morning meeting". Once the result is written down, you can check for it. Three habits follow.

Define the output shape. Say what a good result looks like as structure: which fields, which types, and which ones may never be empty. A step that must return that shape cannot quietly return a polite paragraph instead.

Check at the step that makes it. Validate the result where it is produced, not three steps later. If the search step found no rows on a day when there should be many, that is the place to stop and say so. A check at the end of the flow tells you that something went wrong. A check at the source tells you what went wrong, and where.

Make empty visible. Decide in advance what an empty or malformed result means for each step. Sometimes empty is fine: no new tickets on a Sunday. Often it is not. Either way, the run should record it as a named outcome, such as "finished, nothing produced, because the source returned nothing", and not as plain success. A clear "done, nothing produced" is worth more than a green tick.

There is a real cost here, and it is worth saying. Each check adds work and some false alarms. Teams that add no checks get calm dashboards and late surprises. Teams that add too many learn to ignore their alerts. Start with the jobs where a silent failure costs money or trust, and check the one result each of them exists for.

A missed run leaves no trace inside the tool that missed it. So this check must sit outside the run.

The plain version: for each scheduled job, know how often it should run, and compare that with how often it did. A daily job with no run since yesterday morning is a fault, even when nothing on the screen is red.

A second habit helps. Have every important job write a short "finished" record as its very last step, in a place that something else reads. If that record does not arrive on time, a person hears about it. Silence becomes the signal.

Take one scheduled run. Each morning at seven, an agent reads the new support tickets and posts one line per ticket, with its number and priority, before the morning meeting. Here are three mornings on which that run looks green and the job is not done.

1. A tool error the agent talks its way past. The ticket tool returns an error: access denied. The agent reads the error, writes "No urgent tickets today" and ends the step. What catches it: a defined shape for the result, so that a written excuse cannot pass as the answer. What EpicStaff does: a failed tool call is recorded as an error, but the agent is told about it and may carry on, so a run can finish green after tool errors. In EpicStaff, a step can be given a structured output: you define the shape of the result, and the step must return that shape. If it cannot, the step fails instead of passing.

2. An empty result. The search runs without an error and finds no rows, because someone renamed the queue it reads. The agent posts an empty list, and every step is green. What catches it: a rule for that step that says when empty is not acceptable, checked where the result is made. What EpicStaff does: on agent and task steps you can define the result's shape, including required fields, and an answer that does not match fails the step. An empty result fails a step only where the step's defined shape requires content. Where empty is never acceptable, add your own check after that step.

3. A start that never happened. On Monday the trigger does not fire. There is no run, so nothing turns red. What catches it: a check outside the run that compares how often the job should run with how often it did. What EpicStaff does: EpicStaff can start flows on a schedule; it does not alert anyone when a scheduled run fails to start. So add your own check for scheduled runs, such as the "finished" record described above.

All three come back to what green means. A run's status checks the result's shape only where you defined one; otherwise it means the run raised no error. So decide what each job exists to produce, and define that shape on the step that makes it.