Tool calling lets an AI application connect a language model's interpretation of a request to functions that retrieve information or perform work. The difficult part is deciding what the application should allow, what each function should mean, and how to know whether an action actually succeeded. Those decisions belong in the tool design and execution code.

A practical starting point is an assistant that reads project tasks and proposes a due-date change. Reading a task, drafting a change, and applying it are separate steps with different consequences. Keeping them explicit makes the agent easier to test and gives users a clearer picture of what happened.

Separate the proposed call from its execution

In a client-executed tool workflow, the model returns a structured request for an action. Your application validates the call, executes the permitted operation, and sends the result back for the model to use. The Anthropic tool-use overview documents this round trip and distinguishes client tools from tools executed on the provider's infrastructure. This article focuses on functions your application controls.

That boundary is useful because language understanding and authority are different responsibilities. The model may infer that “move the review to Friday” refers to a task update. The application must still resolve the task, establish the relevant date, identify the acting user, and enforce permission to make the change.

The AI agent API guide provides a broader map of the request, tool, result, and stopping decisions in an agent workflow.

Give each tool one clear purpose

Prefer a narrow tool such as read_task over a universal tool that accepts arbitrary operation names, database queries, or destinations. A small interface is easier to describe, constrain, audit, and test. It also makes failures more understandable: the system can report which business operation could not be completed.

For the task assistant, begin with read_task and prepare_due_date_change. Add apply_due_date_change only after the read and preparation flow is reliable. The preparation result can include the task title, current date, proposed date, and a stable reference to the pending change.

Choose names that describe effects. A tool called manage_task leaves too much interpretation to the caller and maintainer. A tool called update_task_due_date makes its scope visible. Its description should explain required context, valid arguments, and whether the operation changes state.

Design arguments that eliminate avoidable ambiguity

Use a task identifier obtained from an authorized lookup rather than a free-text task name when possible. Require a defined date format. Carry the expected resource version if the underlying API supports conflict protection. Keep optional fields limited to things the operation genuinely needs.

This is an illustrative application-level call, not an available live service:

{
  "tool": "prepare_due_date_change",
  "arguments": {
    "task_id": "task-42",
    "due_date": "2025-06-20",
    "expected_version": "version-7"
  }
}

Do not make the model supply trusted account ownership or permission flags. Derive those from the authenticated application session and authoritative records. A field that says the caller is an administrator is just text until the execution layer verifies the actual identity.

For “Friday,” use the user's relevant date context and time zone. If more than one interpretation could materially change the action, ask for the missing information before preparing the update. Guessing a date can produce a technically valid call with the wrong outcome.

Validate and authorize every execution

Validate the argument structure before invoking a function. Then check the business constraints: the task exists, the user can access it, the requested date is allowed, and the expected version still matches. Apply these checks even when the model selected a tool that was already listed as available.

Tool availability can simplify the model's choices, but it should not be the only authorization control. A user's access may change after a conversation begins, and a resource can move between projects. The execution layer should evaluate the request against current authoritative state.

For consequential changes, make the approval policy explicit. A review screen can present the exact target and proposed change before execution. Routine low-impact actions may have standing authorization in a product's settings. The key is for the application to enforce a defined policy instead of treating persuasive model text as permission.

Return results that support truthful reporting

Design tool results as carefully as arguments. Include a clear outcome, the affected resource identifier, and a concise description of the observed state. Distinguish prepared, applied, rejected, and uncertain outcomes. A prepared change should never be presented as a completed update.

If execution succeeds, return the authoritative result or retrieve the relevant state when the API contract calls for it. If execution fails, provide an error category and an actionable explanation. Avoid returning a large raw stack trace or unrelated private records to the model.

The final user-facing answer should follow the evidence. “The due date is now June 20” requires confirmation from execution. “The proposed change is ready for review” describes a different outcome. This distinction keeps the agent's language aligned with what the application accomplished.

Plan for duplicates and uncertain outcomes

Network failures can occur after an operation has been accepted but before its result reaches your application. Record an operation identifier before making a consequential call, and use the underlying API's supported deduplication mechanism when one exists. Understand its scope and retention behavior rather than assuming a request identifier prevents duplicates automatically.

When the outcome is uncertain, reconcile against authoritative state before repeating the action. For a task date, read the task and compare its current version and value with the intended change. For an operation that creates a new object, use an appropriate lookup or status mechanism provided by that service.

Do not let a generic “try again” instruction trigger unlimited execution. Set a per-turn tool budget, a deadline, and a maximum number of repair attempts. Stop with a useful explanation when the system cannot establish the result.

Be deliberate about parallel execution. Independent task reads may be suitable for concurrent requests within the service's limits. Two writes to the same task introduce a different problem because one may invalidate the other's assumptions. Keep dependent changes ordered, and carry the result of the first operation into the next decision. A faster response is useful only when the resulting state remains understandable and consistent with the user's request.

Treat retrieved content as task data

A task description may contain text that looks like an instruction to the agent. A document may ask the assistant to ignore its rules or send information elsewhere. Keep such content in the role of evidence to inspect, not authority to change application policy.

Support that separation with code. Limit tools to allowed destinations, use scoped credentials, validate identifiers, and keep sensitive context out of calls that do not need it. Prompt instructions can explain the boundary, while execution controls make the boundary meaningful.

Our AI bot integration page considers these boundaries in conversational experiences, where user requests and retrieved messages may appear close together.

Test decisions as well as functions

Unit checks can verify that the update function rejects an invalid date or an unauthorized task. An agent evaluation should also check whether the right tool is selected, whether missing context prompts a question, and whether the final response describes the actual result.

Include a read-only question, two tasks with similar names, an expired permission, a conflicting edit, a tool timeout, and content that attempts to redirect the agent. Record the expected stopping behavior for each. A test that only checks for a successful tool call misses the important cases where no change should be made.

When adding another tool, rerun these scenarios. More capabilities can change the available decision paths, even if existing function code stays the same. The structured-output guide offers complementary techniques for defining and validating the data passed between steps.

Conclusion: make actions accountable

A useful tool-calling agent has narrow functions, explicit arguments, independent authorization, bounded execution, and results that support accurate reporting. Build one complete operation through those boundaries before expanding the tool set. That produces an assistant whose actions your team can explain and whose failures leave enough evidence to recover deliberately.