An AI assistant saying “your repair visit is booked” is not the same as a booking existing in the repair company’s calendar. The useful question is what happened between your request and that answer: which information was checked, which action was authorized, and whether the booking was confirmed.

That distinction is a good starting point for understanding AI agents. In a language-model agent, the model can select tools, receive their results, and choose what to do next rather than follow only a predetermined sequence.[1] The surrounding software executes those tool requests; the model’s words alone do not change a calendar or send a payment.[2]

Chatbot, workflow, agent: look at who chooses the next step

These labels overlap. Anthropic’s December 2024 explanation distinguishes predefined workflows from agents that dynamically direct tool use, while acknowledging that people use “agent” differently.[1] Here is a practical way to read the labels:

  • Chatbot describes the conversational interface. It might simply answer questions, or sit in front of tools and a more capable system. A chat window does not tell you how much authority it has.
  • Fixed workflow describes the route. For example: receive a form, check required fields, add an appointment, send a confirmation. The route can contain conditions or an AI step without giving the model control over the whole process.
  • Agent describes model-directed choices within that process. The model might decide that it needs the service area before checking availability, or ask a follow-up question when a lookup is inconclusive.

Treat these as a continuum of delegated decisions, not a ranking of intelligence. A useful design can combine an agent for interpreting a request with fixed rules for making a booking. Calling every automation an agent hides that distinction; saying chatbots cannot use tools makes the opposite mistake.[1][2]

What a tool actually does

A tool is a capability the application makes available: looking up opening hours, searching a document, or creating an appointment. A function is one common form of tool, with named inputs such as a customer identifier and appointment time.[2]

The model selects a tool and supplies those inputs. Application software receives the request, runs the operation, and returns a result for the model to use.[2] Our recommended design puts permission checks and input validation before execution—not merely in an instruction telling the model to be careful.

A bounded agent loop should work like this:

  1. Set a goal and limits. Find an eligible repair visit; do not book it yet.
  2. Choose the next useful step. Ask for missing details or request an allowed lookup.
  3. Check and execute. Software checks the inputs and permissions, then runs the tool.
  4. Observe the result. Was the address covered? Did the lookup fail? Is the information sufficient?
  5. Continue, stop, or hand off. Another step must serve the goal and remain inside the limits.

This is our simplified design, grounded in the documented tool-call cycle and feedback loop.[1][2] The infrastructure matters too: Anthropic’s April 2026 Managed Agents explanation separates the model-calling loop, execution environment, and event log.[3] That is a vendor’s architecture description, not proof that every agent reliably completes its work.

Example: booking a repair visit

Imagine a repair company offering a booking assistant. This is a hypothetical design, not a product we tested.

A customer asks: “Can someone fix my washing machine on Friday afternoon?” The assistant should clarify the date, address and relevant service details rather than guess which Friday or promise a repair outcome.

Initially, its tools should be read-only: check the service area, consult the company’s service information, and retrieve available appointments. We would restrict access to the customer’s own booking context, not expose the entire customer database. Reading is still a permission decision, especially when personal information is involved.

If the company cannot service that machine, stop or hand the request to a person. If a suitable appointment exists, present the exact proposed action: company, service address, date, time window, applicable call-out charge, and contact details that will be shared. Ask for approval to create that booking—not a vague “shall I continue?”

Only after approval should the application permit the external write: creating the appointment. It should recheck availability, submit once, and retrieve the resulting booking record. A changed slot or charge needs renewed approval.

The final answer should distinguish “booked,” with a confirmation reference, from “requested but not confirmed.” If the booking succeeded but the confirmation message failed, say so. Do not create another appointment merely to try sending the message again.

Where agents fail—and what to check

OpenAI’s safety guidance identifies hallucination, misunderstanding, ambiguous requests, malicious instructions and private-data leakage as risks; it explicitly says mitigations do not eliminate mistakes.[4] For the repair example, we would test these failure cases:

Wrong facts or wrong tool inputs. The assistant could misread a policy or pass the wrong customer identifier, date or address. Check factual answers against the relevant source; validate tool inputs against customer records and allowed values. A correctly formatted date is not necessarily the date the customer intended.

Ambiguous authority. “That time looks good” might express interest rather than permission to commit. Require an approval screen tied to the exact action and recipient. If important details change, the earlier approval should not carry over.

Silent partial failure. A calendar write could succeed while another step fails. Check each required outcome separately, and preserve the distinction in the final answer. An encouraging tool response is not a substitute for checking the resulting record.

Retries that duplicate actions. A timeout leaves an uncertain outcome: the appointment might exist even though the response never arrived. Before retrying, look up the first attempt. Where supported, use a unique request identifier so the service can recognize a repeated request. Otherwise stop for reconciliation rather than gamble on another write.

Malicious instructions inside retrieved material. A webpage or tool result might contain text telling the assistant to ignore its rules or transmit customer data. This is prompt injection: untrusted content attempts to redirect the system.[4] Treat retrieved material as evidence, not permission. Restrict destinations and data access in software, and require approval for sensitive operations. Filters and model instructions are useful layers, not guarantees.[4]

Loops without progress. Repeating a failed search or repair attempt can consume resources while never resolving the request. Agents can incur higher costs and compound errors across steps.[1] We recommend hard limits on elapsed time, tool calls, retries and spending, with a clear stop message and human handoff.

Permissions are not reliability

Permission answers “may this system do this?” Reliability answers “did it do the right thing?” A narrowly authorized assistant can still book the wrong eligible slot. A correct answer does not establish that it had permission to share the underlying data.

Our recommended minimum is limited access, validated inputs, explicit approvals, and a protected activity log showing requested actions, tool results and confirmed outcomes. Keep sensitive data out of logs where possible. The log should help a person reconstruct events, not merely repeat the assistant’s explanation; durable event records are a distinct component in Anthropic’s Managed Agents design.[3]

Before granting write access, test ordinary requests alongside missing details, unavailable slots, timeouts, duplicate submissions and hostile retrieved text. Measure correct completed bookings, unauthorized writes, duplicate bookings, appropriate handoffs, elapsed time and cost per completed task. These are proposed evaluation measures—not benchmark results or claims about a deployed product.

Costs, tokens, and whether you need an agent

An agent’s additional model calls can trade speed and cost for flexibility.[1] Evaluate the whole task: model usage, paid tools, runtime and human review. Compare that with a simpler workflow on the same cases, including failures, rather than comparing only the price of one answer.

In language-model documentation, tokens are chunks of text processed by the model.[5] They are not cryptocurrency assets. The tool-call architecture described here does not require a blockchain or crypto token; those would be separate product choices, not prerequisites for choosing tools and using their results.[1][2]

For related AITI analysis—not independent corroboration—see Bankr’s agents and BNKR economics and when an AI product needs a token.

Do you need an agent? Our quick decision checklist:

  • If the steps are known and stable, start with an ordinary workflow.
  • If you only need an answer, try a single model response with appropriate source retrieval.
  • If the next useful step genuinely depends on intermediate results, test a bounded agent.
  • If you cannot define permission, success, cost limits and a safe stopping point, keep a person in control of consequential actions.

The goal is not maximum autonomy. It is useful work with enough evidence to tell what happened—and enough control to stop when the system cannot safely finish.

Sources