Octomind

The deciding trait is that it can sit in the background and be spoken to later. A running daemon you inject a message into keeps its context between your interruptions, so the agent stops being something you start from nothing every time you have a thought. Anyone who works in fragments rather than in sessions will feel the difference within a day.

What it lacks is polish and a crowd. Pick it if a persistent agent fits how you work. Pick a mainstream terminal agent if you want documentation written by strangers.

The dependency is unusual and worth naming. Most agents implement file access and command execution themselves and use the protocol for extras. Here the fundamentals arrive through it, which means a missing, outdated or misbehaving server degrades not a feature but the whole agent, and nothing in the row records which servers are expected or how a version mismatch surfaces.

What it does right is refusing to hide the mechanism. The tools are visible components rather than opaque built-ins, so a failure has a name and a place.

1. A spend ceiling that is part of a run's declaration rather than a runtime afterthought is the right place for it, because the bound exists before the first token and can be reviewed by someone who never reads the source. 2. Declaring roles in the same document keeps decomposition visible, so who delegated to whom is answerable from configuration instead of from a transcript.

2. No evaluation is published and none is claimed. The argument is about the shape of the declaration, and that argument is made cleanly.

A studio releasing a tool with nothing attached is either patient positioning or a side project, and the numbers here are too small to tell you which. Modest attention and no commercial surface means no revenue to defend and no customer whose departure would be noticed, so continuity rests entirely on the studio's other work paying the rent.

Moat: none; a runtime with several front doors is an engineering choice, not a defensible one. Likely acquirer: none. Position: use it, keep the configuration portable, expect nothing from the vendor.

Piped input is a boring feature and it is the one that matters to me. A tool that takes work from a pipeline can be scoped, budgeted, timed and reported on like any other stage, and its output lands in the review process we already run rather than on somebody's laptop.

What is missing is everything about identity: no single sign-on, no directory sync, no audit export and no console, so access control is whatever the runner already enforces. Nothing to license across sixty engineers. Approved with conditions: pipeline use, with credentials issued by us.

Speaking the agent protocol as a subordinate is the trick nobody else here does. It means this binary slots underneath the editor agent I already use instead of competing with it, and the whole configuration lives in one text file I keep in version control next to the code.

Permissive terms, a compiled binary, and every tool it uses is a component I chose. The only thing outside my reach is inference, since local weights are not a listed destination. Everything else here is mine.