How to Build an AI Agent With ChatGPT: 12 Steps for 2026

By Priya Shah 2026-06-21 19 min read

You can build a working AI agent with ChatGPT in about 10 minutes using the built-in GPT builder, and a production-grade version in roughly two to three days of focused work. The difference between those two outcomes is not the model. It is the instructions, the tools you wire in, the evaluations you run before launch, and the guardrails that decide when the agent stops and asks a human. This guide walks through all 12 steps, from a paid ChatGPT account through a complete support-triage agent that routes requests, drafts replies, and escalates ambiguous cases. Every step includes the exact configuration, the output you should expect, and the failure modes that trip up most first builds.

What building an AI agent with ChatGPT actually means in 2026

An AI agent is not a chatbot with a clever prompt. According to OpenAI's practical guide to building agents, an agent is a system that uses a model to independently accomplish a task on a user's behalf, which means it decides which actions to take and calls tools to take them. A chatbot answers. An agent does. That distinction drives every design choice in this tutorial.

OpenAI describes an agent as three core pieces working together: a model that supplies the reasoning, tools that let the agent interact with the outside world, and instructions that define how it should behave. When you build inside ChatGPT itself, the GPT builder wraps all three in a guided interface, so you define instructions in plain language, upload knowledge files, and toggle tools like web search, code interpreter, and custom actions. When you graduate to the API, you assemble the same three pieces in code, which gives you control over the decision loop, memory, and orchestration.

There are two practical paths, and this guide covers both because B2B teams usually start on one and move to the other. The first path is the no-code GPT builder, available to anyone on a paid ChatGPT plan, which Dust's walkthrough estimates can produce a basic agent in about 10 minutes. The second path is the OpenAI API plus the Agents framework, which is funded separately from your ChatGPT subscription and gives you the control layer real operations require. Marketing, growth, and SEO teams who want to automate repeatable workflows like lead triage, content briefs, or reporting will almost always end up using both: the builder to prototype and validate, the API to ship. If you want this built and integrated for you rather than assembled in-house, our AI automation services cover the API side end to end.

Prerequisites and exact versions before you start

Skipping the setup checklist is the single most common reason a first build stalls halfway through. The GPT builder requires a paid account, and the API requires its own billing and key, so confirm access before you write a single instruction. Below is the full prerequisite list with the versions and account tiers you need as of June 2026. Where a version moves quickly, the constraint is the minimum that supports tool calling and structured outputs.

• ChatGPT Plus, Team, or Enterprise account: the GPT builder and custom GPTs are gated behind a paid plan. Plus is sufficient for prototyping. Team or Enterprise adds workspace sharing and admin controls.
• OpenAI API account with a funded balance: this is billed separately from ChatGPT. Add a payment method and a usage limit in the billing dashboard before generating a key, so a runaway loop cannot drain your budget.
• An API key: create one project-scoped key per agent so you can revoke it without breaking other workloads. Never paste a key into client-side code.
• Python 3.11 or newer (3.12 recommended) or Node.js 20 LTS or newer if you build on the API path.
• The official OpenAI SDK: the Python openai library 1.x or later, or the Node openai package 4.x or later.
• A code editor (VS Code is fine) and a terminal, for the API path only.
• Your operational source documents: SOPs, support macros, refund policy, brand voice guide, and any reference data the agent will rely on. OpenAI explicitly recommends building routines from existing operational materials rather than inventing behavior from scratch.
• A test dataset of 20 to 50 real examples: past tickets, real questions, or sample inputs with known correct outputs. This becomes your eval set in step 9.

One detail that catches B2B teams: the API key and the ChatGPT subscription are not the same wallet. A YouTube walkthrough cited in agent-builder guidance notes the OpenAI API is funded separately, which is exactly why a production agent needs its own usage budget beyond a normal seat license. Decide the monthly cap now. For a low-risk first use case like drafting support replies, a cap of 50 to 100 dollars per month is usually enough to gather weeks of evaluation data. Lock that number in before you build so cost never becomes the reason a useful agent gets shut off.

