GraphBit

The deciding trait is how little ceremony a tool costs. A Python function with a decorator becomes something the model can call, which means your existing code is already most of the integration and there is no schema file to maintain beside it. For anyone who has written tool definitions by hand, that is the whole pitch.

Be clear about what it is not: nothing here edits your repository, so this is a library you build with rather than an agent you hand work to. Pick it when you are the one writing the agent. Pick a coding agent when you wanted something that opens files.

The limitation is structural and deliberate. A declared graph is fixed before the first call, which is what makes parallel execution tractable, and it also means the system cannot take a path nobody drew. Work that branches on what the model finds has to be expressed as every branch, up front, or pushed inside a single node where none of the guarantees apply.

The second option is the one people will take, and it hollows out the design without anybody noticing. What it does right is being honest about the trade: this is a workflow engine, and workflow engines are supposed to be static.

1. Self-authored benchmarks are not worthless; they are unfalsifiable, which is different and worse. The suite measures LLM calls, tool invocations and multi-agent chains, all reasonable axes, and every configuration choice on both sides of the comparison belongs to the party being flattered by it. 2. No harness, no versions and no rerun instructions are published.

2. The row itself records that this is an internal suite rather than a third-party one, which is the disclosure the marketing usually omits and does not repair the methodology. The correct response is not scepticism about the engine, which may well be fast, but refusal to carry the number anywhere.

Agent frameworks are where developer attention goes and revenue does not. There are dozens, several backed by model vendors who can subsidise indefinitely, and this one arrives with no hosted executor, no paid tier and no funding signal in the row. Moat: none, and performance is the least durable differentiator in software.

Likely path: a hosted or managed offering appears, or the company treats this as credentials for consulting work. Neither is bad for a user, and neither guarantees the library outlives the interest. Position: build on it only where swapping the orchestration layer later would cost you a week rather than a quarter.

Somebody here has sat in a compliance meeting. A policy object that blocks personal data before it reaches a provider is a control I can point at in an audit, and a tracer that captures prompts, responses, tokens, latency and errors without anyone editing code is the observability I normally have to build myself.

What it is not is a tool sixty engineers use. It is a library a few of them import into a service we then operate, and there is no console, no single sign-on and nothing to onboard anybody onto. Approved with conditions: it lives inside a service we own, with the guardrail policy set centrally.

The Rust core is the reason to look. A workflow engine written in a language with real concurrency, exposed through the API everyone actually uses, is the correct division of labour, and it means the performance question is not a Python question. Apache-2.0 keeps the whole thing forkable.

What is missing is the protocol. There is no MCP client and no MCP server, so every tool the graph can reach is one somebody wrote into this codebase, and the servers I already run are outside it. For a framework of this vintage that is a real omission. Grudging respect for the engine, filed under incomplete.