Agency Swarm

You will get value here on day one if your task decomposes into people. Agents take roles like CEO or developer, and the trait that decides daily use is that the communication flows are directional: you declare who may talk to whom, so the swarm does not turn into a group chat where every agent broadcasts at every other one and the token bill triples quietly.

Pick it for workflows you can draw as a reporting line. Pick CrewAI when you want a bigger community and more worked examples around the same role metaphor.

The structural risk is that this is not a runtime, it is an opinion placed on top of somebody else's runtime. Tool validation, execution and model handling come from below; what this project adds is topology. When the layer beneath changes semantics, nothing in the orchestration notices, and the failure shows up as an agent that stops answering rather than an exception you can catch.

What it does right: tools are Pydantic models, so a malformed tool call fails at validation instead of arriving in the model's context as a surprise.

1. Thread state persists through load and save callbacks supplied by the caller, so durability is the application's concern rather than a hidden database, which is the principled arrangement. 2. Inter-agent context moves through a send_message tool, meaning one agent's view of another is mediated by a tool call and therefore inspectable. 3. Verification of the resulting conversation is absent; nothing checks that a delegated subtask answered the question that was delegated.

No benchmark is claimed, and the documentation is a single site. The observation: the interesting property here is auditability, and nobody markets it.

The distribution came from content, which is a real channel and a cheap one, and the library has been in the market since November 2023 with 4,551 stars to show for it. What there is not is a price, a hosted tier or any mechanism by which this generates money, which means maintenance is funded by whatever the creator does next rather than by customers of this.

Likely path: a consulting or education business around the library, or dormancy. Position: adopt the code, expect nothing from the vendor, and budget for maintaining your own fork.

The demo is an agency of three. Procurement is simple because there is nothing to procure: it installs from a package index and the only bill is inference on a model contract we already signed. SSO and audit are not applicable to a library, which means they become our problem in whatever service wraps it. Nothing here ships to run in a pipeline unattended, so this lives in an application we build and maintain.

Onboarding is two days for a Python engineer. Approved with conditions: one team, one wrapped service, our keys.

Everything I want from a library is present. MIT means a fork is legal and permanent. One pip command installs it. Routing to Anthropic, Google, xAI, Azure or OpenRouter goes through LiteLLM, so the provider is a string and not a rewrite, and my key stays in my environment where it belongs.

Two gaps annoy me. There is no MCP support, so my existing servers do not plug in, and no local model runtime is documented, so my own hardware is not a first-class target. Both are fixable in a fork, which is the point of the licence.