Ask an AI assistant to explain how to compare suppliers, and it can give you a checklist. Ask an agent to investigate three suppliers, and—if it has the right access—it can search their documentation, extract relevant details and assemble a comparison.

That change is easy to describe and harder to evaluate. A polished report does not establish that the agent checked the right sources or respected its permissions.

To understand agents, follow the work: what they can decide, what they can do and how anyone verifies the result.

What makes an AI system an agent?

The word agent covers several kinds of software. Here, we focus on the language-model-based agents used for digital work.

OpenAI gives a concise definition in its practical guide:

“Agents are systems that independently accomplish tasks on your behalf.”
— OpenAI, A practical guide to building agents, page 4.[2]

A useful distinction is who controls the next step. In a predefined AI workflow, code determines the sequence. In an agent, the model has some discretion to choose the next operation based on the task and what has happened so far. Anthropic uses this architectural distinction in its engineering guidance.[1]

That discretion might mean choosing another search query, opening a file or trying a different approach after an error. It does not imply unlimited authority.

For example, an agent can investigate suppliers while being prohibited from contacting them or making a purchase. Its freedom to investigate and its permission to act are separate design choices.

A chatbot interface does not settle the question

A conversation window can contain a simple answer generator or a tool-using agent. The interface alone tells you little about the underlying system.

Ask what happens after the initial request: does the software only return an answer, or can it choose operations, inspect their results and continue?

OpenAI's practical guide similarly distinguishes agents from applications that use a language model without giving it control over workflow execution.[2]

AI agents vs. chatbots vs. fixed automation

These categories describe different ways of organizing work. A product can combine them.

AI agents vs. chatbots vs. fixed automation
SystemHow the work progressesIllustrative task
Answer-only chatbotGenerates a response from the available inputExplains how supplier comparisons work
Fixed automationExecutes configured rules and stepsCopies submitted supplier details into a spreadsheet
Predefined AI workflowUses AI within a designed sequenceExtracts fields from each document, then creates a summary
AI agentChooses some subsequent steps using intermediate resultsInvestigates missing supplier details and decides what to check next

The practical question is whether choosing the path adds value.

If every submitted form needs the same three fields copied to the same database, fixed automation may be sufficient. If each supplier documents its product differently, a system that chooses where to look can be useful.

More discretion also creates more behavior to inspect. A flexible system needs evidence that its choices improve the outcome.

How an AI agent works

A typical tool-using agent repeats a cycle: choose an operation, execute it, inspect the result and decide what comes next.

The ReAct research paper explored an approach that interleaves language-model reasoning with actions and observations. It is one influential pattern, rather than a specification every agent must follow.[3]

An agent chooses a step, calls a tool, receives a result and checks progress, then repeats or returns a result.
The agent loop. Tools return evidence for the next decision; a stopping rule ends the run or brings in a reviewer. Illustration: AI Chronicle.

AI Chronicle

The model proposes; the application executes

In a common function-calling setup, the model requests a tool operation and supplies its arguments. Application code executes the operation and returns the result to the model. The model can then respond or request another operation.[4]

Consider a tool that searches a document collection. The model might supply a query about a supplier's integration support. The application searches the collection and returns matching passages.

The returned passages become evidence for the next decision. They do not automatically establish that the collection is complete or current.

The surrounding software matters

OpenAI's guide describes three core components: the model, its tools and its instructions.[2] For a reader evaluating a system, translate those into three questions:

  • Model: Can it interpret this task and the evidence it encounters?
  • Tools: Can it access the information and operations the task requires?
  • Instructions: Is the requested outcome specific enough to assess?

Then examine the application around them: permissions, logs, error handling and stopping rules. Two products using the same model can organize those components differently.

Memory is stored information

An agent may retain working information in its current context and save notes outside that context for later retrieval. Anthropic describes structured note-taking as one way to preserve progress across longer tasks.[5]

For our supplier example, a saved note might record that Supplier A supports a required integration but has not disclosed a particular usage limit.

Keeping that note is not the same as retraining the model. It also does not make the note correct. If the agent stores a mistaken interpretation, later decisions can inherit it.

A worked example: researching three suppliers

The following is a hypothetical design example, not an AI Chronicle product test or a measured performance claim.

