How to Build an AI Support Agent with ChatGPT (and Codex)

We'll build the from-scratch path in real detail, note where Codex speeds it up, and then show the shortcut for the undifferentiated infrastructure.

What a support agent actually has to do

A support agent is a loop with four jobs: understand the ticket and its history; fetch context (customer, orders, past tickets, the right help-center article) through tool/function calls; act (draft a reply, tag/route, refund, escalate); and know when to stop — answer confidently or hand to a human. OpenAI gives you strong primitives for the first two; the rest is on you or a platform. (If you're still weighing build-vs-buy, our overview of AI agents for customer service covers the landscape first.)

Option 1: Build it from scratch with the OpenAI Agents SDK

Good news up front: OpenAI's stack gets you further out of the box than a raw model call. The Agents SDK is a lightweight runtime around the model with three primitives that map neatly onto support: Agents (a model plus instructions and tools), Handoffs (one agent delegates to another — e.g. a triage agent routes billing questions to a billing agent), and Guardrails (validate inputs and outputs). It runs on the Responses API, OpenAI's unified, stateful interface that folds function calling and built-in tools (web search, file search, computer use) into one call. OpenAI even ships an official customer-service demo built on it.

In practice, a from-scratch support agent with OpenAI looks like:

1. Define your functions — get_customer, get_recent_orders, reply_to_ticket, escalate — each a schema the model can call. OpenAI's function calling handles the request/return contract.
2. Ground it — drop your help-center articles into file search so the agent answers FAQs from your content instead of inventing policy. For anything beyond basic retrieval you'll still build proper RAG.
3. Compose agents — a triage agent with Handoffs to specialist agents (billing, shipping, technical) is the SDK's sweet spot for support.
4. Add guardrails — validate that the agent isn't leaking PII, answering off-topic, or taking an action it shouldn't.

In code, that's compact — the SDK owns the loop, so you declare agents, tools, and handoffs:

from agents import Agent, Runner, function_tool

@function_tool
def get_customer(email: str) -> dict:
    """Look up a customer by email."""
    ...  # your DB / help-desk API

billing = Agent(name="Billing", instructions="Resolve billing issues.", tools=[refund])
triage = Agent(
    name="Triage",
    instructions="Answer support tickets from the help center; hand off billing.",
    tools=[get_customer, reply_to_ticket],
    handoffs=[billing],
)
result = Runner.run_sync(triage, ticket_text)   # SDK runs the tool loop for you

Because the SDK owns the run-loop, you write far less orchestration than with raw calls. That's real leverage — steps 1–4 above are genuinely faster on OpenAI than hand-rolling. But it's also where the tutorials stop, and it's roughly one-third of a production system.

Where Codex helps

Codex (OpenAI's coding agent, the counterpart to Claude Code) is excellent for the scaffolding: generating the function schemas, the Agents SDK wiring, the help-desk API client, and the tests. Describe the agent — "scaffold an Agents SDK support agent with Zendesk ticket functions and file search over our help center" — and let Codex write the first pass, then refine. It compresses the coding; it doesn't make the design calls (which tools, which handoffs, when to escalate) or run the thing in production.

The part the quickstarts skip

The Agents SDK handles the loop, handoffs, and guardrail primitives, and file search covers basic FAQ grounding. Here's what it does not do — and what you still own:

• Connect your help desk (still yours). The agent needs to read tickets and post replies via Zendesk / Freshdesk / Intercom / your platform's REST API — OAuth and token refresh, pagination, rate limits, and webhooks to trigger the agent on each new ticket (with signature verification and idempotency so a retried webhook doesn't double-reply). Every internal system it touches — orders, billing — is another client you build.
• Host and run it 24/7 (still yours). A quickstart runs locally; a support agent runs always. You need a cloud host, secrets management, a job queue with retries and a dead-letter queue, and autoscaling for ticket spikes.
• Observe it (still yours). When it sends a bad reply overnight you need the full trace — which functions ran, what context it had, what it decided — plus latency, cost, and alerting.
• Evaluate it (still yours). The SDK won't tell you if the agent is right. You need an eval harness: real historical tickets, automated scoring (resolution, accuracy, tone, correct escalation), and a regression run before every prompt or model change.
• Maintain it (forever). Models get deprecated, your help desk changes its API, the help center drifts and file search needs re-indexing, and someone owns the pager.

That's the 60–70% of a production support agent OpenAI doesn't hand you — undifferentiated infrastructure every team rebuilds.

Option 2: Bring OpenAI, skip the plumbing

You've built the agent's brain with the Agents SDK. Macha is the layer for the body — the connect → deploy → monitor → grade infrastructure — so you're not rebuilding it:

• Connect your help desk and any API. Macha's Custom Tools turn any REST API into a tool your agent can call — define the endpoint and auth, or describe it in a sentence and the AI tool builder discovers, tests, and creates the tools. Your help desk is a native connector (Zendesk, Freshdesk, Front, Intercom, HubSpot, Help Scout, Salesforce, Jira Service Management, Pylon); internal systems plug in the same way — no client library, no webhook plumbing.
• Ground it — attach your help-center as a knowledge source; retrieval is handled, so you're not maintaining a file-search index.
• Run and observe — agents run in the cloud, triggered by tickets, with agent analytics showing every run and tool call out of the box.
• Grade it — Studies run the agent against a batch of real historical tickets and score outcomes, so a prompt or model change is measured, not guessed.

The trade is control for time-to-ship: from-scratch is a well-tooled brain plus weeks of body-building and permanent maintenance; a platform is live this week with the infrastructure owned for you.

From scratch vs. on a platform

So which should you build?

Build from scratch if the agent runtime is your product, you need multi-agent orchestration OpenAI's SDK models especially well, or you have constraints (on-prem, data-residency) a SaaS can't meet. (For a fuller side-by-side, see our from-scratch vs. platform breakdown.) Use a platform if resolving support well is the goal: you want it live this week, grounded in your help desk, and measurable from day one, without owning the hosting-observability-eval stack forever. Either way OpenAI is the same strong brain — the question is how much body you want to build. You can start free on Macha and wire your first tool in minutes.

FAQ

Can I build a support agent inside ChatGPT itself (a custom GPT)? Not a real one. Custom GPTs run in ChatGPT's sandbox and can't sit on your help desk and act on tickets unattended. A production support agent is built on the OpenAI API (Agents SDK / Responses API) or a platform — not the ChatGPT product.

Agents SDK or raw Responses API? Use the Agents SDK unless you have a reason not to — it gives you the loop, handoffs, and guardrails so you're not re-implementing orchestration. Drop to raw Responses API only for full control.

Does Codex build the whole thing? Codex is great for the code — schemas, SDK wiring, a first-pass API client, the eval-harness skeleton. It won't make product decisions (tools, handoffs, escalation) or host, monitor, and evaluate the agent in production.

How do I know it's good before it touches customers? Grade it against real historical tickets with automated scoring, and re-run that before every prompt or model change — whether you build the harness or use something like Macha's Studies.