What Is an Agent — And What Isn't

Every product launch in 2026 uses the word “agent.” Customer support chatbots are agents. Autocomplete plugins are agents. Cron jobs with an LLM wrapper are agents. A Zapier flow with a model step is an agent now, apparently.

None of those are agents.

The word has become meaningless through overuse, and the confusion is not academic. If you think your chatbot is an agent, you will build the wrong thing, staff the wrong team, and set the wrong expectations with customers. The distinction matters because the architecture, the reliability requirements, and the trust model are fundamentally different.

This post draws the line.

The Agent Loop — The Only Definition That Matters

An AI agent is a system that can autonomously take actions to accomplish a goal — not a system that responds to a single prompt and waits for the next one.

The defining primitive is the loop. An agent operates in a continuous cycle:

1. Perceive — take in information from the environment (files, APIs, user input, tool outputs)
2. Reason — decide what to do next (which tool to call, what parameters to pass, whether the goal is met)
3. Act — execute the chosen action (call a tool, write a file, send a message, run code)
4. Observe — evaluate the result (did the action succeed? did the state change? is the goal closer?)

Then it loops back. Perceiving the new state, reasoning again, acting again. This loop can run once for a simple query or iterate dozens of times for a complex workflow. The key: the agent decides when to stop — not the human.

Three properties separate a real agent from everything that calls itself one:

• Goal-directed behavior. The agent pursues an outcome, not a response. “Organize this folder by project” is a goal. “What files are in this folder?” is a query.
• Tool access. The agent interacts with the external world — file systems, APIs, databases, browsers, shell commands. Without tools, the model is a brain in a jar.
• Autonomy. The agent takes multi-step actions without requiring human confirmation at every step. The degree of autonomy varies (more on that below), but zero autonomy means zero agency.

This is the formula from Tian Pan’s anatomy of an agent harness: Agent = Model + Harness. The model handles reasoning. The harness handles everything else — tool execution, context management, memory, safety. The loop is what ties them together.

What an Agent Is NOT

The confusion comes from four categories that look agent-like but are not.

Chatbots Are Not Agents

A chatbot receives a prompt and returns a response. One turn. The user drives every interaction. There is no loop — the system does not perceive, act, observe, or iterate. ChatGPT in default mode is a chatbot. Claude.ai in a single-turn conversation is a chatbot. They are useful. They are not agents.

The test: does the system take actions in the world without being asked? A chatbot does not. It waits.

Copilots Are Not Agents

A copilot suggests. It autocompletes code. It offers a draft. It highlights errors. The human accepts or rejects every suggestion. GitHub Copilot, in its original autocomplete mode, is a copilot — the model proposes, the human disposes.

The distinction is the approval gate. A copilot has a human-in-the-loop at every step. An agent has a human-in-the-loop at the goal level (“organize my downloads folder”) but not at every action level (“rename file X, move file Y, create folder Z”).

AI tools require humans to operate them. AI agents operate on behalf of humans. That distinction changes everything about how work gets done.

Workflows Are Not Agents

A workflow is a fixed DAG — a directed acyclic graph of predetermined steps. Step 1 always leads to Step 2, which always leads to Step 3. The path is decided at design time, not runtime. LangChain chains, Airflow DAGs, Step Functions — these are workflows. They are deterministic. They do not reason about which step to take next.

An agent selects its next action based on the current state. If a tool call fails, the agent can try a different tool, adjust parameters, or abandon that approach entirely. A workflow cannot — it follows the graph or it fails.

RPA Is Not Agentic

Robotic process automation scripts follow brittle, pixel-mapped sequences. Click here, type there, wait for this element. They break when the UI changes. They cannot recover from unexpected states. They have no reasoning layer.

An agent navigating a browser can handle unexpected popups, changed layouts, and missing elements because the model reasons about the visual state and adapts. An RPA script cannot.

The Spectrum of Autonomy

Not all agents are fully autonomous. The reality is a spectrum:

The correct operating point depends on the stakes. Renaming files in a personal folder? Fire and forget. Sending an email to a VP on the user’s behalf? Confirm that action.

This is the trust ramp: start at the left, move right as the agent proves reliability. The ramp is not a product decision — it is a per-user, per-workflow decision that evolves over time.

Four Agents, Four Architectures

The agent loop is universal. How it is implemented — what harness wraps the model, what tools are available, what the interaction surface looks like — varies by product. Here are four agents that demonstrate the range.

Claude Code — The Terminal Agent

Claude Code is Anthropic’s terminal-native coding agent. It lives in the terminal. No IDE. No browser. No GUI. You describe a task in natural language, and the agent reads your codebase, plans multi-file edits, writes code, runs tests, observes failures, fixes them, and commits the result.

The agent loop is visible: the model reads a file (perceive), decides what to change (reason), edits the code and runs the test suite (act), sees if the tests pass (observe), then iterates until they do.

Claude Code hit 84.6K GitHub stars by March 2026 and earned a 46% “most loved” rating among developers, compared to Cursor at 19% and GitHub Copilot at 9%. It integrates with 150+ tools via MCP (Model Context Protocol), spawns sub-agents for parallel work, and supports automatic memory across sessions via CLAUDE.md files.

This is not autocomplete. This is an agent that writes, tests, and ships software.

Claude Cowork — The Desktop Agent

