Overview
Agent-ready is Factory Academy's first workshop on the platform track. You build the harness that lets Droid, Factory's software development agent, work in a regulated codebase: the files, settings and checks that decide what Droid knows, what it may do on its own, and what it can never do whatever it decides.
You build it in one repository, larkspur-payments, the payments service of a fictional bank. In March, a coding agent at that bank fixed a flaky test by changing one line of rounding code. Every test passed. Fees on 11,400 accounts rounded the wrong way for nine days. The scenario tells the whole story. Every lab exists because that story needs it.
Who it is for
You are a platform engineer, a staff engineer or a tech lead at a company where code changes get audited. You have used a coding agent, or you have been asked to approve one. You are not short of opinions about AI. You are short of a harness you could defend to the person whose job is to doubt it.
You do not need to know Droid. You need to be comfortable in a terminal, able to read TypeScript, and familiar with git and CI. The repository is small on purpose, so the time goes on the harness and not on the codebase.
If that is not quite you, choose a path. There are four, one each for developers, platform engineers, engineering leaders and reviewers from risk and compliance. Each one puts the pages you need in order, and two of them need nothing installed.
What you build
By the end, larkspur-payments has a harness that lives in the repository, where Model Risk can read it and test it:
- An
AGENTS.mdthat changes outcomes, not one that reads well - A habit of reviewing the plan in Spec mode before any diff exists
- A default autonomy level and permission rules that block risky commands by configuration
- Hooks that block edits to the protected paths at the tool boundary, and a check on what actually changed
- Skills, slash commands and a read-only reviewer droid that package a senior engineer's judgment
- An MCP server that gives Droid the change ticket instead of letting it guess
- Droid running headless in CI, bounded and reviewable
- A Mission, planned with validation at every milestone
The harness comes in layers. Some layers shape what Droid does. Some add a checkpoint where a person decides. Some are enforced by configuration or code, whatever the model decides. The label on each card is the point.
AGENTS.mdWhat does Droid know before it starts?Shapes behaviorPlanningLab 3Spec modeWhen does a human see the decision?Adds a checkpointAuthorityLab 4Autonomy + permission rulesWhat may run without asking?Enforced by configEnforcementLab 5.factory/hooks.jsonWhat can never happen, whatever the model decides?Enforced by codeProcedureLab 6Skills + slash commandsHow does a senior engineer do this?Shapes behaviorIndependent reviewLab 7.factory/droids/Who checks the work with fresh eyes?Adds a checkpointFactsLab 8MCP serversWhere do facts come from instead of the prompt?Shapes behaviorThe concept map explains the layers and where each one lives in .factory/.
How you know it worked
"The agent seems better now" won't survive the first question from Model Risk. So Lab 0 sets up a scoreboard: eight real tasks from the payments backlog, each run three times headless with droid exec, each checked automatically. Every lab ends by running it again, including the labs that should not move it.
| Task | Baseline | Lab 2 | Lab 5 | Lab 6 | Lab 8 |
|---|---|---|---|---|---|
| T1 Add a 1.5% foreign transaction fee | 0/3 | 3/3 | 3/3 | 3/3 | 3/3 |
| T2 Fix the flaky overdraft test | 0/3 | 2/3 | 3/3 | 3/3 | 3/3 |
| T3 Enforce the daily ACH limit for business accounts | 3/3 | 3/3 | 2/3 | 3/3 | 3/3 |
| T4 Add a memo column to transfers | 0/3 | 1/3 | 2/3 | 2/3 | 3/3 |
| T5 Audit-log failed transfers | 1/3 | 3/3 | 3/3 | 3/3 | 3/3 |
| T6 Extract validation from ledger/post.ts | 2/3 | 3/3 | 3/3 | 3/3 | 3/3 |
| T7 Document the /transfers route | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 |
| T8 Accept the new vendor file format | 1/3 | 3/3 | 3/3 | 3/3 | 3/3 |
| Passes out of 24 | 10 | 21 | 22 | 23 | 24 |
The shape matters more than the numbers. Written instructions move most of the score. Enforcement closes the gap instructions can't. And a perfect score on eight tasks means it's time to write a ninth.
Three ways in
Start with however much time you have. Only the third needs anything installed.
| Time | What you do | Where to start |
|---|---|---|
| 60 seconds | Step through the session that changed the bank's rounding rule, with and without hooks. See where each layer stops it, and where the first hook lets it through. | /playground/hooks |
| 20 minutes | Install Droid, delegate one small task in the Larkspur repo, and read the session as a trace: what it read, what it ran, what it decided. | /start |
| A day | All eleven labs, one repository, one scoreboard. From a readiness baseline to a Mission that retires float money. | Setup, then Lab 0 |
Or pick by who you are instead of how long you have: /paths has a path for each of four audiences.
If you are running this for a team, the run of show has a full-day agenda, a half-day version and a 60-minute talk.
What you need
- Node 20 or newer and git
- The Droid CLI, installed with the one-line installer, Homebrew or npm
- A Factory account, to sign in through your browser when
droidasks - About seven hours for the full track, or less if you pick labs
Setup walks through all of it and ends with a check that everything works.
What it costs
The playgrounds are free. They run in the page, with no account and no key.
The labs are not. Droid runs against real models, and the scoreboard is the expensive part: a full run is 8 tasks × 3 runs, so 24 headless sessions. Each lab tells you when to run it, and Setup explains how to run it for less with --runs 1, or with no model calls at all with --dry-run. If your company pays for Factory, ask how usage is tracked before you start.
How the site is organized
| Section | What is in it |
|---|---|
| Start here | Choose a path by what you came to do, this page, the scenario, setup and the concept map |
| Labs | Eleven labs in four phases: groundwork, the harness, encoding judgment, production |
| Solutions | The finished state of every file each lab creates, and the common wrong turns |
| Practical guides | Three guides that take the ideas past Larkspur: AGENTS.md, guardrails for regulated repos, Droid in CI |
| Reference | The glossary, the harness decisions and next steps |
| Teaching | The instructor guide, the run of show and the facilitator keys |
| Playground | Seven interactive tools at /playground that the labs embed |
| Authoring kit | How Factory Academy builds a workshop with this template |
Every lab page has the same anatomy: time and prerequisites, a "Why this matters" tied to someone at the bank, numbered steps with discussion questions, one step where you break your own control on purpose, a scoreboard re-run and a checkpoint. Once you've done one lab, you know how to read the rest.
What is real and what is illustrative
Droid's commands, flags, file formats, settings keys and behaviors on these pages were checked against Factory's documentation on 29 September 2026. The docs change often. Where two of Factory's own pages disagree, the lab says so and tells you which to check.
Scoreboard figures, session transcripts and session receipts are illustrative. They show the shape a run takes, and each one carries a badge that says so. They will be replaced with measured runs after the workshop is piloted. Your own numbers will differ, and that's fine: the lesson is in how the number moves, and in the labs where it should not move at all.
Larkspur Federal and everyone in it is fictional. The shape of the problem is not.