How to Build an AI Agent in 2026: 7 Paths, Real Costs

The seven ways to build an AI agent today, what each one really costs per finished task, and how to pick the one you will not have to rebuild in six months

On October 27, Artificial Analysis showed that a single AI model now behaves like five different products: Claude Opus 5.5 scores 35 on the new Intelligence Index at low effort and 58 at max, while the cost of each index task rises tenfold, from $0.98 to $10.04 - Artificial Analysis. The setting that decides which of those products you get is one line in your agent's configuration, and an agent that never sets it simply runs at whatever default the vendor chose.

The tools for building agents moved just as fast that week. On October 21 Anthropic released API version 2026-10-21 together with new major versions of all its SDKs - Anthropic. On October 22 it handed the Agent Skills standard to the Agentic AI Foundation under the Linux Foundation, the same home as the Model Context Protocol - Anthropic. GitHub made Copilot Fusion generally available on October 28, a coding agent that asks for an effort level instead of a model - GitHub. Mistral published the weights of its 1-trillion-parameter Mistral Large 4 on October 29 - Mistral. And OpenAI confirmed that Agent Builder, its drag-and-drop canvas for building agents, shuts down on November 30 - OpenAI.

The problem is that most advice on how to build an AI agent starts with a tool. Pick a framework or a no-code canvas, follow its tutorial, and you have an agent by lunchtime. But the tool sits downstream of a more important decision: which parts of the agent you want to own and which you want to rent. That decision fixes your cost per task, your exposure to a vendor's roadmap (ask anyone with a workflow in Agent Builder this month), and how much engineering stands between a demo and something that runs unattended. The cost guides that rank for this question are mostly agency quotes for a build, where "simple rule-based agents start at $5,000" and enterprise systems "run $400,000 or more" - Radixweb. Those figures tell you what someone will charge to write the code, not what the agent costs to run.

This guide lays out the seven paths to a working agent in November 2026, from configuring one inside an assistant you already pay for to running open-weight models on your own GPUs. For each it gives the real prices, the code where code matters, and the trade-offs that only show up in production. It then works through what an agent task actually costs with the numbers that drive it, the build steps that apply on every path, how agents fail, and who is leading and rising. No technical background is assumed: where a section gets technical, the plain version comes first.

Contents

1. What an AI agent is, from first principles
2. What changed in October 2026
3. Path 1: configure an agent inside an assistant you already pay for
4. Path 2: build it in a no-code workflow tool
5. Path 3: write the loop yourself on a model API
6. Path 4: use a lab's agent SDK
7. Path 5: use an open-source agent framework
8. Path 6: run it on a managed agent runtime
9. Path 7: self-host open-weight models
10. What an agent really costs: the worked numbers
11. Seven steps that apply on every path
12. How agents fail, and the controls that stop it
13. Who leads, who is rising, and where this goes
14. How to choose your path: the decision framework

The seven paths at a glance

The table scores each path on the five things that decide whether an agent survives contact with real work, using the same evidence standard for every row and sorting by the weighted final score. Every cell carries the score and the fact behind it, so you can disagree with a judgment without having to rebuild the evidence. The weights describe an agent that does real, repeated work for a business. If you are building a personal assistant for yourself, the "skill needed" and "time to first agent" columns matter more than their weights suggest, and section 14 shows how the order changes.

How to read the criteria. Time to first agent (15%) is how quickly a competent person on that path gets something useful running. Cost per task at scale (25%) is what each finished task costs at thousands of tasks a month, all-in. Production readiness (25%) covers durability, logging, evaluation and security out of the box. Control and portability (20%) asks how much of the agent you could move to another model or vendor next quarter. Skill needed (15%) is scored inversely: a higher score means less specialist skill is required.

The order is not a recommendation for everyone, and the gaps are smaller than they look. The top three paths sit within half a point of each other because they are three packagings of the same idea (a developer-owned loop around a frontier model), and which one wins for you depends on whether you value control, speed or managed operations most. The bottom of the table is just as informative: the easiest path to start on and the path with the most control both score lowest, for opposite reasons. One is cheap to begin and expensive to grow out of, the other is expensive to begin and only pays at very large volume.

1. What an AI agent is, from first principles

Strip away the marketing and a language model is a function: text goes in, text comes out, and nothing is remembered between calls. That shape is perfect for answering a question and useless for doing a job, because a job has steps whose content you cannot know in advance. An AI agent is what you get when you put that function in a loop, let its output name an action, run the action, feed the result back in, and let the model decide when the goal is met. Everything that makes an agent useful, and everything that makes it expensive or dangerous, follows from that one change: the model now chooses what happens next, and it keeps choosing until it stops.

Five parts make up every agent, whatever it is built with. The model decides the next step. The harness runs the loop: it sends the context to the model, executes the actions the model asks for, catches errors, trims the context when it grows too large and decides when to stop. The tools are the actions available (an API call, a database query, a browser, a code sandbox, a file system). The context is everything the model sees on each turn: its instructions, the conversation so far, retrieved documents, memory from earlier sessions and packaged know-how such as skills. The guardrails are the limits around it: which tools need a human's approval, how much a run may spend, what gets logged and how quality is checked.

The diagram makes one thing plain that most tutorials skip: the seven paths in this guide are not seven kinds of agent. They are seven answers to the question "who supplies each of these five parts, and who pays for it?" When you configure an agent inside ChatGPT or Claude, the vendor supplies all five and you pay a seat. When you write the loop yourself on a raw model API, you supply four of them and rent only the model. Every path in between moves the line between "theirs" and "yours", and every move changes three things at once: how fast you can start, how much control you keep, and what each finished task costs. If you want the longer treatment of the harness specifically, our guide to agent harnesses shows why the same model can succeed on 68% or 88% of the same tasks depending on the harness around it.

1.1 Why the loop changes the economics

The loop is also where the money goes, and the mechanism is worth understanding before you look at a single price list. A model API has no memory, so on every turn the harness sends the whole context again: the instructions, the tool definitions, every earlier step and every tool result. If an agent starts with 10,000 tokens of instructions and adds 3,000 tokens per turn, the tenth turn sends 37,000 tokens and the fortieth sends 127,000. Add the turns up and total input grows with roughly the square of the run's length: a 40-turn run reads about 2.7 million input tokens, more than eleven times what a 10-turn run reads, not four times.

This is why the same model can cost cents on one task and dollars on the next, why prompt caching (re-reading an unchanged prefix at a fraction of the normal price) is the largest single cost lever an agent builder has, and why the effort setting, which decides how many tokens the model thinks with on every turn, now moves the bill as much as the choice of model does. Anthropic measured the multiplier on its own research system: its agents "typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats" - Anthropic. Section 10 puts real numbers on all of it. For now, hold the principle: an agent is priced per turn, and turns compound.

1.2 When you should not build an agent at all

The honest first step in any guide to building an AI agent is to ask whether you need one. If you can write the steps down in advance (read the invoice, extract five fields, write them to the spreadsheet, email the summary), you do not need a model deciding what happens next. You need a workflow: fixed code that calls a model only at the steps that need judgment. A workflow is cheaper because it never wanders, easier to test because the same input takes the same path, and easier to fix because a failure points to one step.

An agent earns its extra cost when the path genuinely cannot be known in advance: research where each finding decides the next search, a support case where the customer's answer changes what to check, a code change that depends on what the tests reveal. A useful test has four questions. Is the task multi-step and hard to specify in advance? Is the outcome worth a higher and less predictable cost? Can current models actually do this kind of work? And can a mistake be caught and undone before it does damage? If any answer is no, build the simpler thing first. Many agent projects that die in production die because they were agents doing a workflow's job, a pattern we traced in detail in our analysis of why most agent pilots never scale.

