AI agent

An AI agent is a program that plans its own steps, calls tools and adjusts its actions based on the results in order to reach a goal, rather than passively generating a single block of text.

The difference from a one-turn chat is the loop. Given a goal, an agent breaks it into tasks, chooses which tools to call (search, a database, an API, code execution), reads what comes back, decides whether the goal has been met and, if not, runs another round.

What an agent is made of

• Model. Interprets the goal and decides the next step.
• Tools. The external capabilities it can call. They define what the agent can actually do.
• Memory. Context and intermediate results carried across rounds.
• Planning and stop conditions. How the work is broken down, and when the agent should stop.

Agents vs. workflows

In a fixed workflow, a person designs the steps in advance: the path is set and the behavior is predictable. In an agent, the model decides the path at run time. That lets it handle situations nobody anticipated, but the results are not fully reproducible.

In practice the two are usually combined. The backbone runs as a workflow for reliability, and the model only takes over at the points that genuinely need judgment. The more predictable the steps, the stronger the case for a workflow — it is usually cheaper and faster too. Anthropic’s engineering write-up on building effective agents (linked in the sources) draws the same distinction.

The main limitation: errors compound

Agent failures accumulate. A hallucination in one step becomes the input to the next, and the error grows along the chain. The longer the chain, the lower the end-to-end success rate.

Reliable designs therefore:

• keep chains short;
• add checks at the critical steps;
• produce intermediate states that can be rolled back;
• put permission boundaries around tool calls.

In content work, agents often handle topic selection, research and first drafts inside a content factory. In knowledge work, an agent should pull facts from a knowledge graph or vector retrieval; the knowledge stored in the model’s own parameters should not be treated as a trustworthy source.

What a company should define before deploying one

Write down the inputs, the allowed actions and the end condition first. Take an inquiry-handling agent as an example: it might read approved product materials, organize a prospect’s requirements and produce a hand-off summary for a salesperson. Whether it may also send email, edit CRM records or quote prices should each be a separate permission. Being able to call a tool does not mean the agent should automatically be granted every action that tool allows.

When preparing materials, list:

• who owns each source document and how often it is updated;
• which system interfaces the agent connects to;
• what data it is allowed to access;
• which steps require a human to confirm.

When sources conflict, permissions are missing or a customer asks something out of scope, the agent should stop and hand off to the responsible person — not fill the gap with an answer that merely sounds plausible.

How to accept (sign off on) an agent

Test with samples taken from real work and measure task completion rate, factual accuracy, time taken and cost per run. Then add failure scenarios on purpose: missing materials, duplicate requests, tool timeouts. Acceptance is not just “the demo worked.” You also need to confirm that failures are detectable, that actions are logged, and that a person can take over.

For example, if the same customer submits a request twice, the system should not create two contradictory records. If a lookup fails, the agent should say it cannot confirm yet. The right thresholds depend on the business risk and on the existing manual process; there is no universal “agent accuracy” number that applies to every company.

Getting help

If you need to map system connections and scope a pilot, see AI agent implementation. If you have not yet decided between fixed automation and an agent, start with AI consulting and tool selection.