AI and models · 13 Oct 2026

AI agents and agentic AI: what they are, how they work and where the risks begin

An AI agent can choose steps and use tools to pursue a goal. Agentic AI describes the broader approach—not a guarantee of intelligence, independence or reliability. Here is how to distinguish useful delegation from an impressive demo.

By PrimetimeGeek AI Desk

Original editorial illustration of a human operator overseeing documents, a planning board, a mechanical tool arm, an inspection lens and a stop switch. — Planning, tool use and checking form a loop. Permissions and human approval determine what that loop is allowed to change. Conceptual illustration, not a product demonstration.

The important change in AI is not simply that a system can write a better answer. It is that software can increasingly use an answer to decide what to do next: look up a record, run a test, revise a plan or submit a request. That shift turns a conversation into a process—and makes the boundary between proposing an action and performing it worth understanding.

For a worker, an agent might prepare a support case. For a software team, it might investigate a failing test. For a business, it might coordinate several systems. These possibilities do not establish that the technology can safely replace the people responsible for those processes. A system that can act is also a system that can make a mistake with consequences beyond its reply.

This is an independent synthesis of public technical guidance and research, not original reporting, a hands-on product review or a vendor ranking. Vendor documents are used to explain their architectural terminology, not to validate their performance claims. The examples and deployment recommendations below are editorial analysis.

The short answer: what is an AI agent?

In the language-model systems discussed here, an AI agent is software that uses a model to choose actions, access tools and work toward a goal across multiple steps. The model may decide which information to retrieve, which tool to call and whether another step is needed. Its independence can be tightly bounded: a person may still approve consequential actions.

Agentic AI describes an approach to building systems around goal-directed action, tool use and some degree of delegated control. An agent is a particular system or participant; agentic AI is the broader design approach. Neither term is a certification, a measure of reliability or evidence that the software understands responsibility as a person does.

Definitions vary. Anthropic distinguishes workflows, in which models and tools follow predefined code paths, from agents, in which the model dynamically directs its process and tool use. It uses "agentic systems" as an umbrella covering both. OpenAI's practical guide emphasizes systems that perform workflows on a user's behalf with a high degree of independence. These are useful vendor definitions, not a universal standard. 1 2

The wider field of AI has used the word "agent" for much longer than today's language-model products. This article focuses on contemporary software agents built around generative models. It does not equate agency with consciousness, artificial general intelligence or a physical robot.

Chatbot, workflow, copilot or agent: follow the control

Product labels are less useful than one question: who chooses the next action, and who authorizes it? A chat interface can conceal an agent, while an application called an agent may mostly follow a fixed recipe.

A basic chatbot produces a response to a message. If it only writes an email, nothing has been sent. Some chat products also have tools, so the interface alone does not establish the boundary.
A copilot or assistant helps a person draft, search or decide. The label describes an interaction pattern, not a technical guarantee that every action requires approval. Check the actual permissions.
A predefined AI workflow might classify an incoming ticket, retrieve an approved policy and generate a draft through a fixed sequence. Models can be part of a workflow without choosing its overall route.
An agent can choose among permitted next steps—for example, investigating a missing order by querying shipping records, checking an exception and asking for clarification before preparing a response.

These categories overlap in real products. A fixed workflow may contain an agent for one subtask; an agent may invoke a deterministic calculation. More autonomy is not automatically better. Predictable tasks often benefit from predictable software.

How an agent works: the action-and-observation loop

A typical agent combines a model, instructions, tools and a way to keep track of the task. The surrounding application—not the model alone—handles credentials, executes tool calls and enforces controls. A proposed action becomes a real action only when that application permits and performs it.

Consider an illustrative agent asked to investigate a customer's delayed shipment. This is a design example, not a claim about a tested commercial product.

1. Establish the goal and scope. The authorized task is to investigate and draft a reply. Sending the message, issuing a refund and changing the shipping address are outside its authority.
2. Read the available context. The system receives the ticket and the relevant policy. It should distinguish the customer's request from instructions governing its behavior.
3. Choose a permitted tool. The model proposes a lookup of the order. The application checks that the request concerns an authorized record and executes a restricted query.
4. Observe the result. The carrier record may show a delay or return an error. The next step depends on that result, rather than on a complete plan fixed before the lookup.
5. Continue, ask or stop. The agent might retrieve the escalation policy, ask a person about an ambiguity or stop because it lacks permission. Limits on steps, time and spending should prevent an indefinite loop.
6. Check the outcome. A reviewer verifies the proposed reply against the records. If sending later becomes an allowed action, the system should require the appropriate approval and confirm the result from the messaging service.

Not every agent writes an explicit plan or uses every component in this sequence. What matters is the feedback loop: select an action, observe what happened and decide what follows. A confident statement that a task is finished is not a substitute for checking the actual system state.

Tools give an agent reach; memory gives it context

Tools can include search, databases, calendars, code execution and business applications. A tool might be read-only or capable of changing records. That distinction can matter more to risk than which model powers the agent. A powerful model with read-only access cannot legitimately issue a payment through a tool it does not have.

Model Context Protocol, or MCP, provides a shared way for applications to communicate with servers exposing capabilities such as tools and resources. It can reduce integration work, but connecting a server does not establish that the server is trustworthy, the requested action is appropriate or the agent's answer is correct. MCP's own security guidance discusses authorization-related risks and mitigations. A protocol is not a permission policy or a safety certificate. 3 4

"Memory" can mean several different things: the current conversation, a stored task state, retrieved documents or information retained across sessions. It does not necessarily mean that the underlying model is retraining or learning permanently. Ask what is stored, who can retrieve it, how long it remains and how it is corrected or deleted. A remembered mistake can become an input to a later mistake.

