Module 1 · Foundations of Agentic AI · scripted

Exercise: The Agent Forge

45 min

From playing the computer to building it

In the tools exercise, you played the computer: every call paused, and you typed what the world said back. Now we take your hands off the keyboard. In this exercise your tools carry real code — JavaScript written by an LLM from your description — and when the agent calls a tool, that code actually runs and its return value goes back into the conversation. You have just seen the agent loop; now you are going to stand inside one.

What changes

Before:agent calls tool → YOU invent the result → agent continues

Now:agent calls tool → CODE computes the result → agent continues

Your job moves up a level: from playing the world to DESIGNING the tools and GOVERNING when they may run.

Where to run it

Open the Agent Forge →. An agent here is a system prompt plus a set of forged tools; name it and save it as you go. If you prefer an LLM of your choice for the forging half, you can: describe the tool and ask for a JavaScript async function run(params, store) plus a JSON Schema for its parameters, then paste both into the Forge — the code box is editable. The loop half needs the Forge, because something has to actually execute the code.

The Forge in one picture

design a toolname · description · implementation notes

↓ generate

the LLM writesa parameter schema + the JavaScript body

↓ test

you call itwith real parameter values; every run is logged

↓ regenerate

feedback + ticked test evidence → revised code

↓ arm

the agent runsand the "careful eval" executes tool calls for real

Two audiences, two texts

Each tool has a description and implementation notes — and they go to different readers. The description is what the agent sees: the promise, in the vocabulary of action. The notes are what the code generator sees: the engineering ticket. Keeping them separate is the whole discipline of interface versus implementation, in miniature — the agent should never need to know that reading time is computed at 200 words per minute; the generator absolutely does.

One tool, two texts

description (agent-facing):

"Estimates reading statistics for a text."

implementation notes (generator-facing):

"Words = split on whitespace. Reading time at 200 wpm,

round up to whole minutes. Return {words, sentences, minutes}."

The careful eval

When the agent calls a forged tool, the Forge runs the code inside a sandboxed worker with a hard timeout — no page access, no stored keys, and a kill switch for infinite loops. The code gets two things: the params the agent chose, and a store — a plain object that survives between calls of that tool, which is how a tool can keep a counter, a fake database, or notes to itself. Whatever the function returns is translated to text and appended to the conversation, exactly as the loop lesson described.

The shape of every tool body

async function run(params, store) {
  // params: what the agent chose, matching the schema
  // store:  persists between calls — mutate it freely
  return value;   // what the agent will read
}

// No document, no window. To read a public web page, the sandbox
// provides fetchText(url) — a fetch through the course server,
// because the browser blocks direct requests to other sites (CORS).
// Prefer computation and store-kept state. 10s and it's killed.

Files on the bench

You can also hand the agent real material: the 📎 button attaches a file — CSV, PDF, Word, or any text file — and its text is extracted in your browser (nothing is uploaded anywhere). The agent is told only the name and size; two built-in tools let it look inside, and your forged tools can compute over the contents directly.

Attachments, two ways in

the agent's way (built-in tools, always available):

list_attachments()what's on the bench

read_attachment(name, offset) the text, in costly chunks

your tools' way (inside forged code):

const text = readAttachment("budget.csv");

// parse it, search it, aggregate it —

// return the ANSWER, not the file

Attaching is free. READING costs tokens, chunk by chunk. The best tools read the file in code and hand the agent three lines instead of three thousand.

Step 1 · Forge one tool well

Create a single tool and take it around the full cycle. Pick something honestly computable in a browser — reading statistics, a unit or currency-table converter, a date calculator, a dice roller with odd dice, a grade-curve calculator from your own field. Generate it, then test it before any agent touches it: run it with easy values, edge values, and at least one input you expect to break it. Every run lands in the test history. Then improve it without editing the code yourself: write one line of feedback, tick the failing tests as evidence, and regenerate.

Capture — end of Step 1

Your description vs your implementation notes, verbatim.

One test that surprised you (params → output).

The feedback line that fixed it, and what changed in the code.

Step 2 · Run the loop in step mode

Give the agent two or three forged tools and a task that needs them, and run in step-through mode: every call waits for your Allow, and every result pauses for your review before the agent sees it — you can even edit the result in transit, which is a strange power worth feeling once. Watch the loop you studied on paper happen in front of you: call, execute, translate, append, decide.

Capture — end of Step 2

The full run: each call, each real result.

One moment you were glad of the gate — a call you inspected

before allowing, or a result you edited before the agent saw it.

Step 3 · Govern, then let go

Now design the policy. For each tool, decide: does this need a human, every time? Tick needs approval on the ones that do — anything that writes, spends, sends, or deletes deserves the checkbox; pure reads and pure computation usually don't. Then switch to autonomous mode and run a fresh task: unchecked tools fire without you, checked ones still stop and ask — and the Allow for this conversation option lets you lift the gate for the rest of the run once trust is earned. This checkbox is your first governance decision as an agent designer, and it is exactly the decision production teams make tool by tool.

Capture — end of Step 3

Your approval policy: which tools got the checkbox, and the rule

you used to decide.

The autonomous run: how many calls ran free, how many stopped.

Did you use "allow for this conversation"? What earned it?

Deliverable

Three captures. In the comparison at the end we will look at the best feedback-and-regenerate saves, the approval policies people chose and the rules behind them, and the moments autonomy felt different from step-through — the same loop, with the human moved from inside every iteration to standing at the gate.

As you compare

What did the regenerator do with your test evidence that it could not have done from feedback alone?
Where is the line, in your domain, between a tool that may run free and a tool that must ask? Is it about reversibility, cost, or visibility?
You edited a tool result before the agent saw it. When would that power be legitimate in a real system — and when would it be lying to your own agent?