Factory Academy · blueprint
One workshop is a prototype. This is the system for the next ten.
The product is horizontal, so without a structured path people stop after the first demo. The Academy is the path: role-based tracks, one standard every workshop meets, and a loop that turns what the field learns into what the next learner reads.
A discussion draft, not a Factory plan of record. Track and workshop names are proposals.
Tracks
Three audiences outside, one inside
Developers
Self-serve users and engineers in customer accounts
A first real win on your own repository, not a toy app.
- D1Your first real winDroid CLI on your own repo, one delegated task you would have done anywayproposed
- D2Plan, then buildSpec mode and review as a daily habitproposed
- D3Multi-day work with MissionsMilestones, validation and Mission Controlproposed
Platform teams
Staff and platform engineers who set up tooling for everyone else
A repository agents can work in safely, and the evidence to prove it.
- P1Agent-readyThe harness for a regulated codebaseprototype
- P2One harness, thirty reposPlugins, internal marketplaces and managed settingsproposed
- P3The automated SDLCDroid exec, automations, review and incident responseproposed
Engineering leaders
The people who decide whether to adopt, expand or stop
A number that survives a board question, and the controls behind it.
- L1Measuring what agents deliverReadiness, effectiveness and cost, with your own dataproposed
- L2Governance without frictionEnterprise controls, audit and telemetryproposed
Factory team
New SEs, FDEs and anyone who talks to customers
The same material the field teaches, so onboarding and enablement are one thing.
- F1Running a regulated POCScoping, readiness check, guardrail kit and the model-risk FAQproposed
The standard
What every Academy workshop has
Workshop 01 is the reference implementation. Each item below is a component or a convention in this repository, so the next author starts from working code rather than a style guide.
A scenario with stakes
Every lab exists because a named person in the story needs it. Generic examples teach the tool and skip the reason anyone hesitates.
One idea per lab
Each lab adds exactly one thing and depends on the ones before it. The order is the pedagogy.
Measure first
Lab 0 sets a baseline on real tasks, and every lab re-runs it, including the ones that should not move it.
Break it on purpose
Every control is followed by a step that tries to get around it. That is how learners find out what it is worth.
Three ways in
Sixty seconds with nothing installed, twenty minutes to a first success, or the full day. Most people start with the first.
Paths by audience
Each audience gets its own route through the same pages, written to a named person and what they need. The same lab is on several paths, for different reasons. See them →
Every number labeled
Illustrative until piloted, and marked on the page. Facts carry the date they were checked against the docs.
Judgment is assessed in writing
Multiple choice checks recall. The questions that matter are answered in prose and graded against a rubric.
Written for people and Droids
Each harness artifact ships as a file a Droid can run: a skill, a hook, an MCP config. The lab is the explanation.
Where content comes from
Every conversation feeds an artifact
One developer gets stuck
DevRel helps directly, and logs the friction with the Droid session attached.
The same issue three times
It becomes a recipe: a short write-up and a file a Droid can run.
Across accounts
It becomes Academy content, a docs fix, and an item in the monthly readout to Product.
The same loop runs in reverse for Product: a tagged friction log, a monthly readout, and a report back to customers on what shipped because of them. The log watches Droid sessions as well as tickets, because agent failures are often silent.
Keeping it true
A workshop that drifts from the product is worse than none
Dated facts
Every workshop carries a fact sheet built from the docs, with the date it was checked. The site config holds that date and the pages show it. When the docs change, the fact sheet is the diff.
Run against every release
The companion repo’s scoreboard and every recipe run in CI against each new Droid CLI release. A lab that silently breaks is caught by the Academy, not by a customer in the middle of a workshop.
Illustrative until piloted
Numbers and transcripts carry an “illustrative” badge until a pilot replaces them with recorded runs. The badge is a component, so removing it is a deliberate edit, not an oversight.
What we measure
- Time to first meaningful success on the learner’s own repo
- Academy completion followed by real product usage
- First-attempt success on Academy recipes
- Friction items from workshops that shipped as product changes
Build the next one
Workshop 02 starts from this repository.
Copy it, change one config block and the data files, write the scenario first, and keep the components.