Kickoff
At home I had versioned, installable agent harnesses with drift detection and a marketplace. At work, I didn’t bring any of it.
Instead, I forked a workflow baseline the company already had, made it ours, and told every cohort the same thing on Monday morning: this is a starting point, not a decree. No harness. No sensors. No mention of the project that had renamed itself the same evening the first cohort walked in. I shared the article that had given me the word; I didn’t share the tool I’d built with it.
On purpose. And that gap between what I had and what I showed turned out to be the most important design decision of the adoption effort. In the end, it mattered more than anything I had actually built.
The Run
The frontier trap
Here’s the trap for anyone who runs ahead of their organisation on a new practice: your frontier is impressive and unadoptable. Show a busy team the full stack — harness packages, sensors, marketplaces — and you get admiration and zero adoption. Admiration doesn’t ship anything. It is, functionally, a compliment with an exit visa: people say something nice on the way out of the room, and then nothing changes on their machine, ever, ever again. It reads as your thing, dependent on your context, eighteen months from their Tuesday. What converts a team is something two rungs down the ladder: simple enough to adopt this sprint, complete enough to feel real, demonstrated working in their environment, not mine.
The backtrack, repeatable
So the move I’d first made privately in February — the backtrack from Post 8 — became a repeatable public strategy.
Start from what they already trust. The baseline was not mine. It was a fork of a workflow repo people across the company already knew, with the boring, essential parts done: shared settings committed to the repo, deny rules so the agent couldn’t read credential files, a hook that validated every skill on save, and one make install to set it up. My own harness would have been better for me. Theirs was better for adoption, because nobody had to trust me first.
Pick the beachhead artifact. We led with skills: small, reviewable, composable instructions an agent can load. They’re the smallest thing worth sharing. A skill fits in a code review. A skill can’t demand a platform migration. The first ones to ship were unglamorous and aimed at the friction every team shares — pull-request cycle time and sprint hygiene: a pre-review code checker, a standup prep command, a ticket-and-PR-queue health check, a root-cause analyser for log output, a pack of generic documentation rules. A folder of good skills is quietly a proto-harness. The ladder is still there, just entered at the bottom, wearing sensible shoes.
Build the PoC in their world. Nobody demoed on my repos. The Monday prompt was “what’s the most tedious, repeatable thing you do in your project?”, and the Friday demo was that thing, automated, on that project. Live, on the team’s own code. It beats any deck about my code.
Leave things out, loudly. I named what we weren’t doing, every Monday. Supervised workflows only: the agent proposes, a human reviews, then it executes, and that is a strategy, not a stepping stone you’re embarrassed about. Sub-agents: the next layer, not this week. A curated company marketplace: what this could become, not what it is. Versioning and drift: real problems, deliberately parked. Saying “there’s a versioning story and a drift story, and we’re not doing them yet, on purpose” builds more trust than pretending simplicity is all there is.
Then repeat it every Monday. Evangelism at org scale isn’t one great talk. It’s the same honest introduction, given four Mondays running, with one addition from the second week on: a “last week” slide showing what the previous cohort had left behind. By the fourth Monday it had stopped being news, which was the point.
Demand pulled every rung
The last step of the playbook — graduate on demand — was the part I trusted least, until I watched it happen. I didn’t introduce any of the next rungs. People asked for them.
The second cohort asked for plugin packaging and fewer permission prompts. The third asked whether the skills would work in a different vendor’s agent, and started separating workflows that need a human in the loop from workflows that could run on a schedule. The fourth wanted parallel sub-agents, a queryable knowledge server instead of a static lookup skill, and an audit of the whole library. Each cohort climbed one rung higher than the one before, and none of them needed my frontier to do it. Most of the time they needed the previous cohort’s wish list.
The rungs you skip come back as bugs
This is the honest counterweight. Entering two rungs down isn’t free. The rungs you skip don’t disappear; they come back later as defects.
Packaging skills as a plugin broke references between skills in the first week, because the plugin namespace changed every name. By the fourth week, an audit found that inherited skills were carrying metadata the runtime silently ignored: fields that looked meaningful, did nothing, and had been copied forward by three cohorts. Some skills only triggered reliably once a rule in the project instructions told the agent to use them. None of the skill repositories had CI.
Every one of those is a rung I had climbed at home: contracts, validation, observability. I had deliberately left them out of the pitch, and that was right. But I should have brought a linter. You can hide the ladder from your audience. You shouldn’t hide it from your tooling.
The Debrief
The backtrack playbook, tested across four consecutive weeks — enough to ratify, not enough to call settled:
On The Training Ground
Two Rungs Down. By the end you’ll have one piece of your own setup rewritten as something a colleague can adopt this sprint. You’ll also have a written list of what you left out, and the first thing they asked for next. This isn’t Post 8’s starter kit, which shrinks your config. Here you choose which rung to stand on, and make the omissions honest.
Info
You’ll need: your own agent setup, the most advanced version you have; a colleague’s repo, ideally a different team’s; an agentic CLI; and about an hour over two sittings.
Write down every layer of your setup, from simplest to most advanced. For example: one-off prompts, a project instructions file, skills, hooks and permissions, packaged and versioned config, sub-agents, evals. Circle the highest rung you actually rely on. That rung is your frontier.
Count two rungs down from your frontier. The candidate needs to pass three tests:
- Adoptable this sprint: no new platform, no install longer than one command.
- Starts from what they trust: their vendor’s conventions, or their team’s existing config, not yours.
- Visibly useful: it removes a task they already do.
Fresh session in the colleague’s repo, not yours:
Here is something I use at a more advanced level: <describe it>.
Re-express it for THIS repo at the level of <chosen rung> only,
using this repo's existing conventions and config. No dependencies on
my setup. Then list, separately, every capability you dropped to get
here — that list is as important as the result.Turn the dropped capabilities into a short list headed Deliberately not yet, with a single line of reasoning per item. Put it in the README next to the artefact. This is the step that stops a simplification turning into a lie.
The rungs you skipped will come back as bugs. Run whatever validation exists for the format: a schema check, a frontmatter linter, or one test invocation per skill. Do it now, before anyone inherits a silent failure.
Have your colleague run it on a real task. Don’t pitch the next rung. Write down the first thing they ask for, such as “can we version this?” or “can it run on a schedule?”. That question tells you which rung to build next, and they asked for it, so you’re not pushing it.
Tip
What you just proved: the artefact that converts a team is a deliberate step down from the one that convinced you, and an honest “not yet” list builds more trust than pretending the simple version is all there is. When the colleague asks for the next rung, that’s demand doing the climbing for you.
The frontier’s job is to make you sure. The PoC’s job is to make them start.
I own a food processor with, by my count, eleven attachments. I have used two. The other nine sit in a drawer as a permanent, unspoken argument for the version of me who buys equipment instead of learning technique. Every unadopted platform pitch I have ever given had the same drawer in it somewhere.