2. What changed in October 2026

A guide to building agents written in September is already partly wrong, and it is worth being precise about why. October did not bring one big launch. It brought a cluster of changes to the layers underneath an agent (the API contract, the SDKs, the standards for packaging skills, the way models are priced and chosen) that together shift the defaults on every path in this guide. If you built an agent before October, at least one of the changes below touches it; if you are building now, they decide what "the current way" looks like.

The common thread is that the agent stack is maturing from a pile of clever demos into infrastructure with versioned contracts, shared standards and deprecation schedules. That is good news for anyone who wants an agent to keep running for a year. It is also a warning: infrastructure has migration deadlines, and three of them fall on the same day this month.

2.1 Effort became the main dial

The most consequential change is conceptual. For two years, choosing a model was the decision that set an agent's quality and cost. In October the industry's main yardstick showed that the effort setting inside one model now moves results as much as switching between models. Artificial Analysis rebuilt its index on October 27 so that "60% of the Index is now based on evaluations with private test sets or held-out answers", and reported that "effort settings matter more in v5 than in v4.3" - Artificial Analysis. At low effort Claude Opus 5.5 lands at 34.5, below several cheaper models; at max it reaches 58.4 and costs $10.04 per index task - Artificial Analysis.

GitHub turned that idea into a product the next day. Copilot Fusion, generally available on October 28, asks the developer to pick Standard, High or Max effort and routes the work across models itself, billing "each model it uses, at each model's standard rate" - GitHub. GitHub claims Fusion Max scored 60 on its coding benchmark, "within two points of Claude Code with Opus 5.5 Max" at "about half the average API cost per task", a vendor figure worth testing on your own work rather than trusting.

The screenshot captures the shift in one menu: the developer no longer names a model, only how hard the work should be thought about. For anyone building an agent this has a direct consequence. Anthropic's own models now ship with five effort levels, and Claude Opus 5.5 and Claude Haiku 5.5 default to medium, one level below the high default of the models before them - Anthropic. An agent that never sets effort explicitly is running at whatever a vendor chose this quarter, and its cost and quality move when the default does.

2.2 The API contract and the standards moved

On October 21 Anthropic released API version 2026-10-21 and made it the default in a new major version of every SDK (Python 2.0.0, TypeScript 1.0.0, Go 2.0.0 and others, now under the Apache 2.0 license) - Anthropic. The breaking changes are small but sharp: on the new version, "a request that sends temperature, top_p, or top_k returns a 400 error, even at the parameter's default value", the SDK sends your key as a bearer token, and the tool runner's client-side compaction is "removed in favor of server-side compaction" - Anthropic. Any agent code copied from a 2025 tutorial that sets a temperature will fail the moment someone upgrades the SDK.

The standards layer consolidated at the same time. Anthropic donated Agent Skills (the format for packaging instructions, scripts and resources an agent loads when a task needs them) to the Agentic AI Foundation, reporting that "1 million skills have been published and nearly 280 million installed" across more than 70 agent platforms - Anthropic. The foundation added OpenAI's Open Responses, Hugging Face's OpenEnv and Alibaba's OpenSandbox in the same announcement, joining MCP, A2A and AGENTS.md for ten projects in total - AAIF. For a builder, this means the way you give an agent tools (MCP) and know-how (skills) is now vendor-neutral, which lowers the cost of switching paths later. We covered how to package one in our guide to shipping an agent skill across every AI coder.

Managed runtimes also learned to run teams. On October 9 Claude Managed Agents gained dynamic workflows, where "the agent can write a workflow", a program "that runs many agents in phases and combines their results" - Anthropic. A single run can keep 64 agents working at once and start up to 1,000 over its life, and "a run has no price of its own": you pay for the tokens every agent uses - Anthropic. That last sentence matters more than it looks, because fifteen-times token multipliers are exactly what multi-agent work produces.

2.3 Agents started being managed like staff

The third shift is organisational. Companies with agents in production have started to treat them less like software and more like workers who need identities, budgets and managers. SK Telecom announced in June that it would "assign employee identification numbers to artificial intelligence (AI) agents and manage them through processes similar to those for human employees, from onboarding to offboarding" - Asia Business Daily. Microsoft's Agent 365, a control plane for an organisation's agents, has been generally available since May at $15 per user per month - Microsoft, and Microsoft's Ignite conference runs November 17 to 20 - Moscone Center.

Two smaller October releases show where this is heading. On October 28 two OpenAI researchers published "The future of the firm", sketching AI placed beneath, beside and between people on the org chart, with the note that "It reflects our views, not those of OpenAI" - OpenAI. And on October 29 Anthropic shipped a Usage and Cost Analytics API that groups spend by "workspace, API key, model, service tier, or the identity that made each request", down to the individual Managed Agents session - Anthropic. When you can see what each agent costs per day, you can manage it like a budget line. When you cannot, you discover the cost on the invoice, which is how most agent cost surprises happen. Our guide to non-human identity for agents goes deeper on giving each agent its own scoped credentials.

2.4 Trust took hits, and deadlines arrived

Two attacks in October went after the tools agent builders install, not the agents themselves. On October 21, a malicious LiteLLM 1.107.0 (a popular library for calling many model providers through one interface) was live on PyPI from 11:39 to 13:23 UTC, carrying "compiled malware which steals credentials and loads remote-code execution tools" - LiteLLM. Microsoft's analysis found that "an application did not need to import LiteLLM for the payload to run", because it hid in Python's startup hooks - Microsoft. The root cause was mundane: an admin key committed to a public repository in May, used in October to take over a maintainer's account - LiteLLM.

Eight days later, Cursor's extension marketplace served "Anthropic.claude-code version 2.1.312 and 2.1.313 for Windows and MacOS", versions "not developed by Anthropic", for about eleven hours on October 29; the payload "added the attacker's SSH key, installed persistence, and sent host details to the attacker" - Cursor. BleepingComputer put the exposure at "up to 5,000 developers" - BleepingComputer. Both incidents teach the same thing: the machine where you build agents holds every key the agent will use, which makes agent tooling a prize worth poisoning. Pin dependency versions, install from the publisher's own registry, and keep production keys out of developer environments.

The deadlines are the part most likely to cost you money if you miss them, and an unusual number land on one day. On November 30, 2026, Claude Sonnet 4.5 is retired, so requests naming claude-sonnet-4-5-20250929 stop working - Anthropic; fast mode on Claude Opus 4.8 is removed, after which those requests "will return an error" - Anthropic; OpenAI's Agent Builder "is scheduled to shut down" - OpenAI; and Gemini 4 Argon's introductory price ends, after which "$4 per 1M input tokens and $20 per 1M output tokens will apply" - Google. An agent built on any of those four quietly breaks or doubles in price on December 1.

The lesson for choosing a path is structural, not a one-off. Every path that rents a part of the agent also rents that part's lifecycle: its versions, its prices and its end date. Agent Builder's users did nothing wrong; they built on a product whose vendor announced its retirement in June and set the shutdown for November, and the migration path OpenAI offers is to rebuild on the Agents SDK or move to ChatGPT Workspace Agents - OpenAI. Keep that cost in mind as you read the seven paths: the cheaper a path is to start, the more of its lifecycle someone else controls.

3. Path 1: configure an agent inside an assistant you already pay for

The fastest way to build an AI agent in 2026 is not to build one. Every major assistant now lets you describe a recurring job in plain language, connect it to your email, calendar, files and business tools, and let it run on a schedule or on request. The vendor supplies all five parts of the agent: the model, the harness, the tools (as connectors), the context (memory, projects, skills) and the guardrails. You supply the instructions and the access. For a single person or a small team automating their own work, this is often the right answer, and it is the one most technical guides skip.

