OpenAI Agents SDK

An Agent is instructions plus tools, a handoff is one line, and Runner.run drives the loop, so a triage-and-specialists workflow fits on one screen. The daily-use trait that decides it is how little ceremony there is: you write plain Python functions, the SDK turns them into tools, and the afternoon goes to the task rather than the framework.

Pick it if you build on OpenAI models and want orchestration without a graph library. Pick LangGraph when the workflow must pause for days, and the Claude Agent SDK if the agent you are building spends its life editing a repository.

The risk is asymmetric lock-in. The model can be replaced through a custom provider. The tools cannot: web search, file search, code interpreter, computer use, shell and apply-patch are hosted tools that run on OpenAI's platform and bill per call. Move the model and the agent keeps its brain but loses its hands.

The consequence is that portability has to be designed in from the first commit: local function tools for anything that touches your data, hosted tools only where nothing else exists. What it does right: guardrails are a first-class primitive at the input and output boundary, not an instruction buried in a prompt.

1. Agents carry instructions and tools. 2. Handoffs and agents-as-tools delegate, so context is partitioned by transfer rather than shared. 3. Sessions hold memory across runs, the only documented context-gathering mechanism; there is no repository map, the agent reads what a tool returns. 4. The loop ends on a final output or a turn limit, and nothing checks a result against a test, so verification is the caller's job.

MCP servers attach over stdio, SSE or Streamable HTTP. No benchmark is published. The observation: an SDK this small has little to be wrong about, which is a design choice and also a limit.

This SDK exists to make API spend sticky. It is free because the tokens are the product; every tutorial that works recruits another developer onto the account, and the framework's simplicity is a customer-acquisition cost rather than a moat. Fine business for the vendor, neutral for the builder who remembers which side of the ledger they sit on.

The pivot risk is internal. The same company ships Codex and hosted agent products, so a team building here is one launch away from competing with its own supplier, which also sets the price of inference. Position: build on it, keep the model layer abstracted, and assume the vendor ships your feature.

The demo is a triage agent handing off to two specialists. As a dependency it costs sixty engineers $0 in seats, the tokens land on an OpenAI contract procurement already signed, and support is a GitHub issue tracker rather than a phone number, normal for a library and unusual for something in production.

The procurement question is tracing. Built-in tracing lands on OpenAI's platform by default, so a span may contain a customer record before anyone has read the retention terms. Onboarding is a day for a mid-level Python engineer. Approved with conditions: the tracing exporter reviewed by security, and disabled until it is.

Readable Python under MIT, and small enough to read in an afternoon. An MCP server is an object from agents.mcp passed in mcp_servers=[server]; there is no config file, it is all code, which suits me because code goes in version control and JSON blobs get lost. The LiteLLM path points an Agent at a local Ollama model, so the SDK itself runs air-gapped even if the hosted tools do not.

The fork question answers itself: the loop is a few modules, the prompts are in the source, and the pieces I would replace are classes, not services. Grudging respect: the vendor SDK that is easiest to leave.