How to build an agent: a tested example in five steps

How to build an agent, in practice, comes down to four parts: a model that can call tools, the tools themselves, a loop that runs the tool calls and feeds the results back, and rules that stop the agent from doing damage. Anthropic, which has worked with "dozens of teams" building agents, says the most successful ones "weren't using complex frameworks or specialized libraries" but "simple, composable patterns", and that agents "are typically just LLMs using tools based on environmental feedback in a loop". This guide builds exactly that: a working support agent in about 60 lines of JavaScript with no dependencies, which runs against OpenAI, DeepSeek or a free local model, plus the guardrails, costs and decisions around it.

Step 1: decide whether you need an agent at all

Anthropic draws a line between two kinds of systems. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths"; agents are systems where the model "dynamically direct[s] its own processes and tool usage". Its advice is to find "the simplest solution possible" and notes that agentic systems "often trade latency and cost for better task performance". For many applications, it says, a single well-prompted model call with retrieval and examples "is usually enough".

A quick test before you build:

• The steps are always the same (summarize, then translate, then file): build a workflow, a fixed chain of calls. It is cheaper and easier to test.
• The steps depend on what the model finds (look up the customer, check the order, decide whether a refund applies): an agent makes sense.
• The task is open-ended and you cannot predict the number of steps: an agent, with a hard limit on steps and a person approving anything risky.

If you are not sure what counts as an agent, our explainer on what an agent is covers the definitions, and n8n vs Zapier vs Make compares the no-code route for workflows.

Step 2: pick a model and define the tools

Any model with tool calling (also called function calling) will do. OpenAI's documentation describes the flow in five steps: send the request with the tools the model may call, receive a tool call, run your own code with its arguments, send the result back, and receive a final answer "or more tool calls". The same message format is accepted by DeepSeek's API and, locally, by Ollama and llama.cpp, which is why the example below works with all of them.

Tools are where most of the quality comes from. OpenAI's guidance is to write "clear and detailed function names, parameter descriptions, and instructions", to use the system prompt to say when to use each one, and to "pass the intern test": could a person use the function correctly with nothing but its description? It recommends strict mode so that calls "reliably adhere to the function schema". Anthropic calls this the agent-computer interface and recommends crafting it "through thorough tool documentation and testing".

If your tools already exist as MCP servers (the open standard for connecting LLM applications to tools and data), your agent can use them through an MCP client instead of custom functions; see what MCP is.

Step 3: write the loop

The example is a support agent for a small shop with two tools: one finds a customer's orders, the other refunds an order. Save it as agent.mjs and run it with Node 18 or later; it needs no packages.

// agent.mjs: a minimal tool-using agent (Node 18 or later, no dependencies)
import readline from "node:readline/promises";

const BASE_URL = process.env.BASE_URL ?? "https://api.openai.com/v1";
const MODEL = process.env.MODEL ?? "gpt-6-luna";
const API_KEY = process.env.API_KEY ?? "";
const MAX_STEPS = 8;

// Stand-in for your real database
const orders = { "ana@example.com": [{ id: "A-1001", item: "Headphones", total: 79, status: "delivered", daysSinceDelivery: 9 }] };

const tools = [
  { type: "function", function: { name: "find_orders", description: "List a customer's orders by email address.",
    parameters: { type: "object", properties: { email: { type: "string" } }, required: ["email"], additionalProperties: false } } },
  { type: "function", function: { name: "refund_order", description: "Refund one order by id. Allowed only for delivered orders within 14 days; a person must approve it.",
    parameters: { type: "object", properties: { order_id: { type: "string" } }, required: ["order_id"], additionalProperties: false } } },
];

async function approve(question) {
  const rl = readline.createInterface({ input: process.stdin, output: process.stdout });
  const answer = await rl.question(`${question} [y/N] `);
  rl.close();
  return answer.trim().toLowerCase() === "y";
}

const run = {
  find_orders: ({ email }) => orders[email] ?? [],
  refund_order: async ({ order_id }) => {
    const order = Object.values(orders).flat().find((o) => o.id === order_id);
    // The rule lives in code, not only in the prompt
    if (!order || order.status !== "delivered" || order.daysSinceDelivery > 14) return { refused: "Not eligible under the refund policy." };
    return (await approve(`Refund ${order.id} (${order.total} EUR)?`)) ? { refunded: order.id } : { refused: "A person declined the refund." };
  },
};