The three-part anatomy of a ChatGPT agent

Before you click anything, internalize the model-tools-instructions structure, because every later step maps to one of these three components. Getting the split right is what separates an agent that holds up under real traffic from one that hallucinates a refund policy on day three.

The model is the reasoning engine

The model decides what to do next. OpenAI recommends starting with the most capable model to establish a performance ceiling, getting the agent working correctly first, then trading down to a cheaper or faster model only where evals prove quality holds. Do not optimize for cost before you optimize for accuracy. A cheaper model that fails 15 percent of the time is more expensive than a premium model that fails 2 percent, once you count the human cleanup and the trust you lose.

Tools are how the agent acts

Tools are the difference between a system that talks and a system that does. In the GPT builder, tools include web search, code interpreter, image generation, file search over your uploads, and custom actions that call external APIs. On the API path, tools are functions you define with a JSON schema, and the model returns a structured request to call them. OpenAI's guidance frames tool choice and routine design as the central shift from prompt-only chatbots to systems that call APIs, search documents, and trigger actions. Design for actions, not chat.

Instructions are the behavior contract

Instructions tell the model who it is, what it is allowed to do, what it must never do, and how to handle edge cases. OpenAI recommends turning existing SOPs and policy docs into LLM-friendly routines by breaking dense procedures into smaller, explicit steps the model can follow reliably. Vague instructions produce vague agents. The instruction block is where most of your iteration time goes, and it is the cheapest thing to fix, so treat it as the primary lever. The decision loop that ties these three together is simple: user input arrives, the model decides the next action, a tool executes, the result returns to the model, and the loop repeats until the task is done or a guardrail halts it.

Step-by-step: build your first agent in the GPT builder

This is the fast path. It produces a usable internal agent without writing code, and it is the right place to validate your use case before investing in the API. Follow these 12 numbered steps in order. Each lists the action, the screen you will see, and the output to expect.

Step 1. Open the builder. Go to chatgpt.com, sign in to your paid account, and click "Explore GPTs," then "Create." Screenshot description: a two-pane screen titled "New GPT" with a "Create" conversational tab and a "Configure" form tab on the left, and a live "Preview" panel on the right. Expected output: the Create tab greets you and asks what you want to build.

Step 2. Switch to Configure. Ignore the conversational Create tab for production work and click "Configure." Screenshot description: a form with fields for Name, Description, Instructions, Conversation starters, Knowledge (file upload), Capabilities (checkboxes), and Actions. Expected output: an empty form ready for manual entry, which gives you precise control the chat builder does not.

Step 3. Name and describe scope narrowly. Enter a name like "Support Triage Assistant" and a one-line description. Resist the urge to call it "Company AI." A narrow name enforces a narrow job. Expected output: the name appears in the preview header.

Step 4. Paste your instruction block. Copy the instruction template from the next section into the Instructions field. Screenshot description: a large multi-line text box; the character counter near the bottom right rises as you paste. Expected output: the preview begins answering in the new persona on its next message.

Step 5. Upload knowledge files. Under Knowledge, click "Upload files" and add your refund policy, support macros, and FAQ as PDFs or text. Screenshot description: file chips appear under the upload button, each with a filename and a remove icon. Expected output: file search becomes available and the agent can quote your docs verbatim instead of guessing.

Step 6. Enable only the capabilities you need. Check Web Search only if the agent needs live data, Code Interpreter only if it computes, and leave the rest off. Expected output: each enabled capability shows a toggle in the preview's tool tray.

Step 7. Add a custom action (optional). Click "Create new action" to wire an external API. You will paste an OpenAPI schema and set authentication. Screenshot description: a schema editor with a red or green validation banner at the top. Expected output: a green "Schema valid" banner and a list of detected operations.

Step 8. Write conversation starters. Add three or four example prompts your users will actually send. Expected output: clickable starter chips appear in the preview's empty state.

