Agent Builder vs LangFlow / n8n?

LangFlow and n8n have better support for non-OpenAI models, more mature MCP integration, and better in-flow user input. Agent Builder has tighter OpenAI model integration, native widgets via ChatKit, and easier evaluation tooling. Pick based on whether you're all-in on OpenAI.

Can I use non-OpenAI models?

Not in Agent Builder directly — each agent node uses OpenAI models from the dropdown. For other providers, you'd use the Agents SDK in code or a different platform entirely.

How does pricing work for production traffic?

Each node executes against your OpenAI token budget. Estimate per-request cost = sum of all LLM-node token costs. Use smaller models for cheap nodes; profile typical request shape before forecasting cost.

Can I version-control my agent flow?

Indirectly — the “view code” button exports the flow as Agents SDK code that you can commit to Git. Visual versioning inside the builder is limited; the code path is your audit trail.

Do I need ChatKit for production?

For consumer-facing agents with interactive widgets, real tool execution, and mid-flow input — yes. For pure backend agentic workflows (e.g. a webhook triggers an agent that processes data), the visual builder alone may suffice.

What about Claude Skills or Anthropic’s equivalent?

Anthropic's Skills system is a different shape — markdown-based, more lightweight, no visual builder. They're complementary tools for different use cases. If you primarily use Claude, Skills is the more natural path.

OpenAI Agent Builder Review: Honest Tutorial

Introduction

OpenAI’s new Agent Builder shipped in early October 2026 as part of AgentKit, alongside the Connector Registry and ChatKit. The pitch: a visual drag-and-drop interface to build AI agents without code, with persistent state, branching logic, MCP integrations, and a widget system for rich responses.

The reality is more nuanced. The visual builder is genuinely capable, but most of the interesting features (tool calls, OAuth-based MCP, in-flow user input, interactive widgets) only work properly when you connect it to your own backend and write meaningful code. This is the honest tutorial — what works, what doesn’t, and the patterns that make the visual builder useful despite its limitations.

📚 Table of contents

What AgentKit actually includes
The Agent Builder interface
Building your first flow: nodes, state, branches
Structured output with JSON and widgets
The state-driven pattern that makes flows reusable
Guardrails, file search, and other built-in nodes
MCP and the OAuth limitation
ChatKit and going beyond the visual builder
Pricing and token costs
Where it shines, where it doesn’t
Common mistakes
FAQs

What AgentKit actually includes

AgentKit is a bundle of three products that work together:

Agent Builder — the visual flow editor with drag-and-drop nodes for agents, conditionals, state, tools, and widgets.
Connector Registry — a catalog of pre-built integrations to services like Gmail, Google Drive, Shopify, plus the ability to plug in your own MCP servers.
ChatKit — embed the agent in your own front-end with rich widgets (forms, lists, calendar pickers, custom UI) instead of plain chat.

Underneath it all are the existing Responses API and Agents SDK that developers were already using. AgentKit is the higher-level UI layer on top.

The Agent Builder interface

Open platform.openai.com, sign in, navigate to Agent Builder. You get a canvas with nodes you can drag and connect:

Start — entry point; defines initial state.
Agent — an LLM call with system + user prompts, model picker, tool access.
If/else — conditional branching based on state or output.
Set state — persist values across the run.
User approval — Approve/Reject prompt (labels not customizable).
While loop — repeat until condition (tricky to use well).
Guardrail — PII detection, moderation, jailbreak detection, hallucination checks.
File search — vector search against OpenAI-managed vector stores.
MCP — connect to Gmail / Google Drive / custom HTTP MCP servers.
End — terminates the flow.

Building your first flow: nodes, state, branches

Simple example — an agent that asks for the user’s name, then answers questions using that name:

Start node with state: name (string, default empty), name_found (bool, default false).
If/else checking state.name_found == true.
If true → agent that answers the user’s question using their name.
If false → name-collection agent that extracts the name from the user’s message.
Set state after collection — persist name and flip name_found to true.
End.

Connect nodes by dragging from one’s output to another’s input. Drag the entire flow to reorganize. The visual model is intuitive after about 10 minutes.

Structured output with JSON and widgets

Each agent node has an output format: text, JSON, or widget.

Text — free-form natural language. Fine for chat.
JSON — you define a schema (properties, types, descriptions). The agent returns a parsed object you can branch on. Essential for if/else conditions that look at agent output.
Widget — render the response in a styled card UI. Build widgets in the Widget Builder (or have AI generate one from a prompt), download as JSON, upload to the agent.

Widgets work in the Preview pane but you can’t interact with them (click buttons, fill forms) unless you embed the agent in your own frontend with ChatKit. The Preview shows them as static cards.

The state-driven pattern that makes flows reusable

Agent Builder has a real limitation: you can’t pause the flow mid-execution to ask the user for more input. The only ways the user can intervene are User Approval nodes (Approve/Reject only) or by typing in the chat (which restarts the flow).

The workaround: design every flow to be re-entrant. Put an if/else at the start that checks state and routes to a different path based on what’s already been collected. First run collects name, sets state, ends. Second run sees the name is set, goes to the “answer questions” path.

This pattern is awkward at first — you’re effectively writing a state machine by hand — but it’s the way the builder is designed to work. Other agent platforms (n8n, LangFlow) handle in-flow user input more gracefully; OpenAI’s answer is “use ChatKit on your own backend and we’ll show you proper widgets.”

