Alethe

The deciding trait is that the layout survives. Each agent lives in a real terminal inside a project arrangement you built, split the way you like it, and moving panes around does not kill anything. Coming back on Monday to the same windows in the same places is a smaller feature than it sounds.

It is wrong for you if one repository and one agent is the whole job, because then you are running a window manager inside a window manager. Pick it if you juggle projects and want the arrangement to be a thing you keep. Pick tmux if your fingers already know the keys.

The dangerous capability is lifecycle management. This app does not only display the CLIs; it installs them, updates them and removes them, so its defects land in somebody else's binary rather than in its own window. A failed update leaves the user with a broken agent and two suspects, and nothing documented describes rollback.

The exposure widens with every vendor added, since each has its own installer conventions and its own release cadence. What it does right is being honest about the boundary: the row records that files are edited by the CLI in the pane, not by this app.

1. Most agents build their own picture of a repository by searching it, which means n agents perform n incompatible analyses. Serving a graph through a protocol makes that picture a shared artefact instead: the same structure, the same version, available to whichever CLI is asking. 2. The design also survives model changes, since a graph is not a prompt.

2. What is undocumented is how the graph is built: which languages are parsed, how it is kept current as files change, and what happens when it is stale. A shared context structure is only an improvement while it is correct, and no evaluation of its accuracy is published.

The gap between the polish and the structure is the story. Somebody has built a real product here, and there is no entity, no hosted tier and no pricing page to convert that work into a runway. Moat: none, and a manager for other people's agents is the most substitutable position on this board.

Likely path: the vendors whose CLIs it wraps ship their own multi-session views, and this survives only where it is more pleasant than theirs. There is no acquirer, because the parts worth having are a weekend of work for a company that already owns the agent. Position: use it, and expect to replace it.

Give me the inventory and keep the rest. Knowing which MCP servers exist on a machine, and which agents can reach each one, is the closest thing to an access review anybody has offered me for this class of tool. It answers a question I have been putting to vendors for a year.

It is a per-machine view, though, not a fleet view: sixty desks means sixty inventories and nobody to aggregate them. No single sign-on, no central policy, nothing that runs in a pipeline. Approved with conditions: it goes on developer machines as a convenience, and the actual access review stays where it already lives.

The licence is the strongest copyleft on this shelf, which on a locally installed desktop app mostly means the fork is protected rather than that anyone is compelled to publish. Fine by me: the guarantee I want is that a maintainer walking away cannot take the code with him, and this delivers that.

Building from a clone works. The listing of skills installed per agent is the small feature I did not know I wanted: those files accumulate invisibly and nothing else shows me what any given CLI is carrying. Grudging respect, and a wish that it spoke the protocol in both directions.