Does agentic AI require multiple agents?

No. One agent with a small set of tools can be agentic. A multi-agent design distributes work among several agents—for example, a coordinator, a researcher and a reviewer. The agents might use the same model with different instructions or different models altogether.

That arrangement can help separate tasks, but it adds handoffs, context management and opportunities for disagreement or lost information. Several agents repeating the same unsupported claim do not create independent corroboration. A second model may assist review; authoritative records, deterministic checks and accountable human judgment can still be necessary.

Anthropic's guidance recommends starting with the simplest solution that works and notes that agentic systems can trade latency and cost for better task performance. OpenAI's guide also discusses single-agent and multi-agent arrangements. Neither document proves that more agents improve every workflow. 1 2

Where agents may be useful—and where a script may be better

Agents are candidates for tasks where the destination is clear but the route varies: gathering evidence from several approved sources, investigating an exception or iterating on a code change after tests fail. Their usefulness depends on having tools that work, results that can be checked and a failure cost the organization can tolerate.

Customer operations: investigate a case and prepare an evidence-backed draft. Keep refunds, account changes and sensitive disclosures behind separate controls.
Software maintenance: propose a fix, run tests in an isolated environment and open a change for review. Passing selected tests does not prove that a change is secure or ready for release.
Research and administration: assemble source material, identify missing fields and propose updates. Require traceable sources and distinguish an unavailable fact from a guessed one.

These are possible applications, not measured benefits. If the job is "copy this approved field when this exact condition is true," a conventional automation may be cheaper, easier to audit and more consistent. If there is no dependable way to check success, autonomous execution deserves particular caution.

The security problem: bad information can become a bad action

Generative systems can produce plausible but false statements. NIST's Generative AI Profile identifies confabulation and other risks and offers risk-management actions. It is guidance, not proof that following a checklist makes an agent safe. 5

An agent adds another route to harm: prompt injection. Instructions embedded in a webpage, document or tool result may try to redirect the system from its authorized task. For example, a document could tell a research agent to send private material to an external address. The document should be treated as evidence to inspect, not as an authority that can change the user's instructions. OWASP distinguishes direct and indirect prompt injection and warns that safeguards require continuing attention. 6

OWASP's excessive agency risk focuses on too much functionality, too many permissions or too much autonomy. The practical consequence is straightforward: a manipulated or mistaken system can do more damage when it has unnecessary tools, broad access and no approval boundary. Instructions to "be careful" do not replace access controls enforced outside the model. 7

Other failures are less dramatic but still important: repeated tool calls that accumulate charges, duplicate submissions after a retry, stale records, incorrect customer identity or a claimed success after an operation failed. An agent's reliability is the reliability of the whole process, including the surrounding software and the people who handle exceptions.

What benchmarks can—and cannot—tell you

Benchmark results are useful evidence about performance under specified conditions. They are not a warranty for a buyer's data, permissions or workload. Ask which tasks were attempted, how success was judged, which tools were available, how many attempts were allowed and what assistance the system received.

METR's March 2025 research introduced a useful way to discuss longer tasks: a task-completion time horizon based on the human time needed to perform tasks an agent completes at a specified success rate. Its 50% horizon is not the amount of time an agent can safely operate unattended, and a 50% success rate is not a suitable deployment target for a consequential process. The research focuses on the tasks in its evaluation, particularly software-related work; extrapolating to every office job is unwarranted. 8

We cite that study to explain the measurement, not to provide an October 2026 model leaderboard. Longer evaluated task horizons do not settle workplace economics, rare failures or security. A polished demonstration shows a successful run; a useful evaluation also shows unsuccessful runs and the cost of fixing them.

A practical way to evaluate an agentic system

Start with a bounded task and compare the complete process with the way it is done now. Include checking, rework and escalation—not just the time it takes to produce a draft. The following is an editorial evaluation frame, not a mandatory standard or a validated universal recipe.

Define success and failure before the trial. Identify the record or observable outcome that establishes completion. Include unacceptable outcomes such as accessing the wrong account or exposing private information.
Separate reading, proposing and executing. Give the system only the access needed at each stage. Require approval for actions with meaningful financial, legal, safety or privacy consequences.
Test realistic exceptions. Include missing data, contradictory policies, unavailable services, misleading documents and repeated requests. Synthetic data can support early tests without exposing real customers.
Measure end-to-end quality and cost. Track completed valid tasks, material errors, human interventions, review time, tool charges and response time. A fast draft followed by substantial cleanup may not be a gain.
Keep usable records. Log tool calls, approvals and outcomes without unnecessarily copying sensitive data. Do not mistake a model's explanation for a complete or necessarily faithful record of its internal reasoning.
Make stopping and recovery real. Test cancellation, credential revocation and restoration where available. Some actions, such as sending private information, cannot truly be undone; prevention and approval matter especially there.
Expand only on evidence. Decide in advance which outcomes justify continuing, narrowing or stopping the pilot. No fixed trial length can establish safety for every use case.

For a complementary buying checklist, see how to evaluate an AI agent before you hand it the keys. Our guide to reading a technology product announcement explains how to interrogate launch claims, while how AI is changing jobs in America separates task changes from employment outcomes.

What remains uncertain

The sources reviewed do not establish a universal return on investment, an industry-wide failure rate or a safe level of autonomy for every organization. We have not independently benchmarked the products described in vendor guidance or replicated METR's results. Reliability can change with the model, tool definitions, instructions, available context and environment. A test of one configuration does not automatically validate another.

The durable question is not "How many agents does this product have?" It is "What can this system do, what evidence shows that it does it well, and who is responsible when it does not?" Useful agentic AI delegates a bounded process with observable outcomes. The sales pitch delegates confidence; the operating decision must still account for consequences.