AI Agents: What They Do, Where They Fail, and How to Test Them

👁 117 reads

An AI agent is a system in which a model chooses successive actions and uses tools to complete a task. Beyond writing a response, it can read a file, check the result of an operation, and decide what to do next based on that information.

Not every automation with a model is an agent. I reviewed Anthropic’s architecture description, which distinguishes predetermined workflows from processes steered by model decisions. The examples below are task and control designs, not reports from deployments with imaginary clients.

AI agents choose next steps based on results

In their guide on building agents, Anthropic distinguishes predictable paths written in code from systems in which the model directs tool use. Both approaches can be useful. The name “agent” is not, however, a reward for more complicated automation.

Simple example: a program copies rows from a form to a spreadsheet every morning. It doesn’t need to independently choose a strategy. When the task is “find the cause of discrepancies in these documents,” the next step may depend on what was found in the files. Then flexible tool selection has a concrete reason.

Good AI agents need access and termination conditions

A prompt saying “act independently” alone doesn’t create connections to files, email, or databases. The system must have actual tools and permissions. If it doesn’t have them, a response saying “I sent it” doesn’t prove a message was sent. Confirmation must come from the operation, not solely from the model’s description.

In a task, I define input material, allowed actions, and measurable output. For example: “Read documents from this folder and prepare a table of differences with filename and source fragment. Don’t change the originals.” The agent finishes when the table covers the provided set or when it clearly indicates a file it couldn’t read.

I also establish what should happen on error. If a document is missing, the agent should describe the absence. It shouldn’t guess values to complete the table. If it retries an operation, it must check whether the previous attempt already succeeded. This is especially important for actions that create new records.

Evaluate AI agent examples by verifiable output

In research, the result might be a report with open sources and a list of unresolved issues. In programming: file changes and the result of executed tests. In document processing: a completed table with the ability to trace each value. Each of these results can be verified independently of the system’s declarations.

I don’t measure success by number of clicks or response length. An agent that opened many pages might have skipped the right document. An agent that wrote a long report might not have performed the most important operation. Before you choose a tool from the AI tools catalog, write down the evidence you’ll accept as completion of your work.

Where AI agents fail in long tasks

Anthropic points to costs, delays, and the possibility of error accumulation. To see the mechanism itself, I calculated a model example: eight independent steps, each with an assumed 95% success rate, without correction. The chance of success for the entire sequence is 0.95 to the power of 8, or about 66.3%.

This is a calculation based on assumptions, not measured agent effectiveness. In a real process, steps don’t have to be independent, and control and retries change the outcome. That’s exactly why I design checkpoints. An incorrectly read value should stop further calculations instead of passing unnoticed through all stages.

Another boundary concerns permissions. If an agent only needs to prepare a proposed change, it doesn’t immediately need the ability to delete data. Access should match the task. A file copy and operation log make it easier to reconstruct what happened when the result turns out to be wrong.

Don’t treat instructions found in a document as commands from the person assigning the work. An agent analyzing a page might encounter content trying to change its behavior. That’s a reason to separate input data from permissions and task execution rules. The sentence “be careful” alone doesn’t replace restrictions on tool access.

Evaluate cost together with verification work

A subscription or model bill isn’t the entire cost. Tool calls, infrastructure, and time spent checking results are added. Comparison with manual work makes sense only when both sides end with a result of the same quality. A short, incorrect report isn’t savings just because it was produced quickly.

For your own test, choose neutral documents and prepare correct answers before you run the system. Check accuracy, completeness, and the number of cases requiring your intervention. I describe comparison methods in benchmarks. Don’t transfer the result of one task to all possible agent applications.

Limit your first AI agent to one process

Start with a task whose output is easy to receive, for example a table of discrepancies between files. Provide copies of materials, indicate allowed tools, and define what must appear in the report. Add a condition to stop work when a source is missing or a set budget is exceeded.

Run a test and review evidence of execution. Also check a difficult case: missing file, conflicting data, or illegible fragment. Only when you know how the system behaves on error should you consider expanding access. If the entire process fits into simple rules, regular automation may suffice and will be easier to maintain.

See also: Gumloop: AI agents without code · Factory.ai and Droid: code agent

// read moreManus: AI Agent That Completes Tasks Instead of AnsweringAI ToolsAI Agents That Don’t Ask: When AI Stops Advising and Starts ActingMagazineAI Coding Agents: Which to Choose, Costs & Getting StartedGuides

Kinetyra