The offers have converged on the same shape. Claude's paid plans let you "hand off and schedule tasks" and include Claude Code, with Pro at $20 a month, Max at $100 and Ultra at $200, the last now bundling $200 a month of API credits - Anthropic. ChatGPT's Pro plan includes "Dot, your always-on agent" - OpenAI, and its Business, Enterprise and Edu plans add Workspace Agents, which OpenAI now names as the destination for Agent Builder users - OpenAI. Microsoft builds agents into Copilot and governs them with Agent 365 at $15 per user per month - Microsoft. Our comparisons of personal AI agents and of OpenAI's workspace agents go through each one feature by feature.

3.1 What it costs, and why the price is shaped like that

A seat is a flat fee for variable work, and that single fact explains both the appeal and the ceiling of this path. Because you pay the same whether your agent runs twice a day or two hundred times, the vendor protects itself with usage limits: Claude's plans meter usage "every 5 hours and every week", and how fast you reach the limit "depends on the model you use, how long your chats are, and how large your files are" - Anthropic. In practice that means the seat price is the real cost only for as long as your agent stays small. When its work grows, you do not get a bigger bill; you get a wall.

The clearest sign of where this goes sits at the top of the same price list. Claude's Enterprise plan is now "Seat price + usage at API rates", at $20 per seat per month plus metered usage - Anthropic. Once agents do real volume inside an organisation, even the assistant-native path converges on the token pricing that every other path in this guide uses. A flat seat is a starter price, not a cost model.

3.2 Where it works and where it breaks

This path is strongest for work that belongs to one person or one team and tolerates a human glancing at the result: a morning briefing assembled from inboxes and dashboards, weekly competitor research, first drafts of reports, meeting preparation, triaging a shared inbox. The vendor handles the hard parts (sandboxing, connectors, memory), the setup takes minutes, and nothing needs to be hosted or patched. It also has the lowest abandonment cost: if the agent does not earn its keep, you stop using it.

It breaks in three predictable places. It cannot become part of your product, because customers cannot reach an agent that lives inside your employees' assistant. It gives you almost no control over effort, caching, model choice or logging, so you cannot tune cost per task or prove what the agent did. And it ties the agent to one vendor's app and roadmap. If what you actually want is the outcome rather than an agent you maintain, a further step in the same direction is to rent a whole operation instead of a single assistant: platforms such as O-mega build and run a set of agents that operate a business's day-to-day work, which trades even more control for even less setup. Whether that trade is right depends on how much of the agent's behaviour you need to own, the question every remaining path answers differently.

4. Path 2: build it in a no-code workflow tool

The second path keeps the convenience of Path 1 but gives you the steps. In a workflow tool you draw the process on a canvas: a trigger (a new email, a form, a schedule), a chain of nodes that call your apps, and, where a step needs judgment, an AI agent node with its own instructions and tools. The platform hosts it, retries failed steps and keeps a run history. You write no code, but you do design the logic, which is exactly the skill section 1.2 argued most automations need: they are mostly workflow with a little agent, and this path is built for that shape.

The category leader by developer attention is n8n, an automation platform whose open repository has 209,339 GitHub stars and which you can run on your own server under its "fair-code" Sustainable Use License - GitHub. Zapier brings its catalogue of app integrations to a dedicated Agents product, Microsoft Copilot Studio does the same inside Microsoft 365, Lindy sells agent-first automation, and the open-source Dify (160,217 stars) combines visual workflows with retrieval pipelines - GitHub. OpenAI's own entry, Agent Builder, is the cautionary tale of the category: it shuts down on November 30, 2026.

4.1 The billing unit decides what an agent loop costs

Every tool in this category prices a different unit, and the unit matters more than the headline price because it decides how an agent's loop is counted. n8n bills workflow executions, and says so plainly: "Pricing is based on monthly workflow executions, regardless of complexity" - n8n. Zapier's agents bill activities, where each trigger, action, web search, browse or knowledge lookup counts as one, capped at 40 per run on the Pro plan - Zapier. Lindy and Copilot Studio sell credits that bundle the AI usage into their own unit.

The table hides a rule worth stating outright. Per-execution pricing favours long agent loops; per-step pricing favours short ones. A 30-step agent run is one execution on n8n (with tokens billed separately by whichever model provider you connect), about 30 activities on Zapier, and however many credits Lindy's meter assigns it ("everyday asks" run 2 to 250 credits). If your agent will think in many small steps, a per-execution tool with your own model key is usually the cheapest place to run it. If it does a few big steps and you would rather not manage a model account at all, a bundled-credit tool is simpler to budget, at a markup on the underlying tokens.

Microsoft's own walkthrough of Copilot Studio's October release shows the current state of the art on this path, covering automated agents, workflows and apps in one release, and is a fair picture of how far no-code agents have come.

4.2 Where no-code agents break

The weakness of this path appears as the logic grows. A canvas that is clear at ten nodes becomes hard to reason about at sixty, especially when branches, loops and error handlers multiply, and most tools offer weaker versioning, testing and code review than a developer would expect from code. The agent node itself is also a black box with fewer controls than an SDK exposes: effort, caching and context trimming are often not settings you can reach.

The second weakness is lifecycle, and Agent Builder made it concrete. A workflow lives in the vendor's format; if the vendor retires the product, changes the unit price or caps your plan, moving means rebuilding. Self-hostable tools such as n8n and Dify reduce that risk, because the software keeps running on your server whatever the vendor decides. For a deeper look at the leading option, see our practical guide to n8n and our analysis of agentic process automation as the successor to RPA.

5. Path 3: write the loop yourself on a model API

This is the path every other path is built on, and it is smaller than most people expect. A working agent on a raw model API is a list of tool definitions, a function that runs the tools, and a loop that keeps calling the model until it stops asking for tools. There is no framework to learn and no platform fee: you pay the model provider per token and you host a small program anywhere. The trade is that every part of the harness that frameworks and platforms give you (durable sessions, retries, context trimming, sandboxes, tracing, approvals) is yours to write, test and maintain.

The reason to start here, even if you end up elsewhere, is that it teaches you what the other paths are hiding. Once you have watched your own loop re-send a growing context on every turn, the price of a managed runtime or the design of a framework stops being abstract. Anthropic's documentation draws the line clearly: its SDK's tool runner "handles the agentic loop, error wrapping, and type safety so you don't have to", and when "you need human-in-the-loop approval, custom logging, or conditional execution", you write the loop yourself - Anthropic.

5.1 A complete agent in about 50 lines

The example below is a refund-handling agent with two tools: one that reads an order and one that issues a refund, gated behind a human approval. It uses Anthropic's Python SDK on the current API version (2026-10-21), and every parameter reflects that version: effort is set explicitly because Claude Opus 5.5 defaults to medium, there is no temperature because the new version rejects it, and caching is switched on at the top level so each turn re-reads the unchanged prefix at a fraction of the price.

Install the SDK and set your key:

pip install anthropic          # 2.x is the default since October 21, 2026
export ANTHROPIC_API_KEY=...   # from the Claude Console

The agent itself:

import json
import anthropic

client = anthropic.Anthropic()

tools = [
    {
        "name": "get_order",
        "description": "Look up an order by ID. Returns status, amount and items.",
        "input_schema": {
            "type": "object",
            "properties": {"order_id": {"type": "string"}},
            "required": ["order_id"],
            "additionalProperties": False,
        },
        "strict": True,
    },
    {
        "name": "issue_refund",
        "description": "Refund an order. Call only after checking the order.",
        "input_schema": {
            "type": "object",
            "properties": {"order_id": {"type": "string"}, "amount": {"type": "number"}},
            "required": ["order_id", "amount"],
            "additionalProperties": False,
        },
        "strict": True,
    },
]

