Atomic Agent

The trait that decides it is inspectability. Sessions, memory, tasks and traces are ordinary files and a database on your disk, so when the agent does something surprising you open the record and read it, rather than filing a support request against a cloud you cannot see. That changes how much you are willing to trust it.

It is also an early preview and behaves like one. Pick it if you enjoy owning the whole stack. Pick Goose when you want a local agent that has already been through a few release cycles.

The combination is what worries me. Reach is broad, covering the filesystem, a browser and running processes, while the project warns that its own interfaces are unstable, so the configuration that constrains it today may not exist under the same name next month. Upgrades in that situation silently change what is permitted.

What it does right is enumerating consent. Six categories require approval by name, including process termination and outbound requests, which is far more specific than the single confirm dialog most desktop agents offer.

1. A percentage range without a comparison target is not a result. Faster than which build, at which quantisation, on which processor, measured as tokens per second or as end-to-end latency, are four questions the claim requires and none is answered.

2. The claim is also easy to substantiate, which makes its absence more notable rather than less.

3. Everything else here is described honestly, so this reads as an untested marketing sentence in an otherwise careful document rather than as a pattern.

Local-first products have a structural monetisation problem: the thing that makes them attractive, that nothing leaves the machine, is also the thing that removes every hosted revenue line. Nothing published suggests a plan, and a project this young without one is running on enthusiasm.

Moat: the local-first position, which is a preference rather than a barrier. Likely path: a paid desktop edition, an embedding play through the sidecar, or a stall. Position: install it, keep your data where it already is, and do not build a workflow that assumes a second year.

Running against a model on the developer's own machine means our source never crosses a boundary, and that removes the single longest item from my security process. Licensing costs nothing across the whole team.

What I get instead is sixty independent installations with no central provisioning, no shared policy and no way to revoke one. It performs no scheduled work, so there is nothing to report on and no throughput number to defend the exposure with. Not yet: I need one managed configuration before this goes past a pilot group.

This is close to the ideal shape. The inference layer is a library I already compile, the protocol client means my servers attach without adapters, and the whole agent can be embedded into another application rather than only used as one. That last part is rare and it is the difference between a tool and a building block.

Permissive licence over a codebase small enough to read, and state stored in files and a database I can query directly. Best local ownership story in this batch, preview status and all.