What is an AI agent?

Forty vendor emails is a job with a finish line: a one-page brief in a folder, junk archived, nothing sent. A summary in a chat is not that job.

That job has a finish line. Software that can search the inbox, write the file, and stop is an agent. Software that talks about the inbox is a chatbot.

Vendors sell the second thing under the first name: a GPT with plugins, a Zap with an LLM step, the copilot in the sidebar.

Vendors will keep calling the sidebar an agent. An AI agent is software given a job and a set of tools, then expected to finish.

An agent takes a goal you can test, uses named tools, and stops when the artifact exists or the budget is gone. ChatGPT in a browser is not an agent until it can act and stop on a done condition. The model is not the product, the loop is.

What an AI agent actually is

I use a job-finishing definition: you name the work, you name done, and you name the tools it may touch. Then a runtime runs the loop until the artifact exists or a limit you set is hit. If the only output is more chat, you still have a chatbot.

The output has to be a thing in the world: a PDF in a folder, a pull request on a branch, a ticket moved to done.

A slot on a calendar or a row written to the CRM counts the same way. A reply you can grade is not the job. The file is the job.

OpenAI Agents SDK Overview, first published in March 2025, treats an agent as an LLM equipped with instructions and tools, plus a built-in loop that continues until the task is complete.

OpenAI Agents SDK documentation (2026) puts it in one line: agents are applications that plan, call tools, collaborate across specialists, and keep enough state to complete multi-step work.

If the run still waits for your next instruction after every tool, you built a slow assistant. The model can be excellent and the product is still chat.

Anthropic's Building effective agents (19 Dec 2024) draws the same line from the other side. Workflows are systems where LLMs and tools are orchestrated through predefined code paths.

Agents are systems where LLMs dynamically direct their own processes and tool usage, and keep control over how they accomplish tasks.

That is the job-finishing definition in vendor language. A path you drew is a workflow. A model that chooses tools toward a finish line you wrote is an agent.

Both can be useful. Only one is an agent.

I do not care which lab trained the weights. I care whether the run can search, write, and stop without me in every click. The brain can be swapped, the loop cannot.

A useful test: could a script tell that the work finished. If only a person reading the thread can tell, you do not have an agent yet. You have a conversation with extra buttons.

Four parts I require

A testable goal, a short tool list, a runtime that owns retries and stop, and a budget: those four are the product, not the prompt. Skip any one of them and you have a demo that chats until the invoice arrives.

Start with the goal. "Write something about vendors" is not a goal. "PDF in /out/brief.pdf, junk threads archived, no mail sent" is.

A script should be able to check the folder and the archive. If a person has to squint at prose, the finish line is still a vibe.

Then the tools. Each one has a name, a schema, a timeout, and a permission. search_mail is not send_mail, and read_file is not deploy.

Browse is a last resort, not a default. Extra tools are how the worker wanders. I start under ten.

The description of the tool is the prompt. Be exact. Enums beat free text where you can.

Errors should be something the model can use: not found, denied, timeout, or the record. Do not wrap tool output in marketing language. The next thought needs facts.

Then the runtime. The model should not own the loop. The runtime retries a dropped connection, remembers what already ran, refuses a forbidden call, and stops.

I use one runtime for every agent so a score from last month still means something. A tool that exists only in a notebook is a demo.

Then the budget: steps and spend. Unbounded loops are how demos become invoices.

The cap lives in the runtime. The model does not get a vote on it. A retry storm is the first unsupervised failure I see in public.

• A goal you can test. Name the artifact and the check that proves it exists.
• Tools with names and limits. Search is not send. Read is not deploy.
• A loop the runtime owns. Retries, memory, and the stop rule do not live in the prompt.
• A budget. Steps and spend. Kill the trace at the cap.

Those four also tell you what the agent is not: a bigger system prompt, a plugin list bolted onto a chat window, or a Zap with an LLM step unless the model is choosing tools toward a finish line you wrote. Shape first. Model second.

I write the finish line before I pick a model. Teams that reverse that order spend a month tuning tone and then discover nobody can say whether Friday's run worked.

The artifact is the score. The essay is a log.

Agent vs chatbot vs workflow

A chatbot answers a message and waits, a workflow follows a path you drew, and an agent chooses tools toward a finish line you can test. Most teams still need the workflow. Use an agent when you cannot draw the path in advance, and when you can still write what done looks like.

Anthropic is also blunt about when not to reach for this. Agentic systems trade latency and cost for better task performance. For many jobs, a single LLM call with retrieval is enough.

Workflows offer predictability for well-defined tasks. Agents are the better option when you need model-driven decisions at scale, and when you cannot hardcode the path.

YouTube

Open original

Barry Zhang of Anthropic walked the same workflow-versus-agent split at AI Engineer Summit on 4 Apr 2025.

A Manychat flow that DMs a lead magnet is a script. It should stay a script. A Zap that files an attachment on a label is a workflow, useful and not an agent.

Putting an open-ended model on first contact, without a finish line or an eval, is how you spam a list and call it AI.

