How to build an AI agent

What an AI agent actually is

An AI agent is a model running inside a work loop. It receives a goal, decides what to do next, uses an allowed tool when needed, reads the result, and either continues or stops.

Think of it as hiring a junior operator. The instructions are the job description. The model supplies judgment. Tools are the operator's access badges to your order system, calendar, knowledge base, browser, or file store. Memory is the notebook. Guardrails and approvals are the supervisor.

That is different from a basic chatbot. A chatbot can draft an answer. An agent can look up an order, compare the live status with policy, ask for missing information, and route the case to a person. The action loop is the difference.

OpenAI's current agent overview describes agents as applications that plan, call tools, keep state, and sometimes collaborate across specialists. In the SDK, the core object is still deliberately small: a model with instructions, tools, and optional controls such as guardrails and handoffs.

Agents SDK or Responses API?

Use the Agents SDK when you want the runtime to manage repeated tool calls, state, guardrails, handoffs, and approvals. Use the Responses API directly when you want to write and control that loop yourself. OpenAI recommends the Responses path for direct model control and the SDK for bounded conversational or transactional workflows with recurring orchestration.

If you prefer a no-code builder, the architecture is the same. Make sure the platform gives you explicit tools, an approval step, run logs, and a way to stop the loop. A visual canvas does not remove the need for those controls.

How to build the first useful version

The fastest route is to shrink the job before you expand the technology.

1. Write a one-sentence job contract

Name the user, the trigger, the action, and the finish line. "Help with customer support" is too broad. "Answer order-status questions using the order API, and hand off anything involving a refund or address change" is buildable.

Also write the forbidden actions. This turns vague autonomy into a bounded product decision.

2. Check whether the job needs an agent

Agents earn their complexity when the work involves judgment, messy language or documents, and exceptions that make normal rule sets brittle. OpenAI's practical guide recommends a deterministic system when those conditions are absent.

A tax calculation, a fixed form validation, or a scheduled data copy should usually remain normal software. A refund request that requires reading the conversation, checking policy, inspecting an order, and deciding whether a person must review it is a better agent job.

3. Pick the model for the job, not for the demo

The SDK currently defaults to gpt-5.4-mini with no reasoning effort and low verbosity for low-latency workflows. Its model guide recommends gpt-5.6-sol when higher quality matters and you have access.

Start with the lower-cost option that passes your saved test cases. Move up only when the failures come from judgment quality, not from a missing tool, vague instruction, or bad data. A stronger model cannot repair an order API that returns stale status.

4. Give it one read-only tool

Your first tool should retrieve information, not change it. An order lookup, policy search, inventory check, or calendar availability call is easier to evaluate and safer to retry than a refund, cancellation, payment, or outbound email.

The SDK can turn a typed Python function into a tool and generate its input schema automatically. It also offers hosted web search, file search, code interpreter, MCP, and image generation tools. Local computer, shell, and file-editing tools need an execution environment you control.

Here is the smallest useful pattern:

from agents import Agent, Runner, function_tool

@function_tool
def lookup_order(order_id: str) -> str:
    """Return the current order status from the order system."""
    return "Order 123 is packed and awaiting carrier pickup."

agent = Agent(
    name="Order status agent",
    instructions=(
        "Answer order-status questions with lookup_order. "
        "Never change or cancel an order. Escalate anything else."
    ),
    tools=[lookup_order],
)

result = Runner.run_sync(agent, "Where is order 123?")
print(result.final_output)

Install the Python SDK with pip install openai-agents and keep the API key in the OPENAI_API_KEY environment variable. The same product structure is available through the current TypeScript SDK if that better fits your stack.

5. Let the loop stop

The Runner calls the model, executes any requested tool, sends the tool result back, and repeats. It ends when the model returns final output with no tool call. It can also stop at a turn limit and raise MaxTurnsExceeded.

Every production agent needs a maximum step count, a timeout, and a clear failed outcome. "Could not verify, sent to a person" is a valid finish line. Endless retry is not persistence. It is an incident.

