The big picture: how Amenbo is put together

July 16, 2026

Series · Part 2 — “Building task management for AI agents.” Last time covered why it was built. This time is the overall shape of how the inside is assembled.

Part 1 was about the “why.” This part is about “how it’s assembled.” Before getting into any individual piece of tech, here is the whole thing at a glance. The details get dug into one at a time in the parts that follow.

One monolithic Core, two entrances

The insides of Amenbo (https://amenbo.work/) — the business logic — all live in the Rust Core (amenbo-core). The human-facing GUI (React / Tauri) and the CLI (amenbo) that both humans and AI type are thin skins over it. Both call the same Core functions.

Because of that, a feature added from either entrance rides on the same single implementation. There is no central server.

Amenbo's layering. At the top are two entrances, the GUI (React / Tauri) and the CLI (amenbo); both call the central Core (Rust / amenbo-core). All the logic sits in the Core, and the GUI and CLI call the same functions. The Core reads and writes a single local SQLite file, store.sqlite. There is no central server. — The logic sits in one Core; the GUI and CLI are thin skins that call the same functions.

The data lives in the app-data area, not the folder

This may be surprising: the project folder holds no data. All that sits there is a small marker called .amenbo, whose content is just a number (project_id) pointing at which project it is.

The real thing is a single store.sqlite in the OS app-data area. Settings and the display name live in separate files, which hold no secrets either. One store can be pointed at from several folders.

Where the data sits. On the left, the project folder holds only the .amenbo marker, whose content is just project_id. On the right, the OS app-data area holds the one real thing, store.sqlite (a single file), the config and identity files for settings and display name (no secrets), and attachments stored separately from the body. Several folders point at the same single store. The data is not kept in the repository. — The folder is just a marker; the real thing gathers into one file in the app area.

The store is a graph of tasks and decisions

The content of store.sqlite is not a set of scattered tables but a graph. The “connection between decisions and tasks” from Part 1 is directly the shape of the data.

Tasks and decisions are the two kinds of node.
Decisions join to decisions through supersede and the like, decisions join to tasks through links, and tasks join to tasks through dependency — each joined by edges.

What Part 1 called “which records to read, in what relation” is this structure.

The store is a graph. Inside a project are two kinds of node, decisions (D-n) and tasks (T-n). Decisions join to decisions by edges such as supersede, decisions join to tasks by links, and tasks join to tasks by dependency. — The store's content is a graph joining tasks and decisions by edges.

Where the series digs next

That is the overall shape. From the next part on, the series zooms into pieces of it. For example —

Part 3: why catching up is fast
the mechanism that partitions the AI’s reach with .amenbo
why the GUI and the CLI touching the same SQLite at once doesn’t break it

For now, just keep “where things are” in your head.