How do I build an AI agent from scratch?

Start with one narrow job and a written definition of done. Then pick a model, give it the smallest set of tools that can do the job (ideally through MCP servers), write its instructions, add guardrails such as read-only credentials and approval for writes, and test it against twenty or thirty real cases before anyone relies on it. The loop itself is the easy part; agent SDKs give it to you.

Do I need to code to build an AI agent?

Not always. No-code builders and workflow tools such as n8n or Copilot Studio let you assemble an agent from blocks, and the agent features in Claude and ChatGPT can be given tools and instructions without code. You need code when the agent has to run unattended, call your own systems, or meet audit requirements that a builder cannot express.

What is the best framework for building AI agents?

There is no single best one. The Claude Agent SDK and the OpenAI Agents SDK give you a production loop tied to one vendor's models; LangGraph and similar frameworks are model-neutral and good at explicit multi-step graphs. Choose by where the agent will run and who maintains it, not by benchmark claims. The tools, instructions and guardrails you write carry over between frameworks.

How long does it take to build an AI agent?

A working prototype of a narrow agent takes days. Getting it to production takes longer, mostly because of access, approvals, evaluation and logging rather than the model. Plan for the second part to be the larger one.

How do I make an AI agent safe?

Give it least-privilege credentials, require human approval for anything irreversible, keep untrusted content (emails, web pages, tickets) away from write tools, cap its budget, and log every tool call with its arguments and result. Put these rules in the harness or a gateway, not only in the prompt.

How to build AI agents: a practical guide from first job to production

Most guides on how to build AI agents start with a framework. That is backwards. The framework is the cheapest decision you will make, and you can change it later. What decides whether an agent is useful is the job you give it, the tools it can reach, the rules around those tools, and whether you can tell when it is wrong.

This guide walks through those decisions in the order you should make them, then shows them applied to a real example. If you want the background first (what an agent is and how it differs from a chatbot), read What is agentic AI?.

Step 1: Pick one job and define done

An agent that "helps the finance team" will never ship. An agent that "finds invoices more than 14 days overdue, drafts a reminder in the customer's language, and puts it in an approval queue" can ship this month.

Write down four things before you touch a model:

The trigger. What starts a run: a schedule, a new ticket, a message, a button.
The inputs. Which systems and documents the agent needs to read.
The output. What exists when it is finished: a draft, an updated record, a report, a question to a human.
Success criteria. How you will judge a run as correct. "The reminder names the right invoice, amount and due date, and uses the agreed tone" is testable. "Good reminders" is not.

Also write down what the agent must not do. That list becomes your guardrails in step 6.

Good first jobs share three traits: they happen often, the steps are mostly known but need judgment in the middle, and a mistake is cheap to catch before it matters.

Step 2: Understand the loop you are building

Every agent, whatever it is built on, runs the same loop:

goal + context → model chooses an action → tool runs → result goes back to the model → repeat → finish or ask a human

