Design

The CLI and GUI are separate processes, and both write the same store.sqlite at the same time. It holds together because each write is wrapped whole in a single transaction that SQLite serializes, and rolls back whole on failure. Every change leaves one row in change_feed, and the GUI watcher re-reads only what changed by cursor and shows it.

When one AI works across several projects, it picks up the neighbor's context and pollutes its own memory. Asking it in the prompt to "leave that alone" carries no guarantee. Amenbo binds to a project through .amenbo, and the CLI itself turns down any operation that reaches outside with out_of_reach. Not a plea — a boundary drawn by mechanism.

Part 1 measured search running about twice as light, and Part 2 showed that the store is a graph. This part is how that graph is read: catching up on a task follows only the few connected records by index (O(result)). State like whether a task is startable or whether a decision is still current is never stored — it is derived on the spot from the edges, so the list, the card, and the start guard never disagree.

A survey of how Amenbo, a task manager for AI agents, is built, before digging into the individual pieces of tech. The GUI and the CLI both call the same Rust Core, and data lands in a single local SQLite. The project folder holds only a marker; the store is a graph of tasks and decisions.

Amenbo, a task manager built for AI agents, is out. Part 1 is about why it exists: the way context degrades the more you lean on AI agents, and the choice to keep it separate from human task management, in a local, closed environment.