Why I Deleted The Word 'Task' From My Agent Platform

What this article answers (plain language): I removed the "task" abstraction from my agent platform after realizing it was the wrong frame. Operators don't want a task manager. They want autonomous operations driven by their standing intent. The shift is architectural, not cosmetic.

Last month I deleted 9,200 lines of task-management code from my agent platform. That number feels like a brag but it's actually an embarrassment — those lines should never have been there. The word "task" had been the central abstraction since day one, and it was wrong from day one. What operators actually wanted wasn't a task manager. It was an autonomous operation governed by their standing intent. Replacing the frame took six months and was the most important architectural decision I've made.

I'm writing this in the Kevin voice because it's a build-in-public observation, not a category-essay, and I want to be specific about what I got wrong. The lesson generalizes — every agent product I've looked at recently is making the same mistake — but the way it surfaced for me was through a long series of "wait, why are we modeling it this way?" conversations that finally cohered into a single replacement.

What I Built First (And Why It Was Wrong)

The first version of the platform had tasks as a first-class table in the database with about a dozen columns: id, title, description, schedule, status, mode, output_kind, agent_assignments, and so on. The UI had a /tasks page. The API had POST /api/tasks. Operators created tasks. Agents executed tasks. Tasks had outputs. The whole vocabulary orbited the word.

This felt natural because every productivity tool I've ever used works this way. Asana has tasks. Linear has issues. Trello has cards. The metaphor is the same: a unit of work with a definition and a status. Plug in agents instead of humans and you have an agent platform. Right?

Wrong, in the way that took me six months to see. The task abstraction encodes an assumption: work is composed of discrete units, defined upfront, executed once, completed. That assumption is true for human labor that is bounded and ticket-shaped. It is not true for the work operators actually want autonomous agents to do.

What operators want is more like: "Watch my competitors. Tell me when something material happens. Refresh the picture daily. Brief me weekly. Do this indefinitely until I tell you otherwise." That isn't a task. It's a standing intent — a mandate. Forcing it into task-shape required all kinds of awkward syntax: recurring tasks, perpetual tasks, "this task never completes," "this task spawns sub-tasks." Each of those was a sign the abstraction was leaking.

The Symptoms I Should Have Listened To

Three symptoms showed up early and I dismissed each one:

Symptom one: every alpha operator ended up with 8–14 fragmented tasks for what was conceptually one operation. Watch competitors became: "scrape competitor sites task," "synthesize competitor insights task," "send weekly competitor brief task," "alert on material competitor moves task." Four tasks, one operation. The fragmentation made the operator's cockpit unreadable.

Symptom two: my own conversational agent kept defaulting to "let me create a task for that" for every operator request. Operator says "find me three good vendors for X." Agent says "I'll create a vendor research task and assign the analyst." Operator wanted the answer in the next message, not a workflow. The agent was being polite to the architecture, not the operator.

Symptom three: the substrate layout was schizophrenic. Some artifacts lived under /workspace/context/{domain}/ (the canonical accumulating substrate). Others lived under /tasks/{slug}/outputs/ (the legacy task-shaped substrate). Same operator, same workspace, two different storage models depending on whether the work was conceptually a task or conceptually a domain. This was a symptom of the abstraction not knowing where things belong.

I dismissed each of these for months as "we'll clean it up later." Eventually I noticed the cleanup would never come because the underlying abstraction was wrong, and the cleanup would just be re-arranging deck chairs.

The Replacement: Mandate, Recurrence, Invocation

The new architecture doesn't have tasks as a first-class concept. It has three things:

Mandate. The operator's standing intent, authored at /workspace/context/_shared/MANDATE.md. One per workspace. This is the constitutional layer — what the operator is trying to accomplish, with what risk envelope, in what domain. The mandate is the gate: nothing autonomous runs until the mandate is non-empty.

Recurrence. A YAML file at the natural-home path describing what should happen on what cadence. A weekly competitor brief is a _spec.yaml at /workspace/reports/competitor-brief/. A daily revenue digest is an entry in /workspace/_shared/back-office.yaml. A reactive trade signal is an _action.yaml at /workspace/operations/{slug}/. The recurrence file is declarative — it describes the work, not the execution.

