To build an AI agent for your business, choose one narrow job that needs judgment, give a language model only the tools and data that job requires, write the test cases before you write the prompt, put a human approval step in front of anything irreversible, and pilot it on real cases before you widen its scope. Technically an agent is a model calling tools in a loop until a goal is met; almost all of the real work is in the tools, the permissions and the testing around that loop. This plan follows the published guidance of Anthropic, OpenAI, OWASP and NIST, and it is written for the person who has to decide what gets built.
What is an AI agent, in build terms?
Anthropic's engineering guide describes agents as typically just LLMs using tools based on environmental feedback in a loop. OpenAI's guide names the same three parts: a model for reasoning, tools it can call, and instructions that define its behavior, and says every orchestration approach needs the concept of a run, a loop that lets agents operate until an exit condition is reached, such as a tool call, a certain structured output, an error or a maximum number of turns.
That definition sets the build plan. You do not need to invent an architecture. You need to decide what the loop is for, what it can touch, how you will know it worked, and when it must stop and ask.
Step 1: Do you actually need an agent?
Check this first, because the cheapest agent is the one you do not build. Anthropic advises finding the simplest solution possible, and only increasing complexity when needed, which might mean not building agentic systems at all. Agents fit open-ended problems where it is difficult or impossible to predict the required number of steps. OpenAI suggests prioritizing workflows that have previously resisted automation, such as ones involving nuanced judgment and exceptions.
If you can write the steps down in advance, a workflow with a model inside one step will be cheaper and easier to audit. We cover that decision in detail in AI agents vs workflow automation. The rest of this plan assumes the answer was yes.
Step 2: Scope one job, with an owner and an outcome
Pick a single job, not a department. "Triage inbound supplier emails and draft replies for the ones about delivery dates" is a job. "Handle procurement" is not. Write down three things before any technical work:
- The input. What arrives, from where, in what format, and how much of it is messy.
- The outcome. What a finished case looks like, and who uses it.
- The owner. The person responsible for the result, who will review the pilot and decide whether it is good enough.
A narrow first job keeps the tool list short, which matters in Step 4, and makes the evaluation in Step 3 possible. OpenAI's closing advice is the same: start small, validate with real users, and grow capabilities over time.
Step 3: Write the evaluation set before the prompt
Collect real past cases, including the awkward ones, and write down what the right outcome was for each. This is your evaluation set. OpenAI suggests you might even consider writing evals before you start writing prompts, akin to behavior-driven development, and running them against test inputs like you expect to see in production.
The evaluation set drives model choice too. OpenAI's agent guide recommends you build your agent prototype with the most capable model for every task to establish a performance baseline, then try smaller models to see if they still achieve acceptable results. Without the test set you are comparing models on impressions. Anthropic's summary applies to every step after this one: the key to success is measuring performance and iterating, and you should add complexity only when it demonstrably improves outcomes.
Step 4: Map the tools, data and permissions
List every system the job touches and what the agent must do in each. OpenAI sorts tools into data tools that retrieve context, such as querying a CRM or reading PDFs; action tools that change systems, such as sending emails or updating records; and orchestration tools, where other agents act as tools. The split matters because data tools and action tools carry very different risks.
Then cut the list down. OWASP's guidance on Excessive Agency is the checklist:
| Principle | What it means in practice |
|---|---|
| Minimize extensions | If the job does not need to fetch URLs, the agent gets no URL tool |
| Minimize extension functionality | A mail summarizer can read mail, not send or delete it |
| Avoid open-ended extensions | A specific "write report file" tool instead of a general shell |
| Minimize extension permissions | Read access to the products table only, enforced by the database account |
| Execute in the user's context | The agent acts with the permissions of the person it serves, via OAuth with minimum scope |
Invest in the tools themselves. Anthropic's rule of thumb is to put as much effort into agent-computer interfaces as into human-computer interfaces, and it reports that while building its SWE-bench agent it spent more time optimizing tools than the overall prompt. Its example: the model made mistakes with relative file paths, so the tool was changed to always require absolute filepaths, and the model then used it flawlessly. Clear names, clear descriptions and inputs that are hard to misuse beat clever prompting.
If the agent needs several systems, the Model Context Protocol gives you a standard way to connect them: it is an open-source standard for connecting AI applications to external systems, so each system can be wrapped once and reused.
Step 5: Write the instructions and set the loop limits
Instructions should read like an operating procedure: the goal, the steps a good employee would take, what to do with each kind of exception, and when to stop. OpenAI's guide recommends using existing documents like operating procedures and support scripts as the starting point.
Set hard limits on the loop. Anthropic says it is common to include stopping conditions, such as a maximum number of iterations, to maintain control. Start with a single agent. OpenAI's view is that a single agent with tools is often sufficient, and that you split into multiple agents only when one fails to follow complicated instructions or consistently selects incorrect tools. Frameworks are fine for a prototype, but Anthropic's advice is not to hesitate to reduce abstraction layers and build with basic components as you move to production, so that you can see exactly what the model receives.
Step 6: Add guardrails and human approval gates
Give every tool a risk rating. OpenAI recommends rating each tool low, medium or high based on read-only vs. write access, reversibility, required account permissions, and financial impact, and using the rating to pause for checks or escalate to a human before high-risk calls. Its guide treats guardrails as a layered defense mechanism and says they should be coupled with robust authentication and authorization protocols, strict access controls, and standard software security measures.
Decide where a person approves. OWASP: require a human to approve high-impact actions before they are taken, and implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed. OpenAI adds a second trigger for handing over to a person: exceeding failure thresholds, such as retry limits.
Plan for hostile input. An agent that reads emails, documents or web pages will eventually read text written to manipulate it. OWASP describes indirect prompt injection, where content from external sources alters the model's behavior, and notes it is unclear if there are fool-proof methods of prevention. The practical defense is that the permissions from Step 4 and the approval gates here limit what a manipulated agent can do.
Step 7: Pilot in a sandbox, then with real users
Run the agent against the evaluation set in a sandbox before it touches live systems. Anthropic recommends extensive testing in sandboxed environments, along with the appropriate guardrails, because the autonomy of agents means higher costs and the potential for compounding errors.
Then run a supervised pilot: real cases, every consequential action approved, every run logged. OpenAI calls human intervention especially important early in deployment, helping identify failures, uncover edge cases, and establish a robust evaluation cycle. Every case the agent gets wrong in the pilot goes into the evaluation set, so the same mistake is tested for ever after.
Step 8: Measure, then widen the scope
Track a handful of numbers against the process the agent replaces: the share of cases completed without a person, the share escalated, the error rate found in review, the time per case, and the cost per completed case. Cost needs watching because every loop iteration is billed for the conversation so far as input again: OpenAI notes that even in a chained conversation all previous input tokens are billed as input tokens. Our guides to input vs output tokens and prompt caching explain how that is billed and how to cut it. Anthropic states plainly that agentic systems often trade latency and cost for better task performance.
Widen the scope one tool or one case type at a time, re-running the evaluation set each time. For governance beyond the single project, NIST's AI Risk Management Framework, released on January 26, 2023 and intended for voluntary use, and its Generative AI Profile of July 26, 2024, give a common structure for managing AI risk across an organization.
What does the whole plan look like?
| Step | Output | Guidance it follows |
|---|---|---|
| 1. Confirm you need an agent | A yes, or a workflow instead | Anthropic: simplest solution first |
| 2. Scope one job | Input, outcome and owner in writing | OpenAI: start small |
| 3. Evaluation set | Real cases with correct outcomes | OpenAI: evals before prompts |
| 4. Tools and permissions | Minimal tool list, scoped access | OWASP LLM06, Anthropic ACI |
| 5. Instructions and loop limits | Procedure, stop conditions, single agent | Anthropic, OpenAI |
| 6. Guardrails and approvals | Risk ratings, approval gates | OpenAI, OWASP |
| 7. Pilot | Sandbox results, supervised live runs | Anthropic, OpenAI |
| 8. Measure and widen | Metrics against the old process | NIST AI RMF |
Qubba builds AI agents and workflow automation on a fixed written quote after a 30 minute call. You bring a recurring task, the information it uses and the person responsible for its result, which is Step 2 of this plan.
Frequently asked questions
Is it free to build an AI agent?
The building blocks can be.
MCP is open source, and the major providers publish SDKs.
Running an agent is not free: model providers bill every input and output token on every loop iteration, and someone has to build the tools, maintain the evaluation set and review escalations.
The honest cost is the development work plus the running cost per completed case.
Can you build an AI agent with ChatGPT?
You can build agents on OpenAI's models, and its guide walks through the Agents SDK.
Check the product timeline before you commit: OpenAI's deprecations page states that it announced the deprecation of Agent Builder on June 3, 2026, and that Agent Builder is scheduled to shut down on November 30, 2026.
The plan in this article is the same whichever provider you use.
Should I use one agent or several?
Start with one.
OpenAI recommends you maximize a single agent's capabilities first, because more agents add complexity and overhead.
Split only when a single agent keeps choosing the wrong tools or cannot follow its instructions.
How do I keep an agent from doing something harmful?
Limit what it can do, not only what it is told.
Give it the minimum tools and permissions, enforce authorization in your systems rather than in the prompt, put irreversible actions behind human approval, and log every tool call.
OWASP's Excessive Agency guidance names the three root causes to design out: excessive functionality, excessive permissions and excessive autonomy.