def run_tool(name: str, args: dict) -> str:
    if name == "get_order":
        return json.dumps(lookup_order(args ["order_id"]))       # your database
    if name == "issue_refund":
        if not human_approves(args):                              # the guardrail
            return "A human declined this refund."
        return json.dumps(refund(args ["order_id"], args ["amount"]))
    return f"Unknown tool: {name}"

messages = [{"role": "user", "content": "Order A-1042 arrived broken. Sort it out."}]

for turn in range(20):                                            # a hard stop
    response = client.messages.create(
        model="claude-opus-5-5",
        max_tokens=16000,
        system="You resolve order problems. Check the order before acting.",
        tools=tools,
        output_config={"effort": "medium"},
        cache_control={"type": "ephemeral"},
        messages=messages,
    )
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason != "tool_use":
        break
    messages.append({"role": "user", "content": [
        {"type": "tool_result", "tool_use_id": b.id, "content": run_tool(b.name, b.input)}
        for b in response.content if b.type == "tool_use"
    ]})

print("".join(b.text for b in response.content if b.type == "text"))

Read the loop once and the whole idea of an agent becomes concrete. The model receives the task, the tool definitions and everything so far; if it wants to act, it returns tool_use blocks instead of an answer; your code runs those tools and sends the results back as the next message; and the loop ends when the model answers without asking for a tool. The strict flag makes the API guarantee that the model's tool arguments match your schema, the 20-turn cap stops a confused run from looping forever, and the refund tool shows the most important pattern in agent design: the dangerous action checks with a human inside the tool, so no amount of clever text in a customer's message can skip the check.

Swapping the model is one line, which is this path's quiet superpower. The same loop runs on Claude Haiku 5.5, at $0.10 per million input tokens, for simple triage, or on Claude Opus 5.5 for hard cases, and with small changes to the message format it runs on OpenAI's or Google's APIs. Every other path in this guide adds convenience on top of this loop, and every one of them also adds a layer you can no longer see into.

5.2 What it costs

The bill on this path has two lines, and one of them barely registers. The first is tokens: Claude Opus 5.5 lists at $4 per million input tokens and $20 per million output, and OpenAI's GPT-6.1 Sol at $2 and $10. Hosted tools add their own fees: Anthropic charges "$10 USD per 1,000 searches, plus standard token costs" for web search and "$0.05 USD per hour, per container" for code execution beyond 1,550 free hours a month - Anthropic, and OpenAI's web search is "$10.00 / 1k calls" plus search content tokens - OpenAI.

The second line is hosting, and it is small. Anthropic's own guidance for hosting agents puts it bluntly: "Anthropic token cost typically dominates container infrastructure cost by an order of magnitude or more. A minimally provisioned container runs roughly $0.05 per hour" - Anthropic. If your agent needs an isolated sandbox for running code, providers such as E2B bill per second, about $0.000014 per vCPU per second, which works out to roughly $0.17 an hour for the default two-vCPU, 4 GiB machine - E2B. Section 10 works through a full month on these numbers.

5.3 What you will have to build yourself

The fifty lines above are a demo, not a production agent, and it is worth being explicit about the gap, because closing it is where the weeks go. A production agent needs durable state so a crash at turn 30 does not restart the task from zero, context management so a long run does not overflow the window or pay to re-read stale tool output, observability so you can replay any run and see which step went wrong, an evaluation set so you know whether a prompt change helped, and isolation for any tool that executes code or touches the web. None of that is exotic, and Anthropic now does part of it on the server (its compaction summarises old context automatically, with a trigger that "must be at least 50,000 tokens" - Anthropic), but each piece is code you own.

That is the honest trade of Path 3. You get the lowest cost per task and total control over every token, and you pay for it in engineering time and in the risk that your homemade harness is worse than the ones the labs tune every week. Teams that pick it usually have a reason: a regulated environment, an unusual control flow, or an agent so central to the product that its loop is the product. For everyone else it is the best place to learn and the worst place to stay without a plan for those five gaps. Our guides to context engineering and agent observability tools cover two of them in depth.

6. Path 4: use a lab's agent SDK

An agent SDK is the harness from Path 3, written and tuned by the lab that trains the model, and packaged as a library you run on your own infrastructure. Instead of writing the loop, the tools, the context trimming and the permission checks, you import them. The most complete example is Anthropic's Claude Agent SDK, which "gives you the same tools, agent loop, and context management that power Claude Code, programmable in Python and TypeScript" - Anthropic. It ships built-in tools for reading, writing and editing files, running shell commands and searching the web, plus hooks, subagents, MCP connections, permissions, sessions and skills. The current releases are 0.2.176 for Python and 0.3.316 for TypeScript, both published on October 31 - PyPI.

The other labs offer the same idea with different emphases. OpenAI's Agents SDK (Python package openai-agents 0.24.0, released October 15) gained "support for sandbox agents and an open-source harness built in" in May - OpenAI. Google's Agent Development Kit is "available in Python, TypeScript, Go, Java, and Kotlin" - Google, with Python release 2.13.0 published October 23 - PyPI. AWS maintains Strands Agents, at version 1.63.0 as of October 30 - PyPI. All four are free to use and run on your own infrastructure; you pay only for the model and wherever you run them.

The diagram is the same loop as the one you wrote by hand in Path 3, and that is the point. What the SDK adds is everything around the loop that the Claude Code team tuned on production traffic: how to compact a long session, when to spawn a subagent so the main context stays clean, how to ask permission before an edit, and how to resume a session tomorrow. You inherit those decisions instead of rediscovering them.

6.1 A working agent in about 20 lines

The example below is lightly adapted from Anthropic's quickstart. It gives an agent read, edit and file-search tools, lets it apply edits without asking, and asks it to find and fix crash bugs in a file. Everything else (the loop, the tool execution, the context management, the stopping condition) happens inside query.

pip install claude-agent-sdk     # Python 3.10+; bundles a native Claude Code binary
export ANTHROPIC_API_KEY=...

import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, ResultMessage

async def main():
    async for message in query(
        prompt="Review utils.py for bugs that would cause crashes. Fix any issues you find.",
        options=ClaudeAgentOptions(
            allowed_tools= ["Read", "Edit", "Glob"],   # auto-approve these tools
            permission_mode="acceptEdits",            # apply file edits without asking
        ),
    ):
        if isinstance(message, ResultMessage):
            print(f"Done: {message.subtype}, estimated cost ${message.total_cost_usd:.4f}")

asyncio.run(main())

Two details in this snippet carry more weight than their length suggests. The allowed_tools list is the agent's permission boundary: anything not on it either needs approval or is unavailable, which is how you stop a file-fixing agent from also deciding to run shell commands. And total_cost_usd gives you a per-run cost estimate, with Anthropic's caveat that these fields "are client-side estimates, not authoritative billing data" - Anthropic. Log that number for every run from day one; it is the cheapest observability you will ever add.

6.2 What it costs, and the licensing catch

The SDK itself has no fee, so the bill is tokens plus wherever you host it. Anthropic's hosting guidance suggests that "1 GiB RAM, 5 GiB disk, and 1 CPU per agent is a reasonable starting point" and repeats that token costs dominate the container by "an order of magnitude or more" - Anthropic. A thousand ten-minute runs a month need about 167 container-hours, roughly $8 at $0.05 an hour, next to hundreds of dollars of tokens.

The catch is on the billing side, not the price side. You authenticate with an API key or a cloud provider account, and Anthropic states that "unless previously approved, Anthropic does not allow third party developers to offer claude.ai login or rate limits for their products, including agents built on the Claude Agent SDK" - Anthropic. In plain terms: you cannot build a product for other people that runs on your own Claude subscription. The subscription is for your own use (Path 1); a product pays per token (Paths 3 to 6).

