OpenAI's Practical Guide to Building Agents: What It Nails and What It Leaves Out

OpenAI's practical guide to building agents is the best free document on agent design in circulation, and if you're building anything agentic you should read it before you write a line of code.

It's also written from a particular vantage point — a model provider explaining how to construct agents well — which means it is thorough on design and nearly silent on the questions that determine whether the thing you build is worth building. Here's a fair summary of what it gets right, and the operator's addendum.

What the guide gets right

The definition is disciplined. The guide draws a hard line between a workflow that calls a model and an agent that independently accomplishes tasks on a user's behalf, using tools and deciding its own steps within defined boundaries. That distinction matters commercially, because most things people are selling as agents are workflows with a language model in the middle — and that's fine, but it should be priced and evaluated as a workflow.

The "when not to build one" section is the most valuable part. The guide is explicit that agents suit workflows where deterministic rules have failed: complex judgment calls, unmaintainable rule sprawl, heavy reliance on unstructured input. The implication, correctly, is that if a decision tree handles your case, use the decision tree. Most teams skip this section and go straight to architecture. That's how you get an agent doing a job an if-statement was doing fine.

The three foundations are the right three. Model, tools, instructions. Nothing exotic. The guidance to prototype with the strongest model to establish a performance ceiling, then substitute smaller models where quality holds, is exactly correct and rarely followed — most teams pick a cheap model first and spend weeks debugging a capability problem.

Tool design gets serious treatment. Standardized definitions, clear documentation, tools as the boundary of what the agent can affect. This is where real agents succeed or fail and the guide treats it with appropriate weight.

Orchestration advice is refreshingly conservative. Start with a single agent, add tools incrementally, and only split into multiple agents when complexity genuinely demands it. When you do split, the guide offers two patterns: a manager agent that calls specialized agents as tools and retains control, or a decentralized pattern where agents hand off to peers. The bias toward starting simple is the right bias, and it contradicts most of what's in your feed.

Guardrails are treated as layered, not singular. Relevance classification, safety checks, PII filtering, moderation, tool risk ratings, output validation, and explicit human intervention plans. The framing — build guardrails for the failure modes you've actually observed, plus the obvious catastrophic ones — is exactly how mature systems get built.

What it leaves out

None of this is a criticism of the document. It's a design guide and it does that job. But if you follow it end to end you will have a well-designed agent and no way to know whether it should exist.

1. Which job to automate. The guide tells you how to build an agent for a workflow. It doesn't help you pick the workflow. In practice that's the highest-leverage decision in the entire project, and most teams get it wrong by choosing the most intellectually interesting process rather than the most expensive one.

The test we use: high frequency, rule-shaped, survivable failure, touches a system of record, and a computable dollar value for doing it faster. For most service businesses, that lands on inbound lead response — not because it's sophisticated, but because a four-hour average response time is losing them jobs every single week.

2. Integration with systems of record. Tool design is covered thoroughly as an interface question. What's not covered is the organizational reality that your CRM has three custom fields with inconsistent naming, your calendar has double-booking rules nobody documented, and your pipeline stages mean different things to different people. That mess is most of a real agent project. The guide assumes clean tools; production hands you a data model that grew by accretion.

3. Economics. There is no ROI framework in the guide, and there shouldn't be — it's not that kind of document. But it means you can build exactly to spec and still be unable to answer whether the agent is worth its monthly cost. Compute the value before you build: recovered appointments times close rate times average job value beats saved-minutes-per-week as a justification every time.

4. What happens after launch. The guide gets you to a working agent. It doesn't cover the operating discipline that keeps one working: reading transcripts weekly, maintaining a regression set of real conversations, watching for drift when models update, and having someone whose job it is to notice when performance degrades. Agents don't fail loudly. They get slightly worse and nobody sees it for a month.

Design tells you how to build it right. It doesn't tell you whether building it is right.

The guardrails that actually matter for a customer-facing agent

The guide's guardrail taxonomy is comprehensive, which means it's also more than most businesses need. If your agent talks to customers about buying something, these are the four that carry nearly all the risk reduction.

1. Output validation against a schema, every time. The agent's structured output — the lead score, the appointment slot, the extracted phone number — gets validated before anything writes to a system of record. Not "usually valid." Validated, with a defined behavior on failure. This single guardrail prevents most of the damage an agent can do to a database.

2. A hard escalation trigger, defined in business terms. Not "when the model is uncertain" — models are poorly calibrated about their own uncertainty. Define it concretely: the customer asks about pricing outside a stated range, mentions a competitor's quote, expresses frustration, asks a question twice, or requests a human. Any of those, hand off immediately with full context.

3. A tool-permission boundary you'd be comfortable explaining. The agent can read anything; it can write only what you've explicitly allowed. Booking an appointment, yes. Changing a price, no. Sending a contract, no. If you'd be uncomfortable telling a customer the agent had that permission, it shouldn't have it.

4. A stop condition on repetition. Agents in a bad conversational state will loop — re-asking the same question, re-attempting the same tool. Cap it. Three attempts at anything, then escalate. Loops are the failure mode customers describe as "it was clearly a robot and it wouldn't listen," and they do more brand damage than any single wrong answer.

Everything else in the guide's taxonomy — relevance classifiers, moderation, PII filtering — is real and worth adding once you've observed the specific failure. Build for the failures you've seen plus the catastrophic ones you can imagine, and resist building for the theoretical middle.

How to read it, practically

If you're a business rather than an engineering team, here's how to get value from the document:

What this looks like when it's done

Our AI callers are, in the guide's vocabulary, a single-agent system with a tightly scoped tool set and heavy guardrails. They contact every inbound lead within 90 seconds, run a qualifying conversation, book the qualified ones directly onto a calendar, and write everything — score, transcript, next step — into a GoHighLevel pipeline.

Deliberately not a multi-agent architecture. Deliberately not autonomous beyond a narrow boundary. The sophistication is in the tool definitions, the escalation rules, and the fact that a human reads a sample of transcripts every week and tunes the questions.

The guide will teach you to build one well. If you want help deciding whether to build one at all — and which workflow is actually worth it — [book a free strategy call](/book) and we'll map it with you.