ShiroDoro

Why catching up is fast

Series · Part 3 — “Building task management for AI agents.” The previous part was the overall shape; this part is how that graph is read.

Part 1 measured search running about twice as light, and Part 2 showed that the store is a graph. This part is about the reading of it — why it comes out light.

Just follow the edges

When catching up on a task, Amenbo (https://amenbo.work/) reads the task itself and only the few connected records: the decision it was premised on, the blocker holding it up right now, the comments. Each of those is reached from the task’s number in one index hit.

The whole store is never swept. So however large the store grows — thousands of records, tens of thousands — the cost to catch up on a single item does not change: it stays the handful of connected records. The “about twice as light” measured in Part 1 comes from this way of reading.

Reading when catching up on a task. The center, T-123 — the task being caught up on — is looked up by its number, and the premise decision D-45, the blocker T-120, and the comments are each reached in a single index hit. Only the few connected records are read; the whole store is not scanned.
Catching up = following, by index, the few records connected to that task.

State is derived, not stored

“Is this task startable (ready)?” “Is this decision still current?” — Amenbo does not store such state in a column. Every read derives it on the spot from the edges.

The reason for not storing it is to avoid disagreement. If “startable” were stored, then every time a dependency or a decision changed you would have to go and update the list, the card, and the start guard — all of them. Derived, the judgment lives in one place. Everyone uses the same judgment, so “looks startable in the list but blocked once you actually start it” does not happen.

State is not stored; it is derived on the spot. On the left are the inputs: the dependency edges (do any blockers remain) and the decision edges (has it been superseded). In the middle, ready-ness and current-ness are derived on the spot. That single derived judgment is shared by the three on the right — the list filter, the card display, and the start guard — so display and judgment never disagree.
State is derived from the graph each time. One judgment, shared by the list, the card, and the start guard.

Next

Part 4: Partitioning the AI’s reach by structure. Not a plea in the prompt, but a boundary at .amenbo that makes “can’t read, can’t write” a mechanism.

☕ Tip me