Tech & AI, Explained

agents

10 min read

Agents

Status: 🟩 COMPLETE Last updated: 2026-06-19 Plain-English tagline: An LLM plus tools, running in a loop, allowed to choose what to do next at each step. That’s the entire definition. Everything else is design.

In plain English

“AI agent” is the most-hyped, least-defined word in the field. Strip away the marketing and you get a clean idea:

An agent is an LLM that can call tools, observe the results, and decide what to do next — repeatedly, until the task is done.

That’s it. No special “agent” technology. No mysterious autonomy. The pattern is just: LLM + tools + loop.

A chatbot answers one question. An agent works on a task. The difference is the loop: the model gets to take an action, see the result, take another action, see the result, until it decides the work is complete. Along the way it may search the web, read files, write files, run code, send messages — anything you’ve given it tools for.

Claude Code is an agent. So is ChatGPT’s “deep research” mode, Cursor’s agent mode, every “AI assistant” that takes real-world actions on your behalf, customer support bots that look up your order, code review bots that actually open PRs.

Why it matters

Agents are the bridge from “talking AI” to “doing AI.” For developers and users:

  • For users: agents convert vague intent (“help me ship a webapp”) into completed work, with the LLM handling all the intermediate steps.
  • For builders: the agent pattern is the most powerful primitive you have. With a well-chosen set of tools, you can build a system that handles a class of problems automatically.
  • For everyone: understanding agents lets you reason about what’s possible (and what’s hype) when someone announces “our new AI agent.”

The 2024–2026 wave of capable AI products is almost entirely about agents getting more reliable. The underlying models matter, but the practical leap is mostly in how well agents work.

The minimal agent — under 50 lines of code

async function runAgent(task: string, tools: Tool[]) {
  const messages = [{ role: "user", content: task }];
 
  while (true) {
    const response = await anthropic.messages.create({
      model: "claude-sonnet-4-6",
      max_tokens: 4096,
      tools,
      messages
    });
 
    messages.push({ role: "assistant", content: response.content });
 
    if (response.stop_reason === "end_turn") {
      return response.content.find(c => c.type === "text")?.text;
    }
 
    if (response.stop_reason === "tool_use") {
      const toolResults = await Promise.all(
        response.content
          .filter(c => c.type === "tool_use")
          .map(async (call) => {
            const result = await runTool(call.name, call.input);
            return { type: "tool_result", tool_use_id: call.id, content: JSON.stringify(result) };
          })
      );
      messages.push({ role: "user", content: toolResults });
      continue;
    }
 
    break;
  }
}

That’s a real agent. Give it task = "Find the top 3 hacker news stories about AI today and summarize each" and tools like fetch_url, and it will iterate until done.

Every “AI agent framework” (LangChain, LlamaIndex, AutoGen, CrewAI, etc.) is essentially this loop with extra bells. The bells are useful for production, but the loop is the agent.

What makes an agent good vs bad

The agent loop is simple. What separates “useful tool” from “frustrating mess” is design:

1. The system prompt

A good system prompt tells the agent:

  • Who it is (“You are a senior software engineer pair-programming with a developer”)
  • What it’s allowed to do (“You may read files, edit them, and run shell commands”)
  • What it shouldn’t do (“Never delete files without explicit permission; never push to main”)
  • How to communicate (“Be terse. Ask questions when ambiguous. Verify your work.”)
  • The format of common situations (error handling, refusal, escalation)

This is the agent’s “personality” and “rules of engagement.” A great system prompt is the difference between Claude Code and a fancy autocomplete.

2. The tool set

Not too few (then the agent can’t do its job), not too many (then it gets confused choosing).

  • Tools should be orthogonal — each one does a distinct, useful job. Avoid overlap.
  • Tools should have clear descriptions — the model decides when to use a tool based on its description.
  • Tools should match the task domain — a coding agent needs Read, Edit, Write, Grep, Bash. A research agent needs WebSearch, Fetch, Read. Don’t give a coding agent web tools unless it actually needs them.

3. Verification and self-checking

Good agents verify their work. They don’t claim “done” without checking. In Claude Code, this looks like:

  • After editing code → run npm run build to confirm
  • After a UI change → open a preview and screenshot
  • Before claiming a bug is fixed → reproduce the bug, apply the fix, verify the bug is gone

Without verification, agents become confident bullshitters. With verification, they become trustworthy collaborators.

4. Memory and state

A short task fits in the model’s context. A long task — or one resumed across sessions — needs explicit memory. Memory can be:

  • In-context — keep the relevant history in the conversation
  • External — files, databases, vector stores the agent can read/write
  • Summarized — periodically compress the history

Claude Code uses a hybrid: in-context for the current session + memory files (CLAUDE.md, MEMORY.md, individual memory files) for across-session knowledge.

5. Recovery and self-correction