Step 9. Test in the preview pane. Run your 20 to 50 test inputs through the right-hand preview. Screenshot description: a normal chat thread on the right reflecting your live configuration. Expected output: correct answers on easy cases, and visible failures on hard ones, which is exactly what you want to find now.

Step 10. Iterate on instructions. For each failure, add an explicit rule to the instruction block, then re-test. Expected output: the failure rate drops with each tightened rule.

Step 11. Set sharing. Click "Create," then choose "Only me," "Anyone with the link," or your workspace. For internal tools, keep it workspace-scoped. Expected output: a shareable link or a workspace listing.

Step 12. Publish and monitor. Publish, then watch the first 50 real conversations closely. Expected output: a live agent and a fresh stream of edge cases to feed back into steps 10 and 9. You now have a working baseline in under an hour.

Choosing your model: a 2026 comparison table

Model choice sets your accuracy ceiling and your cost floor, so make this decision with evals, not vibes. OpenAI's sequencing is explicit: build with the strongest model, prove it works, then test whether a smaller model holds the same accuracy on your eval set before you switch for cost or latency. The table below compares the model classes B2B teams realistically choose between in mid-2026. Pricing changes frequently, so treat the relative cost column as guidance and confirm exact rates on the OpenAI API pricing page before you commit a budget. Capabilities are summarized from the OpenAI model documentation.

Read this table top to bottom for a first build, not bottom to top. Start at flagship general, get the agent correct, then run the same eval set against the mid-tier and small classes and keep the cheapest model that does not drop measurable accuracy. The reason this order matters is leverage: a routing step that only needs to pick one of five categories rarely needs a flagship model, but a step that interprets an angry customer's ambiguous refund request usually does. Mixing model classes across steps in one agent is normal and is where most of the cost savings live. Embeddings sit apart because they power retrieval rather than reasoning, and almost every knowledge-grounded agent uses them under the hood whether you see them or not.

Writing instructions that do not break under real traffic

Instructions are the highest-leverage and lowest-cost component, and they are where you will spend most of your iteration time. The goal is an explicit behavior contract, not a friendly paragraph. OpenAI recommends converting existing SOPs into numbered routines and breaking dense procedures into smaller steps so the model follows them reliably. Below is a battle-tested instruction skeleton you can paste into the GPT builder's Instructions field or pass as a system prompt on the API. Notice it separates identity, scope, hard rules, the step routine, and escalation.

ROLE
You are Support Triage Assistant for Acme. You classify
incoming requests, draft a reply, and decide whether a human
must review before sending.

SCOPE
You handle: billing questions, refund requests, bug reports,
and how-to questions. You do NOT handle: legal threats,
chargebacks, security incidents, or press inquiries.

HARD RULES
1. Never invent a policy. If the answer is not in the
   uploaded refund policy or FAQ, say you do not know and
   escalate.
2. Never promise a refund above 200 USD. Escalate instead.
3. Always cite the policy section you used.
4. If the request is ambiguous or high-stakes, stop and
   escalate. Do not guess.

ROUTINE
1. Read the request.
2. Classify into exactly one category.
3. Retrieve the relevant policy section.
4. Draft a reply in the brand voice.
5. Set review_required to true if any HARD RULE applies.
6. Output the structured result.

OUTPUT
Return JSON: {category, draft_reply, policy_cite,
review_required, reason}.

Three things make this skeleton hold up. First, the scope section names what the agent must refuse, which prevents the most dangerous failures by construction rather than by hoping the model behaves. Second, the hard rules are numbered and absolute, so when the agent misbehaves you can point to the exact rule that failed and tighten it. Third, the routine mirrors the decision loop, which keeps the model from skipping retrieval and answering from memory. When a test case fails in step 9 of the builder, you do not rewrite the whole block. You add one rule or one routine line and re-test. Over 20 to 30 iterations this converges on an agent that handles your real traffic, including the weird 5 percent that breaks naive prompts. For deeper prompt patterns, the OpenAI prompt engineering guide covers structured formatting and few-shot examples that raise reliability further. If you would rather have these routines designed and load-tested against your historical tickets, our build and automate team does exactly this.

