At McKinsey I was usually the dumbest person in the room

At McKinsey I was usually the dumbest person in the room. That turned out to be the transferable skill.

The excel modelling and the powerpoints stayed at the firm. What transferred was the job underneath: confidence in pursuing the right problems, knowing how to structure problems, and pointing experts at the right direction. In other words: getting a room of experts, each of them deeper than me in their own lane, to contribute without any of them needing the whole story. Years later I found the right name for it: I was the conduit of expertise, not the expert. I optimised three things: the right problem (purpose), the context each expert needed before they could start (context), and the shape and depth of the output they handed back (force). Break the problem into components. Give each component to the person who can fill the gap, then assemble what comes back. For years I thought that was just what managers do. It turns out it was training.

Because last week I ran the same play again, and none of the experts were people.

Nine independent agents interact with every piece of work I commission, from the brainstorming flow through to the implementation plan. The plans they produce carry expert-agent strategies, parallelisation and execution-optimisation sections before a line of code exists. Every plan finalises with a /shipshape review (ShipShape is my open-source skill). Loops like these run across 50+ systems in Frollie and Frollie POS, including the one taking orders at a real counter in Jakarta.

How it runsInside the shipshape chain

A shipshape review runs two layers. A staff engineer agent reviews specs, execution and coding. An independent principal engineer agent reviews architecture. Neither sees the other's findings.

Both report to a CTO agent, which synthesises the two reviews and pushes improvements back into the specs rather than straight into the code. Once the key issues and bugs are addressed, code review and simplification reviews run again over the result.

The separation is the point. One reviewer holding the whole picture tends to talk itself out of its own objections. Two reviewers with different mandates, reporting to a third that has to reconcile them, catches what one would rationalise away.

Source: ShipShape, my open-source review skill. First-hand.

And the split that reorganised my week: 80% of my human thinking and intervention now goes to planning and architecture. That's my own estimate, not telemetry. The loops do the checking, so I don't have to.

Last week I wrote a LinkedIn post built off Boris Cherny's Steps of AI Adoption ladder. Sitting with it afterwards, I realised the honest reading of my own operation: I run my own enterprise at level 3. And the climb had nothing to do with which model I was on.

Boris Cherny · AnthropicThe five rungs, and what "level 3" means

Cherny, who created Claude Code, sets out enterprise AI adoption as a five-step ladder keyed to how many agents one engineer runs. 0 Gated, no agents. 1 Assisted, about one, a fast pair programmer you watch and never look away from. 2 Parallel, about ten, where you review final diffs rather than keystrokes. 3 Supervised autonomy, about a hundred, a manager of managers, where work starts kicking off proactively. 4 AI-native, a thousand or more, where you steer by intent and monitor by exception.

What makes the ladder useful is that the bottleneck moves as you climb, and it sits on the human side at every rung. At step 1 it is your attention. At step 2 it is your review throughput. At step 3 it is whether you trust the loop at all. His warning for that step is the one worth pinning up: the trap is scaling agent count before the loop has earned widespread trust.

Which is this essay's argument arrived at from the other direction. The climb is a verification problem long before it is a model problem.

Source: Boris Cherny, Steps of AI Adoption, 16 July 2026 [1]

My agents and I test the latest models every day. Every release is sharper than the last. The latest LLM doesn't move you up a step. Verification loops you actually trust do. Tests, builds, automated review, end-to-end checks that run without me. Trust the loops and you can look away. Look away and you can parallelise.

I know the operator this lands hardest on, because I meet them constantly: the one who upgrades on release day and still checks every output by hand. The upgrade feels like progress. It isn't. A stronger model inside a loop you don't trust just gives you more output to check by hand. The bottleneck was your checking capacity, not the model's capability, and that didn't change.

The loops also outlast the models. When the next release lands, the model swaps in and the trust carries over. My test suites didn't care which model wrote the code they were checking last quarter, and they won't care next quarter either. Chasing releases without the loops means starting the checking from scratch every quarter: a treadmill dressed up as a roadmap.

This is where the McKinsey training pays out. Orchestrating agents is the McKinsey job: getting experts to contribute deeply without needing the whole story. The staff-engineer agent doesn't know why Frollie POS exists. The principal engineer reviewing architecture has never seen the counter in Jakarta. They don't need to. Each one gets exactly the context required to do its piece well, hands back output in a shape the next loop can verify, and the CTO agent assembles the answer. I spent years doing that with humans in conference rooms. The room changed. The job didn't.

The job I'm doing now has a title: agentic engineer, the forward-deployed kind: drop into a domain I'm passionate about, wire the available expertise into a system that runs without me. Being the conduit of expertise was direct preparation. The same three things: purpose, context, force. Same conduit, different things flowing through it.

The mappingMcKinsey craft, agentic craft

Scoping an expert's pre-read became context engineering per agent: what does this one need to know before it can start, and nothing beyond that.

The output templates I used to enforce became structured outputs a loop can verify without me reading them.

The firm's layers of expert review and syndication became the staff-engineer, principal-engineer, CTO chain in shipshape.

Deciding which problem deserved the room became deciding what to commission at all. That one never got easier, and it is the only one still entirely mine.

Source: first-hand.

One warning before you go build the loops, because I paid for it this year. I commissioned an inventory system for Frollie without being clear on what I wanted. Worse, without being clear on what NOT to build. The agents pushed ahead, and every loop passed. What came back was a massively detailed, very accurate, ERP-style just-in-time COGS model, machinery built for the likes of HelloFresh, where I used to run strategy, not for a startup whose entire storefront was a single counter in Jakarta. That was a purpose failure, not a force failure. The loops validated the execution faithfully. They couldn't supply the direction I hadn't given them.

A loop can only validate intent you already hold. Tests check against behaviour you specified; reviews check against standards you set. Without a strong sense of what good looks like for your product, your customers and your codebase, the loops have nothing to validate. Taste is the precondition. The loops hold the work to the direction you chose, so it survives contact with a thousand generated files.

When the next release drops, skip "how much better is the model?" and ask "which of my workflows have loops I trust enough to look away from?" That answer is your actual level on the ladder. Of the three things, only one can be handed to the machines. The loops keep the force honest. The direction is still yours.

The work we do at Qubit and Ikigai Ventures sits on both halves. We design the direction together, and we build the loops that keep your force honest. Bring us the idea; we partner to build it.