Real tasks have errors. Tools time out, network calls fail, code has bugs. A good agent:

  • Reads error messages carefully and adjusts
  • Retries with backoff for transient errors
  • Asks for help when stuck instead of looping forever
  • Has clear escape hatches (max iterations, kill switches)

Common agent patterns

Designs you’ll see repeatedly:

Pattern A: Single agent with broad tools

One LLM call in a loop, with a set of general-purpose tools. Claude Code is this. Simplest. Effective for many tasks.

Pattern B: Orchestrator + workers (multi-agent)

A “manager” LLM breaks the task into subtasks, spawns subagent LLMs to handle each, then synthesizes results. Useful for parallel work or context isolation. The Agent tool in Claude Code launches subagents.

Pattern C: Plan-execute

Two phases. Phase 1: a “planner” LLM produces a step-by-step plan. Phase 2: an “executor” LLM (or a deterministic system) carries out each step. Helpful when planning quality matters more than execution flexibility.

Pattern D: Reflection / critic

The agent produces output, then a second pass critiques it (“what’s wrong with this? what’s missing?”), and the agent revises. Slower, higher quality.

Pattern E: ReAct (reason → act → observe)

Each iteration: the model writes its reasoning, then a tool call, then observes the result. The reasoning step (visible “thinking”) improves decision quality. This is the underlying pattern of most modern agents.

Pattern F: Specialist agents

Different prompts and tool sets for different roles: a “code reviewer” agent, a “deployment” agent, a “research” agent. Compose them as needed.

Almost every real production agent system is some mix of these patterns.

What current agents are good at (and bad at)

Good at (June 2026):

  • Multi-file code changes with verification
  • Research across many sources, with synthesis
  • Customer support for well-scoped issues
  • Data extraction and transformation
  • Form-filling and routine workflows
  • Software code review and improvement suggestions
  • Cross-tool workflows (Slack → calendar → email → CRM)

Still hard:

  • Long-horizon planning (days/weeks of work) — agents drift without scaffolding
  • Tasks requiring real-world consequences (sending money, making promises) — risk is high
  • Tasks where correctness is hard to verify — the agent can’t tell good output from bad
  • Open-ended creative work without clear “done” criteria
  • Cross-domain tasks requiring deep expertise the model doesn’t have

The 2024–2026 trajectory has been: tasks that were “still hard” two years ago are now “good at.” Expect continued progress.

Cost and latency

Agents make many model calls per task. A simple agent task might be 5 model calls; a complex one (Claude Code refactor of a multi-file feature) might be 50+. Costs and latency scale with calls.

Three levers:

  • Use cheaper models when possible. Routing simple subtasks to Haiku, hard reasoning to Opus.
  • Cache aggressively. The system prompt + tool definitions don’t change across turns; cache them.
  • Parallelize. Independent tool calls in parallel halve wall-clock time.

A well-designed agent costs anywhere from a few cents to a few dollars per task. Without these levers, the same task can be 5–10× more expensive.

Safety considerations

Agents take actions in the world. That’s powerful and dangerous:

  • Permission and approval gates — sensitive actions (writing files, running commands, sending messages, spending money) should require human approval, at least initially. Claude Code’s permission system models this well.
  • Containment — run the agent in a sandbox where damage is bounded. Containers, separate accounts, test environments.
  • Auditing — log every tool call. When something goes wrong (or right), you need to know what happened.
  • Refusal capabilities — the agent should refuse out-of-scope or harmful requests. This comes from the model’s training plus system-prompt rules.
  • Verification — important actions should be verifiable. “I sent the email” is one thing; “I sent the email to recipient X with subject Y, with delivery confirmation Z” is another.

Almost every production agent failure traces back to one of these being weak. Don’t skip them.

Common gotchas

  • “Just give it everything” doesn’t work. Lots of tools, vague system prompt, no verification → confused agent doing weird things.

  • Verification is non-negotiable. Without it, agents are unfalsifiable bullshitters.

  • Loops without max iterations are dangerous. A pathological case can run forever, burning tokens. Always cap iterations.

  • Asking the agent “are you done?” often produces “yes” regardless. Better: ask the agent to summarize what it did and how it verified. Read the summary critically.

  • Context drift in long sessions. The original task gets diluted. Periodically re-anchor by restating the goal.

  • Tool errors that aren’t surfaced. If a tool silently fails and returns nothing, the agent assumes success. Make tool errors loud and explicit.

  • One-shot prompts produce one-shot answers. If you want planning, ask for planning. If you want multiple attempts, build that into the loop.

  • Agents reflect their system prompt. A grumpy prompt produces grumpy outputs. A vague prompt produces vague outputs. Edit the system prompt as obsessively as the rest of the code.

  • Multi-agent isn’t always better. Each additional agent adds coordination overhead and points of failure. Default to a single capable agent; reach for multi-agent when you’ve identified a specific reason it’ll help.

  • Model choice matters. Use the best model you can afford for the planning/reasoning step. Use cheaper models for narrow, well-defined subtasks.

See also

Sources

Graph View

Backlinks