Claude Cowork launched on January 12, 2026 as a research preview inside the Claude Desktop app. It brought the same agentic architecture that powers Claude Code to non-developers.

You grant Cowork access to a folder. You describe the outcome. It reads, edits, creates, and organizes files within that scope — sorting chaotic downloads folders, pulling expense data from receipt screenshots, synthesizing research documents. Powered by Claude Opus 4.6 with a one-million-token context window, it plans an approach, executes across local files and connected applications, and returns a finished deliverable.

The market noticed. Investors wiped $285 billion from software stocks within days as the implications sank in: an AI capable of autonomous knowledge work, running on a desktop, for $20/month.

Cowork is not a chatbot with file access. It is an agent that takes a goal and works until the goal is met.

Kiro — The Spec-Driven IDE Agent

Kiro is AWS’s agentic IDE, built on a fundamentally different philosophy. Where Claude Code and most AI coding tools start with code, Kiro starts with specifications.

The approach is called spec-driven development. Before the agent writes anything, it generates structured specifications — requirements with acceptance criteria, a technical design document, and a numbered task list. You review and edit the specs. Then the agent implements from the spec.

This inverts the model that Cursor, Copilot, and most AI assistants use. In Kiro, the spec is source-of-truth and code is a build artifact. The agent loop runs at a higher level of abstraction: perceive (read the spec), reason (plan the implementation), act (write code, generate docs, create tests), observe (validate against acceptance criteria).

Built on Amazon Bedrock with multiple foundation models, Kiro treats the decisions made during development as first-class artifacts — not ephemeral chat messages that vanish when the tab closes.

Amazon Quick Desktop — The Knowledge Work Agent

Amazon Quick is an agentic AI-powered digital workspace that operates across the full surface of knowledge work — not code, but everything else.

Running Quick Desktop daily with 250+ tools connected in a single conversation, the agent loop operates across Slack, Outlook email and calendar, Salesforce, SharePoint, file systems, knowledge graphs, web search, browser automation, Python/JavaScript execution, and image generation. The agent triages your inbox, drafts replies, searches across indexed folders, posts structured Slack threads, builds dashboards, and manages account context files — all driven by skills (encoded methodology) and a persistent memory system.

A concrete example: the Slack MCP server exposes tools like post_message and search_messages. The Outlook MCP server exposes tools like email_reply and calendar_view. The Salesforce MCP server exposes tools like query_opportunities and update_contact. These MCP servers are the connectors; the tools are the individual functions the agent calls inside its loop. The distinction matters: you don’t connect “Slack” to an agent — you connect a Slack MCP server that exposes a set of tools the agent can invoke.

Quick Desktop’s distinguishing feature: scheduled agents that run 24/7 in the cloud. These are continuous autonomous agents — they run on cron schedules or event triggers (new Slack message, new email, upcoming calendar event) without any human initiation. A morning briefing agent fires at 7:56 AM, scans email and Slack, classifies by priority, and posts a triage report before you open the app.

This is the farthest point on the autonomy spectrum: agents that operate on behalf of humans with no human in the loop at execution time.

Why the Distinction Matters

If you conflate chatbots with agents, three things go wrong.

You underinvest in the harness. A chatbot needs a prompt and a model. An agent needs tool execution infrastructure, context management, memory, safety enforcement, error recovery, and human-in-the-loop workflows. The harness — the infrastructure that wraps the model — is where reliability lives. Skip it, and your agent fails in production even if the model is brilliant.

You set the wrong trust expectations. Users expect chatbots to be wrong sometimes and shrug it off. Users expect agents — systems acting on their behalf — to be reliable. A chatbot that hallucinates wastes 30 seconds. An agent that sends a hallucinated email to a VP wastes a career. The reliability bar is categorically different.

You build fixed workflows instead of adaptive systems. If you think “agent” means “workflow with an LLM step,” you will build rigid pipelines that break when the world changes. Real agents adapt. They recover from tool failures, try alternative approaches, and ask for help when stuck. That adaptability requires the loop — and the loop requires a harness.

The Agent Loop Is the Primitive

Everything in the agent ecosystem builds on top of the loop.

Tools give the agent hands — the ability to interact with the external world. Without tools, the agent is a brain in a jar. But tools alone are atomic: read a file, send a message, query a database. Each tool call is a single action in a single iteration of the loop. MCP servers are the connectors that expose those tools — the Slack MCP server, the Outlook MCP server, the Salesforce MCP server. The tools are the individual functions those servers make available to the agent.

Skills give the agent methodology — the knowledge of how and when to act. A skill encodes a workflow: when to trigger, what inputs to gather, what tools to use in what order, what quality checks to run. Skills are what prevent the agent from reinventing its approach every session.

The harness gives the agent a body — context management, memory, safety enforcement, error recovery, state persistence. The harness is the infrastructure that keeps the loop running reliably across sessions, across tools, and across failures.

Agent → Loop → Tools → Skills → Harness. Each concept builds on the one before it. Get the agent definition wrong, and the rest of the stack is built on sand.

The industry will keep calling everything an agent. That does not mean everything is one. The loop is the line. If the system does not perceive, reason, act, observe, and iterate — it is something else. Call it what it is.

This is post 1 of 4 in the Agent Primitives series. The next three posts define the other foundational concepts: Skills (what encodes methodology), Tools (the atomic capabilities agents invoke), and the Agent Harness (the infrastructure that makes agents actually work).