Get In Touch
0% complete

Application and agent development · Lesson 2 of 3

Agents, tools, and function calling

Give an agent a small, permissioned set of tools with validated arguments.

Lesson

An agent can select tools and repeat steps toward a goal, which adds flexibility but also increases uncertainty and operational risk. Each tool should have a narrow purpose, typed inputs, bounded output, and least-privilege credentials. Validate arguments before execution and authorize the requested action in trusted application code. A model suggesting a tool call is not evidence that the user is allowed to perform it. Set limits for steps, time, token use, and external calls. Require confirmation for destructive or consequential actions, and make retries idempotent where possible. Record tool selection and outcomes for evaluation while redacting sensitive values. Begin with deterministic routing and add agent autonomy only when tests show it improves the target task. A tool definition is an interface, not a grant of authority. Give each tool a narrow name and schema, reject extra or malformed fields, and check the current user’s permissions immediately before execution. Prefer read-only tools first. For writes, use confirmation, idempotency keys, and an audit record; bound the number of agent turns and external calls. Return only the minimum information the next step needs. Test attempts to supply another user’s identifier, repeat an action, pass oversized arguments, or use a tool for an unintended purpose. A model-selected function must never bypass normal application authorization. Implementation drill: trace one representative request through the stages in the diagram. Write down what enters each stage, what output or evidence it produces, and which identity is allowed to perform it. Then test an empty input, an unauthorized request, a dependency timeout, and an unexpected result. For each case, state whether the application should retry, reject, abstain, or ask a person for help. Keep the observed failure as a regression example so changes to prompts, models, data, or code can be checked against the same behavior. Practice task: Who should enforce whether a user may execute an agent-requested action?

Visual guide

Put guardrails around tool use

  1. Step 01 Propose

    Model requests a named tool.

  2. Step 02 Validate

    Check arguments and schema.

  3. Step 03 Authorize

    Enforce user permissions.

  4. Step 04 Execute

    Run bounded action and record result.

Code examples

Validate a tool request before execution
PYTHON 
def lookup_ticket(arguments, current_user):
    ticket_id = arguments.get('ticket_id')
    if not isinstance(ticket_id, str) or not ticket_id.isalnum():
        raise ValueError('Invalid ticket id')
    if not can_read_ticket(current_user, ticket_id):
        raise PermissionError('Not authorized')
    return read_ticket(ticket_id)
Expected output
The application validates input and authorization independently of the model.

Key points

  • Treat tool calls as untrusted requests that require validation and authorization.
  • Limit agent steps, permissions, retries, and external side effects.
  • Keep consequential actions behind confirmation or human review.

Check your understanding

Practice

Who should enforce whether a user may execute an agent-requested action?

Your learning progress

Finish this lesson