Agenvoy

The deciding trait is scope. This is not a repository editor with a chat box; it takes a request, breaks it into steps, calls tools and reports what happened. You keep the say over which tools exist, what runs on a schedule and what sits in its working context.

That breadth is also the problem: if your day is code review and merges, a general assistant is a worse coding agent than a coding agent. Pick it if you want errands and automation on your own machine. Pick a terminal agent if the work you want done lives entirely inside one repository.

One word is doing a great deal of work here. Tools the agent authors are described as sandboxed, and the row's own note records that the mechanism behind that word is not stated. For a program whose distinguishing behaviour is generating and executing new code, that is the sentence a careful engineer looks for first.

The consequence is that the risk is not one-time. Each session can add another executable artefact behind a boundary nobody has described, so the surface only grows. What it does right is keeping all of it on the machine rather than in somebody's cloud, so the audit, when someone finally performs it, is possible.

1. Generating a tool is a reasonable design; the interesting claim is the verification attached to it. The documentation says the agent writes the tool and tests it, but a test with no stated oracle is an assertion about diligence rather than a mechanism.

2. Nothing describes what happens when that test fails.

3. Retention makes the question sharper. A tool kept for next time is reused under conditions its author never saw, so the moment of verification and the moment of use diverge over time. No evaluation of the resulting library is published, and none is claimed, which is at least consistent with the rest of the record.

There is a brand here and a domain, which usually signals an intention to sell something later. Nothing in the row says what that something would be: no hosted tier, no paid seat, no team plan. Stars are the only demand signal available, and stars have never renewed a contract.

Moat: none yet, and the shape of the product makes one hard: a personal agent on your own machine leaves no data behind for the vendor to compound. Likely path: a hosted version appears, or the author's attention moves and the binary stops changing. Position: try it, and do not assume the name outlives the enthusiasm.

The distribution is the blocker. Installation is a script fetched over the network and piped into a shell, which is not a sentence I can put in front of a security review covering sixty machines. The row lists that as the only route, with nothing to mirror or pin.

After that, the usual absences: no single sign-on, no directory sync, no audit export, and nothing that runs unattended in a pipeline, so it produces no number I can report. Licence cost is zero and that is the only cheerful line. Not yet: bring me a packaged build and a policy for what it is allowed to execute.

Both ends of the protocol in one binary is the detail worth having. It consumes MCP servers I already run and publishes its own tool library back over MCP, so Claude Code and Codex reach the same tools instead of each growing a private copy. That is the difference between a tool and a silo.

Apache-2.0 keeps the fork honest and Go means one static artefact with no runtime to install underneath it. The model provider is mine to choose, which is the minimum I ask for. Grudging respect: this is closer to a Unix utility than to a product, and I mean that as approval.