Build an AI Agent: Tool Calling, Execution Limits and Tests

Start with one read-only tool and a four-turn limit. Verify which actions the model requests, which actions your program allows, and how failures stop execution before adding memory or multiple agents.

This handbook begins with a Python exercise, then connects tool execution to MCP, RAG and evaluation. The public tutorials can be read without signing in; course access follows the course's own rules.

#What changes when a chatbot can use tools?

A tool-calling model can request lookup_order({"order_id":"DEMO-1001"}). The application validates the tool name and arguments, performs the lookup and returns the result to the model. The model then answers or requests another action.

The model proposes actions; your application controls execution. Never turn tool arguments into code through eval() or a shell.

text复制
Question → model tool request → allowlist and argument checks
                                     ↓
Answer ← model reads observation ← data or explicit error
                 ↓
      Repeat only within the turn limit

#Run your first exercise

Open the Python tool-calling lab. Download tool_agent.py↗ and test_tool_agent.py↗ into one folder:

bash复制
python3 tool_agent.py
python3 -m unittest -v test_tool_agent.py

Python 3.10+ is required; no third-party packages are needed. Default mode uses a scripted model substitute and a synthetic order, with no API calls or usage charges:

json复制
{"mode": "fixture", "answer": "DEMO-1001: shipped (synthetic_fixture)", "steps": 2}

This verifies the execution loop, not LLM reasoning quality. The lab includes a separate live-model adapter and explains what remains unverified.

#Choose the smallest architecture that solves the task

This is engineering guidance, not a requirement to replace stable workflows with agents.

#Four boundaries to explain before adding features

1. Tool permissions: this exercise reads synthetic orders. It cannot refund, send messages or modify a database.
2. Evidence: an unknown order produces order_not_found, never an invented delivery status.
3. Limits: one tool call per turn, at most four turns; a live HTTP request has a 20-second timeout.
4. Validation: offline tests check program behaviour. Live-model accuracy, cost and provider availability need separate checks.

#Where does MCP fit?

MCP connects an AI application with services that expose tools and context. It does not require one particular model or replace your application's authorisation rules. Continue with the MCP chapter after understanding tool execution. Official MCP architecture↗

#Your next step

• Run the tool-calling lab, then try a missing order.
• Explore RAG and check that answers map to evidence.
• Build an evaluation set from observed failures.
• Review the AI Engineer Bootcamp curriculum and trial information to assess the projects and prerequisites.

Technical references: OpenAI function calling↗, MCP architecture↗. Checked on 2026-09-07: the offline script and nine tests ran successfully; live-model mode was not executed during this verification.