OpenAI Swarm

Nothing here is a trap exactly; it simply ended. The publisher has said in plain language that production work belongs on the successor SDK, and building anything you intend to keep on top of a project its author has retired is a decision you will be explaining to somebody in six months. The daily-use question does not arise because there is no day two.

There is one honest use left, which is reading it to understand where handoffs came from. Pick the OpenAI Agents SDK for anything you plan to run. Do not adopt this.

The archive flag is the whole review. No issue will be answered, no security fix will land, and the interface will not track changes in the underlying API it calls. Compounding it, the loop is stateless between calls by design, so anything resembling memory is code you write and then maintain alone against a frozen base.

There is no mitigation and no configuration that changes this. What it does right, and it is genuine: the entire idea reduces to two concepts, an agent and a handoff, which is why the successor kept both.

1. An agent is defined as instructions paired with callable functions, which collapses prompt and tool registry into one object. 2. Control transfers by returning another agent from a function, so routing is expressed in ordinary code rather than in a configuration graph. 3. Execution is client-side over the chat completions interface and retains nothing between calls, which makes each turn reproducible from its inputs.

That third property is why it reads as a pedagogical text: the absence of hidden state means a student can follow the whole loop. No benchmark exists, and none was ever the point.

There is no company risk here because there was never a company, only a marketing and research expenditure by a very large one. The sequence is familiar: publish something small, watch which abstractions developers adopt, then ship the supported version and retire the experiment. Everyone who built on the experiment paid the migration cost, which was always the arrangement.

The lesson generalises to every free artefact from a platform vendor on this board. Likely path was never acquisition; it was replacement, and it happened on schedule. Position: none. Read it as a case study in how platform vendors run free options.

This one takes thirty seconds. There is no invoice, no support agreement, no directory integration and no obligation of any kind, because the publisher has withdrawn it and named the replacement. Rolling out a retired dependency to sixty engineers creates a migration project we have chosen for ourselves, on a schedule we do not control.

Any pipeline built on it becomes technical debt on the day it is written, and the onboarding cost is wasted twice: once to learn it and once to leave. There is no condition under which this is worth the meeting. Not yet, and not later.

MIT and small, which is the only combination that makes abandoned code useful, because I can lift the fifty lines I want without inheriting a project. The install is a git URL rather than a published package, which tells you how seriously distribution was taken.

The part I cannot forgive is the model layer: one vendor, no substitution, no local endpoint, no protocol for tools. So the fork I would make is not a fork, it is a rewrite that keeps the handoff idea and throws away everything underneath it. Which, as it happens, is exactly what the successor did.