Adding tools and custom actions with working schemas

Tools turn the agent from an answer machine into a system that does work. On the API path you define each tool as a function with a JSON schema; the model reads the schema, decides when to call it, and returns a structured arguments object you execute. This is the mechanism behind every real agent action, from looking up an order to creating a ticket. The OpenAI function calling documentation is the canonical reference. Here is a complete, minimal tool definition for looking up an order, in the format the API expects.

tools = [{
  "type": "function",
  "function": {
    "name": "get_order_status",
    "description": "Look up an order by its ID and return
                     status, total, and last update date.",
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": {
          "type": "string",
          "description": "The order ID, format ORD-12345"
        }
      },
      "required": ["order_id"],
      "additionalProperties": false
    }
  }
}]

In the GPT builder, the equivalent is a custom action defined with an OpenAPI schema. You paste the schema, set the authentication type, and the builder exposes the operation to the agent. Below is a trimmed OpenAPI snippet for the same lookup, which the builder validates with a green banner when it parses.

openapi: 3.1.0
info:
  title: Order API
  version: 1.0.0
servers:
  - url: 

paths:
  /orders/{order_id}:
    get:
      operationId: getOrderStatus
      parameters:
        - name: order_id
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: Order found

The rules that keep tool calling reliable are unglamorous but decisive. Write a description for every parameter, because the model uses descriptions to decide what to pass; a parameter labeled only "id" gets filled with garbage. Set additionalProperties to false so the model cannot invent fields. Make the function do one thing, because a tool named handle_order that updates, refunds, and cancels is impossible for the model to call safely. Finally, validate every tool output before feeding it back into the loop, since the model trusts whatever the tool returns. The decision loop is now concrete: the model emits a tool call, your code runs get_order_status, you return the JSON result, and the model uses it to draft the reply. Keep that loop separate from the model's reasoning so you can log, rate-limit, and audit every action the agent takes.

Setting up evals before you scale anything

OpenAI's strongest recommendation is also the one most teams skip: set up evaluations before you select a model, use them to establish a baseline, and optimize for accuracy first, then cost and latency. Evals are not a nice-to-have you add later. They are the instrument that tells you whether a change helped or hurt, and without them you are tuning a system blind. Treat evals as infrastructure. The table below shows a minimal eval framework you can stand up in an afternoon using your 20 to 50 test examples.

The priority column is the operational instruction. Fix every priority-one failure before you touch priority three. A 200-millisecond latency improvement is irrelevant if the agent invents a refund policy once per 50 conversations. Run the full eval set after every meaningful change to instructions, tools, or model, and never ship a change that causes a regression on a case you previously fixed. The discipline here is what lets you trade down to a cheaper model with confidence: when the mid-tier model passes the same eval set as the flagship, the switch is a measured decision, not a gamble. OpenAI's evals tooling can automate the scoring, but a spreadsheet of 50 inputs, expected outputs, and pass/fail columns is enough to start today.

OpenAI's practical guide is explicit on sequencing: establish a performance baseline with evals, optimize for accuracy first, and only then optimize for cost and latency. Teams that invert this order ship cheap agents that fail expensively.

Memory design: keep it minimal until you have a reason

The most common over-engineering mistake in a first agent is building elaborate memory before there is any evidence the agent needs it. The repeated recommendation across creator and company guidance is to keep memory simple: use only short-term conversation history at first, and introduce JSON files, a database, or vector storage only when cross-session persistence becomes a real requirement. Memory is a liability as much as an asset, because every piece of state the agent carries is a piece of state that can become stale, leak across users, or poison a later decision.

Here is the progression to follow, in order, advancing only when a concrete failure forces you to.

