Tool Calling and the Agent Loop

TL;DR: Tool calling lets a model propose an operation that an execution service may carry out. Trace where that service runs, which credentials and task permissions it uses, and how it validates, admits and observes the operation. Schema compliance and a final assistant message do not establish authorization or completion.

What you should be able to do

Walk a proposed tool call through execution and back into context. Locate the identity, policy, budget and outcome checks for both application-run and provider-run tools. Explain why narrowing a tool description, delegating a user token or counting completed steps does not by itself bound the entire workflow.

Follow one call

Return to the original fictional makerspace assistant. A signed-in member asks to move their own booking to another available workshop slot. The application exposes a scheduling operation with a defined input structure. The model can propose the booking and desired slot; the booking service decides whether the change is permitted and available.

A common application-managed loop is:

1. Supply the permitted tool definitions and eligible task context.
2. Receive a proposed call or another supported response type.
3. Validate and authorize the proposal, then execute only an admitted operation.
4. Record the service outcome and return the appropriate tool result.
5. Continue, finish, or stop under an application-enforced rule.

This is a common pattern, not a claim that every agent implementation has the same loop or ends with a text answer. Some systems schedule work, parallelize operations or use provider-managed execution. The security review follows the actual services and effects.

The model’s output has no independent power to change the booking. The executor and resource service supply that capability. A framework may invoke them automatically, which makes their default configuration relevant; it does not remove the need to identify the checks.

Locate the executor

A client function call normally returns to application code that implements the operation. A hosted tool can instead execute inside the provider’s infrastructure. There may be no application callback before each internal step.

As a dated example, the OpenAI function-calling guide, checked November 2026, documents application-side execution followed by a tool result. Anthropic’s tool overview, checked the same month, explicitly distinguishes client tools from server tools that run on its infrastructure. These are interface examples, not interchangeable guarantees.

For a hosted operation, inspect the available scope restrictions, credentials, approval controls, destinations and observations before enabling it. If the service cannot enforce a required boundary or expose evidence needed for the decision, narrow the capability or choose another execution path. Do not promise that “our orchestrator checks every call” when the integration never receives those calls.

Separate the checks

A schema can restrict more than shape. It may require fields, limit types, enumerate permitted values and constrain lengths or ranges where supported. Those checks remove unsupported representations. They do not establish every fact needed to authorize a particular transaction.

For the booking change, inspect distinct questions:

A field named member_id is not trusted identity merely because it has the right type. Resolve the principal through the authenticated service context. Likewise, a call ID links protocol messages; it is not automatically an authorization proof or an idempotency key accepted by the destination.

An enum can be a useful restriction while still allowing a wrong choice. A valid slot may be unavailable, belong to another workshop, or differ from the one the member confirmed. Evaluate those relations using current trusted state.

Bound authority to this task

A shared service credential may have broad resource access. The backend must still enforce the member and task restrictions; the credential’s breadth increases what a missing check could expose. Delegated user credentials can narrow that reach, but the user may be allowed to do more than this particular task requests.

An assistant asked to explain a booking does not need to cancel every booking the member owns. Intersect resource permission with task scope, allowed operations and relevant approval. A separate agent identity can improve attribution, but its name does not prove least privilege.

Offer a limited tool set and maintain an execution allowlist. Omitting a description is useful input control, but a handler must still reject unregistered or disallowed requests. Review generic capabilities too: a narrowly named tool may invoke a broadly privileged backend, and a general-purpose execution tool may reach operations absent from the visible catalog.

When confirmation is required, bind it to the actual action and significant parameters. Recheck if the proposed change or relevant state differs. The human oversight concept develops that binding; this lesson locates where it enters the loop.

Admit work against real limits

Bound the resources relevant to the task: tool operations, elapsed time, concurrency, model generation and downstream effects. One step can launch several costly or long-running operations. A completed-call counter does not include all work already accepted elsewhere.

In an original synthetic budget, a run has a 50-credit allowance, 18 credits already spent and 24 reserved for pending work. Only eight remain available. A proposed operation requiring a twelve-credit reservation cannot be admitted merely because the dashboard shows only eighteen spent.

A production reservation scheme needs reliable upper limits or a stated bound on possible overshoot, plus coordinated updates under concurrency. If a provider or tool cannot bound its eventual cost, say so. Post-hoc accounting helps detect overuse; it cannot guarantee that a cap was never crossed.

Repeated identical calls may be an accidental loop, a legitimate poll or a retry after a lost result. A universal “three identical hashes means stop” rule ignores those semantics. Use task-specific retry and polling limits, stable operation identity and destination-supported duplicate handling. Keep an accepted operation unresolved until its outcome is established; do not create a new booking change just because the first response timed out.

Treat returned data according to its source

A trusted booking service may return a member-authored comment. The service’s identity establishes where the response came from, not that every field is a trustworthy instruction or verified fact. Preserve that distinction when the result re-enters model context or a saved summary.

Validate the result structure and join it to the intended call. Keep authoritative status fields separate from free text. A provider response, an intermediary or a tool integration may be faulty or compromised, so the execution boundary must not depend on fluent prose claiming that checks already happened.

Store enough protected evidence to explain admission, denial and completion without copying all private context into every log. The relevant record connects the principal, task, operation, policy decision and observed result. Hashing a message alone does not establish who supplied it or whether an external effect occurred.

Work the changed conditions

Write a trace for the fictional booking change. Identify the source of identity, booking ownership, slot availability, any required confirmation, the resource reservation and the completion record.

Now change two facts separately. First, the same member requests only an explanation; show which write capability should disappear. Second, the original scheduling call times out after acceptance; state what remains unknown and which record you must reconcile before retrying. A good answer separates task authority from general user permission and operation uncertainty from a failed request.

For deeper work, use excessive agency, agentic AI security, structured-output validation and the engineering-agent course.

Key takeaways

• Locate the actual executor and its enforcement points, including hosted tools.
• Schema constraints, resource permission and task authority are separate checks.
• Include admitted concurrent work when reasoning about limits.
• Verify actual effects and preserve unknown outcomes before retrying.