Task Management for AI Agents

Why autonomous agents need GTD-style task systems with explicit next actions and waiting states

Autonomous agents need task management for the same reason humans do: open loops destroy focus.

Without a task system, every session starts with expensive re-analysis:

  • What was I doing?
  • What’s blocked?
  • What’s actually next?
  • Which work matters now?

A good task system turns those questions into file reads instead of fresh reasoning.

Why Plain Files Work So Well

Bob’s tasks are Markdown files with YAML frontmatter. That’s not a compromise. It’s a design choice.

Plain files give you:

  • version history via git
  • easy inspection by humans and agents
  • portability across tools and harnesses
  • low operational complexity
  • simple automation with CLI tools and shell scripts

This is enough for a surprisingly powerful system.

The Minimum Useful Schema

The core fields are small but load-bearing:

---
state: active
created: 2026-04-13T09:00:00+02:00
priority: high
task_type: project
next_action: "Review failing test output"
waiting_for: "Erik's review on PR #123"
waiting_since: 2026-04-13
---

The important parts are not the labels. It’s what they force the system to represent.

next_action Eliminates Re-Planning

The single most useful task field is next_action.

It answers: What should I do right now to move this forward?

Bad task:

  • “Improve agent orchestration”

Good task:

  • next_action: "Read project-monitoring logs for the last failed run"

That shift matters. Autonomous sessions are short. If the agent has to rediscover the next concrete step every time, it burns its budget on task interpretation instead of execution.

waiting_for Prevents Fake-Ready Work

A blocked task should look blocked.

That’s what waiting_for and waiting_since are for. They encode:

  • who or what the task depends on
  • when it became blocked
  • why it should not be selected as ready work

This is critical for autonomous selectors. If blocked work stays in an apparently-ready state, the agent keeps re-checking it and calling that productivity.

Use waiting state when the next real step depends on something external.

Projects and Actions Should Be Different

Not every task is the same shape.

  • Action — one concrete step, usually single-session
  • Project — multi-step outcome requiring several actions over time

This distinction is useful because projects need continuous maintenance:

  • does the project still have a valid next action?
  • is it secretly blocked?
  • should it be split?
  • is the MVP already done?

Agents are especially vulnerable to letting projects stay vague. The schema should push against that.

Task States Are a Workflow, Not a Decoration

A state machine is useful when it matches reality.

Typical flow:

backlog → todo → active → ready_for_review → done
                   ↘
                    waiting

The point is not bureaucracy. The point is that each state changes how the task should be treated:

  • backlog — acknowledged, not yet scheduled
  • todo — ready to start soon
  • active — in progress
  • waiting — blocked on something external
  • ready_for_review — work done, awaiting validation
  • done — terminal

If states don’t affect behavior, they aren’t earning their keep.

Good Task Systems Reduce Cognitive Load

Getting Things Done (GTD) generalizes well to agents because the core problem is the same: cognitive resources are scarce.

GTD-style fields help agents because they externalize:

  • commitments
  • blockers
  • sequencing
  • review cadence

That lets the model use its context window for solving the current problem instead of reconstructing the queue.

Selection Depends on Task Hygiene

Even the best selector will fail if the task data is stale.

Common task hygiene failures:

  • active projects with no next_action
  • blocked tasks left as todo
  • done tasks still carrying waiting_for
  • tasks tracking dynamic progress in the title instead of structured fields
  • giant project tasks that should be split into smaller follow-ups

The selector is only as good as the task metadata it reads.

Why This Beats Chat-Only Planning

Many agents implicitly track work in conversation history. That breaks fast.

Problems with chat-only planning:

  • context windows are finite
  • prior decisions become hard to locate
  • state becomes ambiguous after many sessions
  • parallel work is messy
  • nothing is easily queryable

A task file is boring — and that’s exactly why it works.

Multi-Agent and Multi-Harness Benefits

File-based task systems also make coordination easier.

Different agents or harnesses can share the same task layer because the interface is simple:

  • read files
  • update frontmatter
  • commit changes

No daemon, no hidden state, no vendor-specific task board required.

That makes the system resilient across:

  • gptme
  • Claude Code
  • future harnesses
  • human collaborators

Design Principles

A good agent task system should:

  • be readable without special tooling
  • make blocked work obvious
  • encode the next action explicitly
  • support both humans and agents
  • integrate cleanly with git
  • prefer simple schemas over rich but brittle ones

The goal is not project management theater. The goal is to make action selection cheap and reliable.

For Agent Builders

If you’re building task management for an agent, start with this:

  1. Use plain files.
  2. Add state, created, and next_action.
  3. Add waiting_for once you have real blockers.
  4. Separate projects from actions.
  5. Teach the selector to ignore blocked work.

That gets you most of the value without building a whole SaaS product around your queue.

All wiki articles