The practical reasons Zeiko moved production agent execution from Vercel AI SDK patterns to OpenAI Agents SDK: durable tools, state, approvals, handoffs, and safer rollout gates.
The practical reasons Zeiko moved production agent execution from Vercel AI SDK patterns to OpenAI Agents SDK: durable tools, state, approvals, handoffs, and safer rollout gates. Zeiko frames this for teams building production AI agents, so the takeaway is not only the concept but the execution pattern operators can apply to business automation workflows.
More Zeiko field notes on agents, operations, and automation.
Zeiko helps teams deploy specialized AI agents for reporting, customer operations, marketing workflows, and business intelligence.
A practical comparison of AI SDK patterns and OpenAI Agents SDK for teams building specialist multi-agent systems, workflow automation, handoffs, approvals, and deployable AI workers.
A practical breakdown of OpenAI’s harness engineering ideas and how to apply them to OpenClaw: skills, feedback loops, legibility, and safe GitHub automation.
We did not migrate because the Vercel AI SDK stopped being useful.
It is still a strong way to build streaming AI interfaces, structured output utilities, and fast product surfaces. The problem was that Zeiko had outgrown a chat-first model integration pattern.
Our product is no longer just "send a message, get a response." Zeiko runs business agents that:
That is a different job. For that job, the OpenAI Agents SDK became the better runtime boundary.
We moved model-and-tool orchestration into the OpenAI Agents SDK because our agents needed a more explicit execution model.
The Vercel AI SDK helped us build fast UI and model utilities. The OpenAI Agents SDK gave us a clearer home for production agent behavior: tools, guardrails, handoffs, state, tracing, and rollout evidence.
We still keep UI transport and retained utility paths where they make sense. The migration was not "replace everything." It was "put durable agent work in the runtime designed for durable agent work."
| Decision area | Vercel AI SDK pattern | OpenAI Agents SDK pattern | Why it mattered for Zeiko |
|---|---|---|---|
| Primary job | AI UI, streaming, structured generation | Agent execution, tools, handoffs, guardrails | Our core product became deployed agents, not isolated AI calls |
| Tool orchestration | App-defined tool loops around model calls | Agent/Runner execution with SDK tools | Easier to reason about account-safe tool policy and runtime outcomes |
| Long-running work | Usually app-level orchestration | Clearer agent execution boundary | Better fit for approvals, retries, scheduled ticks, and resumable workflows |
| Observability | Mostly our own wrappers and logs | SDK-native tracing concepts plus our event store | Less custom glue around agent outcomes |
| Risk control | Possible, but mostly app-defined | Guardrails and approvals are part of the agent model | Safer for publishing, data access, browser automation, and external channels |
| Best retained use | UI streaming, one-shot utilities, schema helpers | Production agent runtime paths | We kept each tool where it had the strongest job fit |
The migration forced us to separate three categories that had started to blur.
This is work where the system is not just generating text. It is deciding, using tools, applying policy, recording state, and producing an operator-visible outcome.
Examples:
These paths now belong behind the OpenAI Agents SDK runtime boundary.
Some AI calls are still just utilities. They do not need a full agent runner.
Examples:
Moving these for the sake of purity would add complexity without reducing risk. So we kept them as utilities and documented why.
Some surfaces needed evidence before they could become SDK-default:
For these, we built local certification gates before promotion. The point was not to "trust the migration." The point was to prove each risky lane had approval, quota, sandbox, credential, and rollback evidence.
When a product is young, implicit orchestration feels fast.
You call a model. You pass tools. You parse output. You add a few wrappers. You add more wrappers. Then approvals arrive. Then external channels arrive. Then scheduled jobs arrive. Then publishing arrives. Then one day, the "AI call" is actually a distributed business operation with credentials, audit logs, retries, and human review.
That is where our previous boundary started to hurt.
We needed a runtime that made the following things explicit:
The OpenAI Agents SDK gave us a cleaner center of gravity for that.
The honest answer is switching has a cost.
This is where status quo bias can trick engineering teams. Staying with a familiar SDK feels safer because the failure modes are known. But known friction is still friction.
For us, the cost of staying looked like this:
The migration was worth it once the cost of keeping the old shape became larger than the cost of changing it.
We did not throw away everything around the Vercel AI SDK.
The most important retained idea is still excellent: build great AI product interfaces. Users need streaming, responsive UI, stable message transport, and predictable rendering.
So our migration kept the parts that were still doing the right job:
This matters because migrations fail when they become ideological. We were not trying to win a framework argument. We were trying to make the runtime match the product.
Zeiko's product vision is deployable AI agents for small businesses. That means the agent is not a sidebar feature; it is the operating layer.
The OpenAI Agents SDK lined up with five product needs.
Agents need tools, but not every tool should be available in every context.
A support agent, SEO agent, Shopify agent, and social publishing agent need different permissions. The runtime needs to make tool availability visible and enforceable.
An agent should be able to escalate to a human, delegate to a specialist, or resume after a worker finishes. That cannot be treated as just another generated paragraph.
For destructive actions, external publishing, data export, and account mutations, approval is not optional UX. It is part of the runtime contract.
The same agent may run from the web app, a website widget, Slack, Telegram, WhatsApp, or a scheduled tick. If each surface carries its own state model, behavior drifts.
The migration had to be provable:
That evidence is what let us move from "it should work" to "we can merge this without guessing."
The most important improvement was not raw model quality. It was operational clarity.
We can now answer questions like:
That clarity compounds. Every future agent feature has a better place to live.
The migration was not free.
The hardest parts were not syntax changes. They were product-boundary decisions:
This is the part most migration posts skip. The code change is only half the work. The other half is reducing regret risk for the team that has to operate the system after merge.
If you are deciding whether to migrate from Vercel AI SDK patterns to OpenAI Agents SDK, use this checklist.
For Zeiko, the second list became the product.
No. It is very useful for AI interfaces and app-level AI features. Our issue was not quality; it was fit. Zeiko needed a stronger runtime boundary for deployed agents, tools, approvals, and cross-channel state.
No. We retained utility and transport paths where they still fit. The migration focused on production agent execution, not ideological removal.
Because "works" is not the same as "scales safely." The old shape worked for narrower AI features. It became expensive once agents needed durable state, approvals, external publishing, and multi-channel behavior.
High-risk capability lanes: publishing, browser/code execution, data export, Shopify operations, GitHub operations, and broad YouTube workflows. We kept those behind certification gates until evidence existed.
Choose the runtime based on the job. Use lightweight AI SDK patterns for lightweight AI features. Use an agent runtime when the product is actually asking an agent to operate a business process.
The migration was not about chasing a newer SDK.
It was about admitting that Zeiko had crossed a product threshold. Once agents can use tools, publish, approve, hand off, remember, retry, and run across channels, the runtime becomes part of the product's trust model.
That is why we moved production agent execution to the OpenAI Agents SDK.
If your team is building AI features, keep the stack simple. If your team is building agents that operate real workflows, invest in the runtime boundary early.
That boundary is where reliability starts.