• Stage 0, no memory: the agent gets the full task in one message and returns one result. Most classification and drafting agents never need more than this.
• Stage 1, conversation history: pass the running message thread back into the model each turn. This covers multi-turn clarification within a single session.
• Stage 2, scoped session state: store a small JSON object per session (user ID, resolved facts, current step) and inject it into the prompt. Use this when a workflow spans several tool calls.
• Stage 3, persistent store: write resolved facts to a database keyed by user, so the agent remembers across sessions. Add this only when users complain about repeating themselves.
• Stage 4, vector retrieval: embed documents or past interactions and retrieve by similarity. Reserve this for knowledge bases too large to fit in context.

A simple session-state object is all most B2B workflows ever need, and it looks like this.

session = {
  "user_id": "u_8842",
  "category": "refund",
  "order_id": "ORD-12345",
  "refund_eligible": true,
  "review_required": false,
  "turns": 3
}

The reason to stay minimal is not laziness. It is that every stage you add multiplies the number of states you must test in your evals. A stateless agent has one path per input. A vector-memory agent has a path that depends on everything the user ever said, which is nearly impossible to evaluate exhaustively. Add memory the day a failure mode demands it, document why, and add eval cases that cover the new state. If you skip the eval step, persistent memory becomes the source of bugs you cannot reproduce.

Guardrails and human-in-the-loop escalation

OpenAI is unambiguous that guardrails should exist at every stage of an agent: input filtering, tool-use checks, and human-in-the-loop escalation. In enterprise practice, the control layer matters as much as the prompt, because the agent's job is not only to act but to know when to stop and ask a human. The cases that warrant a human are predictable: ambiguity, high stakes, and anything outside the policy envelope. Designing these gates is not optional polish. It is the difference between an agent you can deploy to customers and one that becomes a liability the first time it confidently does the wrong thing.

Build these guardrails as explicit, testable layers rather than hoping the instructions cover everything.

• Input filtering: reject or flag prompt-injection attempts, off-topic requests, and inputs that contain sensitive data the agent should not process.
• Scope enforcement: a hard list of categories the agent refuses, checked before the model reasons, so out-of-scope requests never reach the action loop.
• Value thresholds: any action above a money or risk threshold (a refund over 200 USD, a contract change, a data deletion) routes to a human automatically.
• Confidence gating: when the model's own stated confidence is low or it cannot cite a source, set review_required to true rather than sending.
• Tool-use checks: validate every tool's arguments and output before and after execution, and rate-limit destructive actions.
• Escalation path: a concrete, monitored queue where flagged cases land, with a human who owns response time.
• Audit logging: every decision, tool call, and escalation recorded, so you can reconstruct what the agent did and why.

The human-in-the-loop gate is not a fallback for a weak agent. It is a permanent feature of any agent operating in a domain where being wrong has cost. Start with a low escalation threshold and tighten it as your evals prove the agent handles a category reliably. It is far better to escalate 30 percent of cases in week one and earn trust than to auto-resolve everything and lose it. As the agent's escalation precision improves in your evals, you lower the human load deliberately, backed by data, not optimism.

Six common pitfalls and how to fix each one

These are the failure patterns that show up in nearly every first build. Each one has a specific, repeatable fix. Catching them early saves days of confused debugging.

• Pitfall 1: building a platform instead of one job. The agent tries to handle everything and does nothing reliably. Fix: pick one narrow workflow, such as drafting replies or routing requests, and ship that before adding a second. Creator and company guidance both converge on starting with a single job, not a platform.
• Pitfall 2: optimizing cost before accuracy. Teams reach for the cheapest model first and chase phantom quality problems. Fix: build on the flagship model, hit your accuracy targets, then trade down model by model against your eval set, keeping the cheapest one that does not regress.
• Pitfall 3: vague instructions. The agent improvises policy and tone inconsistently. Fix: convert your real SOPs into numbered hard rules and a step routine, and add one rule per observed failure rather than rewriting the whole block.
• Pitfall 4: over-built memory. Persistent or vector memory added on day one creates irreproducible bugs. Fix: start stateless, advance one memory stage only when a concrete failure forces it, and add eval cases for every new state.
• Pitfall 5: no evals. Every change is a guess and regressions go unnoticed. Fix: build a 50-example eval set before model selection and re-run it after every change. Evals are infrastructure, not a later nicety.
• Pitfall 6: no human gate on high-stakes actions. The agent confidently issues refunds, deletes data, or answers legal questions it should refuse. Fix: add value thresholds, scope enforcement, and an escalation queue before launch, not after the first incident.