Imagine a small team choosing a transcription service. It needs English-language transcription, speaker labels and a way to export results into its existing workflow.

“Find the best transcription tool” leaves too much unresolved. A more useful brief would be:

Compare these three named suppliers using their official documentation. Check language support, speaker identification, export options and published usage limits. Record the source and access date for each finding. Mark unavailable information as unknown. Prepare a comparison for review. Do not contact suppliers, start trials or make purchases.

This brief defines both the deliverable and the limits.

Step 1: Locate relevant evidence

The agent searches official product documentation and pricing or plan pages. It records the pages it actually accesses.

A search snippet might help locate a page, but the comparison should distinguish information checked on the page from information that could not be verified.

Step 2: Investigate gaps

Suppose the documentation confirms speaker identification but does not explain whether it is included in the relevant plan.

The agent can search further within the supplier's documentation. If the answer remains unavailable, the output should preserve that uncertainty.

A blank or “not established” entry is more useful than an unsupported yes.

Step 3: Compare equivalent requirements

The agent builds a matrix around the team's requirements rather than copying unrelated feature lists.

It should distinguish a supported file format from an integration, and a published feature from evidence of its quality. Documentation can establish that a feature is offered; testing is needed to assess how well it works for the team's files.

Step 4: Return an inspectable deliverable

The final comparison should include findings, source locations, unresolved questions and a suggested testing shortlist.

A reviewer can then inspect a sample of claims and decide what requires hands-on testing. The agent has reduced the work of gathering and organizing evidence, while the purchasing decision remains with the team.

Step 5: Check the investigation

The review should ask whether the agent considered the correct plans, used current pages and represented missing information honestly.

It should also check whether any important requirement was quietly dropped. An attractive table can conceal an incomplete investigation.

How businesses can build their first agent

Start with a specific piece of work: one recurring question, investigation or preparation task. Then identify the information it needs, the operations it may perform and the evidence a reviewer will use to accept its output.

The following examples are proposed build blueprints. They are not tested integrations or claims of business results.

Five design choices for a business agent: one task, approved sources, allowed tools, a review point and a useful output, with examples across five business functions.
Design the task before choosing the platform. Each business example starts with a bounded deliverable that someone can inspect. Illustration: AI Chronicle.

AI Chronicle

Choose a build route

A visual workflow builder can connect a model to tools without requiring a complete application to be written from scratch. Custom code offers another route when the task needs more control over integrations, permissions or evaluation.

For a concrete starting point, n8n documents an AI Agent node with tool connections, a system message, a maximum-iterations setting and optional human review for selected tool calls.[9] These are capabilities documented by the provider, not an AI Chronicle recommendation based on testing.

A draft-only pilot in n8n could be assembled like this:

  1. Add a chat or other suitable trigger carrying the task input.
  2. Add the AI Agent node and connect a supported chat model.
  3. Write the system message around the required output, approved evidence and when to stop.
  4. Attach only the lookup tools needed for the task, using appropriately scoped credentials.
  5. Configure an iteration limit and return the draft for inspection. If an action tool is added, configure human review before that tool executes.
  6. Run representative test inputs and check outputs and intermediate results before enabling a recurring trigger.

Exact connectors, authentication and data handling depend on the systems being connected. Returning a draft for review and gating a tool before an action are separate parts of the workflow.

Ecommerce: answer product questions from approved facts

Start with: “Does this item suit the customer's stated requirements?”

Make the product catalog, relevant specifications and approved policies available through lookup tools. The agent can investigate missing details, compare the requirements with the documented facts and prepare a response.

For a first build, allow product and policy lookups plus a draft output. Keep changes to orders, refunds and outbound messages outside its permissions.

Check whether the response identifies the right product, uses the applicable policy and admits when a detail is unavailable. Test ambiguous product names and conflicting requirements. A polished answer that invents compatibility should fail the check.

SaaS: investigate one onboarding issue

Start with: “Why can't this customer complete this onboarding step?”

Use product documentation and permitted account or event information. Build lookup operations around the specific account and problem, rather than exposing every customer record.

The agent can gather the relevant facts, identify missing information and propose a resolution or escalation. The output should show which evidence supports each proposed step.

Begin with investigation and a resolution draft. Keep account changes and customer messages subject to the existing approval process. Test missing logs, outdated instructions and situations that require support escalation.

