Can I build an agent without a framework?

Yes. The core loop is straightforward: call the LLM with available tools, parse the response for tool calls, execute them, and pass the results back. Frameworks like LangChain and LangGraph provide observability, error handling, and state management out of the box. Building without one saves dependencies but adds complexity fast once you need logging, retries, multi-agent orchestration, or debugging.

How many tools should an agent have?

Start with one or two. More tools increase the agent's decision space and the likelihood of mistakes. [Anthropic recommends focusing on "a few thoughtful tools targeting specific high-impact workflows" rather than wrapping every API endpoint](https://www.anthropic.com/engineering/writing-tools-for-agents). Twenty tools is a ceiling for most agents. Beyond that, split into specialized agents or implement a tool-discovery layer.

What's the difference between an agent and a chatbot?

A chatbot responds to user messages without autonomously calling tools or iterating. An agent perceives, plans, takes action, and adjusts. A conversational agent is a chatbot augmented with tools—it can answer questions and take actions. The distinction blurs in practice, but the test is whether the system loops and branches based on intermediate results.

How do I know if my agent is hallucinating?

Validate tool outputs. LLMs can produce syntactically fluent but factually wrong responses. If your agent calls a tool and gets a result, verify that result against the source of truth before acting on it. Log tool calls and responses separately from the agent's reasoning, so you can audit what went wrong. Real data testing catches hallucinations that mock data misses.

How to Build an AI Agent: A Practical Primer for Builders

An AI agent is an LLM-powered system that perceives its environment, plans actions, and executes tools in a loop. Here's what separates a working agent from a failed one—and how to start building.