6. Choose one memory strategy

Memory means carrying relevant context into the next turn. The SDK can store client-side history in a session, or you can use OpenAI-managed continuation with a conversation_id or previous_response_id.

Choose one strategy per conversation. The SDK explicitly prevents combining a session with those server-managed state options in the same run because overlapping histories can duplicate context. Also decide how much history the agent really needs. A support agent may need the current case, not a customer's entire lifetime transcript.

7. Put checks around every risky boundary

Use an input guardrail to reject requests outside the job. Use a tool guardrail around each custom function that can read or change business data. Use an output guardrail to check the final answer. Put a human approval in front of irreversible or costly actions.

One detail matters: input guardrails run in parallel by default. That improves latency, but the agent may consume tokens or start a tool before the check fails. Use blocking mode when the request might trigger a side effect or expose sensitive data.

For a deeper production pattern, use the blast-radius guardrail playbook. The central idea is simple: route every paid, mutating, or permissioned action through one controllable boundary.

8. Trace, evaluate, then add a sandbox if needed

Tracing is on by default in the Agents SDK. It records model generations, function calls, guardrails, and handoffs so you can see why a run succeeded or failed. Review traces against a saved set of real requests and expected outcomes before adding more tools.

Traces can contain model and function inputs and outputs, so disable sensitive-data capture where appropriate. OpenAI tracing is unavailable under Zero Data Retention.

Use a sandbox only when the job truly needs files, commands, packages, or long-running workspace state. OpenAI's April 2026 SDK update added native controlled environments, portable workspace manifests, snapshots, and support for several sandbox providers. A support lookup agent does not need a container. A document analyst or coding agent often does.

What it costs to run

The SDK and Responses API do not add a separate platform fee. You pay for the selected model's tokens and any hosted tools.

At current standard short-context rates, gpt-5.6-sol costs $5 per million input tokens and $30 per million output tokens. gpt-5.6-terra costs $2 and $12. gpt-5.6-luna costs $0.20 and $1.20. Web search costs $10 per 1,000 calls plus search-content tokens. Responses file-search calls cost $2.50 per 1,000, with storage at $0.10 per GB per day after the first free GB. A 1 GB hosted shell or code-interpreter container starts at $0.03 for a 20-minute session.

Those unit prices do not tell you the cost of one completed job. Your trace does. Measure model turns, tool calls, retries, and human escalations for each successful outcome. Then choose the model and tool budget that preserves quality.

Seven agent jobs worth building, ranked

The best agent jobs have a clear buyer, a constrained workflow, and an outcome you can review.

1. Customer resolution agent

An ecommerce support team could give an agent access to approved help content and read-only order data. It could identify the customer, retrieve shipping status, explain the next step, and hand refunds or address changes to a person. The payoff is faster first response and cleaner handoff notes, not removing every human from support.

2. Evidence-first research agent

A strategy team could drop a set of reports into a controlled workspace and ask for a comparison with source filenames attached to every claim. The agent could search, extract, cross-check, and produce a structured brief. It pays by moving analysts from document hunting to judgment and review.

3. Sales qualification and meeting-prep agent

A B2B sales team could let an agent read an inbound message, enrich the company from approved sources, check qualification rules, and draft a meeting brief. It could book only when the prospect meets explicit criteria. The value is consistent preparation and less manual CRM work, while a salesperson still owns the relationship.

4. Operations intake agent

A property manager could route maintenance emails through an agent that extracts the building, unit, issue, urgency, and preferred access time. It could check the tenant record, create a draft ticket, and escalate safety issues. The payoff is less rekeying and fewer incomplete work orders.

5. Contract and policy comparison agent

A procurement team could ask an agent to compare a vendor contract with the company's standard clauses, flag differences, and cite the relevant pages. It could prepare a review packet without approving terms. That shortens the first pass while leaving legal judgment with counsel.

6. Internal IT triage agent

