tRPC-Agent-Python

The deciding trait is that the control flow has names. Chain, parallel, cycle and transfer come as separate primitives, so the structure of your system is legible in the type you chose rather than buried in whichever loop you wrote by hand at midnight. That makes handing the code to a colleague a much shorter conversation.

What you take on is a lot of machinery for a small job. Pick it when the topology is the hard part. Pick something minimal when the hard part is the prompt.

Breadth by adaptation is breadth you rent. Each wrapped library moves on its own schedule with its own breaking changes, and an adapter layer is exactly where those changes land first, so the integrations that make this attractive are the parts most likely to break in a release nobody here controls. Nothing published states which versions are tested.

What it does right is keep the core independent. The orchestration primitives are the project's own code, so a broken adapter costs you an integration rather than the framework.

1. Putting heterogeneous components into one graph is the interesting decision, because it means the boundary between calling a tool, consulting a knowledge source and running generated code is expressed in the same notation. A reader can see the whole topology in one place, which is where most frameworks require three.

2. It also flattens a real distinction: those components have very different failure and security properties, and one notation does not make them equivalent. 3. No evaluation of the execution engine is published.

The gap between the owner's size and the adoption number is the whole story. A company at this scale open-sources what its own teams already run, so funding is a rounding error and continuity depends on whether the internal users stay, not on whether anyone outside adopts it. That is stable and it is also indifferent to you.

Moat: none intended, and no revenue is sought. Likely path: it tracks internal needs and the external release lags. Position: safe to use, and expect the roadmap to answer to somebody else.

The storage detail is the one that reaches my desk. Conversations kept across sessions in a database my team operates means whatever users typed is now subject to our retention schedule, our backup policy and our deletion obligations, and none of that is the framework's problem once it ships.

There is no console and no vendor relationship, because this is a dependency rather than a product, so the operational burden is entirely internal. Approved with conditions: a retention policy on the memory store agreed before the first deployment, not after.

Delegating the provider question to a routing library is the correct kind of laziness: it means the endpoint list is somebody else's problem to keep current and mine to point wherever I like, including things the authors never heard of. Permissive licence, readable Python, no account and no daemon.

Treating protocol servers as nodes rather than as an afterthought is the part I would copy. Whatever I already run becomes part of the topology instead of a special case bolted to one agent's tool list. Very few frameworks get that boundary right.