Claw Orchestrator

The deciding trait is what it does to a tool you already have. A coding CLI designed for a person at a keyboard becomes a session that stays alive and takes instructions from code, which means the agent you know keeps its behaviour and gains a handle.

It is wrong for you if you wanted a better agent, because this makes no agent better; it makes them addressable. Pick it when the thing blocking you is automation rather than capability. Pick a vendor SDK when you would rather program against an interface somebody promised to keep stable.

Seventy-seven tools is the number to sit with. Every one is a promise about behaviour that has to survive the next release of whichever CLI it wraps, and the wrapped CLIs are built by companies with no obligation to this project. Breakage will not arrive as an error; it will arrive as a tool that returns something plausible and wrong.

Nothing in the row describes a compatibility test suite or a supported-version matrix, so the user is the integration test. What it does right is publishing the surface at all: a documented tool list is something you can test against, which is more than most wrappers offer.

1. Role separation is a real design, not a prompt trick: distinct loops with distinct responsibilities is how a system differs from a long completion. 2. The separation is organisational rather than epistemic. A reviewer drawn from the same stack as the coder shares its blind spots, so the check catches carelessness and not misunderstanding.

2. Councils are offered as the answer to that, and a council of one model is not a second opinion. No evaluation is published for either arrangement, and the row claims none, so the design has to be judged on its structure. The structure is sound and the independence assumption is unexamined.

The volume of work here is the signal that worries me. This is far more product than one person maintains indefinitely, and there is no entity, no revenue and no funding to convert effort into a team. Projects at this ratio of ambition to headcount either find a sponsor or slow down.

Moat: none, and wrapping other vendors' tools is a position they can end with a release note. Likely path: an employer absorbs the author and the repository becomes a portfolio piece. Position: use it where it saves you a week, and never where a quarter of work depends on it still being maintained.

The useful fact is that it runs unattended. A wrapped CLI driven programmatically can become a pipeline step, which means this can produce a number rather than an anecdote. The administration story is one embedded dashboard per installation, so what I get is sixty local views and no fleet view.

Distribution is a global npm package, which makes version pinning our problem on every machine that has one. No single sign-on, no directory sync, no audit export, and the model spend stays on whichever subscriptions the wrapped CLIs use. Approved with conditions: run it in CI where we control the version, not on sixty desktops.

Four entry points into one API is the detail I care about. MCP for the assistants, the OpenClaw gateway for anything else, the command line for a shell script, and a TypeScript import when I want types. Most projects pick one and make you build the others; this one shipped them and let me choose.

MIT means the whole thing is forkable, and it wraps any custom CLI, so a tool I wrote myself joins the same session model as the vendors' ones. That is the part that makes it mine rather than theirs. Grudging respect, tempered by how much of this rests on other people's release notes.