I built task management for AI agents

July 15, 2026

Series · Part 1 — “Building task management for AI agents.” How a small app called Amenbo was thought through and put together. This part starts at the beginning: why it was built.

I’ve released Amenbo (https://amenbo.work/), a task manager built for AI agents.

What sets it apart from an ordinary task manager is who uses it: the AI agent is the primary user, and the human comes second. Before touring any features, Part 1 is about why something like this was built at all.

The more you use it, the more context breaks down

When you develop with AI agents, the larger the work and the longer it runs, the more you get stuck in the same spot. Context swells, and every way of dealing with it hits a wall.

A diagram showing how big or long-running work makes context swell until every coping path dead-ends. Keep going and it overflows and performance collapses; cut the session and you pay the cost of re-sharing every time; split across multiple agents and the tasks collide over handling the same information. — The bigger the work, the more the handling of context reaches a dead end

It’s not only that coping becomes hard. The foundation of the work itself erodes.

The flow of decisions gets cut. The running record of “what was decided, and why” is severed part way through.
Dependencies won’t fit in the prompt. Managing task ordering and the decisions behind it inside the conversation alone doesn’t scale.
Other projects’ information turns into noise. When unrelated context mixes in, that alone pollutes the AI’s memory.

Providers try to patch this too, with a feature that keeps internal notes the human never sees, but that comes with its own separate set of problems.

Cutting the cost of catching up on context

What helps with this dead end is Amenbo. For the AI agent, it records, out of the discussion with the human,

what was decided (decisions),
the tasks tied to it,
the connections between decisions and tasks.

The crux is that it makes all of that into a structure you can follow without searching again. Decisions, tasks, and dependencies aren’t scattered notes; they form a connected graph.

A graph where decisions and tasks are joined by dependency and premise edges. From the task in view, following just a few edges to the premise decisions and to the counterpart it is blocked on assembles the context, while the rest of the store (shown gray) stays unopened. — From the task in view, follow a few edges to the premise decisions and to whatever it's blocked on. Context is assembled, and the rest of the store (gray) stays shut

“What does this work assume, what was decided, and what is it stuck on right now” — you pull that from these connections, without combing through the whole history.

To see how much of a difference it makes, I gave an agent the same question under two conditions, with and without Amenbo, and actually measured the number of steps and how much it read.

Amenbo reaches the same answer in about half the steps (measured, median)

It’s not a dramatic difference. Either way, you arrive at the right answer in the end. What differs is the effort, and the amount you read, to get there. The code I tried this on was the well-ordered, easy-to-follow kind, with a clean history and clean commits — the sort that’s already easy to trace without Amenbo. Even so, the search took about twice as long. On messier code, the gap should widen.

Where Amenbo especially helps comes down to these two things.

The search doesn’t swell without bound.
Because you follow edges, you only read the few records that are relevant.
Chasing code on a hunch, when you miss, brute-force search drags on and on.
You can see “what it’s stuck on right now.”
Which task is blocked by which dependency.
That’s the state of this very moment — it’s in neither the code nor the git history.

That said, what Amenbo helps with reaches only as far as “which records to read, and in what relation.” The effort of reading those records themselves remains just as before.

Verification method and the raw numbers (click to open)

Setup (headless runs of the same model claude-sonnet-5, n=4 each, compared on medians)

Two questions drawn from real tasks in my own dev backlog (themes: distribution method / DB connection layer policy).
The questions are neutral wording that doesn't hint at Amenbo, and identical in both conditions: (1) what was decided, (2) why, and what was changed or removed, (3) how far along it is now.
Condition A (without): only Read / Grep / Glob / git. amenbo is blocked; solve from the source and git history alone.
Condition B (with): the above plus the amenbo CLI. Let it read a clone of the real store (prod untouched); the learning cost of using it is excluded (steady state).
Model and prompt are identical in both. Runs with errors, single-turn degeneration, or subagent delegation are excluded from the tally. External memory injection and context carry-over are also blocked.
Collected: tool-call count / bytes read / turn count / cost.

Theme 1: Distribution method (median [min–max])

Metric	Without (A)	With (B)	Ratio
Tool calls	18.0 [14–23]	8.5 [8–14]	×2.1
Read (KB)	41.4	29.1	×1.4
Turns	19.0	9.5	×2.0
Cost (USD)	0.40	0.31	×1.3

Theme 2: DB connection layer (median [min–max])

Metric	Without (A)	With (B)	Ratio
Tool calls	19.5 [19–33]	10.5 [8–12]	×1.9
Read (KB)	29.9	16.2	×1.9
Turns	20.5	11.5	×1.8
Cost (USD)	0.50	0.29	×1.7

The spread of steps differs too: with (B) it converges to 8–14, while without (A) it's wide, at 14–33. Miss a guess and the brute-force search swells without bound. In both conditions, the final answers were correct.

The human is the one who bears responsibility

So where do you run this? Here another immovable dynamic comes into play: an AI can’t take responsibility.

However much you use AI agents, the human bears responsibility for the output. At work, you can only ship it under a human’s name.

That’s why there are situations where an AI agent is better off running in a local, closed environment. In practice, my own task management runs through tools like Asana, coordinating with the people involved under my responsibility. Having an AI wander in there is a problem.

So, keep them separate

The answer was a division of territory.

The real task management that a human coordinates responsibly stays on the human side. Amenbo, built for context, goes into an AI-only, local, closed environment. That gives a clean split.

A diagram splitting two territories: the human-responsibility area (coordination with stakeholders, deliverables, task management such as Jira) and the AI closed-environment area (recording decisions and tasks — that is, Amenbo — with multiple AI agents). — Separate the task management under human responsibility from the task management for the AI

This is Amenbo: task management for AI agents that doesn’t compete with human task management.

No conflict with team-oriented systems

There are plenty of systems out there for putting AI to use across a team. Amenbo doesn’t compete with them, because the problem it faces is fundamentally different.

A diagram showing that team-AI systems and Amenbo solve different problems. On the left, systems where a team collaborates and shares or links its outcomes, gathering information centrally. On the right, Amenbo, where an individual's AI keeps context and decisions, closed locally at hand. The two don't compete. — Systems that solve team collaboration and sharing, versus Amenbo that keeps an individual AI's context. Not a competitor — a different problem

Part 2: The overall shape of Amenbo. It lays out, with diagrams, the GUI ⇄ Tauri ⇄ Core ⇄ CLI layering, where the data lives, and how decisions and tasks are held as a graph. Before diving into individual pieces of tech, take in the whole picture first.

The more you use it, the more context breaks down

Cutting the cost of catching up on context

The human is the one who bears responsibility

So, keep them separate

No conflict with team-oriented systems

Next