Notice the through-line: every pitfall is a form of doing too much too soon, except for the two about evals and guardrails, which are the things teams do too little of. The dominant best practice across the field is to ship a minimal agent, watch how it fails on real traffic, and iterate against measured results. Feature creep, premature memory, and skipped evaluation are the three habits that turn a 10-minute prototype into a three-week debugging slog. If you are running paid acquisition or lead gen alongside this, the same minimal-then-iterate discipline applies to the workflows our lead generation team automates, where a narrow, well-evaluated agent beats a broad, unmeasured one every time.

Troubleshooting: 10 errors and their fixes

When a ChatGPT agent misbehaves, the cause is almost always one of a small set of issues. This table maps the symptom you see to the most likely root cause and the fix to apply first. Work top to bottom; the earlier rows are the more common culprits.

Two of these deserve extra emphasis because they cost real money. The cost spike from a runaway loop is preventable entirely by setting a hard usage limit in the OpenAI billing dashboard and a max-turns cap in your code, both of which you should configure before the agent ever sees production traffic. The invalid-key error usually traces to someone embedding a key in client-side JavaScript, which not only breaks but exposes the key publicly; keys belong on a server you control, scoped per project so a leak is contained. For the grounding failures in the top rows, the durable fix is always the same shape: force the agent to retrieve and cite rather than answer from the model's parametric memory, and make refusal the default when no source supports the answer. An agent that says "I do not know, escalating" is correct. An agent that confidently invents is the most expensive bug you can ship.

Advanced tips for production-grade ChatGPT agents

Once your single agent passes its evals and runs reliably on real traffic, these techniques raise it from a working prototype to a production system. Apply them in roughly this order, and only after the basics hold.

• Mix model tiers per step. Route the classification step to a small model and the ambiguous-judgment step to a flagship. This is where most cost savings live once accuracy is locked.
• Add a single specialized agent before going multi-agent. OpenAI recommends single-agent architecture first, adding multi-agent systems only when complexity genuinely justifies the orchestration overhead. Most B2B workflows never need more than one well-built agent.
• Use structured outputs. Force JSON responses with a schema so downstream systems parse reliably and the model cannot drift into prose.
• Cache stable context. Reuse system prompts and reference docs across calls to cut token cost and latency on repeat traffic.
• Log everything for replay. Store each input, decision, tool call, and output so you can replay failures, build new eval cases from real incidents, and prove what happened in an audit.
• Red-team the scope boundary. Regularly test prompt injection and out-of-scope requests, and add every successful breach to your refusal eval set.
• Version your instructions. Treat the instruction block like code, with a changelog, so you can roll back a change that quietly hurt accuracy.
• Shadow-deploy model upgrades. When a new model ships, run it in parallel against live traffic without sending its outputs, compare on your eval set, then switch only if it wins.

The single-agent-first principle is worth dwelling on because multi-agent architectures are seductive and usually premature. Multi-agent systems multiply the failure surface: now you debug handoffs, shared state, and the interactions between agents on top of each agent's own behavior. OpenAI's guidance, echoed across practitioner writeups, is to exhaust what a single well-instructed agent with good tools can do before splitting responsibilities. When you do split, the trigger should be a concrete limit you have hit, such as a context window that cannot hold all the routines, or genuinely independent workflows that share nothing. Splitting because it feels more sophisticated is how teams turn a maintainable system into one nobody fully understands. The same restraint that keeps your first agent narrow keeps your production system debuggable. Teams building customer-facing agents on top of a site will often pair this with the work our AI websites practice handles, where the agent and the surface it lives on are designed together.

