An agent is software: a model in a loop with tools. This module puts one to work on the kind of repetitive job the automation page names, with a person approving anything that leaves the building.
The meetup talk, next, runs the module in twenty minutes (the SI in its title is simply the name federal agencies now use for AI), and The agent loop and its tools builds the loop itself. The sections below show where an agent sits in the course’s chain and what the three lessons build.
The same chain, with an agent in the middle
The first four modules build an app along one chain: a user story names the job, scenarios say what done right means, the code does the work, tests prove it, and the owner runs it after launch. One feature, scope to launch walks it end to end.
An agent goes into the same chain without changing its order. That is why the Sean Dinwiddie’s Webmastery team, which builds in Haskell, TypeScript and Rust, builds agents too: the craft is the chain, and the stack follows the job. The lessons write the agent in TypeScript, checked by strict tsc and tested in Vitest.
Take the first job on the automation page, the same thing typed twice, with the order arriving by email rather than by phone, so an agent can read it. The module’s last lesson builds it, calling the page’s spreadsheet the order sheet, and along the chain it reads like this:
- The user story names the job. As the person who takes the orders, I want each emailed order drafted into the register, the calendar and the order sheet, so that I check it once instead of typing it three times.
- The scenarios say what done right means. A complete order is drafted once, for one check; an email with no pickup day becomes a question rather than a guess; nothing is entered until a person approves it.
- The agent does the work. Its instructions carry the shop’s know-how: how an order reads, and when to ask rather than guess. Its tools read the email and the menu and leave a draft or a question, and none of them can touch the register, the calendar or the order sheet: those wait for a person.
- The tests and evals prove it. Tests run the loop against a scripted model, so they are quick and give the same answer every run. Evals run the real model over real days’ email, before and after every change.
- The owner runs it after handover, with training and written notes, as the automation page promises.
Four words, plainly
- Agent. A model in a loop with tools. It reads the job, asks for a tool, reads the result and goes round again, until it answers, or stops for a reason the loop names, such as a refusal or a limit. Anthropic’s Building effective agents describes agents the same way: models using tools in a loop, steered by what each step returns.
- Tool. A function the program offers the model, with a contract: a schema for what goes in and, in this module, a typed result and a typed failure. The model only asks for a tool. The program decides whether to run it, and that is where every rule in this module lives.
- Skill. Packaged know-how: a folder holding a
SKILL.mdfile, whose frontmatter gives a name and a description and whose body gives instructions, with any scripts and reference files it needs beside it. Only the name and description load up front; the instructions load when a task matches, and the other files when needed. - Eval. A set of tasks from real work, each with the behavior it should produce, run against the real model before and after a change. A test checks the code; an eval checks what the model does with it.
Anthropic calls a skill’s staged loading progressive disclosure, and published the format as an open standard in December 2025. Its guide to writing skills asks for the evaluations before the instructions, the order BDD asks for: say what done right means, then build.
A person approves what leaves the building
Inside the building, the agent reads and drafts. At the door stands a person: anything that changes something or goes out, such as sending an email, taking a payment, deleting a record or booking a slot, waits for someone to approve it. A draft costs nothing to throw away, and a sent email can’t be unsent.
Three more rules keep the door honest. Each task gets only the tools it needs, so the order-entry agent has no tool that sends email at all. Text from outside is data, never instructions, and the program holds that line, not the model: an email that tells the agent to ignore its rules changes nothing the program lets it do. And every action leaves a log line, so the owner can read what the agent did.
OWASP ranks prompt injection first among the risks to apps built on large language models (LLM01:2026). It names a web page, a document and an email among the ways in, and its controls include least privilege for each operation and a person’s confirmation before any privileged, irreversible or externally visible action. The module’s last lesson tests each rule.
It is the course’s rule about effects, at the scale of a business: the model proposes, plain code and a person decide what happens, and the effects wait at the edge, the habit the lecture What Is a Function? teaches for a single function.
To try it, take one job from your own week and ask two questions: does its input vary, and is a wrong step caught before it leaves the building? Two yeses make it a job for an agent.
How the module runs
Three lessons after this opener and its meetup talk, each building on the one before:
- The agent loop and its tools builds the loop as a function over a model, with typed tools and typed stops, and tests it against a scripted model, so no test calls a real one.
- Writing an agentic skill writes a skill for a local business task from a user story and its scenarios: its description, its instructions and its evals, with two skills from this site’s own repository as worked examples.
- Automating a business process with a person in the loop takes the emailed order from its user story to handover, with the approval gate, a tool list per task and a test that an email’s instructions change nothing.
The code is TypeScript under strict tsc, with Vitest tests named after the scenarios they prove. No machine learning is assumed, only the habits the earlier modules teach. Module 6 follows, opening up the protocols and harnesses around the loop and the model at its center.