6.3 When an SDK is the right choice

An SDK fits best when the agent's work looks like the work the lab built it for. Coding, file manipulation, research across documents and anything that benefits from a shell are where the Claude Agent SDK shines, because that is what Claude Code does all day. OpenAI's SDK puts more weight on orchestration and handoffs between agents - OpenAI, and Google's ADK on workflows of several agents across its cloud. The common limit is that each SDK is tuned first for its own lab's models and conventions, so the SDK you pick quietly becomes a vote for a model family. If you expect to switch models often, a framework (Path 5) keeps that door wider. Our Claude Agent SDK deep dive and our analysis of when subagents pay off go further into both questions.

7. Path 5: use an open-source agent framework

A framework is a library for building your own harness without starting from an empty file. Where an SDK (Path 4) hands you one lab's finished loop, a framework hands you the building blocks (agents, tools, state, memory, graphs of steps, human approvals) and lets you assemble them around any model. That model freedom is the main reason teams choose this path: the same agent can run on Claude for hard cases, on a cheap model for routine ones and on an open-weight model in a region that requires it, and switching is a configuration change rather than a rewrite.

The price of that freedom is structure you have to learn. Every framework has an opinion about how an agent should be organised: as a graph of steps with saved state (LangGraph), as a crew of role-playing agents (CrewAI), as typed functions with validated outputs (Pydantic AI), as TypeScript workflows (Mastra), or as the merged successor of two Microsoft projects (Microsoft Agent Framework). Picking the framework whose opinion matches your problem saves weeks; picking one that fights it costs them.

7.1 The frameworks that matter in November 2026

The table below gives each framework's GitHub traction, latest release and license as read from GitHub on November 2, with the one-line description its own maintainers use. Stars measure attention rather than quality, but release dates tell you something stars do not: whether anyone is still shipping.

Two facts sit behind the table. Microsoft's framework reached version 1.0 in April, described as "the production-ready release" - Microsoft, and Microsoft calls it "the direct successor" to Semantic Kernel and AutoGen, "created by the same teams" - Microsoft. If you are still on AutoGen, that is your migration path. And LlamaIndex, once a default for document agents, last released in September, while Hugging Face's smolagents has not released since May: frameworks age quickly, and a stalled one is a migration you will eventually pay for. Our comparison of LangGraph, CrewAI and AutoGen covers the architectural differences in depth.

7.2 The harness wave: why developers now start from a finished agent

The more striking story is in the projects that are not frameworks at all. Ranked by GitHub stars, the most-watched open agent projects in November 2026 are harnesses, finished agents you configure rather than assemble: OpenClaw at 393,689 stars, DeepSeek's DeepSeek Harness at 268,967 (a repository created only in August), and Nous Research's Hermes Agent at 259,640. The biggest framework in the chart below has a fraction of their attention.

The reasoning behind the shift is first-principles economics. A framework saves you from writing a harness; a harness saves you from designing one. As models got good enough that a well-tuned general harness handles most tasks, the expensive part of building an agent stopped being the loop and became the judgment encoded in it (when to compact, when to spawn a helper, when to ask). Harnesses package that judgment, and skills and MCP servers let you specialise them without forking. The trade is maturity: DeepSeek's README warns that the project is "in developer preview" and that "THERE WILL BE COMPATIBILITY-BREAKING CHANGES" - GitHub. Our head-to-head of Hermes Agent and OpenClaw shows what the leading two do differently.

7.3 What a framework agent looks like, and what it costs

The snippet below uses LangChain's create_agent, which its documentation calls "a highly configurable harness" and which keeps the agent's state in LangGraph - LangChain. It follows the shape of the official quickstart. The model is a single string, which is the whole argument for this path in one line: change it, and the same agent runs on another lab's model.

from langchain.agents import create_agent

def get_order(order_id: str) -> str:
    """Look up an order by ID and return its status."""
    return lookup_order(order_id)          # your database

agent = create_agent(
    model="anthropic:claude-sonnet-5-5",   # or "openai:gpt-6.1-sol"
    tools= [get_order],
    system_prompt="You resolve order problems. Check the order before acting.",
)

result = agent.invoke({"messages": [{"role": "user", "content": "Where is order A-1042?"}]})
print(result ["messages"][-1].content)

The libraries are free, so the cost is tokens, hosting and, usually, a tracing service. LangChain's LangSmith offers a free Developer seat with up to 5,000 traces a month and a Plus plan at $39 per seat per month with 10,000, with additional traces billed at 0.005 of a $1.00 unit each, or $5 per 1,000 - LangChain. CrewAI's hosted platform has a free tier of 50 workflow executions a month and custom enterprise pricing above that - CrewAI. For most teams the tracing bill stays well below the token bill, but it is the line that grows fastest when an agent runs often, because every run produces a trace whether it succeeds or not.

8. Path 6: run it on a managed agent runtime

A managed agent runtime takes the harness from Path 4 and also runs it for you: the loop executes on the vendor's servers, each session gets its own sandbox for code and files, the conversation state survives a crash, and you talk to it through an API. This is the newest path and the one that moved most in 2026. Anthropic launched Claude Managed Agents in April as a "pre-built, configurable agent harness that runs in managed infrastructure" - Anthropic. OpenAI released its Agents API in public beta on September 10, letting developers "build agents with a managed Codex harness while OpenAI handles session orchestration, context compaction, and recovery" - OpenAI. AWS and Google offer the same layer with more model and framework freedom.

The structural reason this path exists is the one Path 3 made visible: an agent is a long-running process, not a request, and long-running processes need state, isolation and recovery that a plain API was never designed to provide. Managed runtimes sell exactly that missing layer. OpenAI's launch video walks through it end to end, building an incident-investigation agent that connects to tools over MCP, and it is the clearest explanation of what a "managed harness" means in practice.

The architecture in that demo is the same across vendors, and OpenAI's documentation draws it in one picture: your application starts sessions and shows output, the vendor runs the harness, and the harness calls into a sandbox where commands and files live.

Everything inside the dashed box in that diagram is code you no longer write, host or wake up at night for. The parts outside it (your application, your tools, your instructions and your evaluation of the results) remain yours, and they are still where most of an agent's quality comes from.

8.1 The four main runtimes and what they charge

The runtimes split into two camps. Lab runtimes (Anthropic's and OpenAI's) bundle the lab's own harness and models; cloud runtimes (AWS's and Google's) host whatever framework and model you bring. The prices are published, granular and, for the first time, comparable, so they are worth laying side by side.

Read the table from first principles and one pattern dominates: runtime fees are cents per hour, and tokens are dollars per task. Anthropic's own worked example on its pricing page prices a one-hour Opus 5.5 session at $0.58, falling to $0.428 with caching, of which the runtime fee is only eight cents - Anthropic. The choice between runtimes is therefore rarely about the runtime fee. It is about which models you can use, whether the harness is the lab's own, and how deeply the runtime ties you to one cloud. Microsoft fills the same slot with Foundry Agent Service, which charges "no additional charge for creating or running Foundry-native agents" and bills tools such as web search at $14 per 1,000 transactions - Microsoft.

8.2 Where managed runtimes win, and what they cost you in control

Managed runtimes win wherever an agent has to run for a long time, unattended, on work that touches code or files: data analysis, document processing, research sweeps, maintenance jobs, anything you would otherwise run on a server you would have to babysit. They also win when security review is the bottleneck, because a vendor sandbox with credential vaults and audit logs is easier to approve than a homemade one. Anthropic's runtime now keeps secrets in vaults: the sandbox holds only a placeholder, it is "substituted with the real secret at egress", and "the agent never sees the secret value" - Anthropic. That removes one of the most common ways agents leak credentials.