async function chat(messages) {
  const res = await fetch(`${BASE_URL}/chat/completions`, {
    method: "POST",
    headers: { "Content-Type": "application/json", Authorization: `Bearer ${API_KEY}` },
    body: JSON.stringify({ model: MODEL, messages, tools }),
  });
  if (!res.ok) throw new Error(`${res.status} ${await res.text()}`);
  return (await res.json()).choices[0].message;
}

const messages = [
  { role: "system", content: "You are the support agent of a small shop. Use the tools and never invent order data. If a refund is refused, explain why." },
  { role: "user", content: process.argv[2] ?? "I'm ana@example.com and my headphones arrived broken. Can I get a refund?" },
];

for (let step = 1; step <= MAX_STEPS; step++) {
  const msg = await chat(messages);
  messages.push(msg);
  if (!msg.tool_calls?.length) {
    console.log(msg.content);
    process.exit(0);
  }
  for (const call of msg.tool_calls) {
    const args = JSON.parse(call.function.arguments || "{}");
    const tool = run[call.function.name];
    const result = tool ? await tool(args) : { error: `Unknown tool ${call.function.name}` };
    console.log(`[step ${step}] ${call.function.name}(${JSON.stringify(args)}) => ${JSON.stringify(result)}`);
    messages.push({ role: "tool", tool_call_id: call.id, content: JSON.stringify(result) });
  }
}
console.log(`Stopped after ${MAX_STEPS} steps without a final answer.`);

To run it, set API_KEY and run node agent.mjs. For DeepSeek, also set BASE_URL=https://api.deepseek.com and MODEL=deepseek-flash. For a free local test with Ollama, pull a model that supports tools, such as qwen3, and set BASE_URL=http://localhost:11434/v1 and MODEL=qwen3; our guide to running an LLM locally covers the setup.

How we tested it. We ran the file against a local test server that answers in the documented Chat Completions format: a scripted stand-in, not a real model. Four checks passed: the full path with a person approving the refund, a person declining it, an ineligible order refused by code before anyone is asked, and an unknown tool plus a model that never stops, cut off at 8 steps. With a real model the wording will vary, and small local models can call tools less reliably than large hosted ones.

Step 4: add guardrails before anything else

Anthropic warns that the autonomy of agents means "higher costs, and the potential for compounding errors", and recommends "extensive testing in sandboxed environments, along with the appropriate guardrails". The example builds in four of them:

1. A hard limit on steps. Anthropic suggests stopping conditions "such as a maximum number of iterations". Here it is 8.
2. Business rules in code. The 14-day refund rule is checked by the function, so a confused or manipulated model cannot talk its way past it.
3. A person approves irreversible actions. Nothing is refunded without a "y" at the keyboard; in production that becomes an approval in your back office.
4. Unknown tools are refused, and the model only gets the data its tools return.

Two risks from OWASP's 2025 Top 10 for LLM applications matter most here: prompt injection (LLM01), where text from a customer or a web page tries to give the model new instructions, and excessive agency (LLM06), where an agent has more permissions than the task needs. The defense is the same: give each tool the minimum permissions, and keep the rules and the approvals outside the model.

Step 5: test, measure the cost and only then add a framework

Evaluate on real cases. Collect 30 to 50 real requests, including awkward ones, and check the agent's final answer and the tools it called. Anthropic's summary is to "start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short".

Estimate the cost per conversation. Each step is a full model call, and every call resends the conversation so far. Suppose an average conversation takes three calls of about 1,000 input tokens and 100 output tokens each, and you handle 10,000 conversations a month: 30 million input tokens and 3 million output tokens. At list prices checked on October 10, 2026, that is about $4.50 a month on GPT-6 Luna or Claude Haiku 5.5, $12.60 on DeepSeek V4.1 Flash at peak hours and $90 on Claude Sonnet 5.5 or GPT-6.1 Sol, before reasoning tokens, which are billed as output. The detail per provider is in our LLM API pricing comparison and our guide to DeepSeek API pricing.

Add a framework when the loop gets crowded. Anthropic lists frameworks such as the Claude Agent SDK and AWS's Strands Agents, and warns that they "often create extra layers of abstraction" that make prompts and responses harder to debug; its advice is to start with the API directly and, if you adopt a framework, "ensure you understand the underlying code". OpenAI's Agents SDK has "a very small set of primitives": agents with instructions and tools, handoffs between agents, guardrails that validate inputs and outputs, and built-in tracing. Move to one of them when you need several agents, tracing or resumable runs, not to get the first one working.