Dust's ChatGPT agent-building walkthrough estimates a basic agent takes about 10 minutes to assemble in the builder: define instructions, upload knowledge files, enable tools, test in the preview pane, and publish. The remaining work, the evals and guardrails, is what separates 10 minutes from production.

Complete working project: a support-triage agent end to end

Here is a complete, runnable example that ties every step together into one agent that classifies a support request, looks up the order, drafts a reply, and decides whether a human must review before sending. It uses the API path so you can see the full decision loop, the tool execution, and the guardrails in code. This is the production shape; the GPT builder version is the same logic expressed through the form. Adapt the strings to your own policy and voice.

from openai import OpenAI
client = OpenAI()  # reads OPENAI_API_KEY from env

SYSTEM = """
You are Support Triage Assistant for Acme.
SCOPE: billing, refund, bug, how-to. Refuse legal,
chargeback, security, press; set escalate=true for those.
HARD RULES:
1. Never invent policy. Cite the FAQ or refund policy or
   set escalate=true.
2. Never promise a refund above 200 USD; escalate instead.
3. If ambiguous or high-stakes, escalate.
Return JSON: {category, draft_reply, policy_cite,
review_required, escalate, reason}.
"""

tools = [{
  "type": "function",
  "function": {
    "name": "get_order_status",
    "description": "Look up an order by ID; returns status,
                     total_usd, last_update.",
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": {"type": "string",
          "description": "Order ID like ORD-12345"}
      },
      "required": ["order_id"],
      "additionalProperties": False
    }
  }
}]

def get_order_status(order_id):
    # Replace with a real API call to your order system.
    return {"status": "delivered", "total_usd": 149.00,
            "last_update": "2026-06-15"}

def triage(user_message, max_turns=4):
    messages = [{"role": "system", "content": SYSTEM},
                {"role": "user", "content": user_message}]
    for _ in range(max_turns):  # guardrail: cap the loop
        resp = client.chat.completions.create(
            model="gpt-flagship",  # start strong, trade down later
            messages=messages,
            tools=tools)
        msg = resp.choices[0].message
        if msg.tool_calls:
            messages.append(msg)
            for call in msg.tool_calls:
                args = json.loads(call.function.arguments)
                result = get_order_status(**args)  # execute tool
                messages.append({
                    "role": "tool",
                    "tool_call_id": call.id,
                    "content": json.dumps(result)})
            continue  # loop back so model uses the result
        return json.loads(msg.content)  # final structured output
    return {"escalate": True,
            "reason": "max turns reached"}  # safety net

Walk through what this code enforces, because each line maps to a step in this guide. The SYSTEM block is the instruction contract from step seven, with scope, numbered hard rules, and a structured output spec. The tools array is the function schema from step eight, with a described parameter and additionalProperties set to false so the model cannot invent fields. The triage function is the decision loop: the model reasons, optionally calls get_order_status, your code executes the tool and returns the result, and the loop repeats until the model produces a final answer. The max_turns cap is a guardrail that prevents a runaway loop from draining your budget, and the final return is the safety net that escalates rather than failing silently. To wire the human gate, you read review_required and escalate from the output and route those cases to a queue instead of sending automatically.

To take this to production, add three things in order: structured outputs so the JSON is schema-validated rather than parsed hopefully, logging of every message and tool call for replay and eval mining, and the eval harness from step nine running on your 50 examples before every deploy. Then, and only then, run the accuracy-proven model trade-down, swapping the classification turn to a small model while keeping the judgment turn on the flagship. You now have the full arc: a 10-minute builder prototype that validated the use case, and a code agent with guardrails, evals, and cost control that you can actually run against customers. The same pattern generalizes to lead routing, content brief generation, and reporting agents, which are the workflows B2B growth teams automate first.

Cost, access, and what it takes to run this in production