The copilot in the sidebar is usually a chatbot with extra context. It waits, you paste, it replies. That can be the right shape for a conversation.

It becomes an agent only when it can call tools across steps and stop on a done condition you wrote. I wrote the split out in AI agent vs chatbot.

You can keep the chat UI. People like chatting. The window is not the product.

If the run still needs you after every tool, you did not take the person out of the loop. You slowed the person down.

A workflow is what you want when the path is already drawn: label, file, notify. An agent is what you want when the path depends on what the last tool returned: this thread is junk, that thread needs a brief, this one needs a human.

If you can write the graph in an afternoon, write the graph. Save the model for the part you cannot draw.

What the loop looks like

Think, act, look, repeat: the model proposes a tool call, the runtime executes it, returns a short true result, and asks again. The run ends on the artifact, on a hard error, or on the cap. The model does not get a vote on spend.

OpenAI Agents SDK Overview is explicit that the SDK is worth using when you want the runtime to manage turns, tool execution, guardrails, handoffs, or sessions. Use the Responses API when you want to own the loop yourself.

Either way, someone has to own stop. If that someone is the model, you will pay for the argument.

1. 01

   Receive a job with a done check

   The goal arrives as a command or a short discussion. Once the task is clear, the agent plans. Anthropic's 19 Dec 2024 post says agents then operate independently, and may return to a person for judgment, with a done check a script can see.

2. 02

   Pick a named tool

   The model should return a tool name and arguments, not an essay. If it essays instead of calling, the schema or the goal is wrong. This is tool calling: a contract, not a vibe.

3. 03

   Run it in the runtime

   Retry a dropped connection. Do not retry a business failure without a rule. Log the call: input, output, latency, cost, error, because a double send hides in the tools, not in the final message.

4. 04

   Read a short true result

   Not found, denied, timeout, or the record. Ground truth comes from the environment at each step. Anthropic calls this out: tool results and code execution are how the agent assesses progress, and invented recaps are how it lies to itself.

5. 05

   Stop

   Success, hard error, forbidden call, or the cap. OpenAI's runner stops when the run finishes or pauses for approval. People stay at the edge, which is the point of how to run AI agents without a human.

Guardrails belong in the runtime, not in a paragraph of the prompt. OpenAI's SDK treats guardrails as validation of inputs and outputs that can fail fast.

I split read from write from spend from deploy as separate grants. An agent that can search the inbox should not also be able to wire money.

Draft is not send. Branch is not production. Those two sentences save more incidents than any slogan about autonomy.

Unsupervised does not mean no owner. It means the owner is not the next token. The owner designed the runtime, the eval, and the grants.

Memory is a pile. The loop is a decision. Agents can read memory, and they should not have to mine it to know what to do next.

Keep both. Memory holds the files. The current goal, the evidence so far, and the limits left belong in the run, not in a novel the next specialist has to reread.

Tools and the MCP socket

Tools are named functions with schemas. MCP is a socket for those tools, not an agent by itself. The specification splits a host, clients, and servers so one mailbox or repo can be granted without handing over the rest of the desk.

The Model Context Protocol specification Architecture (2025) splits host, client, and server. The host creates one client per server, enforces consent, and coordinates the model.

Each client talks to exactly one server. Servers expose tools, resources, and prompts.

That split is the point. The spec is clear that servers should not be able to read the whole conversation, nor see into other servers.

The mailbox server does not get the repo. The repo server does not get the bank. The host holds the conversation, and the servers hold capabilities.

MCP primitives are boring on purpose. Tools are functions the model can call. Resources are data the model can read, and prompts are templates.

Discovery is a list call. Execution is a call with a name and arguments. JSON-RPC carries the messages, over stdio for a local process or streamable HTTP for a remote one.

Connecting MCP does not make you an agent. A chat host that lists tools and never loops is still a chatbot with sockets. An agent is the loop that uses those sockets until the job is done.

I have watched teams celebrate an MCP demo and then paste the result by hand into the folder the job was supposed to fill.

Anthropic's 19 Dec 2024 post already pointed at MCP as one way to attach retrieval, tools, and memory to the model. The building block they start from is the augmented LLM.

That block is necessary. It is not sufficient. Without a finish line and a stop rule, you built a nicer chatbot.

Keep the tool list short even when the socket makes it easy to add twenty more. Each extra tool is a way to wander.

If the job needs a researcher and a deployer, that is two workers, not one worker with both keys. I wrote the contract in AI agent tool calling.

Retrieval is one tool among others. An agent that only retrieves and replies is still close to a chatbot. An agent that retrieves, writes the file, and ships it is using tools to finish work.

RAG is not a synonym for agent. It is a way to read.

Inbox, code, ops, research

I do not ship a generic agent. I ship a job: inbox triage, a coding agent that opens a pull request, an ops worker that closes a ticket, a research worker that files a brief. Same loop, with different tools, grants, and finish lines.

The forty vendor emails are an inbox job. Search the mailbox, classify junk against the threads that need a brief, write one page to a folder, and archive the rest.

