Dapr Agents

The deciding trait is that a long run survives the process that started it. Restart the pod halfway through and the work picks up where it stopped, which changes what you are willing to let an agent attempt: an hour of tool calls stops being a bet on uptime. Nothing else in this category treats that as the headline.

Whether you should care depends entirely on what you already run. Pick it if the runtime is already in your stack. Pick a smaller library if this would be the reason you adopted one.

The promise moves the failure one layer down. Runs survive restarts because their state is written somewhere, and what that somewhere is remains a deployment decision: an in-memory component during development looks identical in code to a replicated one in production, and the difference only appears the first time a node dies. Coordination inherits the same caveat from the broker.

What it does right is reuse infrastructure rather than invent it. The persistence and messaging are the same ones the surrounding services already use and already monitor.

1. Replay-based durability is a well-studied execution model with a documented constraint, and applying it here forces a separation most agent frameworks never make: deterministic control flow on one side, non-deterministic model output recorded as an activity result on the other. 2. That separation is exactly what makes a run reconstructible rather than merely retried.

2. It also means the framework's correctness depends on authors respecting the constraint, which is a discipline the type system cannot enforce. No evaluation is published, and the claim under test would be an operational one rather than a capability score.

Neutral governance is the strongest longevity structure available in this category, and it is the reason this scores where it does. No investor needs an exit, no acquirer can redirect the roadmap, and the commercial parties contributing are shipping products on top rather than selling this. Adoption rides on the parent runtime's existing install base rather than on marketing.

Moat: distribution through the runtime, which is real and inherited. Likely path: incremental releases funded by the vendors already embedding the parent. Position: the safest maintenance bet among the frameworks on this board.

This is the rare case where adoption is a smaller decision than it looks, because the boring parts are already solved. Agent workloads inherit the security posture, the reliability behaviour and the observability we configured for everything else, so an incident here reaches the same on-call rota through the same alerts rather than through a developer noticing.

The limits are ordinary. It is a library in one language, so the cost is engineering time and the audience is the teams who write in it. Approved with conditions: it ships inside services my platform group already operates, never as a tool handed to developers.

Calling tools over a protocol instead of through an in-tree plugin list is the decision that decides whether I can extend something without asking permission. Anything I have already exposed is reachable here, and the licence is permissive enough that a fork stays legal for as long as I need it.

Where it disappoints me is inference. The provider list is two hosted vendors, and nothing documented points the model layer at a runtime on my own hardware, so the weights stay somebody else's no matter how much of the rest I control.