The cost is control, in two forms. Lab runtimes lock the harness and model together: a Claude Managed Agents session runs Claude, an Agents API session runs OpenAI's models. And all four runtimes are betas or young products whose prices and limits are still moving; Claude Managed Agents is "not eligible for Zero Data Retention or HIPAA", for example, which rules it out for some regulated work - Anthropic. Our guides to Claude Managed Agents, OpenAI's Agents API and the enterprise agent platforms compare them in depth.

9. Path 7: self-host open-weight models

The last path removes the final rented part: the model itself. You download open weights, run them on GPUs you rent or own, and put a harness from Path 4 or Path 5 (or an open one such as Hermes Agent or OpenClaw) on top. Nothing leaves your infrastructure, no provider can retire your model on November 30, and no price list changes under you. This is the only path where your cost does not depend on how many tokens your agent uses, because you pay for hardware hours whether the GPUs are busy or idle.

October made this path more serious than it has been. Mistral released the weights of Mistral Large 4, "a 1 trillion-parameter natively multimodal Mixture-of-Experts model with 49 billion active parameters per token", with 128 experts and a 1-million-token context - Hugging Face. The license is a modified MIT that is "free to use, modify, fine-tune, and commercialize", with one condition: companies offering it as a hosted model service need a separate commercial license - Mistral. The release drew 1,719 points on Hacker News - Hacker News, a measure of how much developers want a frontier-scale model they can own.

9.1 What it really costs to run a trillion-parameter model

A trillion parameters is a hardware question before it is an AI question. The FP8 checkpoint is about 1.06 TB and the compressed NVFP4 version about 610 GB, and vLLM validated the model on 8x B300, 8x B200 (NVFP4) and two nodes of 8x H200 - vLLM. On Lambda's public price list an 8-GPU B200 machine costs $6.69 per GPU-hour on demand - Lambda. Running one around the clock is 8 GPUs × $6.69 × 730 hours, about $39,000 a month, before a single agent task and before the engineers who keep it running.

Compare that with renting the same model by the token. Mistral Large 4 lists at $0.70 per million input tokens and $2.10 per million output. On the reference agent task used in section 10 (15 turns, with caching), that is about $0.10 per task, so the self-hosted node only breaks even at roughly 400,000 tasks a month, around 13,000 a day, every day. Below that, you are paying for idle GPUs. It is also worth knowing what you are buying: on the Artificial Analysis index, Mistral Large 4 scores 26, and "it costs $2.06 per task to evaluate" - Artificial Analysis, well below the closed frontier, because owning a model and having the best model are different goals.

9.2 When self-hosting is the right call anyway

The numbers say self-hosting a frontier-size model rarely wins on cost, but cost is not the only reason teams take this path. It is the right answer when data cannot leave your infrastructure (some health, defence, financial and government work), when you need to fine-tune a model on your own data and serve the result, when the agent must run offline or at the edge, or when your volume is so high and so steady that the GPUs never sit idle. It is also the only path immune to a vendor's lifecycle decisions, which, after this month's deadlines, is worth more than it was in September.

The pragmatic middle is to self-host a smaller open model for the bulk of simple steps and send hard steps to a frontier API, a pattern we priced in our guide to model routing. Smaller open models have become surprisingly capable for agent work on a single card, as our test of running an agent on one 24 GB GPU showed, and our ranking of open-source LLMs covers the rest of the field.

10. What an agent really costs: the worked numbers

Every path above quotes prices in different units (seats, executions, activities, credits, session-hours, GPU-hours), which makes them almost impossible to compare by reading price pages. The way through is to fix one realistic agent task, price it from first principles, and then add each path's platform costs on top. Doing that reveals the most useful fact in this guide: for most paths, the platform you choose changes the monthly bill by a few percent, while the model, the effort setting and caching change it by ten times or more.

This matters because cost, not capability, is what quietly ends agent projects. McKinsey's 2026 survey found that "about 20 percent of respondents report that AI-related operating costs (including token costs) constrained their AI use", and its senior fellow Michael Chui put the mechanism plainly: "Even as per-token costs have declined, the number of tokens consumed and generated has increased even faster" - McKinsey. Agents are where that second effect lives.

10.1 One reference task, priced on six models

Take a typical working agent: it starts with 10,000 tokens of instructions and tool definitions, takes 15 turns, adds 3,000 tokens of tool results and reasoning per turn, and writes 1,000 output tokens per turn. Over the whole task it reads 465,000 input tokens and writes 15,000. With prompt caching, each turn re-reads the previous context from the cache and writes only its new tokens: on Anthropic's models a five-minute cache write costs 1.25 times the input price and a cache read on Claude Opus 5.5 or Sonnet 5.5 costs 0.05 times - Anthropic; on the others we use each model's listed cached-input price.

Two conclusions fall out of the chart. First, caching cuts this task's cost by 66% to 73% on every model, a bigger saving than dropping from Claude Opus 5.5 to Claude Sonnet 5.5, which halves the price. An agent that does not cache is paying three times what it needs to, and on the API paths caching is one parameter. Second, at equal token counts the spread between models is enormous: a thousand of these tasks a month costs about $643 on Claude Opus 5.5 ($4 input), $295 on GPT-6.1 Sol, $148 on GPT-6.1 Terra ($1 input) and $18 on Claude Haiku 5.5. Our guide to prompt caching for agents shows how to keep the cache from silently breaking.

10.2 Why longer runs cost disproportionately more

The reference task has 15 turns, but real runs vary, and the cost does not scale in proportion. Because every turn re-sends everything before it, input cost grows with roughly the square of the number of turns. The chart below prices only the input side of the same agent on Claude Opus 5.5 as the run gets longer.

Without caching, a 40-turn run costs $10.96 in input alone, nearly twelve times a 10-turn run. With caching the curve flattens to $1.16, because re-reading old context becomes cheap and only new tokens pay full price. This is also why turn caps and context trimming are cost controls, not only reliability controls: the turns at the end of a long run are the most expensive ones, and they are often the ones where a confused agent is going in circles.

10.3 Equal token counts are a fiction: measured cost per task

The worked example assumes every model uses the same number of tokens, and in reality they do not. Models differ in how much they think, how many turns they take and how verbose they are, and effort multiplies all three. Artificial Analysis now measures the real cost per task at each effort level, and the result is the most useful price chart in the industry right now.

Read the chart with the scores beside it. At low effort, Claude Opus 5.5 and GPT-6.1 Sol both score 34.5 on the index, but Opus costs $0.98 per task and Sol $0.16. At max, Opus reaches 58.4 and Sol 54.5, and Artificial Analysis notes that Sol "scores within 4 points of Claude Opus 5.5 (max) at about an eighth of the cost per task" - Artificial Analysis. Going from xhigh to max on Opus buys 1.4 points for 66% more money. The practical rule: set effort per step, keep low and medium for routine steps, and pay for max only where a measured quality gap justifies it.

The same lesson shows up on a different benchmark with a twist. On the Vals Index, Claude Haiku 5.5 costs $3.17 per test and GPT-6.1 Sol $3.61, even though Haiku's tokens are twenty times cheaper - Vals AI. Cheap tokens do not guarantee a cheap task when a smaller model needs more tokens and turns to finish. Judge models by cost per task on your own work, never by price per token.

10.4 The monthly bill on each path

Now add the platforms. Assume 1,000 tasks a month like the reference task, each keeping a sandbox or session busy for about ten minutes (167 hours a month), on Claude Sonnet 5.5 tokens with caching (about $321). The table adds each path's own costs, using the prices verified earlier in this guide.

