Partitioning an AI agent's reach by structure

July 16, 2026

Series · Part 4 — “Building task management for AI agents.” Last time was why catching up is fast. This time: partitioning the AI’s reach.

Part 1 listed, among the troubles of working with AI agents, one in particular: another project’s information turns into noise and pollutes memory. This part is the answer to it — how to partition the reach.

You can ask in the prompt, “don’t touch the neighboring project.” But there is no guarantee that request is obeyed. Amenbo (https://amenbo.work/) partitions the reach by mechanism instead.

The folder is the boundary

As we saw in Part 2, a folder’s .amenbo is a marker that points at which project you are in. That same marker becomes the AI’s reach. Inside the project that .amenbo binds, the AI can read and write. But any operation that reaches out toward an outside project is turned down by the CLI itself.

Name another project, or reference another project’s T-nnn / D-nnn, and what comes back is out_of_reach. This applies to both reading and writing: the AI cannot so much as list the neighboring project. If it cannot read, the neighbor’s context cannot slip into the session — and that is the point.

The boundary. The AI and the amenbo CLI are both bound to project A by .amenbo. A single store holds projects A and B; the AI can read and write project A, but an attempt to reach toward project B is turned down with out_of_reach and never arrives. The store is physically one; the partition is logical. — Only inside the project that `.amenbo` binds. Reach outside and `out_of_reach` means it never arrives.

The boundary cannot be widened with a flag. Point at another project with --project and the operation is refused before the specification ever takes effect. On the code side too, the design does not let you forget: omit which reach a read or write is scoped to and it will not even compile. Containment does not depend on the writer remembering.

Refusal, not a plea

The important part is that none of this rests on the prompt’s goodwill. A plea of “don’t touch it” can be broken. When the CLI cannot reach in the first place, there is nothing to break.

Not a plea but a boundary. On the left is the prompt approach, asking 'don't touch the neighboring project'; whether it is obeyed is up to the other side, and it can be broken. On the right is the structural approach through .amenbo, where an attempt to cross is refused by the CLI with out_of_reach, so nothing rests on the plea. — A plea can be broken. A boundary never arrives.

One caveat: what Amenbo closes is only its own window — the CLI. It does not fence off an AI that opens the database directly with raw SQL from the terminal, or reads files on disk. That is the OS’s job, and Amenbo does not pretend otherwise. Still, as long as the AI works through amenbo, crossing into the neighbor stops by mechanism rather than by plea. The idea is to stand a boundary on the side of the tool you hand the AI.

Part 5: writing at the same time without breaking. Why a GUI and a CLI writing the same SQLite in parallel, from two entrances, does not break.

The folder is the boundary

Refusal, not a plea

Next