An AI task is not done until the world has changed

This morning I caught one of my AI agents doing something subtly stupid.

I had emailed my co-founder a question that needed a considered answer. My system did what it is designed to do: it created a follow-up task. Check for his reply, and if none has arrived by tomorrow, prepare a chase. The task carried a start time for a reason. The earliest his answer could plausibly exist was the next day.

The agent that works my task queue picked the task up within the hour. It checked, found no reply, decided something must be broken, and marked the task blocked on a missing capability. From the agent’s point of view, its work was done. In the real world, nothing useful had happened. The actual follow-up was now buried under a false “blocked” flag, and I had to notice that myself.

No model upgrade fixes this. It was not an intelligence failure. It was a bookkeeping failure. The task said “follow up on the reply.” It should have said: this obligation exists because of a specific email I sent this afternoon; it is not ready to act on before tomorrow morning; step one is to verify whether a reply exists; and if it does not, that is a normal outcome with its own next step, not an error.

I have spent the past several months moving most of my working life onto AI agents. They read my email and chat, prepare my meetings, chase my follow-ups, reconcile my books, and keep my task list honest. I run a travel software company on top of this system. Almost everything I now believe about making it work traces back to one realization: the to-do item is the wrong primitive.

Task managers were built to remind humans

A task manager stores reminders for a person who already carries the context. “Follow up with Sarah” works for me because I know who Sarah is, what I asked her, when an answer is overdue, what I am allowed to do about it, and what finished looks like. The app stores seven words. I supply everything else.

An agent supplies nothing. Whatever the task does not say, the agent invents or ignores. So when humans and agents share one list, every gap in the record becomes a behavior: work starts before it is ready, two parties act on the same item, or an item quietly belongs to no one.

What an agentic system needs is not a task but an obligation, and an obligation has five properties:

• A source: the real-world event that created it, with a pointer back to the evidence.
• An owner: exactly one, human or agent. Never both, never neither.
• A readiness condition: the time or event before which acting is wrong.
• An authority boundary: what the owner may do without asking, and where it must stop.
• Proof of completion: the observable change in the world that closes it.

Every failure I have logged in months of running this maps to one of these being missing. The rest of this essay is four of those failures.

An agreement is an obligation, even without an artifact

Recently I agreed to a meeting over email. Neither side said “I’ll send an invite,” so my system, which at the time created calendar events only when an invite had been promised, created nothing. No ball was dropped that anyone could see. There was no ball. The meeting existed only in two people’s assumptions, and I missed it.

The rule that came out of the incident: a mutually agreed meeting creates a calendar obligation at the moment of agreement, invite or no invite. The source of an obligation is the event itself, not the artifact that usually follows it. Most dropped work I have found since follows this pattern. Nothing failed; something was simply never recorded as owed.

Readiness is a hard gate, and absence is an answer

Back to the opening incident. The fixes were small and none of them involved a smarter model. A future start time is now a hard gate: before it, the task does not exist as far as the executing agent is concerned. Step one of every follow-up is a precondition check with an explicit branch for absence, because a person who has not answered yet is a normal state of the world, not a system failure. And when the awaited evidence lands early, a separate detector agent notes it on the task and pulls the gate forward.

Waiting, it turns out, is a behavior you have to design. Left undesigned, an agent treats “nothing has happened yet” as a problem to solve, and solves it by making noise.

Authority boundaries produce their own failures

Nothing in my system sends anything. Drafts are created in the real channel, in the actual compose box or drafts folder, and held. I approve the exact recipient and the exact text, or it does not go. That boundary is not negotiable, because an agent that can send one wrong message costs more trust than a hundred correct drafts earn.

But a boundary drawn carelessly fails in the other direction. My system once held back a calendar invite it had promised, because it could not attach the video-call link. It treated one missing capability as permission to do nothing. The invite went out late, after I noticed. The correction: act to the edge of your authority, then flag the shortfall. Send the invite without the link and say so.

The missing capability itself got a second treatment. In my system, a tool gap mints a build task with an owner and a priority. It does not disappear into an error log. The gaps queue is real work, and it is how the system grows instead of quietly shrinking around its limitations.

Done means the world changed

“Done” is the most abused word in automation. A drafted email is not a sent email. A submitted form is not a confirmed submission. An agent that ran an action is not an agent that verified the effect.

So completion in my system is defined as an observed change: a send is complete when the message is verified in the Sent folder, a payment when the confirmation reference is recorded, a scheduling task when the event exists on the calendar with the right people on it. Completed obligations keep their evidence attached. Six weeks later, an audit can reconstruct what actually happened without trusting anyone’s memory, mine or the machines’.

This sounds like pedantry until you watch an agent report success on work the world never received. Then it sounds like the whole ballgame.

What I run today

Concretely: detector agents scan my email accounts, chat channels, and calendars on an hourly loop through the workday. One executor agent works the obligation queue every thirty minutes. The ledger is an ordinary task manager; tags mark each item’s owner, and items blocked on me surface into my own views. Every run leaves an audit trail of what was checked, what changed, and what was deliberately left alone.

It still fails. That is partly the point. Because obligations are inspectable, each failure becomes a rule, and the rules compound. Every principle in this essay was paid for with a specific, logged mistake.

Two pilot seats

I want to find out how much of this transfers to someone who is not me. I am taking two founder-operators through a four-week paid pilot: one workflow only, commitments detected across your email and meetings, routed to the right owner, chased at the right time, and closed only on verified completion. You need Google Workspace; I install the rest. My support is capped at two hours a week, which is a feature, because the goal is a system that runs without me.

If that is you, email [email protected] with “pilot” in the subject and one paragraph on where work currently slips through.