Across Paths 2 to 6 the platform line moves the total by 2% to 15%. Switching the same workload from Sonnet 5.5 to Haiku 5.5, or turning caching off, moves it by 3x to 18x. So choose your path for control, speed and operations, and manage cost with the model, the effort setting, caching and turn limits. The one path where that rule inverts is self-hosting, where the hardware is the whole bill and volume is the only thing that brings it down. The cost line this table leaves out is the largest one at the start: the people building, evaluating and supervising the agent, which is why the steps in the next section matter more than any price. Our complete cost-cutting guide and cheapest LLM APIs for agents go further on the token side.

11. Seven steps that apply on every path

Whichever path you choose, the work that decides whether the agent succeeds is the same, and very little of it is code. The steps below are ordered the way they should be done, which is not the order most first projects follow: most teams start with the model and the tools and end with evaluation, if they get there at all. Reversing that order is the single biggest difference between agents that reach production and agents that stay demos.

The data backs this up. In LangChain's survey of 1,340 practitioners, 57.3% now have agents in production, yet "quality is the production killer, with 32% citing it as a top barrier", and while 89% have observability in place, only 52.4% run offline evaluations - LangChain. Teams can see what their agents do, but half of them cannot tell whether a change made the agent better or worse.

11.1 Write the job as an outcome with a definition of done

Start with one sentence that names the outcome, not the activity: "every refund request under $200 is resolved within an hour, with the customer told why", not "an agent that handles refunds". Then write down what done looks like for a single task, specifically enough that a stranger could grade it: which fields must be filled, which systems must be updated, what the customer must receive. This is the brief the agent will work to, and it is also the grading rubric for step two.

Most failed agents fail here, quietly. A vague job produces an agent whose output is never clearly wrong, so it is never clearly fixed, and the project drifts until someone asks what it is for. The outcome sentence also answers section 1.2's question (should this be an agent at all?): if you can list the steps to reach the outcome, build a workflow; if the steps depend on what the agent discovers, build an agent.

11.2 Build the evaluation set before the agent

Collect 20 to 50 real examples of the task, with the correct outcome for each, before you write a prompt. Use real historical cases where you can, including the awkward ones, because the awkward cases are where agents fail. Decide how each will be graded: an exact check where possible (the refund amount, the record updated), a rubric scored by a model where judgment is needed, and a human review of a sample either way.

This set is the most valuable asset in the project, more than the prompt or the code, because it outlives every model and every path. When a new model ships, you rerun it. When you change effort from high to medium, you rerun it. When a vendor retires your platform, it tells you whether the replacement is as good. Our guide to agent evals and benchmarks covers how the public benchmarks do it and what to borrow.

11.3 Start with one agent and the simplest path that could work

Begin with a single agent on the lowest-effort path that can plausibly do the job, and resist the pull toward a team of agents. Multi-agent systems are genuinely more capable on wide research tasks, but they use about 15 times the tokens of a chat - Anthropic, and most tasks are not wide enough to repay that. Split into subagents only when one agent's context fills up with reading it does not need to keep, which is a measurable condition rather than an architectural preference.

The same logic applies to paths. If a no-code tool or an assistant-native agent can pass your evaluation set, ship that and learn from real use; you can move down the table later with the eval set telling you whether the move helped. Teams that start on Path 3 or 5 for a task Path 2 could handle often spend their first month building infrastructure instead of learning what the task needs.

11.4 Choose the model and effort by measurement, and set both explicitly

Run your evaluation set on two or three models at two or three effort levels, record the score and the cost per completed task for each, and pick the cheapest combination that clears your quality bar. Set the effort explicitly in code or configuration, because defaults change: Claude Opus 5.5 defaults to medium where earlier models defaulted to high - Anthropic. Section 10's data shows why this matters: the same model ranges tenfold in cost across its effort settings.

Expect different steps to want different settings. Classification and routing steps often do well on a small model at low effort, while the step that decides whether to issue a refund deserves a stronger model at higher effort. Routing of this kind can cut an agent bill by more than half, as our guide to routing between models shows.

11.5 Give the agent few tools, described like documentation

Every tool you add is something the model must choose between, so start with the minimum set and describe each one as if writing documentation for a new colleague: what it does, when to use it, what it returns, what it must never be used for. Use strict schemas so arguments are always valid. For connections to other systems, prefer MCP servers, whose specification moved to a stateless design in its July 2026 version - MCP, and for packaged know-how prefer skills, which load only when a task needs them.

The reason to keep the set small is the same compounding cost from section 1.1: every tool definition is re-sent on every turn, and a long list of overlapping tools makes the model hesitate and pick wrong. A good test is whether a human expert, given only your tool descriptions, could tell which tool to use for each of your evaluation cases. If they could not, the model cannot either. Our guide to building a remote MCP server shows how to expose your own systems this way.

11.6 Put the guardrails inside the tools

Decide which actions are irreversible or expensive (sending money, emailing customers, deleting data, deploying code) and put a human approval or a hard limit inside the tool that performs them, as the refund example in Path 3 does. Instructions in the prompt are advice; a check in the tool is a law. Give the agent its own scoped credentials rather than a person's, set a budget per run, and cap the number of turns.

These limits cost almost nothing to add on day one and are expensive to retrofit after an incident. Managed runtimes now offer several of them as settings (session budgets, permission policies, credential vaults), and the SDKs expose hooks where you can add your own. Section 12 covers the failure modes these guardrails exist to stop.

11.7 Ship to a small slice, log every run, and widen as the evals allow

Launch on a small share of real traffic with a human reviewing the results, log every run with its cost, its turns and its outcome, and review the failures every week. Each failure becomes a new case in the evaluation set, so the set grows into a precise record of what your agent gets wrong. Widen the agent's autonomy and its share of traffic only when the eval scores and the reviewed samples justify it.

The cost log is not optional. Without per-run cost, the first signal of a looping agent or a broken cache is the monthly invoice, and by then it is a month old. With it, and with tools such as Anthropic's new analytics API that group spend by agent and session, a cost regression shows up the day it happens. That is the difference between an agent you manage and an agent that manages your budget.

12. How agents fail, and the controls that stop it

The failure statistics for agent projects are bleak enough to be worth reading before you start. Gartner predicted that "over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls" - Gartner. McKinsey's 2026 survey found 40% of large organisations scaling agents, yet "only 37 percent of organizations report any positive EBIT contribution" from AI - McKinsey. And BCG reports that 42% of companies expect to give agents genuine autonomy by 2030 while "only 5% have the full set of controls in place today" - BCG.

Read structurally, those three numbers describe the same gap. Agents fail less because models are weak than because the systems around them are missing: no evaluation set to prove value, no cost visibility to catch a runaway, no controls to make autonomy safe. Each of the failure modes below maps to one of the steps in section 11, which is the point: they are preventable, and they are prevented by design rather than by hope.

12.1 Reliability decays with repetition

An agent that succeeds on a task once has not proven it will succeed every time. Sierra's τ³-bench measures exactly this by running each task several times: on its banking-knowledge tasks, Qwen 3.8 Max at its highest effort succeeds on 55.2% of tasks in a single attempt but only 35.1% when it must succeed on all four attempts - Sierra. A customer who contacts support four times experiences the second number, not the first.

The control is to evaluate for consistency, not just capability: run each evaluation case several times, track how often the agent succeeds on every attempt, and route the case types where it is inconsistent to a human. Narrowing the agent's scope usually raises consistency faster than upgrading the model does.

12.2 Costs run away in loops

