How to Build an AI Agent for Your Business, Step by Step

Which job should your first AI agent do?

Pick one job that happens often, has a finish line you can check in a system, and has a person who owns it today. Anthropic's Building effective agents says agents add the most value on tasks that need both conversation and action, have clear success criteria, allow feedback loops and keep meaningful human oversight.

Write the finish line as one sentence about the state of a system, not about what the agent says. "Done means a drafted reply and a refund decision are waiting in the helpdesk for approval" can be checked. "Handle customer support" cannot.

Rule out three kinds of job at this stage:

• Jobs where one wrong action moves money or deletes data and nobody can review it first.
• Jobs in systems with no API, where the agent would have to click through screens.
• Jobs nobody owns, because someone has to take the hand-offs and review the logs.

My running example is made up: an online store's refund-request agent. It reads the customer's email, finds the order, checks the refund policy, drafts a reply and proposes refund or no refund. A staff member approves or edits before anything is sent or paid.

What data and tools will the agent need?

List everything the agent must read and every action it might take, and mark each one read or write. That list becomes your tool set and your permission plan. For the refund example:

Make each tool narrow. The OWASP entry on Excessive Agency warns against open-ended tools such as "run a shell command" or "fetch a URL", and recommends tools with more granular functionality. A "get order by number" tool is safer than a database query tool, and easier for the model to use correctly.

Describe each tool as if for a new colleague: what it does, what each input means and what comes back. Anthropic makes thorough tool documentation and testing one of its three core principles. If the system already speaks the Model Context Protocol, an open-source standard for connecting AI applications to external systems, the agent can use an MCP server instead of custom tool code. My WHMCS MCP server guide shows what a read-only one looks like.

Do you need an AI agent, or would a workflow do?

Use a workflow when the steps are the same every time, and an agent only when the path depends on what the model finds along the way. Anthropic recommends the simplest solution possible, which "might mean not building agentic systems at all", and notes that agentic systems often trade latency and cost for better task performance.

In words, I ask four questions in order:

1. Can one model call with your own content answer it? Then build a single call or a chatbot.
2. Are the steps always the same? Then build a workflow: your code runs the steps, with a model call where judgment is needed.
3. Is a wrong action costly or hard to undo? Then the agent can plan freely, but every action waits for a person.
4. Do you have at least 20 real tasks to test with? If yes, build the agent with logs and spend caps. If not, collect them first.

The refund example is mostly a workflow: read email, find order, check policy, draft. The agent part is small: which order the customer means, and whether a policy exception applies. Anthropic's routing pattern fits too: classify the email first, then send refunds, questions and complaints down different paths.

Do not build an agent when a rule in your existing system would do the job, when nobody will take the hand-offs, or when you cannot say what a correct result looks like.

Which model and framework should you build on?

Pick the framework by who should run the agent loop, and pick the model by testing two candidates on your own test set. OpenAI and Anthropic each document several options, separated by where the loop runs:

For a business agent that calls your own systems, I start with a library that runs inside my application, so approvals, logs and storage stay in code I control. The OpenAI Agents SDK quickstart installs with pip install openai-agents or npm install @openai/agents zod, starts with one focused agent and one turn, and adds capabilities incrementally rather than starting with a large multi-agent design.

Anthropic suggests starting with the model API directly, since many patterns take a few lines of code, and understanding any framework you do use: incorrect assumptions about what is under the hood are, in its words, a common source of customer error. Two more details matter. Unless previously approved, Anthropic does not allow third-party products to offer claude.ai login, so an agent you ship uses an API key. And "Building effective agents" now notes that much of its tooling landscape has changed since December 2024.

Other frameworks exist; I reviewed only these two vendors' docs. When you test two models, compare correct outcomes, cost per task and speed. Anthropic's routing pattern can also send easy requests to a smaller, cheaper model.

How do you give an agent tools without giving it too much power?

Give the agent read-only tools first, put every action behind human approval, and give each tool only the access it needs. OWASP names three root causes of Excessive Agency: excessive functionality, permissions and autonomy.

• Functionality: remove every tool the job does not need.
• Permissions: OWASP's example is a read tool whose database identity can also update, insert and delete. Give it a read-only user.
• Autonomy: a person confirms every high-impact action until the logs justify relaxing that for a specific action.

The OpenAI Agents SDK has this built in. In its guardrails and human review guide, a tool marked as needing approval pauses the run instead of executing:

from agents import Agent, Runner, function_tool

@function_tool(needs_approval=True)
async def cancel_order(order_id: int) -> str:
    return f"Cancelled order {order_id}"

The result returns interruptions plus a resumable state; your app approves or rejects each one and resumes the same run, and can serialize and store the state if review takes time. The page also warns that input guardrails run only for the first agent and output guardrails only for the agent producing the final output, so put validation next to the tool that creates the side effect.

The Claude Agent SDK handles this with permission rules and modes. Its documented locked-down setup pre-approves three read tools and denies any other call that would prompt (calls that never need approval, such as read-only Bash commands, still run):

const options = {
  allowedTools: ["Read", "Glob", "Grep"],
  permissionMode: "dontAsk"
};

Deny rules apply even in bypassPermissions mode, and the docs warn that allowed_tools does not constrain that mode: listing only Read still approves every tool. Whichever SDK you use, also set a stop rule; Anthropic names a maximum number of iterations as a common one.

How do you test an AI agent before customers see it?

Build a test set of 20 to 50 real tasks, define the correct outcome for each, and run the agent against it in a copy of your systems. Anthropic's Demystifying evals for AI agents (January 2026) calls 20 to 50 simple tasks drawn from real failures a great start, taken from your manual checks, bug tracker and support queue.

Grade the outcome, not the words. In Anthropic's example a flight-booking agent may say the flight is booked, but the outcome is whether the reservation exists in the database. For the refund agent, check that the right order was found, the decision matches what staff would decide, and no refund ran without approval.

Run each task more than once, because outputs vary between runs. In Anthropic's numbers, an agent that succeeds 75% of the time per try passes all of three tries only about 42% of the time, which matters for customer-facing agents. Keep two suites: capability tests the agent still struggles with, and regression tests it must keep passing.

OpenAI's agent evals guide suggests starting with trace grading while you are still debugging, then moving to datasets and eval runs when you need repeatable results. Answer quality from documents is its own problem, covered in my RAG chatbot guide.

What does a safe launch look like?

A safe launch logs every model and tool call, caps spend, and hands anything uncertain to a named person with a summary. I start in shadow mode: the agent drafts, staff send, and I compare its drafts with what staff did.

Set the spend cap in the provider's console, not only in your code. Anthropic's rate limits page says the Start, Build and Scale tiers each carry a monthly spend cap, that you can set your own lower limit on the Billing page, and that workspaces can get their own limits. When a limit you set is reached, requests return HTTP 400 with a message starting "You have reached your specified API usage limits" (the tier cap returns HTTP 429), so your code must treat these errors as "hand off to a person", not crash.

Write the hand-off rule before launch: which cases go to whom, through which channel, with what summary. "Refund request, order 1042 found, outside the 30-day window in our policy, draft attached" saves staff the whole lookup.

My launch checklist:

• Every tool marked read or write, with least-privilege credentials.
• Every write action behind approval, tested with an approve and a reject.
• A maximum number of steps per run.
• The test set passing the agreed bar over several runs.
• Traces of every model call, tool call and approval decision.
• Provider and workspace spend limits set, and limit errors handled.
• A named hand-off owner and a weekly log review.
• An off switch that needs no deploy.