OpenAI AgentKit — drag-and-drop replaces the agent build-from-scratch

Redaktion · · 5 Min. Lesezeit

At DevDay on October 6, 2025, OpenAI introduced AgentKit — a bundle of three tools designed to replace much of the in-house plumbing that agent projects used to require. ChatKit and the new Evals capabilities have been generally available (GA) ever since, the Agent Builder is in beta, and the Connector Registry is rolling out in stages to API, ChatGPT Enterprise, and Edu customers. Pricing: everything is included in standard API model pricing — no separate platform tier.

What used to be true

Until autumn 2025, anyone building a multi-agent workflow on OpenAI models had a choice: the Agents SDK (code-first, Python) or rolling your own on top of the Chat Completions API with tool use. Both require you to build agent routing, state management, trace logging, and an eval harness yourself. Embedding the result into a web app added a custom chat frontend with streaming, cancel handling, and theming.

In real projects, that exact plumbing is the reason “let’s build an agent for X” turns into two weeks of engineering — the model call is the smallest part; everything around it is plumbing.

What’s true now

1. Workflow design without code. Agent Builder is a visual canvas where you connect agents, tools, conditions, and routing logic by dragging and dropping. Workflow versioning is built in, and a workflow can be deployed directly from the builder. For teams without a dedicated backend engineer this is the biggest lever — the first 80% of an agent workflow now exists without writing a line of code.

2. Chat UI as a finished component. ChatKit is an embeddable web component that ships the entire chat frontend: streaming, cancel, history, theming, auth hooks. Anyone who has built a React chat surface from scratch knows how much detail work that is. ChatKit has been GA since DevDay, so it’s cleared for production use.

3. Evals as an integrated step, not an afterthought. The new Evals tooling supports prompt optimization and trace grading directly inside the AgentKit lifecycle — no switching to a second tool. That’s the answer to the practical problem that agent quality drifts the moment models, prompts, or tools change unless you have structured tests in place.

4. Connector Registry centralizes data hookups. Rather than wiring data sources into every agent individually, an admin defines connections once in the Connector Registry — every agent and ChatGPT workspace under the account can use them. That solves a governance problem that grows fast as agent teams scale.

5. Apps SDK for ChatGPT-native apps. Alongside AgentKit, OpenAI shipped the Apps SDK — an open-source SDK for building external apps that run directly inside ChatGPT. Notable detail: it builds on Anthropic’s Model Context Protocol (MCP). OpenAI and Anthropic effectively share the same tool-connection standard, which raises the odds that MCP becomes the industry default.

Where it helps, where it doesn’t

AgentKit moves the threshold at which an agent project becomes economical noticeably down. Use cases that previously didn’t justify the engineering budget — internal tools, lead qualification, onboarding flows, support triage — become days-not-weeks projects with Agent Builder + ChatKit. The GA pieces (ChatKit, Evals) are ready for production; Agent Builder itself is beta, so it’s right for internal pilots, not revenue-critical customer flows.

The flip side: leaning hard on AgentKit deepens the bind to OpenAI infrastructure. Workflows from the visual builder are not 1:1 portable to other vendors. Anyone who wants to avoid vendor lock-in stays in code with the Agents SDK — the trade-off is effort for flexibility.

What you can do now

If you need a simple chat agent: start directly with ChatKit + Agents SDK. ChatKit is GA, and the setup time for an embedded chat widget with custom logic is hours, not weeks.

If you want to try multi-agent workflows: use Agent Builder in its beta state for prototypes and internal tools. For revenue-critical customer flows, wait for GA, or export the workflow into SDK code — the builder designs work as a starting point.

If you also use Anthropic/Google in parallel: MCP keeps becoming the common denominator through the Apps SDK. Tool integrations you write as MCP servers can plug into both worlds — that’s the only known bridge that doesn’t depend on a single vendor.

Entdecke mehr