Mastery: from tools to agents

A user asks, “Why are summers warmer than winters?” The assistant has a weather tool. Should it call the tool?

Answer: Usually no. The user wants a stable scientific explanation, not current local conditions. A call adds latency and cost without supplying necessary evidence. If the user instead asks, “Is today warmer than yesterday in Cairo?” a weather or historical-observation tool is appropriate.

Now consider “What is 17% of 8,492?” A model may often calculate it, but a deterministic calculator is appropriate when exactness matters. The decision is not “models know arithmetic” versus “models know nothing.” It is whether the task benefits from externally verified, deterministic computation.

The lesson: tool selection includes choosing none, and it follows the user’s intent rather than keywords.

An application exposes:

{
  "name": "account",
  "description": "Handles accounts.",
  "parameters": {
    "type": "object",
    "properties": {
      "action": { "type": "string" },
      "user_id": { "type": "string" },
      "admin": { "type": "boolean" }
    }
  }
}

Name at least five weaknesses.

Answer: The name and description are vague; unrelated reads and writes are combined; action is unconstrained; required fields are absent; extra properties are not rejected; user_id may permit cross-account access; and admin wrongly asks the model to assert authorization. The implementation also lacks visible limits, confirmation behavior, and a result contract.

Split the capability into narrow tools such as get_own_account_profile and request_account_closure. Derive actor, tenant, and roles from the authenticated session. Use typed fields, semantic validation, per-request allowlists, and explicit approval for closure.

The lesson: schemas guide model proposals, while code enforces identity and policy.

A user says, “Create a 20-minute focus block at 2 p.m.” Put these events in order: provider execution, final natural-language response, model proposal, application validation, user request, normalized result.

Answer: User request → model proposal → application validation and authorization → provider execution → normalized result → final response. If confirmation is required, it belongs before execution and must bind to the exact proposal.

The model’s call:

{
  "name": "create_calendar_event",
  "arguments": {
    "title": "Focus block",
    "starts_at": "2026-07-19T14:00:00+04:00",
    "ends_at": "2026-07-19T14:20:00+04:00",
    "timezone": "Asia/Dubai"
  }
}

does not prove creation. Only a verified provider result licenses “I created it.” The application executes the tool; the model proposes the call.

A payment provider times out after the application sends a request. Should the application report failure and retry with a new request?

Answer: No. The outcome is unknown: the provider may have completed the payment. Query status using an operation ID or retry with the same idempotency key if the provider guarantees duplicate suppression. Keep bounded retry and time budgets. If the state remains unknown, say so and escalate or reconcile.

Classify failures before choosing a response. Invalid arguments need correction. Permission denial needs authorization or a different actor, not retry. Rate limiting may allow bounded backoff. A conflict may require refreshed data. A timeout on a write requires verification.

The lesson: truthful failure is a product feature, and retries belong in controlled application logic.

Before releasing a tool-enabled assistant, require evidence in four areas.

Contracts and selection

• Tools have distinct operation-specific names and bounded descriptions.
• Schemas reject missing, malformed, and extra arguments.
• Evals include tool-required, no-tool, ambiguous, unsupported, and multi-tool requests.
• Selection and arguments are measured by risk slice, not only average accuracy.

Execution and safety

• Authentication comes from trusted application state.
• Authorization checks the exact actor, resource, action, and current conditions.
• Side effects use confirmation where appropriate and duplicate-resistant execution.
• Credentials have least privilege; results and logs minimize sensitive data.

Failure and truthfulness

• Timeouts, rate limits, conflicts, invalid results, and partial success are tested.
• Retries are bounded and restricted to safe cases.
• Unknown writes enter reconciliation rather than becoming automatic success or duplicate execution.
• Final claims are checked against normalized tool results.

Operations and learning

• Trace IDs link proposals, gates, attempts, results, and responses.
• Metrics and alerts reveal selection drift, denials, latency, and duplicate risk.
• A staged rollout, pause control, and human escalation path exist.
• Incidents become redacted regression cases.

One overall model score cannot replace these system checks.

Structured outputs and tool calls both use machine-readable data. Structured output asks the model to produce typed data for application consumption. A tool call is a particular typed proposal to invoke a capability. In both cases, code must parse and validate the result.

Agents repeatedly choose actions, use tools, observe results, and continue toward a goal. The loop increases autonomy and magnifies every tool-design decision. Agents need limits on steps, time, cost, and permissions, plus clear stop conditions. Calling a system an agent does not transfer execution responsibility from the application.

Model Context Protocol (MCP) standardizes how clients discover and connect to tools and data sources. It can reduce custom integration work, but a standard connection is not an authorization policy. The host still chooses which server and tools to expose, protects credentials, validates calls, and controls side effects.

Human in the loop (HITL) adds review where consequences justify it. A person may approve a typed proposal before the application executes a payment, message, deletion, or other consequential action. The interface should show exact arguments and source evidence. Human review complements deterministic controls; it does not replace schema validation, permissions, or idempotency.

Together, these concepts form a layered system: structured contracts make proposals inspectable, tools connect language to capabilities, agents sequence calls, MCP standardizes connections, and HITL inserts accountable judgment. The application remains the control plane that decides what runs.