The Author in the Machine // Session 201 / 14
Session 2 // building the agent

We're building
an agent. Together.

Today: what one is actually made of — and why anyone can now build software just by describing it.

Where we got to

The ladder so far

01Machine learning — the predictive layer your bank already runs (scoring a transaction as suspicious).
02Generative models — same family, but they produce new text. The model is the author.
03The desk — the author can only use what's on it right now. That desk is the context window.
04Agents — today. The next rung up.
The frame for today

An agent is made of things
you can write.

Not code — instructions and tools, both plain English. Today we take a tiny, silly agent apart so you can see every part… because soon we write yours.

What an agent is
Instructionswhat it's for
Toolsthings it can do
Memorythe conversation
the MODEL
think → act → observe → repeat
agent = model + instructions + tools, on a loop.
Part 1 of an agent — the instructions
# the lunch agent's entire "brain"
You are the Lunch Decider — cheerful
but extremely decisive.

1. ALWAYS check the menu + calendar
   tools first. Tools, not vibes.
2. Recommend exactly ONE dish; defend
   it in two sentences.
3. Under 20 min free? Pick the fastest.
4. If they push back, hold once, then fold.

Building one
starts here.

That's the whole brief — plain English, no code. Writing this is building the agent. You could write it. We'll write your controls agent's brief together.

Part 2 of an agent — the tools
get_canteen_menu(day)
  "Get today's menu. Use whenever they
   ask what to eat — never guess."

check_meeting_calendar(time)
  "How much free time they have
   around lunch."

Where it touches
the real world.

Two functions, each with a plain-English description the model reads to decide when to call it. A tool is the agent reaching out — fetch a file, send an email, hit an API. Every tool is a control point: log it, gate it, approve it, audit it.

What's actually in one request

The desk — sent every turn

Instructionsthe brief we just read
The toolswhich ones it's allowed to call
Conversationeverything said so far
Documents / resultsanything fetched, e.g. the menu it pulled
Your question"what should I have for lunch?"
↑ this whole pile = the context window · not on the desk = invisible · you pay for all of it
The loop, on a real example

Every tool call is a control point

You
ask
MODEL
decides
get_menu()control point
check_calendar()control point
MODEL
weaves
"the burrito
bowl"

It didn't guess — it chose to call tools, then committed. Each call is a place you can stand and govern.

▶ live demo

Now we run
what we just read.

Same brief. Same two tools. Switch to the terminal.

What it costs

It's all tokens — and tokens are a cost line you govern.

Everything on the desk is counted in tokens, in and out. The one that's yours: feed the whole FCA Handbook in → get a 10-page gap report out. That's a real cost, per run.

Democratised ≠ free. The more autonomous it gets, the more control surface there is — and good setups still cost money and skill. That's a build-vs-buy decision, not a free-tool one.

Half 2 — anyone can build

Now a whole app —
by describing it.

Same move as the agent's brief, bigger: I describe an exam in plain English; the AI writes the entire website. That description is a prompt.

▶ live build

Copilot builds
the exam.

The prompt + your two images → it returns the whole site. I write zero code.

The thing to leave with

You didn't code.
You described.

Anyone in your org can now do this. That's the opportunity — and a brand-new ungoverned-risk problem that lands on your desk. Knowing what's on the desk and where the control points are is exactly what lets you govern it.

Next session

We write your
agent — for real.

We point all of this at the real FCA data, and you help decide what the agent should actually do — and where the controls go.

🎤 say· press N to hide · ← → to move
← → move · N notes · F fullscreen