WayFlow

The deciding trait is that plan steps arrive prepared. Instead of writing the control flow of an assistant yourself, you compose pieces somebody already shaped, which gets a working prototype out in a day and means the interesting decisions have partly been made for you. Whether that is a relief or an irritation depends entirely on you.

There is no shell, no file editing and nothing that touches a repository, so this builds assistants rather than coding agents. Pick it for that job. Pick a coding tool for the other one.

A reference implementation with no second implementation is a specification with extra steps. Portability is the reason anyone adopts a standard, and portability can only be demonstrated by moving a definition to a different runtime and watching it behave the same way. Nothing in the row records such a runtime, so the guarantee being offered has not yet been tested by anybody.

What it does right is publishing the specification separately at all, which at least makes the second implementation possible for somebody else to write.

1. Declaring an assistant as a composition of typed steps is the more durable of the two available designs, because the structure survives a change of model while a system prompt encoding the same logic does not. 2. Shipping a standard library of those steps is the useful half: shared vocabulary is what lets two teams read each other's assistants without a meeting.

2. No evaluation is offered and none is claimed. The argument is about representation, and it is made in the correct register for that.

This is the one project on the page where survival is not the question. A corporation of this size can fund a library indefinitely out of a rounding error, and the reason it would is written into the provider list: assistants built here run inference somewhere, and the default somewhere belongs to them.

Moat: the standard, if it takes, plus the cloud attachment. Likely acquirer: none, and none possible. Likely path: maintained while a product team benefits, archived quietly if that changes. Position: safe to depend on, deliberate about the model.

A recognisable corporate publisher changes the conversation in my review board, because the questions about provenance, patching and contributor agreements have familiar answers even without a support contract. That is worth more than most features I am shown.

Operationally nothing changes: this becomes a dependency inside a service my team builds and operates, so identity, retention and the on-call rota are ours, and no engineer is handed it directly. Nothing per seat across sixty of them. Approved with conditions: a dependency we own, with the model provider chosen by us.

A corporate publisher naming a local serving option is rarer than it should be, and it is the difference between a library I will try and one I will not. Permissive terms mean the fork survives whatever a strategy review decides, and installing it is a single package into an environment I control.

What is missing is the protocol everyone else speaks, so tool servers I already run cannot attach and every capability has to be written against this library instead. That is a real cost and it is a deliberate one.