Task managers are the wrong abstraction for AI agents

This morning, one of my AI agents turned a follow-up scheduled for tomorrow into a false blocker.

I had emailed my co-founder a question that needed a considered answer. My system created a follow-up: tomorrow morning, check for his reply; if none has arrived, prepare a chase. Tomorrow was the earliest an answer was plausible.

An hour later, the agent that works my task queue picked it up anyway. It checked, found no reply, and marked the task blocked on a missing capability. The task had a start time, but the queue did not enforce it. The real follow-up disappeared under a false “blocked” flag, and I had to notice that myself.

No model upgrade fixes an eligibility rule the system does not enforce. The executor needed a rule that made future work ineligible and treated an empty inbox as a valid result.

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. The failures kept pointing back to the task record itself.

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 may do about it, and what finished looks like. The app stores four words. I supply everything else.

An agent does not share that memory. When context is missing, the system still has to choose. It may start early, duplicate the work, or leave it unowned.

An obligation in my system 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.

Most of the failures I have logged trace to one of these fields being missing or treated as decoration. The opening follow-up needed a pointer to my sent email, one owner, a readiness condition of tomorrow morning or an earlier reply, permission to check and draft but not send, and evidence of whichever branch closed it.

I enforce ownership mechanically. The executor sees agent-owned obligations, while items waiting on me appear in my views. On handoff, the existing obligation gets a new owner. There is no second copy to race the first.

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 work only when an invite had been promised, recorded nothing. The meeting existed only in two people’s assumptions, and I missed it.

A mutually agreed meeting now creates a calendar obligation at the moment of agreement, whether or not anyone promises an invite. The agreement is the source. The calendar event is the artifact the obligation must produce.

Readiness is a hard gate, and absence is an answer

The opening incident produced two small fixes. A future start time is now a hard gate: before it, the obligation does not exist as far as the executor is concerned. Every follow-up also has an explicit branch for absence, because a person who has not answered yet is a normal state of the world.

Readiness can change. If the reply arrives early, a detector attaches it to the obligation and opens the gate. The executor does not have to keep checking work that is not ready.

Until I represented waiting explicitly, agents treated “nothing has happened yet” as a failure and created noise.

Authority boundaries produce their own failures

Nothing in my system sends an outbound message without my approval. Drafts are created in the real compose box or drafts folder and held. I approve the exact recipient and text before they go. One wrong message costs more trust than a hundred correct drafts earn.

A boundary drawn carelessly can also stop approved work. I had approved a calendar invite, but my system held it back because it could not attach the video-call link. The invite went out late, after I noticed. It should have created the approved event, surfaced the missing link, and opened a repair obligation.

A tool gap now creates its own build obligation with an owner and priority. It does not disappear into an error log or prevent unrelated approved work from landing.

Done means the world changed

“Done” is the most abused word in automation. A drafted email has not been sent. A tool returning success does not prove that the target system changed.

Completion is an observed external state. A send is complete when the exact message appears in the Sent folder with the intended recipient. A payment is complete when the provider shows the right payee, amount, status, and confirmation reference. Scheduling is complete when the event exists on the calendar with the right people and time.

Those states prove dispatch, payment, and scheduling. They do not prove delivery, settlement, attendance, or a reply; each of those outcomes may create another obligation. Completed obligations keep their evidence attached so an audit can reconstruct what happened without trusting my memory or an agent’s report.

I am testing completion contracts in TraceGuard, which checks the systems where an outcome should exist. It currently covers one workflow and synthetic injected faults; it is not yet evidence for the broader claim.

A separate routing experiment moved six written rules into deterministic code ahead of the model. Those rules covered 13 of 631 logged decisions. On that subset, the rules matched every corrected outcome and the model missed three. The sample is still small, so the system continues to collect disagreements rather than treating the result as settled. I wrote up the method in The LLM call you can delete.

What I run today

Detector agents scan my email accounts, chat channels, and calendars hourly through the workday. One executor works the eligible agent-owned obligations every thirty minutes. The ledger is an ordinary task manager. Owners and readiness gates determine what each party acts on. Every run records what was checked, what changed, and what was deliberately left alone.

The system still fails. Each failure now leaves an inspectable record I can turn into a rule.

Testing it with other operators

I do not yet know how much of this transfers to someone whose workflows and judgment are different from mine. I am taking two founder-operators through a four-week paid pilot. We will install one commitment workflow across email and meetings, route each obligation to one owner, chase it at the right time, and close it only when the expected state is visible. You need Google Workspace; I install the rest. I cap my support at two hours a week so the pilot tests whether the system can run without me.

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