An agent stuck on a failing tool will retry, reason about the failure, and retry again, and because each turn re-sends the growing context, the cost of those turns accelerates. Million-token context windows removed the natural brake that used to stop such runs when the window filled. The controls are the ones from section 11: a turn cap, a budget per run, alerts on cost per task, and context trimming so that dead ends do not keep being re-read.

The vendors have started to build these brakes into the platforms, and they come in two strengths. Anthropic's task budgets are advisory: they give the model "an advisory token budget for the full agentic loop to help the model self-regulate on long agentic tasks" - Anthropic. Its Managed Agents session budget is a hard stop: "a hard ceiling on the session's list cost", after which "the session stops issuing new model requests" - Anthropic. Use both kinds where you can, the soft one so the agent paces itself and the hard one so a bug can never spend more than you decided in advance.

12.3 Instructions arrive through the data

Any text an agent reads (a web page, an email, a document, a tool result) can contain instructions, and models still sometimes follow them. This is prompt injection, and it is why the most important guardrail is architectural rather than verbal: dangerous actions require approval inside the tool, credentials are scoped to what the task needs, and agents that read untrusted content do not also hold the keys to irreversible actions. Anthropic's talk on building secure agents for knowledge work, published in October, walks through how one team applied these principles on a managed runtime, and is the clearest recent explanation of the design.

The pattern in the talk generalises to every path: separate the agent that reads the world from the actions that change it, and make every crossing between them visible. Our guides to prompt injection defence and sandbox security controls list the specific controls.

12.4 The ground moves under the agent

The last two failure modes come from outside the agent. Supply-chain attacks, like October's LiteLLM and Cursor incidents, target the machines where agents are built because those machines hold every key. And vendor lifecycle changes (retired models, removed modes, shut-down products, ended introductory prices) break or reprice agents that nobody touched. November 30 alone retires a Claude model, removes a fast mode, shuts down OpenAI's Agent Builder and doubles Gemini 4 Argon's price.

The controls are unglamorous and effective: pin every dependency version and update deliberately, keep a list of every model, mode and product your agent depends on with its deprecation date, subscribe to each vendor's deprecation page, and keep the evaluation set from step two ready so that a forced migration takes days rather than weeks.

13. Who leads, who is rising, and where this goes

The market for building agents has sorted into three layers, and the leaders differ by layer. At the model and runtime layer, the labs are moving up the stack: Anthropic now offers a raw API, an SDK, a managed runtime and the skills standard; OpenAI offers an SDK, the Agents API, Workspace Agents and always-on Dots, and even runs its Agents API harness inside AWS as "Amazon Bedrock Managed Agents, powered by OpenAI" - OpenAI. At the cloud layer, AWS, Google and Microsoft compete on hosting any framework and any model, with governance on top. At the independent layer, frameworks (LangChain, CrewAI, Mastra, Pydantic AI) and workflow tools (n8n, Zapier, Dify) compete on model freedom and ease.

The rising force is the open harness. OpenClaw, DeepSeek Harness and Hermes Agent each hold more GitHub stars than the five frameworks in section 7 combined, and OpenClaw is now "stewarded by the OpenClaw Foundation, an independent 501(c)(3)" with "no paid tier, hosted service, or token" - GitHub. The standards layer is consolidating around the Agentic AI Foundation, whose ten projects now include MCP, A2A, AGENTS.md and Agent Skills - AAIF, with AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI as platinum members - AAIF.

Four shifts look durable from here. Effort replaces model choice as the everyday dial, with routers like Copilot Fusion picking models behind it. Agents get identities, budgets and managers, the direction set by SK Telecom's employee IDs, Agent 365 and per-identity cost analytics. Harnesses commoditise, so differentiation moves to the tools, data, evaluation sets and guardrails you build around them. And lifecycle churn continues, so portability (standards, evaluation sets, model-agnostic code) becomes a cost you pay up front to avoid a larger one later. OpenAI's essay on the future of the firm sketches where the organisational shift leads.

The diagram's middle and right charts are the ones to notice: agents beside people and between layers of people, not only beneath them. Every one of those placements needs what this guide has argued for throughout, an identity, a budget, an evaluation of its work and a human who owns it. Deloitte's survey found that 74% of respondents expect their companies to use AI agents at least moderately by 2027 - Deloitte, so the organisations that build those management habits now will have a head start that compounds.

14. How to choose your path: the decision framework

The decision reduces to four questions, asked in order: is the agent for your own work or for other people, how much code can you write and maintain, how long and how unattended will it run, and are there hard requirements about where the data and model must live. The diagram below turns those questions into a route.

A few profiles make the routes concrete. A founder or manager automating their own research and reporting should start on Path 1 and stay there until the usage cap bites. An operations team automating a business process with a few judgment steps belongs on Path 2, ideally on a self-hostable tool. A product team putting an agent in front of customers should pick between Paths 4, 5 and 6 by asking whether it values the lab's tuned harness, model freedom, or managed operations most, and should expect the token bill, not the platform, to decide its margin. Path 3 suits teams whose agent loop is their product, and Path 7 suits teams with hard data-residency rules or very large, steady volume.

If what you need is the work done rather than an agent to maintain, the equivalent decision is between building and renting an operation: managed agent-workforce platforms such as O-mega sit at that end, alongside the assistant-native agents of Path 1, and trade control over the internals for the shortest path to results.

The bottom line

Building an AI agent in November 2026 is easier than it has ever been and more expensive to get wrong than it looks. The loop itself is fifty lines; the judgment around it (the evaluation set, the effort settings, the guardrails inside the tools, the cost log) is where agents succeed or fail. Choose your path for control, speed and operations, and manage cost with the levers that actually move it: the model, the effort level, caching and turn limits, which together move the bill tenfold while the platform moves it by a few percent. Build the evaluation set first, because it is the one asset that survives every model release, every price change and every November 30.

This guide reflects the AI agent landscape as of November 2, 2026. Models, prices, effort defaults and product lifecycles change frequently (several change on November 30, 2026), so verify current details on each vendor's pricing and deprecation pages before you commit.

What this article rests on

Every model figure above is read from its record, re-read from OpenRouter's model feed every 6 hours, so the figures on this page are current even where the prose around them is older. Prices are OpenRouter's listed price per million tokens: for a lab's closed models that is the lab's own list price, and for an open-weight model it is the price of the host OpenRouter routes to by default, which can differ from the lab's own API and from other hosts.

• Claude Haiku 5.5 (Anthropic): $0.10 in and $0.50 out per million tokens, cached input $0.01, a 1M token window, listed 7 October 2026.
• Claude Opus 5.5 (Anthropic): $4 in and $20 out per million tokens, cached input $0.20, a 1M token window, listed 22 September 2026.
• GPT-6.1 Sol (OpenAI): $2 in and $10 out per million tokens, cached input $0.10, a 1.05M token window, listed 29 September 2026.
• Mistral Large 4 (Mistral): $0.70 in and $2.10 out per million tokens, cached input $0.07, a 1M token window, listed 6 October 2026.
• GPT-6.1 Terra (OpenAI): $1 in and $5 out per million tokens, cached input $0.05, a 1.05M token window, listed 26 October 2026.

In this topic: Building agents

• Single Agent vs Multi-Agent: When Subagents Pay Off (2026)
• AI Agent Observability Tools 2026: 9 Ranked on Real Cost
• Best AI Agent Harness 2026: What It Is, 8 Ranked
• Jev AI vs Clef vs OpenAI Decisions API: Which to Use 2026
• OpenAI Agents API: Ship a Long-Running Agent 2026
• Context Engineering: 4 Techniques for Agents (2026)
• Where AI Agents Run Code: E2B vs Modal 2026
• AI Agent Memory in 2026: Architectures & Tools

How do you build an AI agent? Every guide on it