harness

The deciding trait is that the core is about a hundred lines. You can hold the entire control flow in your head, which means every question you have about why it did something has an answer you can find yourself in under a minute. Nothing else in this category is honest enough to be that small.

What that means in practice is that you assemble the tool rather than receive it, and the parts you do not write, you find or go without. Pick it if you enjoy building your own. Pick a maintained agent if you want to start working immediately.

This is the dealbreaker and it is documented as a feature. Executable plugins are found by searching upward from wherever the process was started, so cloning a repository and running the agent inside it hands that repository's author a place to put code. Rediscovery on every iteration means the set can change mid-run, after you approved what you saw at the start.

What it does right is depend on almost nothing. A shell, a JSON tool and a transfer client, all of which are already on the machine.

1. Reducing the kernel to dispatch and iteration is a defensible architectural position, and an unusually rigorous one: message serialisation and provider selection are policy, and policy outside the core can be replaced without a fork. 2. Allowing plugins in any language makes the extension boundary a process boundary, which is simpler to reason about than an in-process interface.

2. No evaluation is published and none is required, because the claim is about structure and the structure is a hundred readable lines.

That ratio tells a specific story. A hundred lines of shell script implementing an agent loop is an argument people enjoy having, and enjoying an argument is not adopting a tool. The attention is real and it converts to readers rather than users, which finances nothing and sustains nothing.

Moat: none, and by design; the whole point is that you could rewrite it. There is no entity, no commercial surface and nothing an acquirer would be buying. Likely path: it remains a widely cited demonstration. Position: read it, learn from it, do not depend on it.

A control that ships as an optional component is not a control. Approval before execution and spend accounting are the two things I would require, and here they are files a developer can decline to install, with nothing centrally verifying that they are present on any given machine.

It does run headless, which in a governed setting would be interesting. Everything else is missing: no identity integration, no provisioning, no audit record, and a supplier who is one person and a package tap. Not yet, and the condition would be a distribution where the gates cannot be omitted.

Three dependencies, all of which are already on every machine I own. No runtime, no package tree, no version manager, and a permissive licence over a script I can read during a coffee. Plugins in any language means my extensions are programs rather than callbacks inside somebody's framework.

What is missing is the model floor. No MCP client, so my servers stay outside, and no local endpoint, so a tool this determined to depend on nothing still depends entirely on an API. That is the one place the philosophy stops, and it is the place I would have started.