A local backlog, built for agents
Tasks with IDs,
search, and history.
An agent can create, find, and update work through JSON commands or a stdio MCP server. One SQLite file is the source of truth.
See an actual command sequence ↘Review webhook retries
Check duplicate events before changing the worker.
- status
- in_progress
- priority
- 2
- source
- cli
01 created as todo
02 status changed to in_progress
The CLI speaks JSON. The MCP server uses the same core.
Each command returns structured output, so an agent can read a task ID and use it in the next step without scraping a web interface.
$ export AGENT_TASK_DB=./tasks.db
$ bun run src/cli.ts add "Review webhook retries" "Check duplicate events" api issue-123
{ "id": 1, "status": "todo", "project": "api" }
$ bun run src/cli.ts search webhook
[{ "id": 1, "title": "Review webhook retries" }]
$ bun run src/cli.ts status 1 in_progress
{ "id": 1, "status": "in_progress" }
The stdio server exposes task_add, task_search, task_list, task_get, task_update, and task_stats.
One SQLite file, three connected pieces.
Current title, description, status, priority, project, source, and idempotency key.
Creation and updates are recorded with the task change in one transaction.
SQLite triggers keep the text index synchronized when a task changes.
Creating with the same idempotency key and identical fields returns the existing task. Changing the content under that key fails, which prevents a retry from quietly creating a second version.
The database file is the access boundary.
Attach the MCP server only to agents that may read and write this backlog. The project has no multi-user authentication, hosted HTTP endpoint, remote synchronization, or issue-tracker bridge.
Back up the SQLite file if the task history matters to your workflow.