Invocation. One cycle of execution. The scheduler walks recurrences, finds what's due, fires invocations. Each invocation produces a narrative entry, a substrate write, and an audit row. Invocations are the atom — the unit of execution — but they're not a user-facing concept. The operator never thinks about them.

The user-facing vocabulary diverges from the storage vocabulary on purpose. Operators talk about "reports" (recurring deliverables), "trackers" (accumulating context), "actions" (external writes), and "system" (back-office hygiene). The substrate stores them in shape-appropriate locations. The translation between operator language and substrate layout happens at the edge of the system.

The thing that's gone: the word "task." Nothing in the operator UI says "task." Nothing in the user-facing API says "task." The substrate doesn't have a tasks directory. The abstraction is dead because the abstraction was wrong.

What This Unlocks

A few patterns that the new shape makes natural and the old shape made awkward:

Chat-first triggering by default. The operator says "pull today's revenue" and the agent fires an invocation immediately and writes the result. No task is created. If the operator wants the same thing tomorrow, they say "do that every morning" and a recurrence YAML gets written. The transition from one-off to recurring is gradient and reversible.

Substrate that lives where it conceptually belongs. Reports live under /workspace/reports/. Domain context lives under /workspace/context/{domain}/. External actions live under /workspace/operations/. There's no /tasks/ namespace fighting with the natural homes for content.

Mandate as the gate. Nothing runs autonomously until the operator authors a mandate. This sounds restrictive; it's actually liberating. The platform stops trying to be useful before the operator has told it what useful means.

Cadence as a first-class property. The recurrence YAML carries the schedule. The schedule isn't an attribute of a task; it's the defining shape of recurring work. A /schedule surface can read across all recurrences and show "everything happening this week" without inventing anything new.

Why Most Agent Products Will Hit This Wall

Every agent product I've looked at recently has tasks-as-first-class. They will all eventually run into the same symptoms — fragmentation, conversational agents defaulting to task creation, schizophrenic substrate layout. They will then face the same choice: tear out the task abstraction or live with the leakage.

Tearing it out is expensive (I deleted 9,200 lines and added 700 — net minus 8,400, but the migration was high-risk). Living with the leakage means the product never feels coherent.

The cleaner path: don't use tasks as the central abstraction in the first place. Mandate-driven operations is the right frame. The agent products that adopt it from the start will skip the painful migration. The ones that ship with task-shaped architecture will eventually have to do what I did, or accept that their cockpits will always feel like a Jira backlog dressed up as an AI product.

The Lesson I'd Tell Past Me

Pick the abstraction by listening to what operators actually say, not by reaching for the productivity-tool metaphor. Operators don't ask for "tasks." They ask for "watch this," "tell me when," "every morning," "do that for me until I say stop." Those words describe standing intent and recurrence, not discrete work units.

The wrong abstraction is invisible at the start. It looks like the natural fit. It survives because every developer is familiar with task-shaped tools. By the time the symptoms surface, the cost of fixing it is high. Listen to the symptoms early. The fragmentation, the agent's reflex behavior, the schizophrenic substrate — these are diagnostic signals, not implementation problems.

What I'd tell past me: build the mandate-driven shape from the start, even if it feels weirder than the task shape. The weirdness is the abstraction being honest about what the work actually is.

Key Takeaways

• Tasks are the wrong central abstraction for autonomous agents. They encode an assumption (discrete, bounded, completed work) that doesn't match what operators want.
• The replacement: Mandate (standing intent), Recurrence (declarative cadence), Invocation (execution atom).
• Symptoms of the wrong abstraction: fragmentation, agent defaulting to task creation, schizophrenic substrate layout.
• The migration cost is real but the architectural shape is much cleaner afterward.
• Build mandate-driven from the start if you can.
• For the deeper architectural picture, read The Agent OS Is Real. For why this is the layer operators actually want, read Mandate-Driven AI.