Do not send. Done is the file plus the archive. I keep that worker small on purpose.

The inbox agent is allowed to search, write, and archive. It is not allowed to mail the list.

A coding job looks the same from the outside. The finish line is a pull request, or a branch with tests green.

GitHub's Copilot coding agent, introduced 19 May 2025 and later documented as Copilot cloud agent, is a public version of that shape: you assign an issue, it works in a development environment, and it comes back with a pull request. Existing branch protections still apply. Draft is not merge.

That is why a coding agent is a job, not a chat in the editor. Completing a line of code is autocomplete. Opening a PR against a written issue is an agent.

Anthropic's same 19 Dec 2024 appendix names coding as a fit because tests can verify the work and the problem space is structured. The review is still a person. The inner loop is not.

Ops is a ticket, a runbook, a status page, a deploy window. The finish line is the ticket closed with evidence, or a change that stayed inside the grant.

An ops agent that can read logs should not, on the same key, be able to ship production. Pager noise is a workflow.

An incident that needs a model to choose the next diagnostic is an agent job, if you can still write what done looks like.

Research is a brief with sources, filed where the next person will find it. Not a chat full of links.

A research agent searches, reads, writes the note, and stops. If it cannot name the files it used, it did not finish. Invented citations are a failed tool result, not a style issue.

• Inbox: brief in a folder, junk archived, no send. See the inbox agent.
• Code: tests, a branch, a pull request. See the coding agent.
• Ops: ticket closed with evidence, grants that cannot deploy on a read key. See the ops agent.
• Research: a sourced brief on disk, not a chat of URLs. See the research agent.

Same loop under all four: goal, tools, runtime, budget. The reason to split them is permissions, not fashion.

One worker with the mailbox, the repo, and the bank is a story. It is not a design. Start with one job, and add a specialist when one body would hold keys that should never sit together.

I run that worker as one job with a short tool list. A goal goes in. Tools fire.

The artifact has to exist or the run is a miss. It is not a product you install. It is the loop I keep honest in eval before anyone depends on it.

When you should not use an agent

Write the script when a script would do, and use a chatbot when the work is the conversation. If you cannot say what done looks like, you do not have an agent yet. You have a chat with extra steps, not a worker with a finish line.

Write the finish line first. Then give it tools. Then measure it on a frozen set of jobs before anyone depends on it.

Anthropic's 19 Dec 2024 advice is the one I quote when a team wants a fleet on day one. Find the simplest solution. Only increase complexity when you need it.

That might mean not building an agentic system at all. Latency and cost go up the moment the model starts choosing the path.

Use a chatbot when the work is support, FAQ, or a guided form. The person is in the loop because the work is the conversation.

Use a workflow when the path is already drawn: on this label, file this attachment, notify this channel. Use an agent when the next tool depends on the last result, and when a script can still see done.

Skip the agent if you have not written the spec. "Make it handle vendors" is not a spec. The forty-email job is a spec: one page, this folder, junk archived, nothing sent, stop.

If you cannot write that sentence, you are not ready to give it tools.

A fleet on day one is usually a slide. One worker with a short tool list is the default. A fleet is a shop, and extra agents add extra failure at the handoff.

Split when research should not deploy, or when retrieval, writing, and review fight in one prompt. Not because the word fleet sounds like the future.

First contact with a customer list is a script, not an unsupervised agent. Capture is a script. Completion is a job.

After the lead exists, an agent can research, qualify, book, follow up with tools. Mixing those jobs is how a demo becomes a reputation problem.

Eval is not optional. A beautiful thread that misses the attachment is a zero. If you cannot freeze ten jobs you already know and score the artifact, you are still in demo, and the first users are not a test set.

How I tell if I have one

I score the artifact, not the essay, on the same jobs more than once, with a log of every tool call. Pretty traces that miss the file are zeros. If I cannot name the score I am still in demo, and production starts after the score holds.

1. 01

   Write done so a script can see it

   Name the file, the PR, the ticket state, the row. If only a person can tell that the work finished, a person will stay in the loop forever.

2. 02

   Give it a tight tool set and a cap

   Only the APIs and files the job needs. No open internet by default. Steps and spend as hard limits, which is the first half of putting an AI agent in production.

3. 03

   Run the same jobs more than once

   Freeze ten to fifty tasks that look like production. Log every tool call. Compare against last week's agent, a script, or a careful human, which is the method in how to evaluate AI agents.

4. 04

   Keep people at the edge

   They set the goal and the grants. They read the weekly score. They do not click every tool, and you promote one job at a time, because inbox triage can go unsupervised before deploy does.

The tell is a file you can count. Monday's forty emails become a brief in a folder and an archive a script can open.

If I have to open the chat to know whether it worked, I built a chatbot with ambitions. If the file is there, the junk is gone, and nothing was sent, I have an agent.

Vendors will keep calling every window an agent. Let them. Your test is the job.

A goal, tools, a loop you can kill, a budget, an artifact. That is the whole definition I use. Extra labels do not change the loop.