How to Create an AI Agent: A Build Guide That Survives Day Two

Last updated 27 August 2026.

Key takeaways

• Creating an agent takes an afternoon. Making it behave identically on run 50 is the actual project.
• An agent is a model that chooses the steps. A workflow whose steps you hard-coded is not one.
• Start with one narrow task, three tools, and a human checkpoint on anything irreversible.
• You can build an agent with no code and you can build one free. Both options hit real walls.
• Any step that does the same thing every time should be code, not a model call.

What an AI agent actually is (and what isn't one)

An AI agent is a system where a language model decides which steps to take and which tools to call to finish a task, rather than following a path a developer wrote in advance. It runs in a loop: read the current state, pick a tool, observe the result, repeat until an exit condition fires.

That definition excludes most things currently sold as agents. Anthropic draws the line cleanly in Building Effective Agents: workflows are "systems where LLMs and tools are orchestrated through predefined code paths," while agents are "systems where LLMs dynamically direct their own processes and tool usage." OpenAI's practical guide to building agents rules out applications that integrate a model "but don't use them to control workflow execution."

So a chatbot is not an agent. A RAG pipeline that always retrieves, always summarizes, and always returns is a workflow with a model in the middle, and there is nothing wrong with that. We cover what an AI agent is at more length separately.

The moment the model picks the path, you inherit a system whose behavior varies run to run. Everything hard about production agents follows from that property.

The seven types of AI agents

The taxonomy is borrowed from classical AI. IBM's types of AI agents covers the canonical five: simple reflex agents that map a perception straight to an action, model-based reflex agents that keep an internal model of the world, goal-based agents that plan toward a target state, utility-based agents that score competing options, and learning agents that improve from feedback. The count reaches seven with the two architectural framings used in practice: multi-agent systems, where several agents split the work, and hierarchical systems, where a manager agent delegates to specialists.

Two of these describe almost every LLM agent shipping today. Goal-based, because you hand it an objective and it plans. Utility-based, when you give it criteria to weigh. The reflex categories are pre-LLM control theory. Treat the taxonomy as vocabulary, then get back to the build.

How to create an AI agent, step by step

The worked example running through these steps is an inbox-triage agent. It reads an inbound support email, classifies it, looks up the customer record, and drafts a reply that a human approves before anything sends.

1. Pick one narrow task. One task with a clear input, a clear finished state, and a way to tell whether it went right. Narrow enough that you can list every tool it needs on one hand. If you are stuck choosing, what people actually build agents for is a starting inventory.
2. Choose the model. OpenAI's guide recommends prototyping with the most capable model to set a baseline, then swapping in smaller models where they still pass. Do it in that order. Starting cheap and debugging upward confuses model capability with prompt quality.
3. Define the tools. OpenAI splits these three ways: data tools that fetch context, action tools that change something in an external system, and orchestration tools, where an agent is exposed as a tool to another agent. Triage needs two data tools and one action tool.

TOOLS = [
{"name": "get_customer",
"description": "Look up a customer record by email address.",
"parameters": {"type": "object",
"properties": {"email": {"type": "string"}},
"required": ["email"]}},

{"name": "search_past_tickets",
"description": "Find this customer's previous tickets, newest first.",
"parameters": {"type": "object",
"properties": {"customer_id": {"type": "string"},
"limit": {"type": "integer", "default": 5}},
"required": ["customer_id"]}},

{"name": "submit_draft_for_approval",
"description": "Queue a drafted reply for human approval. Does not send.",
"parameters": {"type": "object",
"properties": {"ticket_id": {"type": "string"},
"category": {"type": "string",
"enum": ["billing", "bug", "howto", "other"]},
"body": {"type": "string"}},
"required": ["ticket_id", "category", "body"]}},
]

Note what is missing. There is no send_email. Nothing the agent can call reaches a customer, so no prompt injection buried in an inbound email can make it write to one.

4. Write the instructions. State the sequence, the wording of anything user-facing, and what to do when information is missing. OpenAI's guidance is to build routines from documents you already have, break dense procedures into explicit steps, and write the edge cases down rather than trusting the model to invent a policy. "Ask for the order number if it is absent" is an instruction. "Be helpful" is decoration.
5. Add guardrails and a human checkpoint. OpenAI describes guardrails as a layered defence: relevance and safety classifiers, a PII filter, moderation, rules-based checks like blocklists and length limits, output validation, and tool safeguards that rate each tool by whether it writes, whether it is reversible, and what it costs if wrong. That rating drives the checkpoint.

def approval_required(tool_name, args):
# Any write that a customer sees goes to a person first.
if tool_name == "submit_draft_for_approval":
return True
if tool_name == "get_customer" and not args.get("email"):
return True # never fan out an unbounded lookup
return False

OpenAI names two triggers for human intervention: exceeding a failure threshold, such as retry limits, and high-risk actions that are sensitive, irreversible, or expensive. Anthropic's version is that agents "pause for human feedback at checkpoints or when encountering blockers."

6. Test on real inputs. Twenty real emails from the actual inbox, including the two that are barely legible. Synthetic test cases pass because you wrote them in the same frame of mind you wrote the prompt.
7. Instrument it. Log the tool inventory available at each turn, the tool chosen, the arguments, the result, and the token count. You need this before the first incident. We go deeper on knowing what your agent actually did elsewhere.
8. Deploy it with exit conditions. Every agent run is a loop, and loops need a stop. OpenAI lists the usual exits: a final-output tool fires, the model returns without a tool call, an error surfaces, or the turn limit trips. Anthropic recommends stopping conditions "such as a maximum number of iterations." Set the turn cap before launch, because you will not want to be choosing a number during an incident.

Can you build an AI agent without coding?

Yes, and the tooling is real. The current no-code shape is a visual canvas where you drag nodes, wire tools, and configure guardrails without touching Python. OpenAI shipped exactly that as Agent Builder, then announced in June 2026 that Agent Builder and Evals are winding down and leave the platform after 30 November 2026, pointing durable workflows toward the Agents SDK and toward Workspace Agents.

Take the lesson rather than the product. Visual builders get a working agent fast and are good at the first 80%. Where they stop is version history you can diff, a place to put shared state, permissions that survive the person who built it, and an audit trail. That is where "no-code" quietly becomes "no record." Our notes on choosing an agent builder go through the trade.

Can you do this for free?

Two honest routes, both with a wall at the end.

Provider free tiers get you to a working prototype and then meter you. Cost per run scales with the number of reasoning steps the model takes, so a triage agent that takes four turns on an easy email and eleven on a messy one has a bill that moves with your inbox. Do that arithmetic against the provider's current rate card, not against a number in a blog post, including this one.

Open-weight models on your own hardware are free at the margin. OpenAI's gpt-oss-120b and gpt-oss-20b ship under Apache 2.0, and a local runner like Ollama keeps everything on your machine. The cost moves into GPU memory, latency, and your own time. Test tool-calling reliability on the smaller open models first, because a model that fumbles the JSON is not free at all.

Can ChatGPT build an AI agent?

It builds agent code well, which is a different claim from being the agent runtime. Ask ChatGPT for tool schemas, a loop, and a guardrail function and you get working scaffolding faster than typing it. The runtime question is separate: Workspace Agents runs shared agents in the cloud under organization permissions, a product with defined boundaries rather than a chat window drafting Python for you. Keep the two apart when you plan.

Frameworks vs platforms: which to start on

• Major · What you write: A description of the task, in English · What you get for free: SSO, role-based permissions, audit log, managed database, file storage, deploy · When it fits: The work has to repeat identically, hold state between runs, and be explainable afterwards
• Agent SDK or framework · What you write: Python or TypeScript: loop, tools, guardrails · What you get for free: Tool-calling plumbing, handoffs, tracing hooks · When it fits: You want line-level control and are staffed to maintain the day-two work yourself
• Model API directly · What you write: Everything, including the loop · What you get for free: Nothing beyond the model call · When it fits: The agent is small and you are willing to own state and audit later
• Visual no-code builder · What you write: Nodes on a canvas · What you get for free: Hosting, a prompt editor, basic guardrails · When it fits: A first prototype, before anything needs a record of what it did
• Local open-weight stack · What you write: Python, plus the ops · What you get for free: No per-token bill · When it fits: Data cannot leave your hardware and you have the GPUs to spare

Every row here ships real agents. What separates them is how much you own on day two. For the wider map, see the framework landscape.

The part the tutorials skip: making it run the same way twice

Your agent works. Now it runs a thousand times, and four problems arrive together.

It re-decides. The same email arrives on Tuesday and the agent reasons from scratch to the same classification it reached on Monday. That is a model call spent re-deriving a known answer, and it is where cost detaches from value.

It forgets. State lives in a context window that ends with the run. Anything it learned about this customer last week is gone unless you paid to refill it.

It varies. Two near-identical inputs take different paths because the model chose differently, and neither run is wrong enough to catch.

It leaves no record. Three months later someone asks what the agent did in March and you have the output but not the decision, the tool inventory, or the reason.

A better prompt does not fix any of this. Every step that does the same thing every time should stop being a model call and become code. Classification with four fixed categories is a function. The customer lookup is a query. Ranking past tickets is a sort. Push each one out of the model and the agent's reasoning shrinks to the part that needs judgment, which for triage is roughly one decision: is this escalation-worthy. That is agentic workflow patterns compressed into a sentence.

Be willing to go further and not build the agent at all. OpenAI's guide, which exists to sell agents, tells you to validate that your use case involves genuine judgment, unstructured data, or rules too tangled to maintain, and says that otherwise "a deterministic solution may suffice." Anthropic's advice is to find "the simplest solution possible, and only increasing complexity when needed," noting that agentic systems "often trade latency and cost for better task performance." Both are right. An agent wrapped around a task a cron job could do is a slower, costlier cron job with a plausible explanation for its mistakes.

This piece does not cover training or fine-tuning a model, and it treats multi-agent orchestration only in passing.

What we think, and what we build

The industry made creating an agent easy and left running one hard. Every guide on this topic, including the strong ones cited above, ends at the moment the agent works once. That is where the expensive problems begin: the same task reasoned through on every run, state that evaporates with the context window, and no way to reconstruct what happened. An agent that re-derives the same answer every Tuesday is a recurring bill with a reasoning trace attached.

Major is built on the other half of that arc. When an agent works out how to handle a repeatable part of a task, it builds an app for that part, and that app is deterministic code with a managed database, file storage, and its own logs. From then on the agent runs the app instead of reasoning through the step again. The model stays for the judgment calls, so it does less rather than nothing. The repeatable work stops being re-decided, so it runs the same way every time. The state stops being ephemeral, because it lives in a database. The actions become inspectable, because they live in code with permissions and an audit trail. Reason once, run forever.

None of that makes an agent correct. Bad judgment moved into an app is bad judgment that now runs reliably, which is why the human checkpoint in step five stays whatever platform you build on. What changes is the shape of the day-two problem, from "why did it do something different this time" to "is this app still the right app," and the second question is one a team can answer.

If the agent you are planning has a repeatable core, the design question worth settling early is where that core runs. You can see how Major turns the repeatable part of an agent's work into a governed app and decide whether the trade holds for your case.

Related articles

• Agent Platform: What It Means Now That Google Owns the Term
• Enterprise AI Agents: What "Enterprise-Grade" Actually Means
• AI Agent Governance: Why Control Must Move to the Point of Action