How do AI agents work?

An agent connects a model to a workflow

An AI agent is a software system that uses a model to help choose steps toward a task. The surrounding application may let it search records, call a tool, inspect the result and choose another step. A chatbot that only answers a question and an agent that can change a business record therefore have different operational consequences. The label “agent” alone tells you very little about what a system can actually do.

Separate four things

Start with the model, which proposes an answer or next step. Then identify the tools, which provide concrete capabilities such as retrieving an invoice. Next inspect the permission boundary: which identities, operations and records can those tools access? Finally examine the execution record: what was requested, what actually ran and what state changed? These are separate parts of a system, even when a product presents them as one conversation.

A fluent answer is not a verified result

Language models generate outputs from learned patterns and the context supplied to them. They can produce plausible statements that are wrong. NIST discusses this risk as confabulation in its Generative AI Profile. A useful workflow checks an important claim against an appropriate record and distinguishes a proposed action from a confirmed execution result. Asking the model whether it succeeded is weaker evidence than inspecting the system that owns the resulting state.

Follow one payment through the system

In Victoroff’s synthetic PAY-88219 example, the useful question is not just “What did the agent say?” It is “Why is this payment on HOLD, and what would authorize a release?” The demonstration retrieves a fixed set of synthetic records. Its authority decision is deterministic; it does not ask a language model to grant permission. This is an example of separating explanation from the authority to act, not a live payment integration.

Questions to bring to an evaluation

Ask which tools are available, who grants their permissions, which actions require a human, how failed calls are reported and where the final state can be verified. Request a bounded demonstration using synthetic data. Try a question with missing evidence and inspect whether the system acknowledges the gap. These observations are more useful than a claim that an agent is autonomous or intelligent without a defined task and boundary.

The moment a conversation becomes an operation

Imagine a fictional operations team asking an assistant to explain a delayed supplier payment. A text-only assistant might summarize a policy. A tool-connected assistant might retrieve the payment, compare an invoice and prepare a request for review. A system with write access might also change a status. These experiences can look nearly identical in a chat window, yet the last one can alter a business process. The first useful question is therefore concrete: what can change outside the conversation?

Write down the verbs. Read, classify, recommend, draft, approve and execute mean different things. A product demonstration should show which verbs are implemented, which are proposed and which require another person. If a vendor says the agent “handles payments,” ask it to replace that phrase with a list of operations. This simple translation turns an attractive claim into something your team can inspect and test.

Inspect one run in five stops

For an initial walkthrough, choose one synthetic case and follow five stops: request, context, proposed operation, execution result and final state. At the request, record what the user actually asked. At context, inspect the documents and records the system received. At the proposed operation, identify the tool and arguments. At the result, distinguish a successful response from a timeout or rejection. At final state, check the system that owns the record.

These are Victoroff’s suggested review stops, not a universal definition of an agent. Their value is that they force an explanation to connect to observable events. A sentence such as “I updated the record” belongs to the conversation. A system-side event showing the authorized write belongs to the execution evidence. If the two disagree, keep both in the review rather than smoothing the discrepancy into a confident summary.

Ask for the boring demonstration

The exciting demo is the happy path. The informative demo is what happens when a required record is unavailable. Ask the demonstrator to remove one piece of evidence, use an expired approval, or return an error from a tool. The system should have a defined response to that condition. A refusal, a request for more evidence or a handoff can be the correct outcome; completing the task at any cost is not the objective.

For a fictional payment-review workflow, define success before watching the run: explain the recorded hold, identify the missing evidence and keep release unavailable when authority is absent. That is more precise than “make the agent helpful.” Preserve the inputs and expected behavior so the exercise can be repeated after a change. One successful demonstration remains evidence about one case, not a measurement of performance across an institution.

What should a buyer request before a pilot?

Ask for a scope statement that names the workflow, the outcome under review and the operations excluded from the pilot. Request a list of required source systems without handing over credentials during the sales conversation. Agree who owns the business decision, who owns technical execution and who can accept the deliverable. Those may be different people.

Then ask what you will receive at the end. “An agent” is not a sufficiently clear deliverable. A workflow map, a bounded prototype specification, a set of acceptance cases and an evidence register are easier to review. Implementation feasibility, access and delivery capacity still need confirmation. A good scoping conversation should make these dependencies visible early, so neither side mistakes a polished interface for an agreed production implementation.

A practical comparison sheet

When comparing products, use the same synthetic task for each and write down the result at the same level of detail. Can you inspect the retrieved records? Does the answer distinguish facts from missing evidence? Can a reviewer see which operation was attempted? What happens if the request exceeds the permitted scope? Can the output be exported in a form another person can understand?

Avoid collapsing these observations into a single impressive-looking score without a defined method. A tool may provide an excellent explanation and still lack an appropriate execution boundary for your use case. Another may have narrow capabilities but a much clearer record of what it does. The comparison should support a decision about a particular workflow. It should not imply that a short exercise establishes overall security, regulatory suitability or return on investment.

Try the distinction yourself

In the public Victoroff example, PAY-88219 is a fictional USD 48,500 payment. The connected tool has a release capability, while the recorded delegation excludes release. The amount being within the agent’s hold limit does not change that exclusion. Follow the source links and check the different questions each record answers: invoice match, bank verification, human approval, delegation and final state.

After trying the demo, write one sentence about your own non-confidential workflow: “We need to explain why this kind of outcome occurs, using these kinds of records.” You do not need customer data to formulate that question. It is enough to begin a scope discussion. The proposed Snapshot is one possible next step, subject to evidence handling, delivery ownership, capacity and commercial agreement.

Three questions to take into your next meeting

First: if this system could only recommend and never execute, would it still create enough value to justify a bounded experiment? That question helps separate the value of information from the value of autonomy. Second: what evidence would persuade the workflow owner that a particular outcome was correct? That turns a vague requirement for explainability into a concrete review task.

Third: who can stop or change the workflow when a condition is no longer satisfied? Record the answer as a design question, not as a capability you assume already exists. These questions do not select a model for you. They help the people responsible for the workflow decide what should be built, which claims should be tested and where an AI-assisted explanation can be useful without becoming the authority for a business action.

Worth your next read

Outside perspectives selected to deepen the discussion. These links do not imply a partnership or endorsement.

• Anthropic engineering — Building effective agents ↗

  A useful architectural distinction between predefined workflows and model-directed agents. Published in 2024; the page flags that its tooling discussion has evolved.

• Martin Fowler’s site — Making Your Data Ready for Agentic AI ↗

  A complementary engineering discussion of data preparation and agent-facing access. Read it alongside the questions here about the records a workflow can actually use.

Sources and further reading

Primary references checked on 24 September 2026. The workflow examples and suggested review questions are Victoroff’s explanation.

• NIST: Generative AI Profile
• OWASP: Excessive Agency