Cost is where the GPT builder path and the API path visibly diverge, and being clear about it up front prevents a stalled project. The GPT builder is bundled into your paid ChatGPT plan, so a prototype costs you nothing beyond the seat you already pay for. The API is funded separately, which a practitioner walkthrough cited in agent guidance flags explicitly: the OpenAI API has its own billing distinct from a ChatGPT subscription. That separation is a feature, because it lets you cap and monitor production spend independently, but it surprises teams who assume their Plus plan covers API calls. It does not.

Here is how to think about the money without guessing at rates that change. Your cost per task is the number of tokens in plus out, multiplied by the model's per-token rate from the pricing page, summed across every model call and tool turn in the loop. The levers you control are model tier, context size, and turn count. A triage agent that classifies with a small model and only escalates the hard cases to a flagship can cost a fraction of one that runs everything on the flagship. This is exactly why OpenAI sequences accuracy before cost: you cannot safely cut tokens until your evals tell you where quality actually depends on the bigger model.

For a first deployment, the practical playbook is to start with a cheap, low-risk use case precisely because it limits token spend, reduces error risk, and generates measurable evaluation data before you scale. Drafting support replies or triaging requests fits all three. Set a hard monthly usage limit in the billing dashboard, instrument cost-per-task in your logs, and let real numbers, not estimates, drive the model trade-down. Teams that try to automate an entire function on day one face both the highest token bill and the highest risk, which is the worst combination for proving value to a budget owner. If you want a partner to scope the first use case, build the agent, and run it against your historical data, that is what our build and automate and AI automation services exist to do, and you can browse the rest of our stack in the tools directory.

How to get started Monday morning

You do not need a plan, a committee, or a platform to begin. You need one narrow job and a paid ChatGPT account. Here is the exact sequence to run this week, compressed into what you do first. Monday: confirm your paid ChatGPT access and, separately, fund an OpenAI API account with a 50 to 100 dollar monthly cap so cost can never become the blocker. Pick one workflow that is repetitive, low-risk, and measurable, such as drafting first-pass support replies or triaging inbound requests, because that is the use case that limits spend and generates eval data fastest.

Tuesday: gather your real operational docs, the SOPs, macros, and policy files OpenAI recommends turning into routines, and assemble 20 to 50 past examples with known correct outputs as your eval set. Wednesday: build the agent in the GPT builder using the 12 steps above, paste in the instruction skeleton, upload your docs, and run every test example through the preview pane, adding one hard rule per failure. Thursday: stand up the eval table from step nine, score the agent on classification accuracy, grounding, hallucination rate, and escalation, and fix every priority-one failure before anything else. Friday: wire the human-in-the-loop gate, set your guardrails and usage cap, and publish to a small internal audience.

The week after, you watch the first 50 real conversations, harvest the new edge cases they expose, and feed them back into your instructions and evals. Only once the single agent passes consistently do you consider the API path for control, structured outputs, and the model trade-down that cuts cost. Resist every urge to add memory, multi-agent orchestration, or a second use case until the first one is boring and reliable. The teams that win with agents are not the ones that built the most ambitious system first. They are the ones that shipped one narrow, well-evaluated agent, learned from how it failed, and iterated against real numbers. Build that agent this week, and you will have something running against real work before most teams finish their planning doc.

Priya Shah

AI Engineering Lead

Priya runs Skitrate's marketing automation and AI agent stack. Builds the workflows, schemas and data pipelines that move clients from manual ops to autonomous campaign management. Background in distributed systems before pivoting into ad-tech and martech in 2021. Holds patents on agentic campaign orchestration.

• Builds and operates the Skitrate AI automation stack (n8n + LangChain + Postgres + pgvector)
• Designed the agent workflows now running enrichment, scoring and reporting for 40+ clients
• Previously SRE-turned-platform-engineer at a Tier-1 ad-tech firm
• Speaker on AI in marketing operations at SaaStr and MarTech Conference

More posts by Priya Shah →