AI Agents Explained: What Works, What Fails, and What They Can Do Today

Every software company appears to have discovered the word agent.
Some have also discovered what it means.
That distinction is becoming useful, because the AI industry increasingly talks about agents as if we were halfway to hiring digital employees who never sleep, never complain and, as an added benefit, never ask why the quarterly planning meeting could not have been an email.
The reality is less theatrical and considerably more interesting.
AI agents are already doing real work. They can research unfamiliar topics, inspect files, write and execute code, operate software, call external systems, recover from some mistakes and decide what to do next based on what happened before. Yet the most useful agents today do not resemble independent employees very much at all.
They are better understood as models operating inside carefully engineered loops, with access to tools, context, feedback and boundaries.
That may sound like a technical distinction, but it changes how we should think about the entire agent market. The industry tends to romanticise autonomy; in practice, feedback, permissions and observability may matter just as much.
What makes an agent different is not the first action
A chatbot can explain how to update a customer account. Give a model access to the CRM and it may be able to make the change itself.
That is usually where the demonstration stops, because watching software click a button is rather more impressive than watching it check whether the button did what it was supposed to do.
The second part, however, is more important.
Did the customer record actually change? Did the API return an error? Did the browser land on the correct page? Did the code compile? Did the test pass?
A useful agent receives information from the environment after it acts, then uses that information to decide what should happen next. Anthropic has described this as giving agents access to “ground truth” from the environment, while OpenAI’s agent tooling similarly centres on multi-step execution in which models call tools, receive results and continue working.
That gives us a better definition than the usual “AI that acts autonomously”.
An agent becomes interesting when it can discover whether its last action worked.
Without that feedback loop, autonomy can become little more than the ability to make several mistakes before anyone notices.
The easiest way to know whether you need one
Consider a straightforward invoice process.
An invoice arrives in a known format. Software extracts the supplier, checks the total, records the transaction in an accounting system and sends a confirmation. Each step is predictable, and the sequence rarely changes.
There is little reason to insert an agent simply because agents happen to be fashionable this quarter. A conventional automation is easier to test, easier to understand and often cheaper to run.
Now make the process more realistic.
Some invoices arrive as PDFs, others inside emails. Supplier names do not always match the accounting system. A missing purchase order might require searching another application. A price discrepancy could mean checking a contract, and only certain exceptions should be escalated to finance.
At that point, the next action depends on what the system discovers.
That is where an agent begins to justify its complexity.
Anthropic makes a similar distinction between workflows, where code defines the path in advance, and agents, where the model has greater freedom to determine which steps or tools are appropriate. Its recommendation is notably conservative: start with the simplest architecture that works and add agentic behaviour only when the problem actually requires it.
| Dimension | Deterministic Workflows | Agentic Systems |
|---|---|---|
| Execution Path | Explicitly defined by code or rules | Chosen dynamically within defined boundaries |
| Decision Logic | Predefined conditions determine what happens next | The model interprets context and decides what happens next |
| Tool Usage | Tools and conditions are specified in advance | The model can select among available tools as the task evolves |
| Best Fit | Stable, repeatable processes with predictable paths | Variable tasks where the correct path depends on what is discovered |
This is much less exciting than putting “AI Agent” on the product page, but it is probably better engineering.
If you can confidently draw the entire flowchart before the task begins, you may not need an agent.
The interesting cases begin when the flowchart starts acquiring so many branches that it looks less like a process and more like an attempt to map the London Underground from memory.
What AI agents can actually do today
The answer depends surprisingly little on the word agent itself and a great deal on what the model is allowed to touch.
Current agent platforms can connect models to web search, company files, code environments, APIs, shell tools, databases and software interfaces. OpenAI’s current tool stack is one example. Once those connections exist, the model is no longer limited to producing an answer; it can participate in the work that produces the answer.
Research is a good example.
A normal AI search may retrieve a few sources and summarise them. An agent can begin with a question, discover that an important claim lacks evidence, search again, encounter a contradictory source, narrow the question and continue until the evidence is strong enough to support a conclusion.
The difference is not simply that the agent searches more.
It is that the search path changes because of what the agent has already learned.
Coding makes the same pattern even clearer. An agent can inspect a repository, modify files, run tests, read the resulting error, revise the code and try again. The environment itself becomes part of the reasoning process.
This may help explain why coding has become one of the strongest early use cases for agents: software can often tell you, with admirable lack of tact, whether you were wrong.
A strategy document rarely responds with:
17 tests failed.
A compiler will.
And that exposes one of the most important truths about agentic systems: agents become dramatically more useful when the environment can grade their work.
The less ambiguous the feedback, the easier it becomes to give the system room to operate.
The agent market may be watching the wrong number
Most public discussion about AI capability still revolves around model intelligence.
Which model reasons better? Which one wins the benchmark? Which one can solve the more difficult test?
Those comparisons matter. But once models are placed inside agentic systems, another question becomes equally important:
What can the model actually reach?
The same underlying model connected only to web search is one product. Give it access to a repository and development tools and it becomes something quite different. Connect it to internal documents, a CRM, email and a browser, and its practical range changes again.
This is why I think the agent market currently overvalues raw autonomy and undervalues the tool surface around the model.
A slightly smarter model with poor tools may be less useful than a slightly weaker model with excellent access, clear permissions and reliable feedback.
Anthropic has reached a similar conclusion from the tool-design side: badly designed or overly broad tool sets can make agents less effective rather than more capable.
Giving an agent fifty tools is therefore not necessarily an upgrade.
It may simply be a very sophisticated way of presenting it with fifty opportunities to choose the wrong button.
Computer use changes a boundary that used to look fixed
For years, serious software automation has depended largely on APIs.
That makes sense. APIs are predictable, structured and designed for machines.
Unfortunately, many real companies also depend on software that appears to have been designed on the assumption that nobody would ever want to automate anything.
Legacy admin panels, supplier portals, internal dashboards, obscure enterprise applications and web forms still absorb extraordinary amounts of human time. Some have APIs, though often with the generous feature set of a hotel minibar.
Computer-use agents create another path.
A model that can interpret screenshots and interact with a browser can potentially operate systems that were originally built only for people. OpenAI’s computer-use documentation describes this class of interaction. The result is not as clean as an API integration, and it should not replace one when a good API exists, but it changes the boundary of what can be automated.
Traditional automation asks:
Does this application expose the right API?
Agentic automation can increasingly ask:
Can this application be operated at all?
That difference is strategically important.
A company may have a dozen systems with excellent APIs and another fifty tools that only a human being can reasonably navigate. Reaching even part of that second group expands the automation surface substantially.
This is not the kind of thing that makes for a particularly cinematic AI future.
It does, however, make accounts payable considerably less tedious.
And companies have historically shown a suspicious willingness to pay for that.
MCP is important precisely because plumbing is boring
Model Context Protocol, or MCP, has received a great deal of attention despite having a name apparently designed to make ordinary people stop reading.
The underlying idea is much simpler.
MCP provides a common way for AI applications to connect to tools and data sources. Instead of building every integration from scratch around a particular model or application, developers can expose capabilities through a shared protocol. OpenAI supports remote MCP connections in its agent tooling.
What MCP does not do is make an agent intelligent.
It makes the surrounding capabilities easier to connect.
That distinction matters because integration cost may become one of the major constraints on agent adoption. If every new tool requires a bespoke connector, the theoretical flexibility of agents quickly runs into the entirely practical reality of engineering budgets.
MCP is plumbing.
But plumbing is generally considered uninteresting only until it stops working.
If protocols like MCP make useful systems easier to expose to models, a large part of the agent opportunity may come from connecting AI to thousands of ordinary business tools rather than waiting for some single extraordinary model to acquire magical powers.
The future of agents could therefore depend as much on integration standards as on benchmark scores.
That would be disappointingly sensible.
It would also be very normal for technology.
The next step may be specialised agents, not one universal agent
Once models can call tools reliably, another question appears: why should one agent do everything?
Google’s Agent2Agent initiative points towards a world in which agents built by different teams, frameworks or vendors can discover one another’s capabilities and coordinate tasks.
That architecture makes sense for reasons that have little to do with science fiction and a great deal to do with organisational reality.
A procurement agent needs different information from an IT agent. A finance agent should have different permissions from an HR agent. A research agent may need broad access to external information but no authority to modify production systems.
Trying to combine all of those responsibilities into one omnipotent agent might be technically elegant right up until someone asks why the same system has access to payroll, customer data and the production database.
We normally call that a security problem.
Specialised agents suggest another model: each system understands its domain, its tools and its limits, while coordination happens when work crosses boundaries.
The future may therefore look less like one brilliant artificial employee and more like a network of specialised systems negotiating with one another.
In other words, an unusually fast bureaucracy.
With luck, one that can actually find the document.
Why autonomy is not the finish line
The AI industry understandably likes autonomous demonstrations.
A system completes twenty steps without asking for help, and everyone applauds.
The uncomfortable question is whether those twenty steps included anything consequential.
Imagine an agent reviewing a customer complaint and correctly determining that a $15 refund is appropriate. Giving it permission to complete that action automatically may be perfectly reasonable.
Change the figure to $150,000.
The reasoning problem has barely changed.
The governance problem has.
This is why I think permission may prove to be one of the most underestimated constraints in agent deployment.
Whether a model can determine the right action is only half the problem. Organisations must also decide whether the system should be allowed to perform that action without approval.
That turns autonomy into a dial rather than a destination.
A coding agent might be allowed to edit files and run tests but require approval before merging. A finance agent might prepare a payment while remaining unable to release it. A research agent might gather information freely but stop before anything is published externally.
The best agent is therefore not necessarily the one that eliminates human intervention.
Sometimes the better system is the one that performs almost everything automatically and becomes suddenly, magnificently cautious at exactly the right moment.
That is not a failure of autonomy.
It is good judgement encoded into the architecture.
Bigger context windows do not solve memory
There is another assumption worth challenging: once models can hold enough context, long-running agents will simply remember everything they need.
Larger context windows certainly help, but having access to information is not the same thing as knowing what deserves attention.
An agent working for an extended period can accumulate instructions, tool outputs, documents, errors, decisions, notes and messages. Eventually the problem stops being whether the information is present and becomes whether the important information can still be distinguished from everything else.
Anthropic’s work on context engineering treats context as a finite resource and recommends techniques such as retrieval, compaction and selective memory precisely because carrying more information does not automatically produce better reasoning.
The analogy is familiar.
A larger filing cabinet is useful.
Dumping the entire filing cabinet onto the desk is not a memory strategy.
Long-running agents therefore need information management, not simply information storage. They must retain what remains useful, retrieve what becomes relevant again and discard what no longer deserves space in the active working context.
That problem will not disappear merely because future models can read another million tokens.
More autonomy also creates a stranger debugging problem
A chatbot produces an answer, which can usually be inspected directly.
An agent may arrive at its answer after dozens of intermediate decisions.
It may search for evidence, choose a source, interpret that source, call a tool, modify something in another system, inspect the result, choose another tool and continue. A mistake made early can influence several later decisions without appearing obviously in the final output.
That is why evaluation becomes harder as systems become more agentic.
The model may have reasoned correctly but called the wrong tool. The tool may have returned misleading information. The agent may have misunderstood a valid result. A bad assumption may have survived long enough to contaminate the rest of the process.
The final answer is no longer the entire product.
The trajectory matters.
Anthropic’s work on agent evaluations highlights this problem, while OpenAI’s agent tooling emphasises tracing and observability so developers can reconstruct what happened across a run.
From this follows a rule that deserves at least as much attention as the latest autonomy benchmark:
The more freedom an agent receives, the more important it becomes to understand what it actually did.
Autonomy without observability is not advanced engineering. It is debugging with suspense.
Companies should delegate decisions before they delegate jobs
This may be the most useful way to think about adoption.
Do not begin by asking which job an agent can replace.
Ask where, inside a job, people repeatedly inspect information and decide what should happen next.
That unit is smaller, easier to evaluate and usually much safer.
A customer-support organisation may gain enormous value from an agent that investigates an unusual ticket, gathers the customer’s history, checks policy and prepares a resolution, even if a person remains responsible for approving a large refund.
A finance team may not need an “AI accountant” to benefit from an agent that investigates mismatched invoices and hands only ambiguous cases to a human reviewer.
A developer does not need to disappear for a coding agent to be useful. Removing three hours of repository archaeology before the developer sees the actual problem may already justify the system.
This is where much of the public agent conversation becomes unnecessarily grand.
If a system removes twenty minutes of tedious judgement from a task performed ten thousand times a year, the company does not need to declare the arrival of artificial general intelligence.
It has saved a lot of time.
That will do nicely.
What agents are actually changing
The deepest shift is not from human workers to artificial ones.
It is from software that follows a predetermined path to software that can choose the next step from the state of the work.
For most of computing history, the next action was determined either by a person using the software or by a programmer who had encoded the decision beforehand.
Agentic systems introduce another possibility.
A model can inspect the situation, select among available actions, observe what happened and continue within defined boundaries.
That architecture is already useful, even though it remains a long way from the carefree autonomous employee depicted in some product demonstrations.
And that is perfectly acceptable.
The most sensible question for companies today is probably not how much work can be removed from people.
It is:
Which decisions no longer need to be hard-coded?
Then comes the harder question:
Which of those decisions are we actually comfortable giving away?
The distance between those two answers is where much of the real AI-agent market will be built.
And, inconveniently for anyone selling fully autonomous digital employees, that distance may remain rather large for quite some time.
AI Agents FAQ
What is an AI agent?
An AI agent is a model that can use tools, inspect results and decide what to do next based on what it discovers. The useful difference is not simply that it can act, but that it can receive feedback from the environment and adjust its next step.
How is an AI agent different from traditional automation?
Traditional automation usually follows logic and paths defined in advance. An AI agent can choose among available tools or actions dynamically, which makes it better suited to tasks where the correct next step depends on context, exceptions or newly discovered information.
What can AI agents actually do today?
AI agents can research across multiple sources, inspect and modify code, use software interfaces, call APIs, work with files and databases, and complete multi-step tasks. Their practical capability depends heavily on the tools, permissions, feedback and systems they can access.
Do AI agents still need human approval?
Often, yes. The right level of autonomy depends on the consequence of the action. An agent may be allowed to research, prepare a payment or edit code automatically while still requiring a person to approve a large transaction, publish externally or merge changes into production.
What is MCP and why does it matter for AI agents?
Model Context Protocol, or MCP, is a common way for AI applications to connect to tools and data sources. It does not make an agent smarter by itself, but it can reduce the cost and complexity of giving agents access to useful external capabilities.