What Is an AI Agent (and What Isn't)

A working definition: an AI agent is an LLM with the ability to call tools, observe the results, reason about them, and decide what to do next. Unlike a simple prompt—which generates a single response and stops—an agent maintains a loop: perceive, plan, act, observe, repeat.

According to Anthropic, the fundamental difference is that agents "plan and operate independently" after receiving instructions, adjusting based on environmental feedback from tool results. A prompt-based system is deterministic by design: you ask, it answers, done. An agent interprets the situation each time and decides what to do—which is necessary when inputs are messy and the correct action isn't predetermined.

This matters because it changes what you're actually building. A tool calling system might be an agent, or it might be a workflow—a predefined sequence of LLM calls that happen to look like an agent in testing. The difference emerges in production, when reality throws something unexpected at the system.

Unlike a simple prompt—which generates a single response and stops—an agent maintains a loop: perceive, plan, act, observe, repeat.

When a Prompt Isn't Enough

Not every AI problem needs an agent. Simple prompts work best for single, isolated tasks: generating marketing copy, summarizing a document, translating a paragraph. A well-crafted prompt does the job in a fraction of the time, cost, and risk.

Use an agent when the workflow requires "loops, persistence, and cyclic reasoning" across multiple steps. Research tasks, coding workflows, and autonomous automation are classic agent territory. Customer support that requires multiple API calls to ticketing systems, order management systems, and knowledge bases. Code review and refactoring that needs to examine multiple files, run tests, iterate. The test is whether the problem requires the system to make branching decisions based on intermediate results.

OpenAI's documentation frames it this way: use agents when your application needs to "plan, call tools, collaborate across specialists, and keep enough state to complete multi-step work." If you don't need the loop—if the steps don't branch or don't depend on each other—a workflow or a single well-designed prompt suffices.

The Building Blocks: Tools, Memory, Planning

An agent's architecture rests on three components: tools, memory, and planning logic. Each can be simple or sophisticated depending on the problem.

**Tools** are the agent's interface to the world. Writing good tools is different from writing traditional APIs. Tools should be consolidated—a single `schedule_event` tool is better than separate `list_users`, `list_events`, and `create_event` tools because it reduces the combinatorial explosion of choices the agent must reason through. Tools need clear descriptions written as if explaining to a new teammate, explicit parameter definitions in JSON schema format, and example usage. Semantic identifiers (human-readable names) are faster for agents than cryptic UUIDs.

**Memory** comes in two forms. Short-term memory is the conversation's context window—what the agent has seen so far in this session. Most agents use a rolling buffer to maintain recent context without blowing up token counts. Long-term memory is persistent storage: databases, vector embeddings, knowledge graphs. A tiered approach mimics operating-system memory: active context in the prompt (like RAM), archived context in a vector database (like disk). Small agents often skip long-term memory. Production agents need it.

**Planning** is where agents diverge from workflows. Anthropic identifies two patterns: workflows encode decision logic in code (if X, then call tool Y); agents let the LLM decide which tool to call next. Workflows are reliable and predictable but inflexible. Agents are adaptive but require careful design to avoid hallucination and infinite loops. In practice, production agents add constraints: step limits, tool whitelists, explicit output formats, and fallback handlers for when tools fail.

Frameworks: Which One to Reach For

The framework landscape shifted in 2026. LangChain dominates for rapid prototyping with 1,000+ integrations and easy model-provider switching. LangGraph, its graph-based successor, is now the framework of choice if you need control over the agent loop and debuggability. CrewAI excels at role-based multi-agent workflows with intuitive abstractions. LlamaIndex (formerly GPT Index) is specialized for retrieval-augmented generation over large document corpora. OpenAI's Agents SDK is lightweight and clean for delegating work between specialists. Microsoft's unified Agent Framework (AutoGen + Semantic Kernel) targets enterprise teams on Azure.

Choose based on priorities: speed to prototype (CrewAI, LangChain), production control (LangGraph, OpenAI SDK), cloud-provider fit (GCP ADK for Google Cloud, Azure for Microsoft), language preference (Mastra for TypeScript, others for Python).

A framework succeeds when it prevents failures and diagnoses them fast when they happen. Look for built-in observability, durable execution with error handling, multi-agent orchestration patterns (sequential, concurrent, handoff), and integration ecosystems for APIs and databases.

An agent that hasn't been explicitly designed for edge cases fails on 30–40% of real interactions.

Starting Small: The First Agent

Build the smallest possible working agent, not the most capable one. Start with a single tool, no memory, basic planning. Test it with real messy inputs before adding complexity.

The pattern: (1) Define a tool schema in JSON. Describe what it does, list required parameters, include at least one example. (2) Choose a model and framework. For a first agent, Claude (via Anthropic API) and LangChain or LangGraph work well; Haiku 4.5 ($1/$5 per million tokens) is cheap for testing, Sonnet 4.6 ($3/$15) balances cost and capability. (3) Write the agent loop: call the model with available tools, parse the response, execute the tool, pass the result back. (4) Set a hard limit on loops (typically 5–10) to avoid runaway agents. (5) Test with 20–50 realistic inputs and log failures.

Expect failures. An agent that hasn't been explicitly designed for edge cases fails on 30–40% of real interactions. Most agents look perfect in demos and fail in production. Common breakpoints: tool APIs that return unexpected formats, authentication tokens that expire, network latency, rate limits, database schema changes. Test integrations last and earliest—they're usually the least tested and the most fragile.

Reliability: Where Agents Falter

88% of AI agent projects fail before reaching production. Scope creep and data quality cause 61% of failures. Integration—the agent's ability to interact with CRM systems, ticketing systems, calendars, databases, authentication layers—is the last thing built and the least tested. In production, integrations break. APIs change. Tokens expire. Schemas update. Rate limits get hit.

A March 2026 survey found 78% of enterprises have an agent pilot running, but only 14% have successfully scaled one to organization-wide use. The gap between proof-of-concept and production isn't about the agent logic—it's about the infrastructure around it.

Build defensively: (1) Assume tools fail. Implement retry logic, exponential backoff, graceful degradation. (2) Log everything: tool calls, results, reasoning steps, failures. Observability is the difference between "it's broken" and "here's why." (3) Set timeouts on tool calls and the overall agent loop. (4) Validate tool outputs before using them; LLMs can produce fluent but factually wrong outputs. (5) Test with real data and real APIs early, not just mocked responses. Tools that work in isolation often break in the agent loop because the agent calls them with unexpected parameter combinations.

Cost and Performance Trade-offs

Anthropic's Claude API pricing reflects the agent economics of 2026: Haiku 4.5 at $1 per million input tokens, Sonnet 4.6 at $3, and Opus 4.8 at $5. OpenAI's pricing is comparable for commodity tasks, but Opus 4.7 and 4.8 perform better on complex reasoning and agentic tasks—which matters when your agent makes ten tool calls per task. Longer loops mean more tokens, which means higher costs.

Token optimization matters. Prompt caching saves 90% on repeated context. Batch API pricing cuts costs by 50% if latency isn't critical. Shorter tool descriptions and filtering results before passing them back to the agent reduce token burn. If your agent makes 100 calls per task on average and consumes 2,000 tokens per call, and you run 1,000 tasks per month, the difference between Haiku and Opus is $1,800 per month—and the difference in success rate (Opus handles edge cases better) could be worth far more.

Start cheap, optimize later. Build with Haiku. Measure failure rates and token consumption. Move to Sonnet if failure rate exceeds your tolerance. Reserve Opus for tasks where reasoning complexity actually requires it.

Item	Value
Essential Components	LLM (Haiku 4.5–Opus 4.8), tool definitions (JSON schema), loop orchestrator, state storage, observability (logging, tracing)
Typical Loop Depth	3–10 iterations; set a hard limit to prevent runaway agents
Tool Density	1–20 tools per agent; consolidate operations to reduce decision space
Production Reliability	88% of projects fail before production; 78% have pilots, only 14% scaled to org-wide use
Failure Rate (Unoptimized)	30–40% of real-world interactions fail without explicit edge-case handling
Token Cost (Anthropic)	Haiku $1M/$5M, Sonnet $3M/$15M, Opus $5M/$25M (input/output); add 10–30% for tool parsing and retry overhead
Time to First Working Agent	2–4 hours with LangChain or LangGraph; 1–2 days with custom loop

Written by Manclass Editorial Team for Manclass. See our editorial policy for how Manclass is researched and edited.