After the Roadmap, Someone Has to Build the Road

System-change organizations are brilliant at convening the field and writing the roadmap. The next frontier is harder and more valuable: building the tools the roadmap calls for, with humans kept firmly at the center.

Eli Wood headshot

Eli Wood

June 24, 2026 4 min read
A small lever on a fulcrum shifting a large interlocking structure of gears and girders

The convener's ceiling

Some organizations exist to move a whole system, not a single classroom. They convene the field, broker the hard conversations, and produce the thing everyone then cites — the roadmap, the framework, the state-level plan for how AI should and shouldn't show up in schools. It's genuinely hard, valuable work, and the organizations that do it well earn a kind of trust that is almost impossible to buy: they are seen as the honest broker, the one in the room for the public good rather than the sale.

But there is a ceiling on facilitation. A roadmap describes the road; it does not pave it. Once the convening is done and the document is published, the field looks up and asks who is actually going to build the tools the plan calls for — and the answer is usually a patchwork of vendors whose incentives the intermediary spent the whole process trying to balance. The organization with the clearest view of what the system needs, and the most credibility to build it responsibly, often hands that work to whoever is selling. The insight that the roadmap represents quietly leaks out to the market.

You wrote the spec; you can be trusted to build it

The useful frame is to separate the rules engine from the judgment engine — and to see that a good system-change roadmap has already done that separation at the level of an entire field. It says, in effect: here is where AI can safely take load off the system, and here is where human judgment, equity, and accountability must stay central. That is a product specification of unusual quality, written by the one party with no incentive to overreach. The move is to compile it — to build the tools the roadmap calls for, embodying the same boundary the convening process fought to establish.

Building, for an intermediary, does not mean becoming just another vendor. It means doing the thing the market won't: putting humans at the center on purpose, keeping people in the loop exactly where being wrong is costly — equity decisions, who gets flagged, what gets recommended for a child — because those are the calls the organization's whole credibility says must stay human. You start where the judgment is expensive and repetitive across the system, the place the roadmap kept returning to, and you build a narrow tool that does the mechanical work and structures the human one.

And the entire thing has to be explainable, because an honest broker that ships a black box stops being an honest broker. Every recommendation traceable, every assumption visible, so districts and educators and the public can interrogate it the same way they trusted the organization to interrogate the field. Explainability isn't a technical nicety here; it's the continuation of the trust that made the roadmap credible in the first place. The organization that convened the conversation is uniquely positioned to build tools people will actually trust — if it carries its values into the software instead of leaving them in the document.

A two-day starting point

The trap is to treat tool-building as a betrayal of the convening mission, or as a multi-year capability you'll get to someday. The fix is to take the single most important thing your own roadmap says the field needs — the one capability it returns to and no vendor is building responsibly — and build a thin version that does the mechanical part, keeps humans central on the judgment, and shows its reasoning end to end.

In two days you can have that running against a real scenario and learn whether your roadmap's boundary holds when it's compiled into software — where the system genuinely needs a human in the loop and where automation is safe. That working artifact does something no document can: it proves the organization can build, responsibly, the tools it has been telling everyone else how to build. Get it right once and you have both the pattern and the standing to set the bar for the whole field — humans central, judgment explainable, automation only where being wrong is cheap.

Black Flag Design builds applied-AI products that keep humans at the center, for organizations that are trusted to set the standard. If you've written the roadmap and you're ready to build the road, spend two days with us — we call it a Foundation Sprint.

About the author

Eli Wood headshot
Eli Wood

CEO, Black Flag Design

Eli Wood leads Black Flag Design, a creative technology company focused on shipping ambitious digital products, AI systems, and design-forward software with a direct point of view on how technology changes work.

Related stories

More from the journal

Pen-and-ink sketch of a small clockwork robot working at a tool-covered workbench late at night while a human sleeps peacefully on a couch in the background, a wall clock reading 2:00 above
ai April 24, 2026 13 min read

The Agent Stays Up Late, Not Me

Every senior engineer knows the right way to set up a codebase. None of them do it. Here’s the four-stage framework we use — The Ratchet — to take a vibe-coded project all the way to a thing you’d trust in production, and the punchline about why this only just became worth doing.

Most teams have always known they should be running tests, type-checking, security audits, accessibility checks, dead-code analysis, prose linting, and a coverage floor. Most teams run two of those. Here’s why that math has finally inverted, and the four-stage framework we use to ratchet a vibe-coded project to a hardened one.

Keith Pattison

Keith Pattison

Founder, Black Flag Design

Read
Black Flag Journal
claude code April 20, 2026 5 min read

What a Year of Claude Code Trails Tells You About Your Team

Claude Code leaves evidence — sessions, commits, PRs, review notes. Read it like a logbook and you'll find what devs actually need to know before they go deeper.

After a year of shipping with Claude Code across real client work, the signal isn't in any single session — it's in the trails. Here's what those trails told us about where Claude Code shines, where it drifts, and the habits devs should build before they lean in harder.

Eli Wood headshot

Eli Wood

CEO, Black Flag Design

Read
Black Flag Journal
playbook April 20, 2026 6 min read

The Black Flag Playbook: Six Principles for Shipping with AI

Battle-tested principles for teams building real software with AI-generated code. Human judgment, tight scope, and weekly evidence — the disciplines that keep AI-built systems reliable.

The six rules we use to ship production software with AI. Small scope, weekly demos, human-led oversight, and continuous improvement — drawn from six months of real client engagements.

Keith Pattison

Keith Pattison

Founder, Black Flag Design

Read