Failed Checks Belong in Your Inbox, Not Your Notifications
When an agent's work fails a check, it needs an owner, the evidence, and a next action. That is inbox work, not another alert to scroll past.
Founder, Task Machine
You set an agent loose on a recurring task overnight. In the morning you have eleven notifications. Two are progress updates you do not need, one says a draft is ready, one says something failed, and the rest are noise from the same run. You scroll, you skim, and you move on, and the one that mattered is now three swipes up and already forgotten.
That is how agent work usually fails. The work itself often goes fine. What breaks is the moment something does not pass: a check that did not clear, an output that needs a human eye, a step the agent could not finish. That moment arrives as a notification, gets the same half-second of attention as everything else, and disappears into the stream.
A notification tells you something happened. It does not tell you who has to act on it, what exactly went wrong, or what the next move is, so important failures get the same treatment as trivial updates: a glance, then nothing.
Better notifications will not fix this. A failed check should stop being a notification at all.
Events and work need different handling
When work passes through a person or an agent, the system can produce two kinds of things.
The first is an event: a fact about what happened. The run started, the draft is ready, the export finished. Events are fine as notifications. You read them when you want to, and nothing breaks if you do not.
The second is a decision someone now has to make. A check failed, an output needs approval before it goes out, or the agent got stuck and needs context only you have. That is work to be done, and work needs three things a notification never carries:
- An owner. A named person responsible for resolving it, instead of whoever happens to see it.
- The evidence. What was being checked, what the output was, and why it did not pass, attached to the item instead of buried in a log.
- A next action. A clear set of choices, such as approve, retry, answer, escalate, or stop, and what happens after you pick one.
A notification has none of these. It is a tap on the shoulder with no follow-through, and once a failed check becomes one notification among many, a piece of work has been downgraded into trivia.
What a failed check needs
Put the two side by side and the gap is obvious.
| Notification | Inbox item | |
|---|---|---|
| Has an owner | No, it goes to everyone or no one | Yes, it is assigned to a person |
| Carries the evidence | No, usually a one-line summary | Yes, the output and the failing check are attached |
| Tells you the next action | No, you have to work it out | Yes: approve, retry, answer, escalate, or stop |
| Can be resolved in place | No, you leave to act elsewhere | Yes, you decide and the work moves |
| Leaves a durable record | No, it scrolls away | Yes, the decision is kept with the work |
You acknowledge a notification, and you finish an inbox item. When a check fails, the agent has reached a boundary it cannot cross on its own. That is the moment to pull a person in, with everything needed to act.
Different failures need different next actions
"Failed check" is a blunt label. In practice agent work stalls for a handful of distinct reasons, and each needs a different next action. Lumping them into one alert is part of why the stream feels like noise: everything looks identical, so nothing feels urgent.
These are the common ways recurring agent work comes back to a person, what each one means, and what it should turn into.
| Failure type | What it means | What it should become |
|---|---|---|
| Check failed | A verifier, such as a rule, a test, or a quality gate, did not pass | An item asking whether to retry, fix, or accept with a reason |
| Needs approval | The output is finished but should not move forward without a sign-off | An item with the output attached and one explicit approve or reject |
| Agent blocked | The agent could not finish because a tool, a credential, or access was missing | An item naming the exact blocker, routed to whoever can clear it |
| Missing context | The agent hit a business judgment call it cannot make | An item with the specific question, instead of a transcript to read through |
What matters is the difference between a vague "something went wrong" and a specific "the publish step failed the link check on these two URLs, so retry or accept." The first sends you off to investigate. The second lets you decide in seconds.
Not every failure deserves a queue
This can be taken too far. Turning every minor hiccup into a tracked item with an owner and a history creates its own noise, only slower and heavier.
A lightweight notification is enough when:
- the event is informational and needs no decision, such as a run starting or a backup completing
- the failure was transient and the system already retried and recovered
- the work is one-off and low stakes, so a missed item costs nothing
- you are the only person involved and will see the result anyway
The test is whether someone has to decide something, and whether it matters if that decision is dropped. If both are true, it is inbox work. If not, a notification is fine, and forcing it into a queue only makes the queue less trustworthy. An inbox earns its place by staying scarce, and the fastest way to ruin one is to route everything into it until it becomes the stream you were trying to escape.
The goal is to capture the right things, with enough attached that they can be resolved.
Where Task Machine fits
Task Machine draws the line there. Its inbox is where decisions land, while an agent's routine activity stays in the task history. Approvals, questions, failed checks, and exceptions arrive as items you can act on, each with an owner, the evidence from the run, and a clear next action.
When a verifier fails on a workflow run, the result becomes an item instead of a log line or an alert that scrolls away. It shows what was checked, what the agent produced, why it did not pass, and what your choices are. You decide in place, and the decision stays with the work, so anyone who looks back later can see what failed, who handled it, and what they chose.
Watching agents means staring at a stream and hoping you catch the one that counts. Operating them means the work comes to you only when it needs you, ready to be finished.
For a solo builder running agents on recurring tasks, that is the difference between a morning spent reconstructing what happened overnight and a morning spent making a handful of clear calls. The agents did the work, and the inbox shows you the few moments that needed your judgment.
Turn alerts into decisions
If your agent work lives in a notification stream you have learned to ignore, the failed checks were never given the shape of work: no owner, no evidence, no next action.
Task Machine's inbox gives recurring work done by humans and agents that shape. If a stream of alerts you have stopped reading is the friction you feel, start a 7-day trial.