Guardrails, file search, and other built-in nodes

Guardrail — drop it right after Start to sanitize input. PII detection, jailbreak prevention, moderation, hallucination check. Failed guardrails route to a separate path (typically End).
File search — works only with OpenAI’s vector stores. You upload files via Files API, create a vector store, reference it in the agent. Solid for RAG on documents but tied to OpenAI infrastructure.
While loop — iterates a sub-flow while a condition holds. Useful for “keep asking clarifying questions until you have enough info” but easy to write infinite loops.
User approval — the only inline human-in-the-loop primitive. Limited to Approve/Reject; button labels not customizable.

MCP and the OAuth limitation

The MCP node is the biggest gap between “sounds amazing” and “actually works.” You can:

Connect built-in MCP integrations (Gmail, Google Drive, Calendar) — but you have to manually exchange OAuth tokens via a clunky setup page, and the tokens expire in days.
Connect custom MCP servers — but only HTTP MCP servers using API key or custom header auth. OAuth flow is not supported, which is how most MCP servers in 2026 authenticate.

Net effect: most popular MCP servers (Notion, Slack, Linear, GitHub, etc.) can’t be plugged in directly to the visual builder unless they offer an alternate API-key auth path. This is the single most frustrating limitation for a tool branded as “the way to build agents that take real actions.”

ChatKit and going beyond the visual builder

The escape hatch is ChatKit — embed your agent in your own front-end. Three benefits:

Widgets become interactive (buttons fire events, forms submit data back to the agent)
You can write real tool implementations on your backend that the agent calls
You control conversation state, can pause and inject new input

Cost: you write code. Real code, with auth, session management, and event handling. The ChatKit Python SDK is also brand new at the time of writing — the GitHub repo has no README and minimal documentation. Plan to read source.

Pricing and token costs

Agent Builder runs on standard OpenAI tokens. Every agent execution is one or more model calls; every reasoning step costs. Pricing depends on the model picked per node (GPT-5, GPT-5 Mini, older models).

Cost reality check: an evening of exploration with a multi-step flow can easily burn $10 of credits. For production agents with traffic, monitor token usage from the OpenAI Usage dashboard. Pick smaller models for routing/parsing steps, reserve GPT-5 for the actual reasoning.

Where it shines, where it doesn’t

✅ Good for

Prototyping agent flows before writing code
Visualizing branching logic for stakeholders
Pure-LLM workflows that don’t need external tools
RAG over OpenAI-managed vector stores
Evaluating different prompt structures side by side
Teams that want a single source of truth for an agent’s logic

❌ Not yet good for

Agents that integrate with OAuth-based MCP servers
Interactive widgets without writing front-end code
Mid-flow user input without state-machine workarounds
Complex branching with more than 2–3 levels (UI gets messy)
Production-grade workflows without ChatKit integration
Cost-sensitive batch processing (each node is an LLM call)

❌ Common mistakes

Expecting interactive widgets in the Preview. They render statically; you need ChatKit + frontend.
Building tools in the visual UI and expecting them to execute. Tool nodes only generate the tool call; you handle the actual function on your backend.
Trying to plug in popular OAuth MCP servers. Most won’t work without an API-key bypass.
Designing flows that require mid-execution user input. Use state-driven re-entry instead.
Running everything with GPT-5. Use smaller models for routing/extraction; reserve GPT-5 for genuine reasoning.
Not setting up guardrails. Adversarial input becomes your problem the moment users touch the agent.
Skipping the eval system. The built-in evaluator lets you grade agents with another model — underused but valuable.

💡 Pro tips

Design every flow as re-entrant from the start. State at the top, if/else branching, paths converge to End.
Use JSON output format on every agent that feeds into an if/else. Text outputs are unreliable to branch on.
Have AI generate your widget schemas. The Widget Builder accepts “build a card that shows X” prompts.
Export your flow as code (button in the UI). Useful as a backup, a reference, and a starting point for the eventual code-driven version.
Build an “evaluator agent” that grades responses from your real agent. Wire it into the Eval system for automated regression checks.
Plan to graduate to ChatKit + code if the project sticks. The visual builder is for design; production is in code.

Conclusion

OpenAI’s Agent Builder is a serious attempt at a visual agent platform — and at the same time, it’s clearly early. The visual flow design works well for prototyping. The state-driven pattern is elegant once you internalize it. The widgets are beautiful when they work. The OAuth-less MCP integration is the gap that most users will hit fastest.

For production agent work in 2026, plan to use the visual builder for design and prototyping, and code (Agents SDK + ChatKit) for the actual deploy. For internal tools and self-contained LLM-only workflows, the visual builder may be all you need.

OpenAI has the resources to fix the gaps quickly. Worth revisiting every couple of months — the trajectory is good even if the current state has rough edges.

Explore More on DevShelf

LangGraph — Tool Profile
The code-first alternative to Agent Builder — stateful graphs, human-in-the-loop, and multi-model support without vendor lock-in.
Learn Agentic AI in 7 Steps
The framework-agnostic path that covers the orchestration patterns behind Agent Builder's visual nodes.

OpenAI Agent Builder: An Honest Tutorial and Its Real Limitations