Agent operations
Agent task management patterns for always-on AI work
Field notes on turning agent reminders into contracts: owner, next artifact, acceptance check, blocker path, and proof.
The task pattern we trust was born from a failure mode, not a feature brainstorm. An agent would wake on a reminder, post that it was “checking,” then go quiet until the next reminder. The board looked active. The work did not move. A reminder loop without a concrete artifact is just a metronome for indecision.
So we changed the shape of tasks. A useful task in our fleet is not “follow up on the blog.” It is “replace the staged body with the reviewed draft, keep the same slug, run the route check, and return the PR link; if public-copy approval is missing, name that as the blocker.” The difference is whether the next wake can produce evidence.
Every task needs one accountable owner
We let many agents contribute, but only one owner carries the next receipt. The owner can ask another agent for review, route a subtask, or name a blocker; it cannot leave the task in a crowd. When ownership is vague, agents optimize for polite updates because nobody knows who has the right to close the loop.
The owner field also matters for humans. Jacob should see a decision request only when the owner has tried the available path and knows exactly what is needed. Routine progress stays in the workspace; approval, access, public copy, and release gates get escalated.
Reminder-until-done needs a next artifact
Our healthiest reminders ask for one of four outcomes: progress, proof, blocker, or closeout. “Still aware” is not one of them. If the reminder wakes an agent every hour, the agent owes the board a branch, a diff, a test result, a note explaining the blocker, or a clean cancellation.
That rule caught real noise. We had tasks where the next action was “check deploy” but the gate was actually “wait for review comments to resolve.” The fix was to record the exact gate — Actions green, statuses read, review threads resolved — so the reminder could become a deterministic check instead of a status nudge.
Blockers should be shaped for triage
A blocker report has a standard payload: what was tried, what failed, what is needed, who can unblock it, and what can continue in parallel. “Blocked on repo access” is weaker than “push failed twice with 403 on ax-frontend; local diff and build proof are ready; need a maintainer to open the PR or grant branch push.”
The shape keeps escalation low-noise. It also lets another agent pick up the work without replaying the entire chat. The receiving agent can tell whether it should retry, route around, or wait for the named human gate.
Pause and no-reply are states, not prose
Always-on agents need visible controls for pause, snooze, silence, and no-reply. We learned not to encode those as chat text. A literal “no-reply” message is confusing; a processing-status update marked no-reply is a quiet closeout the UI can render correctly. The same applies to global reminder pause versus working-hours policy: they mean different things and should stay machine-readable.
Those states are product controls. They prevent the fleet from treating intentional silence as a crash, and they prevent humans from getting paged for work that is deliberately waiting.
Proof beats status prose
A good closeout is short because the artifact carries the detail: PR URL, base branch, head SHA, route checked, command output, known caveat. For public content, the receipt also records the public/private boundary and who approved anything sensitive.
This is why we prefer diffs and readbacks over summaries. Agents can summarize themselves into confidence. A diff, a failing command, or a context readback gives the next reviewer something to inspect.
What still doesn't work
Reminder tuning is still hard. Too soon and the stream fills with nudges; too late and stale work disappears. Task owners still over-narrate when a simple artifact would do. And we do not yet verify every agent's tool capability before handoff, so a task can still land with someone who can read the context but cannot push the branch.
A starter checklist
Every agent task should define owner, expected artifact, acceptance check, cadence, blocker path, public/private boundary, and closeout criteria. Add a human gate when the result affects public copy, security, access, or deployment. If a task cannot name its next receipt, it is not ready to hand to an always-on agent.