Chapter 42Giving Agents Real Tools: Web, Code, Files, and APIs

From Toy Tools to Real Capabilities

In Chapter 33 we built simple, safe tools to learn the mechanics. Real-world tools are different in kind, not just degree. Browsing the web, executing code, touching the file system, calling business APIs — these let an agent affect the world in consequential ways. With that power come two ever-present concerns. Real tools fail — networks drop, data is malformed, services time out — so reliability is essential. And real tools can cause harm — delete a file, send a wrong message, run dangerous code — so security is essential. Keep both in mind for every tool below.

Web Access: Search and Fetch

Web tools usually come in two parts: a search tool to find relevant pages, and a fetch tool to read a page's content. Together they let an agent pull in current information the model never saw in training. The challenges are instructive. Web content is messy and huge, so you must extract or summarize it before it floods the context window (Chapter 12). It is unreliable, so you must handle failures gracefully (Chapter 33). And — critically — fetched content can contain hidden malicious instructions aimed at hijacking your agent, a threat called prompt injection that we cover in Chapter 45.

def fetch_page(url):
    if not url.startswith("https://"):
        return "Error: only https URLs are allowed."
    try:
        text = download_text(url)
        return summarize(text, max_words=500)   # extract, don't dump the whole page
    except Exception as error:
        return f"Could not fetch the page: {error}"

Code Execution: A Powerful, Dangerous Tool

Letting an agent run code is one of the most powerful capabilities you can grant it — it can calculate, transform data, automate tasks, and solve problems no fixed tool anticipated. It is also one of the most dangerous, because arbitrary code means arbitrary actions: deleting files, accessing the network, consuming resources. The non-negotiable safeguard is a sandbox — an isolated, restricted environment where code runs without access to anything it should not touch. Never run agent-generated code directly on your real system.

def run_code(code):
    # Run ONLY inside a locked-down sandbox: no file access, no network,
    # strict time and memory limits. Never execute on the host directly.
    return sandbox.execute(code, timeout=5, network=False, filesystem=False)

File Access: Reading and Writing

Agents often need to read and write files — load documents to process, save results to disk. The risks are reading files it should not see and overwriting or deleting files it should not touch. The defense is to scope file access tightly: confine the agent to a specific directory, validate every path, and be especially careful with anything that writes or deletes. An agent that can roam your entire file system is an accident waiting to happen.

import os

SAFE_DIR = "/app/agent_workspace"      # the only place the agent may touch

def read_file(path):
    full = os.path.abspath(os.path.join(SAFE_DIR, path))
    if not full.startswith(SAFE_DIR):  # block escaping the safe directory
        return "Error: access outside the workspace is not allowed."
    with open(full) as f:
        return f.read()

Calling External APIs

Much of an agent's real-world usefulness comes from calling external services — weather data, databases, payment systems, business tools. Increasingly these connections are made through MCP (Chapter 40) rather than hand-written, but the practical concerns are the same either way. You must handle authentication (keep secrets in a .env file, Chapter 3), errors (services fail), and rate limits (retry with backoff, Chapter 30). An API tool that does not handle these will work in a demo and break in production.

def get_weather(city):
    try:
        response = call_api("weather", {"city": city}, key=os.environ["WEATHER_KEY"])
        return response["summary"]
    except RateLimitError:
        return "The weather service is busy; try again shortly."
    except Exception as error:
        return f"Could not get the weather: {error}"

The Reliability Mindset

Real-world tools fail far more often than beginners expect — and that is normal, not exceptional. Robust agents are built to expect failure: they validate inputs before acting, catch errors, return useful error messages to the agent so it can adapt (Chapter 33), and retry transient failures with backoff (Chapter 30). The difference between an impressive demo and a dependable product is almost entirely in this unglamorous failure-handling. An agent that assumes its tools always succeed will work beautifully until the first hiccup, then fall apart.

The Security Mindset

Real tools are the main place an agent can cause harm, so each one is a door that must be guarded. The principles, gathered from across the book, are: grant each tool the least privilege it needs; sandbox anything that runs code; validate every input and scope every path; require confirmation for dangerous or irreversible actions; and beware injected instructions hiding in content the agent fetches. Every real-world capability is a potential avenue for harm, which is why Chapter 45 is devoted entirely to agent safety. Treat power and caution as inseparable.

Putting It Together: a Capable Agent

An agent equipped with well-guarded web, code, file, and API tools — wired up through the loop, ReAct reasoning, memory, and perhaps MCP that you have learned — is genuinely powerful. It can research a question online, run a calculation to analyze the findings, read your documents for context, call a service to take an action, and remember what it did. This is what real agents are made of: not a single magic trick, but the careful composition of capable, reliable, well-secured tools around a reasoning loop. You now have every piece needed to build one.

Summary

Real-world tools — web access, code execution, file access, and external APIs — are what make agents genuinely useful, and each must be approached through the dual lenses of reliability and security. Web tools require extracting rather than dumping content, handling failure, and guarding against injected instructions. Code execution is immensely powerful and must run only in a sandbox. File access must be tightly scoped to a safe directory with validated paths. API calls need authentication, error handling, and rate-limit backoff, and are increasingly made via MCP. Throughout, the reliability mindset expects failure and handles it, and the security mindset treats every powerful tool as a guarded door — because power and caution are inseparable, and that careful composition is exactly what a capable real-world agent is made of.

This completes Part VIII — you can now build real agents with frameworks, standardized tools via MCP, multiple cooperating agents, and real-world capabilities. Part IX turns to the cutting edge: advanced retrieval, evaluating and observing agents, safety in depth, cost optimization, and deployment, beginning with agentic and graph-based RAG in Chapter 43.