zot

The deciding trait is that it reads the files you already have. Standing instructions come from AGENTS.md and reusable ones from SKILL.md, both of which are probably sitting in your repository already because another tool put them there, so the setup cost of trying this is genuinely zero minutes.

What you are trying is a small binary with a big provider list and not much else around it. There is no version control integration and nothing to catch a bad edit. Pick it if you want to swap harnesses without rewriting your conventions. Pick something with git awareness if you let agents run unsupervised.

The sandbox tells you to use a different sandbox. /jail roots the file tools at the session directory and blocks obvious shell escapes, and the README's own advice is to run the whole thing under Docker if you need real isolation. That is an honest disclosure and it is also an admission: the guardrail stops accidents, not an agent that has been talked into something.

Blocking obvious escapes is a phrase that carries the whole risk. Obvious is doing work there, and the set of non-obvious escapes from a shell is not a set anyone has finished enumerating.

1. The subagent model has no isolation boundary. A swarm shares the host working directory and the same read, write, edit and bash tools, with no per-agent worktree and no branch, which means two agents editing the same file are racing and the result is not attributable to either.

2. That is a design choice with a real benefit, since shared state is what lets subagents cooperate without a protocol, and a real cost, since nothing in the record says which agent made which change. 3. No evaluation is offered, and the interesting measurement here is not capability but how often concurrent agents interfere.

Thirty-plus provider integrations maintained by one person is the number that matters here, and it is a liability rather than an asset. Every one of those is an API that changes without asking, and the maintenance load grows with the list while the differentiation does not, because provider breadth is the most copyable feature in this category.

Moat: none. Likely path: the list decays quietly, with the popular providers staying current and the long tail rotting, which is what always happens. Likely acquirer: nobody. Position: fine to use, and check that the provider you rely on was updated this quarter.

The print and JSON modes are the only reason this reaches my desk. They accept piped input and emit structured output, which means it can sit in a pipeline and produce something a build step can act on, and Windows is supported, which most of this category is not.

Everything governance-related is absent: no identity, no audit trail, no retention statement, no organisation behind it. The sixty-seat cost is zero in licence and entirely in provider keys, which I would want issued centrally rather than personally. Approved with conditions: pipeline use with a service key, and nothing interactive on a machine that holds customer data.

MIT, one static binary, and Ollama is a first-class provider rather than an afterthought bolted to a compatibility shim, so a model on my own hardware is a menu entry like any other. That is the baseline and it clears it.

The part I did not expect is the extension mechanism: extensions in any language attach over subprocess JSON-RPC, which means a tool I wrote in whatever I felt like that week becomes an agent capability without linking against anything or learning a plugin API. There is no MCP client, and this is the first tool where I do not mind, because the subprocess contract is simpler.