Skip to main contentSkip to footer
ExamplescriptadvancedRunnabletool-agent

Level 3: Tool-Calling Agent — Scoped Autonomy

The agent decides which tools to call and in what order, but only within a fixed set of well-defined capabilities.

Key Facts

Level
advanced
Runtime
Python • Pydantic + Python Dotenv
Pattern
Agent autonomy inside a fixed capability boundary
Interaction
Live sandbox • Script
Updated
14 March 2026

Navigate this example

High-level flow

How this example moves from input to execution and reviewable output
Level 3: Tool-Calling Agent —… -> Use bounded tools -> Run the agent task -> Task framing -> Tool trace -> Resolution output

Start

Level 3: Tool-Calling Agent —…

Checkpoint

Use bounded tools

Outcome

Run the agent task

Why this page exists

This example is shown as both real source code and a product-facing interaction pattern so learners can connect implementation, UX, and doctrine without leaving the library.

Visual flowReal sourceSandbox or walkthroughMCP access
How should this example be used in the platform?

Use the sandbox to understand the experience pattern first, then inspect the source to see how the product boundary, model boundary, and doctrine boundary are actually implemented.

UX pattern: Agent autonomy inside a fixed capability boundary
The agent chooses the tool order
Tools are fixed and inspectable
Structured output summarizes autonomous action
Source references
Library entry
agents-agent-complexity-3-tool-calling-agent
Source path
content/example-library/sources/agents/agent-complexity/3-tool-calling-agent.py
Libraries
pydantic, python-dotenv
Runtime requirements
Local repo environment
Related principles
Design for delegation rather than direct manipulation, Replace implied magic with clear mental models, Represent delegated work as a system, not merely as a conversation, Optimise for steering, not only initiating

Model context

Model-dependentRequires native tool callingMedium reasoning requirementOrchestration compensates

Reliable native tool calling is required. Most open-source models support function calling but quality varies significantly across tool selection and parameter accuracy.

3-tool-calling-agent.py

python
"""
Level 3: Tool-Calling Agent — Scoped Autonomy
The agent decides which tools to call and in what order,
but only within a fixed set of well-defined capabilities.
"""

from dataclasses import dataclass

from pydantic import BaseModel
from pydantic_ai import Agent, RunContext
from dotenv import load_dotenv
from utils import print_agent_trace
import nest_asyncio

load_dotenv()

nest_asyncio.apply()


# --- Dependencies ---


@dataclass
class CustomerDeps:
    customer_id: str
    db: dict  # simplified — in production this would be a real DB client


# --- Output ---


class BillingResolution(BaseModel):
    action_taken: str
    refund_amount: float | None
    follow_up_needed: bool


# --- Agent ---


billing_agent = Agent(
    "anthropic:claude-sonnet-4-6",
    deps_type=CustomerDeps,
    output_type=BillingResolution,
    system_prompt=(
        "You are a billing support agent. Use the available tools to look up "
        "customer data, check policies, and resolve billing issues. "
        "Always verify the charge before issuing a refund."
    ),
)


# --- Tools (the agent decides when and how to use these) ---


@billing_agent.tool
async def get_customer_balance(ctx: RunContext[CustomerDeps]) -> str:
    balance = ctx.deps.db.get("balance", 0)
    return f"Current balance: ${balance:.2f}"


@billing_agent.tool
async def get_recent_charges(ctx: RunContext[CustomerDeps]) -> str:
    charges = ctx.deps.db.get("charges", [])
    return "\n".join(
        f"- ${c['amount']:.2f} on {c['date']}: {c['description']}" for c in charges
    )


@billing_agent.tool
async def check_refund_policy(
    ctx: RunContext[CustomerDeps], charge_description: str
) -> str:
    return (
        f"Policy for '{charge_description}': "
        "Duplicate charges are eligible for automatic refund within 30 days. "
        "Refunds over $100 require manager approval."
    )


@billing_agent.tool
async def issue_refund(
    ctx: RunContext[CustomerDeps], amount: float, reason: str
) -> str:
    return f"Refund of ${amount:.2f} issued successfully. Reason: {reason}"


# --- Run ---


if __name__ == "__main__":
    import asyncio

    deps = CustomerDeps(
        customer_id="cust_12345",
        db={
            "balance": 149.97,
            "charges": [
                {
                    "amount": 49.99,
                    "date": "2025-02-01",
                    "description": "Monthly subscription",
                },
                {
                    "amount": 49.99,
                    "date": "2025-02-01",
                    "description": "Monthly subscription",
                },
                {
                    "amount": 49.99,
                    "date": "2025-01-01",
                    "description": "Monthly subscription",
                },
            ],
        },
    )

    result = asyncio.run(
        billing_agent.run(
            "I was charged twice on Feb 1st for my subscription. Please fix this.",
            deps=deps,
        )
    )

    print_agent_trace(result)

    print(f"\nAction: {result.output.action_taken}")
    print(f"Refund: ${result.output.refund_amount}")
    print(f"Follow-up needed: {result.output.follow_up_needed}")
What should the learner inspect in the code?

Look for the exact place where system scope is bounded: schema definitions, prompt framing, runtime configuration, and the call site that turns user intent into a concrete model or workflow action.

@billing_agent.tool
async def get_recent_charges
async def issue_refund
billing_agent.run(
How does the sandbox relate to the source?

The sandbox should make the UX legible: what the user sees, what the system is deciding, and how the result becomes reviewable. The source then shows how that behavior is actually implemented.

Choose a billing scenario.
Run the investigation and inspect the tool trace.
Review the structured billing resolution before accepting the outcome.
SandboxAgent autonomy inside a fixed capability boundary
Scoped autonomy with visible tool use

This example turns the sandbox into a tool-using support workflow where the agent can investigate and act, but only through a bounded toolset.

UX explanation

The user asks for an outcome, not a sequence of steps. The experience should still make it clear which tools the system consulted and when the agent crossed from reasoning into action.

AI design explanation

The model is allowed to choose tools and ordering, but only from a curated set. That creates useful autonomy without handing over the entire runtime or hiding all intermediate work.

Interaction walkthrough

  1. 1Choose a billing scenario.
  2. 2Run the investigation and inspect the tool trace.
  3. 3Review the structured billing resolution before accepting the outcome.

User request

I was charged twice on Feb 1st for my subscription. Please fix this.

Allowed tools onlyAgent chooses orderStructured resolution

Tool trace

The trace appears as the agent decides which tool to call next.

Resolution

The final output should summarize what the agent did, not leave the action implicit.

Autonomy boundary

  • The agent chooses the tool order
  • Tools are fixed and inspectable
  • Structured output summarizes autonomous action
Used in courses and paths

This example currently stands on its own in the library, but it still connects to the principle system and the broader example family.

Related principles

Runtime architecture

Use this example in your agents

This example is also available through the blueprint’s agent-ready layer. Use the For agents page for the public MCP, deterministic exports, and Claude/Cursor setup.

Define triggers, context, and boundaries before increasing autonomy
Make control, observability, and recovery explicit in the runtime
Choose the right operational patterns before delegating to workflows