OpenAI AgentKit brought several parts of agent development together: workflow design, chat interfaces, connections, and evaluation. For a team deciding how to automate support, the useful question is which parts it wants to build and maintain.
There is also an important update to the original launch story. As checked on September 8, 2026, Agent Builder is being deprecated, with shutdown scheduled for November 30, 2026. ChatKit remains available. The Agent Builder documentation explains the transition. An old tutorial that ends at publishing a visual workflow is no longer enough for planning a new deployment.
What is OpenAI AgentKit?
AgentKit is best understood as a collection of building blocks for custom agents, rather than a finished employee for one business role. The original package connected visual workflow design with deployment, chat UI, and evaluation. Those are related responsibilities, but they are not interchangeable products with one availability status.
A visual canvas can make workflow design easier without requiring you to write every step in code. It does not remove the need to decide what the agent may access, which actions it can take, or how to handle failures. Those decisions matter whether the implementation uses a canvas, an Agents SDK, or a ready-made teammate.
For support teams, I would separate two decisions: do you need to build a custom application, or do you need to configure a teammate that can work with your existing helpdesk? eesel CLI is relevant to the second decision. It gives technical users and coding agents a way to do that configuration without moving every step into a browser.
The core components of OpenAI AgentKit
Agent Builder: Visual workflows and the transition
Agent Builder uses connected nodes to define multi-step workflows. Nodes have typed inputs and outputs, and the preview lets you inspect a run. Existing users should now plan beyond that hosted canvas.
OpenAI’s migration guide describes exporting Python or TypeScript Agents SDK code. You can continue in an application you deploy, or use the export to recreate a ChatGPT Workspace Agent where your workspace has access. Neither route guarantees unchanged behavior: tools, authentication, permissions, and control flow need testing.
If the workflow has strict branching requirements, preserve those requirements as test cases before changing the implementation. A fluent answer is not evidence that the migrated agent took the required steps.
ChatKit: The chat interface
ChatKit supplies an embeddable, customizable chat UI, including widgets and file attachments. It is not the same thing as Agent Builder. OpenAI now directs new apps and migrations toward a custom server integration with a server-side agent implementation.
That distinction also matters when comparing it with eesel. ChatKit is for a chat experience you build into your application. eesel has its own website chat bubble that the CLI can configure and provide an embed snippet for. You still place that snippet on your website; a terminal command does not automatically edit or deploy your site.
Evals: Checking what the agent actually did
OpenAI’s evaluation tools help inspect traces and measure behavior against defined criteria. Trace grading is useful for questions such as whether the agent selected the right tool or handed off at the right point. Datasets and repeatable eval runs help compare changes over time.
For a support workflow, include cases with missing information, conflicting policies, and requests that need human approval. The business outcome and the technical trace belong in the same review. An answer can sound helpful while using the wrong source or taking an unauthorized action.
Connections and safety
An agent needs more than access to data. Someone must decide which sources are appropriate, which credentials it uses, and which actions require a person. Moving from a visual builder to code does not transfer those decisions automatically.
The same responsibility applies when configuring eesel. Connecting a helpdesk, downloading selected knowledge, and defining standing instructions are distinct tasks. Treat access and approval settings as part of the setup to review, not as proof that every future answer will be correct.
Operate a support teammate through eesel CLI
If your AgentKit project was primarily about answering support questions from company knowledge, it is worth considering whether you need a custom application at all. eesel’s helpdesk teammate provides the support-focused product; eesel CLI gives you terminal access to its setup and ongoing work.
The CLI operates the same agent and workspace as the dashboard. A support manager can review the setup in the dashboard while a developer, script, or coding agent such as Claude Code, Cursor, or Codex works through commands. There is no separate copy of the teammate to keep in sync.
For an existing eesel workspace, start by logging in and checking which account and agents you are using. These examples require Node.js 18.17 or newer:
npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
Then replace AGENT_ID with the intended agent’s ID. Inspect its setup before changing it:
npx @eesel/cli status --agent AGENT_ID
npx @eesel/cli integrations --agent AGENT_ID
npx @eesel/cli instructions --agent AGENT_ID
The distinction is useful during a handover from a custom prototype. status reports connections and whether connected content has downloaded. integrations shows which integrations the agent uses. instructions lets you inspect its standing rules. None of these checks alone proves that it will answer a difficult customer question correctly.
For example, suppose the prototype answered returns questions from a policy PDF. You can upload that approved document to the eesel teammate:
npx @eesel/cli files upload ./returns-policy.pdf --agent AGENT_ID
Uploading the PDF adds knowledge; it does not rewrite the standing instructions. Separately review the rules for exceptions and escalation. Then use a test agent with appropriately restricted actions to ask representative questions, compare answers with the policy, and inspect its activity. Chat can invoke actions, so do not assume that every test message is read-only.
Let a coding agent handle the setup, with clear limits
The CLI prints JSON results and structured errors, so a coding agent can inspect the result of a command and decide what to do next. This makes it useful for a bounded task such as “check which sources are connected, identify missing setup, and ask before making changes.” That request is an instruction to the coding agent, not a CLI-enforced approval gate for its commands.
You can then use automations to inspect event, scheduled, and webhook automations, approvals to review held actions, and activity to see what the teammate has been doing. Use --help for the specific command’s options. For write operations, --dry-run prints the proposed server call without sending it; it does not simulate a customer conversation or validate its outcome.
For unattended scripts, the CLI supports EESEL_API_URL and EESEL_API_TOKEN, with EESEL_AGENT_ID or an explicit agent flag for scope. Keep tokens out of source control. Your OpenAI application credentials and eesel workspace credentials are separate.
This is a way to configure and operate a support teammate, not an Agent Builder workflow importer. If you choose eesel, recreate the support job’s sources, instructions, integrations, and approval requirements, then test them against the outcomes your original workflow was meant to deliver.
Which approach fits your project?
| Your requirement | What to evaluate |
|---|---|
| Preserve a custom Agent Builder application | Export the workflow, choose an OpenAI migration path, and test tools, permissions, and behavior |
| Keep a custom chat interface | ChatKit with a server-side agent implementation you maintain |
| Operate a support teammate in an existing helpdesk | eesel’s helpdesk teammate, configured through the dashboard or eesel CLI |
| Let a coding agent assist with support setup | eesel CLI’s commands, JSON output, and explicit agent selection; set change limits in the coding agent’s instructions |
The choice is not “code is bad, no-code is good.” A custom application may be necessary when your product depends on a specific workflow or interface. eesel CLI fits when the job is configuring a support teammate and you want that work accessible from the terminal as well as the dashboard.
Understanding pricing and availability
Check the current OpenAI API pricing for the models and tools your application uses. Include hosting and maintenance in a custom implementation’s budget. A launch-era statement that tools were bundled with API usage is not a complete quote for your deployment.
For eesel, check the current pricing page and workspace billing rather than assuming the older interaction-based plans still apply. The CLI’s billing command reads the workspace’s billing state; using eesel CLI does not move its charges onto your OpenAI API account.
Choose the job before rebuilding the workflow
If you need to preserve a custom AgentKit application, use OpenAI’s migration guidance and verify the exported behavior. If the actual requirement is a teammate that answers support questions and works with your helpdesk, evaluate that outcome directly.
Try eesel, then use the CLI setup guide to connect the relevant knowledge and inspect the teammate’s instructions. Start with one support scenario and review the answer and actions before expanding its responsibilities.
