LEARN SOMETHING. BUILD SOMETHING.
Build a bounded assistant that can choose tools, inspect results, and stop safely. Start with a reliable workflow before adding autonomy.
6 short lessons · 1 project · video resources · no login for this guide
Before you start: Basic Python, functions, JSON, and HTTP requests.
Your toolkit: Python · tool calling · evaluation
Trending selection reviewed : GitHub’s 2026 Octoverse reports growing agent-driven development. Read the report. This is an editorial selection, not a live popularity ranking.
A workflow follows steps you wrote in advance. An agent chooses its next action from observations. If a task is simply fetch → summarize → save, fixed steps are easier to debug. Use an agent only when the next step depends on what a tool returns.
Try it: Write down a support-ticket task. Mark which decisions need a model and which can be ordinary Python.
A tool needs a name, a description, validated inputs, and a predictable result. Keep the first version read-only: searching a local FAQ is enough. Reject unknown fields and invalid types before a tool executes. Model-generated arguments are untrusted input.
Try it: Define lookup_faq(query: str) and return a JSON object with answer and source fields.
The controller sends the goal and available tools to the model. It validates any requested call, executes it, adds the result to context, and asks for the next step. Stop after a fixed number of steps, on repeated failures, or when a final answer is available.
Try it: Set a three-call budget. Make an unknown tool request fail with a clear error instead of executing arbitrary code.
A retrieved page may contain text telling the agent to ignore its rules. That text is data, not permission. Keep tool access narrow, redact secrets from traces, and ask for human approval before sending messages or changing records.
Try it: Add a fake instruction inside a FAQ document. Check that it cannot authorize another tool.
Create cases for a normal question, missing information, a malformed tool argument, an unavailable tool, and an instruction hidden in a document. Score correct tool use, grounded answers, and whether the agent stops. Log latency and call counts alongside correctness.
Try it: Run the same cases after a prompt change. Keep the old version if tool correctness gets worse.
Use three sample tickets and a local FAQ. Return category, suggested response, and evidence. Draft only; a human chooses whether to send the response. This gives you a useful automation without granting the model email access.
Try it: Deliver a CLI that reads a ticket, uses at most three FAQ lookups, and prints a reviewable JSON draft.
This controller sketch is pseudocode; lookup_faq must be implemented before using it.
MAX_STEPS = 3
allowed_tools = {"lookup_faq": lookup_faq}
# Controller outline (pseudocode):
# validate request → call an allowed tool → record observation
# stop on final answer, repeated failure, or MAX_STEPS
PUT IT INTO PRACTICE
Build the project described in the lessons, then verify these acceptance criteria:
Deliverable: your source code, a short README, and evidence for each check. Explain one tradeoff you made.
Videos open externally and do not autoplay. Provider exercises, certificates, and account requirements are separate from this free guide.
To prevent runaway loops and limit cost; a limit does not by itself make a tool safe.
Hugging Face Agents Course — continue with the original documentation and exercises.
Go deeper: continue to our existing AI Agents & Automation course.