Agents, part 2: how they actually work

If part 1 gave you the map — model, goal, tools, loop — this piece opens the hood. Still no jargon pile. Just enough to read a product page, spot marketing fluff, and know where things can go wrong.

The agent loop (one job, many turns)

Under the hood, most agents run the same cycle: read state (your goal, prior messages, tool outputs), decide next step (the model picks an action in words or structured JSON), act (call a tool), observe (get result back), repeat until done or stopped. A chatbot stops after one model reply unless you prompt again. An agent keeps spinning because the harness — the software wrapping the model — feeds each result back in as context. That harness is often more engineering than the model itself.

Tools: how the model touches the world

Models alone only emit text. Tools are the hands: search the web, read a file, run SQL, post to Slack, classify a tariff code, open a pull request. The model does not execute code magically; it requests a named action with arguments, and your runtime runs it and returns the output. APIs are the usual shape — REST endpoints the agent calls through a wrapper. MCP (Model Context Protocol) is a newer standard way to plug tools in so the same agent can talk to GitHub, Google Drive, or a customs database through a shared connector format — think USB-C for agent integrations. A browser tool lets the agent click and scroll like a user; powerful, slow, and easy to misuse. More tools mean more capability and more ways to break things.

Memory: what the agent remembers

Context window is short-term memory: everything in the current conversation and recent tool logs, bounded by a token limit. Long threads get summarized or truncated. Long-term memory is optional storage outside the chat — user preferences, past tickets, a company wiki, embeddings in a vector database. Retrieval pulls relevant snippets back into context when needed. Memory is not magic recall; it is search plus injection. Bad memory makes agents confidently wrong about what you said last week.

Planning: who decides the steps

Simple agents let the model improvise step by step — fine for small tasks, brittle for long ones. Richer systems add explicit planning: break the mission into subtasks, assign tools, revise when a step fails. Some products show you the plan before execution; others hide it. Neither approach removes the need for supervision on high-stakes work. Planning is still prediction, not guaranteed correctness.

Multi-agent: when one worker is not enough

A multi-agent setup splits work across specialized roles — researcher, coder, reviewer, billing clerk — that pass messages to each other. That can improve quality on complex jobs, but it also multiplies cost, latency, and failure modes (agents talking past each other, duplicating work, or coordinating an action you never approved). Single-agent with good tools beats a committee of confused bots for most everyday tasks.

Guardrails and human approval

Production agents need guardrails: allowlists on tools, spend caps, PII redaction, sandboxed shells, and hard stops before irreversible actions (payments, deletes, outbound email). Human-in-the-loop means the system pauses for approval on sensitive steps instead of running unattended. The right default depends on blast radius — drafting marketing copy is not filing customs entries. Our agentic hacking report shows what happens when guardrails are thin and credentials are wide.

How to read an "agent" product page

Ask five questions: (1) Which model (or models) run the loop? (2) Which tools can it actually call — and under whose credentials? (3) Does it remember beyond this session, and where is that stored? (4) Where do humans approve actions? (5) What happens on failure — retry, escalate, or silently guess? If the page only shows a chat UI and the word "autonomous," assume assistant until proven otherwise.

What to browse next

See live products in Agentic AI. For the generative layer underneath, read Generative AI. For a real-world failure mode, read the Hugging Face incident. For open models people run locally as agents, see open-weight models.

The point

An agent is a language model running in a loop with permissions. Tools let it act in real systems, memory and planning let it handle longer tasks, and guardrails and human review limit the damage when it gets something wrong. You don't need to build one to use the directory well; you just need to know what a product's agent can actually do. Part 1 covers the basic vocabulary.