How to Build an AI Agent That Works in Production (2026)

Most AI agents people are building right now are not agents. They are workflows pretending to be agents — and the confusion costs teams weeks of unnecessary engineering. Anthropic's December 2024 research note Building Effective Agents draws the line clearly: a workflow is a predefined LLM-and-tool chain where each step is decided in advance. An agent is a system where the LLM dynamically decides what to do next until the task is done. Workflows are simpler, cheaper, more reliable, and easier to debug. They are the right answer 80 percent of the time.

This guide covers what you actually need to build a production AI agent: the four components every agent has, real TypeScript code for each, the build vs buy decision framework that most teams skip, honest cost math at production scale, and the five failure modes that will appear in every production deployment if you do not plan for them upfront.

Everything in this guide assumes you have already determined you need a real agent — one where the LLM must dynamically decide between multiple tools based on what it discovers at runtime. If you are not certain that is what you need, read the workflow vs agent section first. Most teams who think they need an agent actually need a well-structured workflow with one or two LLM calls, which is dramatically easier to build, maintain, and debug.

The guide uses a customer support triage agent as the running example throughout — it is concrete enough to illustrate real decisions but general enough that the patterns apply across most agent use cases. All code is TypeScript using the Anthropic SDK, with notes on where GPT-4o or other model APIs differ.

Build or buy: be honest with yourself

Engineering time is the most expensive resource in any organisation. A senior developer at $200K fully loaded costs about $4,000 per week. A simple agent will take 2-4 weeks to build to MVP and another 4-8 weeks to harden for production. That is $24K-48K of engineering cost before maintenance, monitoring, and iteration. An off-the-shelf agent that solves 80% of your use case at $200/month pays for itself for a decade against that math.

Workflow or agent? The distinction that saves weeks

From Anthropic's research: workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents are systems where LLMs dynamically direct their own processes and tool usage. The implication is huge — if your problem can be solved with a fixed sequence of LLM calls and known tools, you do not need an agent. You need a workflow, which is dramatically simpler to build and maintain.

We'll use the second example — a customer support triage agent — as the running case throughout this guide.

The 4 components every agent has

Strip away the framework hype and every agent is just these four pieces. Get any one wrong and the whole thing fails.

Decision 1: Pick your model

Three serious contenders matter for production agents in 2026. Pricing below is per million tokens (input / output) as of mid-2026 — verify current rates before budgeting. The recommendation: start with the cheapest model that passes your evals. Most teams default to flagship models out of habit and burn 5x more than necessary.

Practical rule: build your eval set first, run it on the cheapest viable model, then upgrade only when you hit a wall. Most agent tasks do not need flagship reasoning.

Decision 2: Design your tools

Tools are what turn an LLM into an agent. The model needs three things to use a tool reliably: a clear name, a description that explains when to use it (not just what it does), and a strict input schema. Here's a real tool definition for our customer support agent — using Anthropic's tool use format, but the structure is similar across providers:

const tools = [
  {
    name: "lookup_order",
    description: "Look up a customer order by email or order ID. Use this when the customer asks about delivery status, items in their order, or refund eligibility.",
    input_schema: {
      type: "object",
      properties: {
        email: { type: "string", description: "Customer email" },
        order_id: { type: "string", description: "Order ID like ORD-12345" }
      },
      required: []
    }
  },
  {
    name: "check_shipping_status",
    description: "Get real-time shipping status from the carrier. Use AFTER lookup_order has confirmed the order exists and shipped.",
    input_schema: {
      type: "object",
      properties: {
        tracking_number: { type: "string" }
      },
      required: ["tracking_number"]
    }
  },
  {
    name: "escalate_to_human",
    description: "Hand off to a human agent. Use when the issue involves refunds over $500, account security, or the customer explicitly asks for a person.",
    input_schema: {
      type: "object",
      properties: {
        reason: { type: "string", description: "Why escalation is needed" },
        priority: { type: "string", enum: ["low", "medium", "high"] }
      },
      required: ["reason", "priority"]
    }
  }
]