The model decides. Tools act. Your code (or the platform's) runs the loop, enforces limits, and decides when to stop. Three limits belong in every loop from day one:

A maximum number of steps, so a confused agent stops instead of circling.
A token or cost budget per run.
A defined way to give up: return what it found and ask a human, rather than guessing.

Step 3: Choose the model

Use a capable frontier model while you prove the job works, then see whether a smaller, cheaper one passes the same tests. Things that matter more than leaderboard position:

Tool-calling reliability. Does it call the right tool with valid arguments, and recover when a call fails?
Instruction following over long runs, not just the first turn.
Where it runs. For an EU company, which region processes the prompt and the tool results is a legal question, not a detail. See step 9.
Cost per successful run, not cost per token. A cheap model that needs three retries is not cheap.

Keep the model behind an abstraction you control (an SDK setting, a config value or a gateway route) so you can swap it when a better or cheaper one appears. Our AI Hub exists partly for this reason: one endpoint, many models.

Step 4: Give it tools through MCP

Tools are what turn a model into an agent. The Model Context Protocol has become the standard way to provide them: a tool provider runs an MCP server, and any MCP-capable agent can discover and call its tools. Many SaaS vendors now ship official servers, so you often connect rather than build. Our MCP guide covers the protocol, and the best MCP servers guide lists what exists.

Rules that save pain later:

Fewer, sharper tools. Every tool you add is something the model can pick wrongly. Start with the minimum for the job.
Read and write as separate tools, ideally separate credentials. It makes approval rules simple.
Clear names and descriptions. The model chooses tools from their descriptions. "search_overdue_invoices(days_overdue)" beats "query(sql)".
Return what the model needs, not everything. A 40 KB JSON blob per call fills the context and degrades decisions.

When no server exists for an internal system, a small in-house MCP server with three or four narrow tools is usually a few days of work and reusable by every agent you build afterwards.

Step 5: Write the instructions

The system prompt is the agent's job description. Include the goal, the steps you expect, how to handle the known edge cases, the output format, and when to stop and ask. Write it like onboarding notes for a capable new colleague, with examples of good output.

Know-how that applies to several agents, such as your tone of voice, your invoice policy or how to read your CRM, is better packaged as skills: folders of instructions and scripts the agent loads only when relevant. Skills keep the base prompt short and let you update a procedure in one place.

Step 6: Add guardrails outside the model

A rule written only in the prompt is a request, and content the agent reads can argue it out of following it. Real guardrails live in the code or platform around the model:

Least privilege. The agent's credentials can do exactly what the job needs. A reminder agent reads invoices and creates drafts; it cannot change amounts or send payments.
Approval for irreversible actions. Sending an email, issuing a refund, deleting a record: a human approves until the log shows months of correct behaviour.
Isolate untrusted input. Emails, web pages and tickets can contain instructions aimed at your agent (prompt injection). Keep sessions that read untrusted content away from write tools. Our MCP security guide goes deeper.
Budgets and rate limits per agent and per user.
A complete log: who triggered the run, which model, every tool call with arguments and result, every approval. If you cannot answer "what did the agent do at 14:32?", you are not ready for production.

If you run more than one agent, these controls are easier to enforce once, centrally, than in every agent's code. That is the job of an MCP gateway.

Step 7: Evaluate before you trust it

Collect 20 to 50 real cases from history, including the awkward ones, with the correct outcome for each. Run the agent against them every time you change the model, the prompt, a tool or a skill. Score against the success criteria from step 1.

Check three things: did it reach the right outcome, did it take a sensible path (no unnecessary tool calls, no attempts at forbidden actions), and did it stop and ask when it should have. Once live, keep sampling real runs for review and add every failure you find to the test set.

Step 8: Choose how to build it

With the decisions above made, the build option mostly picks itself.

Use an existing agent. Claude, ChatGPT and Microsoft Copilot can be given tools and instructions, and coding agents such as Claude Code take tools through MCP and know-how through skills. Best when a person drives each run.

No-code and workflow builders. n8n, Copilot Studio and similar tools let you put an agent step inside a designed workflow. Good for back-office jobs with clear boundaries, and easy for non-developers to maintain.

Agent SDKs and frameworks. The Claude Agent SDK and the OpenAI Agents SDK provide a production-grade loop, tool handling and subagents for their vendors' models. Model-neutral frameworks such as LangGraph model the agent as an explicit graph of steps, which suits flows you want tightly controlled. Choose this route when the agent runs unattended or calls your own systems.

A managed or gateway-based agent. The agent runs behind a gateway that already holds the models, the MCP connections, the policies and the log. You write the job, tools and instructions; access, approvals, budgets and audit come from the platform. This is the route that scales when the second and third agents arrive.

Whatever you choose, the tools, instructions, skills and test set are portable. That is where your effort should go.

A worked example: the overdue-invoice agent

Job. Every weekday morning, find customer invoices more than 14 days overdue and draft a reminder for each.

Done. One draft per overdue invoice in an approval queue, with the correct invoice number, amount, due date and contact, written in the customer's language using the agreed tone. Invoices with an open dispute are flagged instead of drafted.

Tools. list_overdue_invoices and get_customer (read-only, accounting system), get_open_tickets (read-only, support system), create_draft (write, but only to the approval queue). No send tool at all.

Instructions. The reminder policy as a skill: first, second and final reminder wording, when to mention late fees, which customers have a named account manager who must be copied.

Guardrails. Read-only accounting credentials. The agent cannot send; a person reviews and sends from the queue. Run budget capped. Every run logged.

Evaluation. Thirty past invoices with known correct outcomes, including disputed ones, partial payments and customers who changed contact person.

Rollout. Two weeks where finance reviews every draft and logs corrections, then fixes to the skill, then a decision on whether first reminders for small amounts can be sent automatically.

Nothing in that example depends on a particular framework. Most of the work is in the tools, the policy skill and the test set.

Running agents in an EU company

Three questions come up in every European rollout.

Where does the data go? Each model call carries the prompt and whatever the tools returned: customer names, amounts, ticket text. Under GDPR, where that is processed and by whom needs to be settled with your DPO. Running models in an EU region and keeping tool traffic inside your own environment is the cleanest answer.

Does the AI Act apply? It depends on the use case, not on the fact that you used an agent. Most internal productivity agents fall outside the high-risk categories, while some uses, such as AI that screens job applicants or decides access to essential services, are listed as high-risk and carry real obligations. Map each agent's use case against the regulation, and get legal advice for anything near the high-risk list.

Who is accountable? Name an owner for each agent, as you would for any system with write access, and make sure the log can reconstruct what it did.

Where to go next

What is agentic AI?: the concepts behind this guide.
Model Context Protocol: the complete guide: how agents get tools.
Claude skills explained: how agents get know-how.
What is an MCP gateway?: one control point for many agents.
Claude Managed Agents: Anthropic's hosted harness, if you would rather not run the loop yourself.

If you want help building the first one, from the tools and the evaluation set to running it inside your own Azure tenant in the EU, see our custom solutions or the Walma AI Hub.