What does an AI agent actually do?

You want an assistant to check a list, look up a time, or send a message. A language model on its own only produces text. Other software does those jobs. Who decides when it runs?

An AI agent lets the model choose the next step. Follow a request through the software to see what that means.

A tool is ordinary software the model can ask to use: a search, calculator, calendar lookup, or email sender. The model writes a request in a set format, such as "search the shelf list for this title." The surrounding software runs the search and returns the result as text.

The model asks; the software acts. That software can enforce limits.

In this authored illustration, a neighborhood book swap runs Saturday, November 14, from 10 a.m. to noon at the community hall. The organizer has a list of 40 donated books to compare with the hall's small lending library shelf list. The request: "Find which donated books the hall already has, and draft a short thank-you note to donors that mentions how many new titles we got."

One way to handle that request goes like this:

1. The model reads the goal and the tools it may use: search the shelf list, read the donation list, write a draft.
2. It asks to read the donation list. The software returns 40 titles.
3. It asks to search the shelf list for the first title. The result comes back: no match.
4. It keeps going, one title at a time. For one book, the search finds a similar title by a different author. The model has to decide whether that counts.
5. When every title is checked, it counts 31 new titles and writes the draft note.
6. It stops and shows the note.

Nobody wrote "search 40 times, then count, then draft" in advance. The model chose each step from the last result. That loop of choosing tools and reacting to results is what people usually mean by an AI agent.

In a workflow, a person writes the steps into the software ahead of time; the model fills in some of them. Anthropic's Building effective agents (December 2024) draws this line. It recommends the simplest approach that works, and notes that agents trade time and cost for flexibility while their errors can build on each other. The page now flags its own tooling advice as dated; the distinction still holds. Designing the system around a model compares these designs in more depth.

Step 4 needs care. Counting a near match can undercount new titles; rejecting it may thank a donor for a book the hall already had. A useful agent flags it for the organizer.

Products used to connect tools their own ways. The Model Context Protocol, or MCP, is an open standard for that connection. The MCP introduction compares it to a USB-C port: one shape of plug, many devices.

In the current specification (revision 2026-07-28), the app you use is the host. Inside it, a client connects to a server, and the server offers 3 kinds of things: resources (data to read), prompts (templates), and tools (actions the model can call). A book-swap server might offer the shelf list as a resource and "add a title" as a tool.

The specification says hosts must get the user's explicit consent before calling any tool, and distrust a tool's self-description unless the server is trusted. The protocol cannot enforce either principle. The app must do that. Before adding a connector, check the permissions you grant and how the app enforces them: what can it read or change?

Once a loop can send, delete, or pay, ask 4 questions:

• Which tools can it use, and on which data? The thank-you task needs to read 2 lists and write a draft. It doesn't need the donor email list or the ability to send.
• Which steps wait for a person? Sending the note to every donor should wait for the organizer to read it first.
• What ends the loop? Anthropic's article suggests stopping conditions such as a maximum number of steps, plus checkpoints where the agent pauses for human feedback.
• If a step fails halfway, what happens on the retry? A send that timed out may have gone anyway, so trying again can send it twice. A careful design checks before repeating anything that changes the world.

What should I share, and what can it do? covers the drafting-versus-sending split for everyday assistants. Should a model make this decision? covers narrowing what a model is allowed to choose.

The large cloud providers now sell managed homes for agents. Amazon's Bedrock AgentCore includes a runtime, identity, a gateway that turns existing services into MCP tools, monitoring, and a policy service that checks each tool call before it runs. Google's Gemini Enterprise Agent Platform gives each agent its own identity and puts a gateway in front of its tool calls to enforce access rules. Microsoft's Foundry Agent Service offers per-agent identity, tracing of each step, and content filters that it says help mitigate prompt injection risks.

A gateway enforces your rules; an identity carries the access you grant. Allow the book-swap agent to email anyone, and the platform will let it. "Help mitigate" is a careful phrase: text in a document or web page can still try to steer a model, which is why OWASP keeps a separate Top 10 for Agentic Applications (December 2025) of security risks.

Before choosing a platform, decide whether the job needs an agent or a fixed workflow. Give it the smallest tool set it needs and decide which actions wait for a person. Then check whether the platform can enforce those choices.

Sort these 5 fictional book-swap tasks into "draft only," "fixed workflow," or "agent." For each, name the approval it needs.

1. Write a friendlier version of the event notice.
2. Every Monday, email the sign-up list a reminder with the event date.
3. Check 40 donated titles against the shelf list and flag near matches.
4. Turn a photo of the sign-up sheet into a typed list of names.
5. Answer a volunteer's question about which tables are still free by checking the room booking system.

Answer:

1. Draft only. Nothing leaves the screen until someone copies it.
2. Fixed workflow. The steps never change, so software can run them on a schedule. Approve the message text and the recipient list once, and review them when either changes.
3. Agent. The number of searches and the near-match decisions depend on what each search returns. It needs read access to 2 lists and no send access, and the organizer approves the flagged titles.
4. Draft only, though it is tempting to call it automation. The output is a list someone should check against the photo, since a misread name ends up in every later email.
5. An agent is reasonable, because the model may need several lookups. It should read bookings only. If the volunteer then wants to reserve a table, that is a change, and it waits for a yes.

If you sorted task 2 as an agent, the reasoning is understandable: it runs on its own. But running without a person is different from choosing steps. A scheduled email follows the same path every time, which makes it easier to test and easier to trust.

• Anthropic's Building effective agents explains workflows, agents, and when to use neither. Its tooling advice is from December 2024.
• The MCP specification is technical, but its security section reads well on its own.
• OWASP's Top 10 for Agentic Applications lists the main security risks for agent systems. It is written for builders.
• Microsoft's Foundry Agent Service overview shows one cloud platform's managed and self-built agent types. It is a vendor's product page.
• On this site, how someone can trick an AI covers the hidden instructions an agent can meet in email and web pages.