An IT team could connect a staff-facing agent to device inventory, service status, and approved troubleshooting guides. It could gather diagnostics, suggest safe steps, and open a ticket with the relevant evidence. The payoff is fewer back-and-forth messages before a technician starts work.

7. Controlled file and code agent

A finance or engineering team could place documents or a repository in a sandbox, allow a narrow set of commands, and define an output directory. The agent could inspect files, run analysis, edit a draft, and return artifacts for review. This is where the newer sandbox capability matters, because the work needs a real workspace and a durable trail.

Three products you could build from this

The broad phrase "AI agent" is not a market. These three jobs show measurable buying intent.

Strongest: a vertical customer resolution agent

Build one support agent for a specific operating system, such as Shopify stores, property managers, or field-service companies. The buyer pays for resolved cases and usable handoffs, not for a general chat window.

The commercial signal is sharp. "AI customer service agent" gets about 720 Google searches a month, has commercial intent, and carries a $264.61 CPC. People also ask AI assistants for the same job about 69 times a month. Intercom's current benchmark is $0.99 for a successful chat or email resolution, procedure handoff, or disqualification.

The smallest sellable version needs one channel, one approved knowledge source, one read-only account tool, a human handoff, and an outcome dashboard. The catch is that your moat is not the model call. It is the vertical integrations, evaluation set, escalation design, and proof that a "resolution" was actually good for the customer.

This is the strongest opportunity because the job is narrow, the buyer is obvious, and success can be counted. The extremely high CPC also signals that vendors already compete hard for this buyer.

An evidence-first research agent for one profession

Build a research workspace for a narrow buyer such as compliance analysts, grant writers, healthcare market researchers, or due-diligence teams. It should search an approved corpus, attach sources to claims, compare conflicting evidence, and export a repeatable brief.

"AI powered research assistant" gets about 18,100 Google searches a month with commercial intent. The broader "AI research assistant" gets another 2,400. Elicit currently prices its Pro plan at $49 per user per month and Scale at $169, which proves buyers already pay for structured research workflows.

The MVP is one corpus type, one report template, a cited evidence table, and a review queue. The catch is breadth. A generic research assistant competes with large general products. The defensible version owns a specialized data source, workflow, or quality standard that general tools do not.

A sales qualification and follow-up agent

Build an inbound agent that answers product questions, checks fit, creates a CRM record, drafts a meeting brief, and books time only when rules are satisfied. Start with inbound traffic. Unsupervised outbound messaging creates more brand and compliance risk.

"AI sales agent" receives about 1,000 Google searches a month, has commercial intent, and carries a $74.89 CPC. Intercom now prices a successful qualification outcome at $9.99, giving you a concrete market anchor.

The MVP needs website chat or email, a read-only CRM connection, explicit qualification rules, calendar access, and human review before any sensitive follow-up. The catch is bad source data. A clever agent operating on incomplete CRM records will qualify the wrong people with great confidence.

The limits that matter

An agent does not make uncertain software deterministic. It moves uncertainty into a loop that you can observe and control.

• Do not use an agent for fixed logic that normal code handles better.
• Do not give write access before the read-only version passes real cases.
• Do not rely on one top-level guardrail. Agent guardrails do not wrap every hosted or built-in tool, so permission checks must also live in your application and tool layer.
• Do not combine memory systems casually. Duplicate context creates confusing behavior and needless token use.
• Do not start with a team of agents. OpenAI recommends maximizing one agent with tools before adding multi-agent orchestration.
• Do not let a model approve irreversible actions. High-risk steps need a person until the evidence supports a narrower approval policy.

Security tooling can help, but architecture carries the larger burden. The AI security tools comparison is useful once you know which risks your agent actually creates.

The honest take is that the model is often the easiest part. The hard product work is tool design, permissions, clean data, evaluation, escalation, and economics. Build those well and the agent becomes useful. Skip them and a polished demo becomes an unreliable employee with production access.

If you want one of these built around your systems and approval rules, see AI agent development.