What an AI agent actually is (and what it isn't)
An agent is chat plus three properties: it knows your project, checks its own work, and keeps going without you.
Most of what gets called an "AI agent" today is just chat with a longer leash. The word is doing a lot of marketing work. It's worth being precise about what actually separates an agent from a chat window, because the difference changes what you can safely delegate.
The three properties
An agent, as distinct from a chatbot, has three properties at once:
- It knows the project. Not just what you typed in this message, but the repo structure, the build commands, the conventions your team uses — pulled from files, not re-explained every time.
- It verifies its own work. It runs the tests, reads the error, checks the type-checker, rather than handing you code and hoping.
- It continues without you. Given a task, it takes multiple steps — read, edit, run, read the failure, edit again — without you re-prompting after each one.
Anthropic's own framing draws the same line around autonomy: agents are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks," as opposed to workflows that follow predefined code paths (Building effective agents). That same piece is explicit about the verification part too: "it's crucial for the agents to gain 'ground truth' from the environment at each step (such as tool call results or code execution) to assess its progress."
In the figure, the left side is what most people mean by "using AI" today: one arrow, you to model, model to you, done. The right side is the loop — three properties feeding each other in a cycle that doesn't stop until the task's own success condition is met, not until you get bored of prompting.
Where chat quietly becomes agent
You don't need a special product to cross this line. Pasting a stack trace into a chat window and getting a suggested fix is chat — one arrow. Asking a coding tool to fix a failing test, watching it read the test file, run the suite, see it still fail, and try a different fix, is an agent — because step three (continues) and step two (verifies) are both happening without you in the loop.
The "knows the project" property is the one people skip most. A model with no CLAUDE.md, no access to your repo, and no memory between turns can still take multiple steps and check its work in a single session — but it's re-deriving context every time, which is slow and inconsistent. A durable, readable project memory is what makes the other two properties cheap to repeat.
Why the distinction matters for delegation
If a task only needs one of the three properties, you don't need an agent for it — a well-crafted prompt is faster and cheaper. Save the agent setup (project context, a verification step, permission to run tools) for tasks where you'd otherwise be the one manually re-running tests and re-pasting errors back into chat. That manual loop is exactly what an agent automates.
Try it today
- Pick one recent chat session where you copy-pasted an error back to the model more than twice.
- Note what "verification" looked like each time — a test, a build, a manual read of output.
- Give the same task to an agentic tool (Claude Code, or any CLI agent) with permission to run that same test or build command itself.
- Compare how many times you had to intervene versus how many times it self-corrected.
- Write down which of the three properties was missing when it needed you.
Where this breaks
- An agent without a real verification step (no tests, no type-checker, nothing that can fail loudly) will happily loop on the wrong fix and call it done.
- "Knows the project" is only as good as what's written down — an agent can't infer tribal knowledge that lives only in a senior engineer's head.
- Longer autonomous loops mean more tokens spent per task; for small, well-specified changes, plain chat is still cheaper and faster.
Next: how to write a CLAUDE.md the agent actually uses.