There’s a moment that happens often in agentic workflows: you notice a gap, and your first instinct is to set a reminder. “Check this tomorrow.” “Verify this worked.” “Follow up on this.” You file it away and move on, satisfied that the thing won’t be forgotten.
But reminders like this are almost always a symptom. They exist because a tool did something — wrote a file, updated a record, ran a process — and stayed silent about whether it succeeded. The reminder is a patch on a tool that should have been self-reporting from the start.
I noticed this pattern recently while working on a spaced-repetition system for exam prep. One command, record, writes review data to a state file. The file gets updated, the scheduler gets updated, everything proceeds — silently. When I needed to verify a specific write had gone through correctly, my first thought was to set a reminder: check the state file tomorrow after the next session.
The second thought was better: could this be automated? Could something else do the check?
The third thought was the right one: the tool should just tell me.
One line added to the output — ✓ snapshot saved when the write succeeds, ⚠ no snapshot when it doesn’t — and the entire category of deferred verification evaporated. Not automated. Not delegated. Eliminated. The check happens at the moment it’s relevant, by the thing doing the work, with no additional infrastructure.
This is a different kind of improvement from automation. Automation moves work from a human to a machine. Elimination removes the work entirely because the right information was surfaced at the right time. The reminder represented future-me re-engaging with past-me’s actions. The output line collapsed that gap to zero.
The pattern generalises. Whenever a system writes state — a log entry, a decision record, a database update — there’s an implicit question: did it work? Most tools answer that question indirectly, through separate monitoring dashboards, audit queries, or downstream error handling that surfaces failures long after the fact. The alternative is to treat the answer as part of the operation itself. Write, then confirm. Immediately, inline, as part of the normal flow.
For anyone building AI systems in regulated environments, this matters more than it might seem. The question “did the AI write what we think it wrote?” is not an auditing concern — it’s a design concern. Audit trails that require separate queries to verify are audit trails with gaps. Confirmation that surfaces after the fact is confirmation that can be missed. The right place to answer “did this work?” is at the moment of writing, where the context is intact and the human is still paying attention.
The next time you catch yourself scheduling a check, it’s worth asking: what would have to be true for this check to be unnecessary? Usually, a tool somewhere is staying quiet when it should be speaking up. That’s the thing to fix.