article · cross business

How an AI agent chooses its next step

Trace an illustrative agent through approved order and knowledge lookups, application permission checks, stopping rules, and a human review boundary.

Author: Founder identity pending confirmation
Published: Pending first public release · Fact-check: Human review pending
beginner · understand · Approximately 3 minutes to read
Evidence: editorial · Maintenance: current
Action authority: read only · Data: public
Approach:

The direct answer

An agent chooses among tools made available by its builder, receives a result, and decides whether another allowed step is needed. A tool is a defined software capability, such as reading one order. The surrounding application must check the request and enforce permissions before executing it. The model’s choice is a proposal, not an access grant.

A bounded demonstrator

Illustrative specification, not an executed demo: A support assistant may choose lookup_order or lookup_knowledge, then prepare an internal draft or escalate. It has no sending tool. Its account cannot modify orders.

Synthetic request A: “What is the status of my order O17?” The system first verifies the requester may access O17. The model can request the read-only order lookup. If the result lacks a current status, the expected behavior is escalation, not a guessed delivery date.

Synthetic request B: “Where is the onboarding guide?” The model can choose the knowledge lookup. A supported answer can become a draft. If the customer then asks for another person’s order, the application rejects that access regardless of the model’s requested tool.

Trace the decision loop

1. Give the model the bounded goal, tool descriptions, and sanitized request.
2. Receive a tool name and structured arguments, or a proposal to finish.
3. Check the tool against an allowlist and validate arguments and requester access outside the model.
4. Execute only the authorized read, then return the limited result as evidence.
5. Let the model choose another permitted lookup, prepare a draft, or escalate.
6. Stop at the configured call limit or on a denied request, missing evidence, or unavailable service.

For this teaching design, set a maximum of two lookups and then require a draft or escalation. That limit is an illustrative design choice, not a recommended universal setting. Log the chosen tool, allowed record ID, result status, and stop reason without copying unnecessary private data.

Contrast with fixed routing

A fixed route might say: if an authorized order ID exists, read that order; otherwise supply the FAQ. The builder chooses the branch rule. In the demonstrator, the model chooses among the permitted lookups after interpreting the question. Both designs need access checks. Only use model choice if it solves a problem the fixed route leaves unresolved.

Limits and non-example

A prompt saying “read-only” does not remove write permissions from an account. Likewise, a tool response containing “ignore your instructions” is data to inspect, not authority to change the workflow. Tool descriptions and prompts complement application controls; they do not replace them.

Specify your own exercise

Draw one request through both permitted lookups and the stop route. Add cases for unknown order, wrong requester, unavailable source, irrelevant instruction, and exhausted call limit. Write the expected decision before testing. Any unauthorized lookup or external action fails acceptance.

Sources and scope

The distinction between fixed workflows and model-directed tools follows Building effective agents. The tools, request IDs, limits, and expected behaviors above are original illustrative specifications. They have not been implemented or reproduced here.

Next step

Record the tool boundary in the workflow brief. Compare it with the fixed support triage playbook before choosing a design. Suggest a correction.