Rivet

The deciding trait is watching a run happen. You attach to a graph while it executes, including one running inside your own application, and see which branch it took and what each node received. Debugging a chain of prompts usually means reading logs and guessing; here you watch it, and the difference in how quickly you find the wrong node is not small.

What it is wrong for is a codebase where everything else is text and reviewed as text. Pick it for logic other people need to see. Pick a library when they do not.

The problem arrives at the second contributor. A visual project is a file, and files get branched, conflicted and reviewed, but nobody reads a serialised node layout for intent. So changes are approved by opening the editor and comparing by eye, or approved without being read at all, and the second happens more often than teams admit.

What it does right is refusing the usual two-artefact trap, where you prototype visually and then rewrite the whole thing by hand for production.

1. Eliminating the gap between the development representation and the deployed one removes an entire family of defects, the ones that exist only because a prototype was transcribed. 2. Live attachment to a running instance means observation happens on the real execution, which is a stronger position than reconstructing behaviour from logs after the fact.

2. Two model vendors are supported and no evaluation is offered, which is consistent with a product that claims an authoring and debugging method rather than a capability.

Tooling published beside a company's actual product has a predictable life. While the internal team uses it, it ships; when their needs move, it slows, and no customer contract obliges anyone to keep it current. The star count reflects genuine adoption and buys the project no protection at all inside the parent.

Moat: none required, since it is not competing for revenue. Likely path: continued light maintenance, or a hand-off to the community. Position: safe to build with because the source is yours, unsafe to expect a roadmap from.

The language constraint is the first filter. My services are not all TypeScript, and adopting a component that only executes inside one runtime means either a new service boundary or a rule about where agent logic is allowed to live. Both cost more than the software, which costs nothing.

There is no administrative surface, no directory integration and no unattended execution, so nothing here appears in an audit or a dashboard. Onboarding is a day for anyone who already writes TypeScript. Approved with conditions: one team owns the graphs and the runtime around them.

Publishing the execution engine as an ordinary package is the part that matters to me. I am not locked into their desktop application; I can import the core, run a graph from a script, and the permissive licence means a fork is legal if the editor ever goes closed.

The narrowness is real, though. Two providers, no protocol support for the servers I already run, and nothing about the design invites a third-party endpoint. I can extend it, but I would be extending it alone.