Three tool design rules that matter:

• Descriptions explain when to use, not just what. — The model picks tools based on the description. "Look up order by email" is weak. "Use this when the customer asks about delivery status" tells the LLM the trigger.
• Fewer tools beats more tools. — Past 10-15 tools, models start choosing wrong. If you need more, group related ones into a single tool with an action parameter.
• Schemas should be strict and minimal. — Loose schemas create parameter hallucinations. Mark fields required only when truly required. Use enums for fixed value sets.

Decision 3: Memory

Memory has three tiers and most teams overbuild this. Use the simplest tier that meets your needs — vector DBs are not free.

Decision 4: The reasoning loop

The loop is where most agents fail. Here's the pattern that actually works in production — note the iteration cap, the schema validation, and the explicit error handling. Skip any of these and your agent will eventually hit a state that costs you real money:

async function runAgent(userMessage: string) {
  const messages = [{ role: "user", content: userMessage }]
  const MAX_ITERATIONS = 10
  let iterations = 0

  while (iterations < MAX_ITERATIONS) {
    const response = await anthropic.messages.create({
      model: "claude-haiku-4-5",
      max_tokens: 1024,
      tools,
      messages
    })

    // Agent finished — return the final message
    if (response.stop_reason === "end_turn") {
      return response
    }

    // Agent wants to call a tool
    if (response.stop_reason === "tool_use") {
      const toolUse = response.content.find(c => c.type === "tool_use")
      if (!toolUse) throw new Error("Expected tool_use block")

      // Validate the tool exists and params match schema
      const result = await executeToolSafely(toolUse.name, toolUse.input)

      // Append assistant turn + tool result, then loop
      messages.push({ role: "assistant", content: response.content })
      messages.push({
        role: "user",
        content: [{
          type: "tool_result",
          tool_use_id: toolUse.id,
          content: result
        }]
      })
    }

    iterations++
  }

  throw new Error("Agent exceeded max iterations — possible loop")
}

The 5 production failure modes

These will all happen to you. Plan for them on day one — bolting them on after launch is a much harder retrofit.

Cost math: what you'll actually pay

Here's a real calculation for our customer support triage agent at production scale. Assumptions: 1,000 tickets per day, average 3 tool calls per ticket, ~4,000 input tokens (system prompt + tool definitions + conversation context) and ~500 output tokens per LLM call.

Two things this calculation hides: prompt caching can cut input costs 70-90% if you reuse a stable system prompt, and context growth on long conversations can double these numbers if you don't implement summarisation. Budget conservatively — your real cost will be 1.5-2x your napkin math the first time.

Pre-deploy checklist

Before you put this in front of users, every box below should be ticked. Skipping any of these is how teams end up with $5K surprise bills or angry customers.

• ☐Hard iteration cap is set and tested.
• ☐Every tool input is validated against its schema before execution.
• ☐Per-session cost cap with hard-stop in place.
• ☐Cost and latency dashboards live before launch, not after.
• ☐Eval set of 50+ representative inputs runs on every code change.
• ☐Human-in-the-loop checkpoints for any irreversible action (refunds, sends, deletions).
• ☐Errors and tool failures are logged with full context for debugging.
• ☐Context summarisation kicks in before hitting model limits.
• ☐You've manually traced 10 representative runs end-to-end.
• ☐Rollback plan exists if production behaviour diverges from eval.

When you're done iterating

Agents are never "finished." But there's a point where further tuning has diminishing returns and you should stop touching it. You're done iterating when: your eval set passes consistently above your target threshold, the failure modes you see in production are the same as the failure modes you see in eval (no surprises), per-conversation cost is stable and predictable, and the agent can run unattended for a week without you needing to check on it.

Past that point, your time is better spent building the next agent than tuning this one.

Frequently Asked Questions

All agents listed are editorially reviewed by The AI Agent Index. See our editorial methodology. Pricing data verified mid-2026 — confirm current rates before budgeting.