Marketing: create a source-backed competitor brief

Start with: “How do these three competitors describe this particular capability?”

Provide named competitors, the comparison criteria and the campaign's intended audience. Connect public-source search and retrieval tools, plus a way to save a structured brief.

Have the agent record claims, source locations, access dates and unanswered questions. Separate what a competitor says from evidence of product performance.

A useful first output is a sourced comparison for a marketer to review. Publication and outreach remain separate actions. Check whether the agent compared equivalent products and avoided turning promotional language into established fact.

Growth: investigate a funnel change

Start with: “What should we examine after activation declined?”

Provide an approved report, metric definitions, the comparison period and relevant release or experiment notes. Use controlled data queries and reliable calculations to check the numbers before asking the model to interpret them.

The agent can investigate changes by segment, document anomalies and propose follow-up questions. Its output should distinguish observations from hypotheses.

Begin with an investigation brief and experiment proposals. Have the growth owner review the evidence before changing a campaign or experiment. A simultaneous release and metric movement alone should not be presented as proof of causation.

Finance: investigate invoice exceptions

Start with: “Which invoices need a person to examine a mismatch?”

Provide approved invoice, purchase-order and receipt records, plus the team's matching rules. Keep arithmetic and exact matching in deterministic checks; use the agent to investigate missing context and organize exceptions.

The output can list the affected records, the discrepancy and the evidence needed to resolve it. Use read access and a draft exceptions list for the initial build.

A finance reviewer should inspect the findings before records are changed or payments are initiated. Test duplicate invoices, partial receipts and missing documents. Passing a formatting check is not enough: each flag needs a defensible reason.

Turn the example into a build brief

Whichever business function is involved, write the output contract before configuring the agent. Specify the required fields, permitted sources, unknown-value handling and escalation conditions.

For example: “Return the record ID, finding, supporting evidence and unresolved question. If evidence is missing, mark the finding unresolved. Do not change the source record.”

That contract gives the builder something concrete to implement and the reviewer something concrete to evaluate.

Why AI agents fail

Failure can occur in the evidence, the interpretation, the action or the verification. Diagnosing the layer matters more than simply calling the model “bad.”

Incomplete or misleading context

The agent might receive an outdated policy, miss a necessary file or lose a qualification when information is summarized. Anthropic's context-engineering guidance notes that aggressive compaction can discard details that later become important.[5]

In the supplier example, omitting “available only on the enterprise plan” could turn a technically supported feature into a misleading recommendation.

A requested action is mistaken for a completed action

A model can request a tool operation without the operation succeeding. OpenAI's function-calling documentation separates the requested call from execution and the returned tool output.[4]

A completion message should therefore be checked against the relevant result: does the file exist, did the record change or did the search return evidence?

External content redirects the system

An agent reading a webpage or document can encounter instructions embedded in that content. OWASP calls this indirect prompt injection: external material influences the model's behavior in an unintended way.[6]

For the hypothetical research agent, a supplier page that tells automated readers to rank its product first should be treated as source content, not authority over the investigation.

OWASP cautions that there is no established foolproof prevention method. Reducing access and constraining consequences remain important alongside input handling.[6]

Permissions exceed the task

An agent preparing a supplier shortlist does not need purchasing authority. OWASP identifies unnecessary functionality, excessive permissions and excessive autonomy as sources of excessive-agency risk.

OWASP states:

“Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.”
— OWASP Gen AI Security Project, LLM06:2025 Excessive agency.[7]

High-impact actions can also be gated for human review.[7]

For our example, “do not buy anything” should be supported by the absence of purchasing permission. The instruction and the permission boundary serve different functions.

How to judge whether an agent is doing useful work

A demonstration shows what happened on one run. A useful evaluation asks what happens across the tasks and conditions that matter.

Anthropic's evaluation guidance distinguishes the record of an agent's activity from the final state it produces. It also recommends multiple trials because behavior can vary between runs.[8]

For the supplier investigation, we would use this starting rubric:

How to judge whether an agent is doing useful work
DimensionA useful check
CoverageEvery required field is addressed or explicitly unresolved
EvidenceEach material finding is supported by an accessible source
ComparisonRelevant plans and definitions are compared consistently
BoundariesNo unapproved contact, signup or purchase occurs
Review effortThe reviewer can verify findings without rebuilding the investigation

