Which open-source agent frameworks are production-ready enough for small teams?

Treat production-readiness as an operations filter, not a feature scoreboard. For small teams, the open-source agent frameworks that actually stick are the ones with boring release notes, explicit deprecations, and docs that describe failure modes—not only demos. Community energy and plugin counts help later. First ask whether maintainers practice upgrade discipline: every minor bump should say what broke, what is deprecated, and what you must migrate before promote day.

Before you standardize, run one control. Pin a minor version, then stage the next minor against a single golden workflow—tool call, retry, and a human-approval step—in a throwaway environment. If behavior shifts without a migration note, or the path only works on main, that stack is not ready for a lean team yet.

The quiet consequence is that the noisier ecosystem often loses. Small teams pay more for thrash than for a missing plugin they can stub. Bake the pin, the golden-path check, and a scheduled upgrade window into the rollout itself. That is how open-source agents stay operable without a platform group babysitting every release.

“Production-ready open source” is a procurement phrase that smuggles in a false equation: popular repo + decent docs = supportable production system. For a small team, the product you are buying is not the framework. It is the residual ops load after the demo works—upgrade cadence, plugin breakage, and who owns 2 a.m. failures when the model host, tool endpoint, or worker dies mid-run.

Before any shortlist, force a commercial control: pick one candidate, pin exact versions of framework, runtime, and every plugin you would ship, then run a cold redeploy of a real multi-step agent job with forced tool timeout and worker kill. Require a written runbook that names who restarts what, how state is recovered, and which logs prove the run is safe to retry. If that package cannot be produced in a fixed evaluation window without heroics, the framework is a research stack with a community, not a production platform for your headcount.

The non-obvious cost is dependency gravity. A rich plugin ecosystem looks like leverage until every integration becomes a second product you must patch, version, and explain to auditors. Documentation and stars do not reduce that surface. Ownership does. Treat “who owns the failure path” as the purchase criterion, not the README’s completeness.

Production-ready is not a ranking frameworks earn in the abstract. It is a fit between workload shape, ops capacity, and how much of the control plane a small team can own. The question smuggles in certainty that a shortlist exists independent of those constraints. That certainty is false.

Qualified support holds for a bounded use case only: internal assistive agents with one owner path, deterministic tool boundaries, and a kill switch that does not depend on the framework staying healthy. Documentation quality, community velocity, maintenance cadence, plugins, and deployment patterns are evidence to weigh—not trophies to chase. They matter insofar as they reduce the cost of recovery when something drifts.

Draw the line where failure cost exceeds the team’s ability to debug without upstream maintainers. Multi-agent autonomy facing customers, unsupervised write tools, or any loop whose state you cannot reconstruct from logs crosses that line for most small teams.

One move: freeze-and-replay. Pin framework, model client, and tool stubs; re-run the same five failure scenarios after a cold restart. If recovery needs tribal knowledge the docs do not encode, treat the stack as research, not production. Non-obvious consequence: the most active project can still strand you when its upgrade cadence outruns your capacity to re-verify agent behavior.