Zypher Agent

The deciding trait is that it refuses to be a workflow. The model picks the next step every time, and the library says so plainly rather than pretending there is a graph underneath, which means you get an agent's flexibility and an agent's unpredictability in the same package. Anyone who has tried to make a workflow engine behave like an agent will recognise the honesty.

That also means you cannot promise a customer what it will do. Pick it if you are embedding an assistant and the paths are genuinely open. Pick a workflow library if anyone downstream needs the sequence to be the same twice.

It is published for one runtime. JSR and Deno are the documented install, and npm support is described as coming, which puts most of the TypeScript teams who would want this on the wrong side of the line today. A library's reach is its package manager, and this one has picked the smaller of the two by an order of magnitude.

There is no unattended mode and no second agent, so the failure surface is whatever your own application exposes. What it does right is being explicit about that boundary: the library takes a loop and stops, and the rest of the risk is yours by design.

1. Checkpoints are git-based, so the record of what an agent changed is the same record everything else in the repository uses, and reverting is an operation the team already understands rather than a proprietary undo stack. That is the correct choice and it is not the common one.

2. The loop interceptor runs after inference, which places the intervention point where a caller can inspect what the model produced before anything acts on it. Between those two, an embedder can both prevent and undo. 3. No evaluation accompanies the library, and none is needed for claims about structure.

An SDK with no hosted component captures nothing by construction, and CoreSpeed has not indicated what the paid half is. 330 stars for an embedding library is a reasonable start and a poor proxy, because libraries are adopted quietly by companies who never star anything.

Moat: none yet; embedding libraries win on the number of applications that depend on them, which is a distribution race this has barely entered. Likely path: a hosted control plane appears above it, or it becomes reference code for the company's real product. Likely acquirer: a platform vendor buying the team. Position: fine to build on, keep the integration thin.

It ships a terminal tool, and that is the sentence my security review will stop at. Whatever we embed this in inherits the ability to run commands on the host it lands on, so the question is not whether the library is good, it is what our own product does with a capability we handed it.

There are no seats and no invoice, so this is an engineering decision rather than a purchase. Nothing here runs in my pipeline and there is nothing to audit centrally, because whatever we build becomes ours to log. Approved with conditions: the terminal tool disabled unless a specific feature needs it.

Apache-2.0, and the MCP support includes OAuth, which is the part almost nobody implements. Every other client I have wired up handles the easy case and leaves me holding a token I have to refresh by hand; native OAuth means the servers behind an authorisation flow are actually reachable rather than theoretically supported.

Custom tools sit alongside the built-in ones rather than in a plugin ghetto, so extending it is writing a function. What is missing is any route to a model I serve myself: two hosted providers, both of them somebody else's, which for a library I embed in my own product is the wrong shape.