These are proposed checks for this example, not results from testing.

Include awkward cases: missing documentation, conflicting pages and an unavailable source. An investigation that appropriately marks a finding unknown may be preferable to one that finishes every cell with a confident guess.

Check ordinary cases repeatedly too. Record the model, configuration, task inputs, tool access and test date so a later change has a meaningful baseline.

Measure the complete workflow

For a small pilot, compare the agent-assisted process with the existing manual process. Record preparation, waiting, verification and correction.

An illustrative time budget shows why this matters. Suppose a manual investigation takes 60 minutes. An assisted version needs 8 minutes of preparation, 10 minutes of waiting, 25 minutes of verification and 12 minutes of correction.

That totals 55 minutes of elapsed time and 45 minutes of active human work, assuming the waiting requires no supervision. The savings depend on which measure matters and whether quality is comparable.

These figures are invented to demonstrate the calculation. They are not a forecast.

Likewise, cost per acceptable deliverable should include unsuccessful attempts and review work. A cheap run that produces unusable research has not completed the task cheaply.

A practical way to start using an agent

Anthropic's engineering guidance offers a useful starting principle:

“Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short.”
— Anthropic, Building effective agents.[1]

Choose a task narrow enough to inspect completely.

For the research example, begin with one comparison, a small approved source set and a draft-only output. Establish what a correct result looks like before expanding the task.

A pilot brief should specify:

  1. Outcome: The exact file, answer or proposed change required.
  2. Evidence: Which materials may be used and how findings are recorded.
  3. Access: The minimum data and operations needed.
  4. Escalation: When missing information requires a question or handoff.
  5. Limits: When the run must stop.
  6. Review: Who checks the output and which criteria they apply.

Try a simpler alternative alongside it. If a fixed workflow produces the same quality with less work, that is a useful result.

Expand only one responsibility at a time. A research agent that consistently creates a good source ledger can next be evaluated on synthesis. Publishing should have its own checks and authorization rather than arriving as an incidental extension of research access.

Questions readers commonly ask

Does an AI agent need several models?

No. A system can use one model to select tool operations and continue the task. Adding models or specialized agents is an architectural choice, not a requirement for the label.[2]

Can an agent work without internet access?

Yes. Its tools can operate on permitted local files or internal systems. Internet access is one possible capability, not a prerequisite.[4]

Does a longer run mean better work?

No. Additional activity must be judged against the deliverable. More searches can uncover missing evidence, but the relevant question is whether they improve coverage or correctness.

Can an agent check its own work?

It can perform checks, but the strength of the check depends on its evidence and method. Anthropic describes evaluation approaches combining code-based, model-based and human assessment; model-based grading needs calibration against human judgment.[8]

For a research report, asking the same system whether it “looks accurate” provides less assurance than inspecting whether the cited sources support the claims.

What to do next

Choose one real task and write down the evidence a reviewer would need to accept its result.

For a supplier comparison, that means defined requirements, source-backed findings, visible unknowns and a reviewed shortlist. For a code change, it means the intended behavior and checks appropriate to that change.

An agent becomes useful when its freedom to choose steps improves a result that can be inspected. Keep that result—and the work needed to verify it—at the center of the decision.

About these sources

Primary sources and direct quotations checked on 12 October 2026. This explainer combines provider documentation, a research paper, independent security guidance and AI Chronicle's proposed examples. Vendor guidance establishes how systems are designed, not independent proof of a product's performance. The examples contain no first-hand product test or original empirical findings.

Sources

  1. Anthropic, Building effective agents
  2. OpenAI, A practical guide to building agents
  3. Yao and colleagues, ReAct: Synergizing Reasoning and Acting in Language Models
  4. OpenAI, Function calling documentation
  5. Anthropic, Effective context engineering for AI agents
  6. OWASP, LLM01:2025 Prompt injection
  7. OWASP, LLM06:2025 Excessive agency
  8. Anthropic, Demystifying evals for AI agents
  9. n8n, Tools AI Agent documentation
Disclosure

This article was researched and drafted with the help of AI tools, then edited and fact-checked by the AI Chronicle editorial team. Illustrations are original artwork created for AI Chronicle with AI image generation.

Related reading