Here is an experiment worth doing with the most capable AI you can reach — the long-horizon kind that plans across stages, delegates to sub-agents, and works for hours or days without you.¹ Ask it: "How do I make money selling agents?"

Then do the one thing that feels wrong. Tell it not to answer.

Whatever it says next will be worthless — not because the model is weak, but because you've asked it the wrong kind of question. You've asked the best strategist that ever existed to strategise about a person it knows nothing about. It will hand you a competent, plausible, strategy-shaped answer. And it will be roughly the same answer it hands everyone else.

Why the naked model gives you the distribution's answer

A model with no access to you can only answer that question for a generic person. It reaches into the enormous distribution of business advice it was trained on and returns the average: pick a niche, build a portfolio, post on LinkedIn, productise the service. None of it is wrong. All of it is the mean.

The truth underneath doesn't soften as the models improve:

And the thing that was never in the room is you: what you actually believe, what you've actually built, and who would actually take your call. A frontier release makes the reasoning sharper. It does nothing about the inventory. Which is why everyone asking the same model the same question gets the distribution's answer — and why, with your inventory loaded, you'd get yours instead.

Everyone else asking that model the same question gets the distribution's answer. You'd get yours.

This is the ceiling of an idea we've written about before — Context Arbitrage, the widening value gap between a frontier model and a compiled context to point it at. At the low end it saves money on routine agent work. At the high end — strategy — it's the whole game: the difference between generic advice and a plan that could only have been written for you.

Strategy is a matching problem

Strip business development back to its mechanism and it stops looking like creativity and starts looking like matching: fitting what you have against what the world currently wants. This isn't a metaphor. It's the oldest serious idea in strategy — the resource-based view of the firm, which holds that durable advantage comes from looking inward at your own resources and capabilities, not only outward at competitors.² Firms differ because their resource mixes differ; the work of strategy is exploiting the mix you actually hold.²

Here is the part that quietly changed. For the entire history of that idea, one half of the match — what you have — lived in your head, your old drives, your inbox, and a folder of half-finished projects. It was never machine-readable. So the matching had to be done by a human, slowly, from memory — the weakest instrument any of us owns.

That is not a better prompt. It is a different, and solvable, problem. "Search" here is literal — retrieval over your real assets — which is why a patient model that can walk a large compiled corpus is the right instrument, and a clever one-shot prompt is not.

The three corpora: the complete input set

Every competent business-development advisor works from exactly three files. No advisor in history has ever had all three compiled, current, and walkable at once. You now can.

Knowledge, capability, network. Point a patient, long-horizon model at all three and the earlier question finally has somewhere to land. "How do I make money selling agents?" resolves into concrete matches: this thesis you hold is one the market is paying for right now; this thing you shipped last year de-risks it in a first meeting; this person, two threads deep in your inbox, runs exactly the business that would buy it.

IP wiki: what you believe. Dev wiki plus CV: what you can prove. Gmail wiki: who you know. That is the complete input set of business development — and no advisor in history has ever had all three compiled, current, and walkable.

So which corpus decides the deal?

If you're the technical kind of operator, you rate your knowledge highly, your capability accurately, and your network barely at all. That's the expensive mistake. In the source conversation behind this book, the email corpus was the one flagged as maybe not even relevant. It turns out to be the one that most often decides the outcome.

The numbers on this are not subtle. Warm introductions convert to a first conversation roughly 10–20× more often than cold outreach.³ Referrals are the single highest-converting channel of any, landing around 11–26% where cold sources sit near 0.2–2%.⁴ Referred deals close at 50–70% against 20–30% for cold ones.⁵ And when buyers decide who to trust, they lean hardest on people and vendors they already know — Forrester found 82% trust colleagues and 79% trust incumbent vendors.⁶

A warm intro transfers credibility before the first meeting; the person making it has already done the trust work for you. That is why the "maybe-irrelevant" email corpus is so often the commercially decisive one.

The dev wiki knows what you can build. The Gmail wiki knows who'd take the call.

Your knowledge tells the model what's true. Your network tells it what's reachable. Strategy that ignores reachability is just a wish list.

Why not simply let the AI decide?

Because strategy hallucination is expensive, and because the market's own data says the tool is not the edge. Teams that adopt AI proposal software win no more often on average than teams that don't — one 2026 analysis found essentially zero correlation between AI adoption and win rate.⁷ What moves the number is the substrate and the discipline around it: heavily-templated proposals win 15–25% of the time; fully customised ones win 50–65%.⁸ The tool writes faster. The match wins.

So the machine's job is not to decide. It is to propose with receipts. Every play it surfaces should arrive as an evidence package — the belief it rests on, the proof it can wave, the relationship it would travel through — each with its receipt. A goal-run that can't cite its way through isn't strategy; it's enthusiasm.

The economics only work because a long-horizon model can afford to do this properly. It holds the goal, dispatches cheap sub-agents to explore each corpus in parallel, judges what comes back, and returns proposals — the orchestrator-worker pattern that already outperforms single-agent approaches on hard research tasks.⁹ The patient director and the walkable substrate arrived at the same time. That is why this is a now-problem, not a someday one — a run shape we return to in Chapter 2.

The historian hands its files to the strategist

There is a quiet symmetry worth naming. Everything in those three corpora is backward-reaching — a record of what you've believed, built, and done. The instinct is to treat an archive as memory, something you consult about the past. Point it at a goal and the archive turns around. The historian hands its files to the strategist; institutional memory becomes prospective.

And notice the recursion, because it is the first exhibit of the whole argument. The question was "how do I make money selling agents?" — and the thing answering it is an agent, running on a compiled worldview, matching your assets against the market.

Whatever plays it surfaces, the demonstration was already running. The proof of the idea is the machine producing the answer.

What to actually do

You don't need three tidy wikis to start. You already own the raw material — years of writing, a drive full of projects, an inbox you can't search. What changed is that making it walkable is now cheap. Three moves:

Then ask your big question — and this time, let it answer. Not because the model got smarter, but because for the first time your side of the match is in the room. The distribution's answer is available to everyone. Yours is available only to you.

The rest of this book is the engine that runs on this substrate: how a compiled goal keeps a multi-day campaign pointed (Chapter 2), how your own doctrine reshapes which proposal not to write (Chapter 3), and how every play the engine generates gets filed so the next one starts from your accumulated judgment rather than a blank page (Chapter 4).

A frontier orchestrator ran a serial publishing project overnight — one item at a time, dispatching sub-agents, checking their work — and by morning it had shipped thirteen artefacts. That is the kind of run a long-horizon model now makes cheap. It is also the kind of run that goes quietly, expensively wrong when nobody wrote down what it was for.

Chapter 1 built the substrate — the three corpora a goal-run searches. This chapter is about aiming: how you keep a long, expensive campaign pointed at the right goal without standing over it, and how a small habit from the earliest days of prompting graduates into the governing artefact of the whole run.

From priming to goal compilation

The prethink started life as a warm-up. Before asking the model to do the work, you'd get it to think about the work: what's the real problem, who feels it, why now. Its lineage is journalism, not engineering.

The prethink is about why you're writing. It comes from journalism — it's the thing they don't say that makes it interesting. Every line has to earn its spot on the page.

Point that habit at a multi-day campaign and it stops being a warm-up and becomes something with real authority. The compiled version produces an inspectable purpose — a one-page artefact — reviewed by a human at the moment of maximum leverage: before spend, not after output. It extends our published Pre-Thinking Prompting framework from a technique into campaign governance, and applies the North Star discipline per engagement.

Discovery hooks: claims about them carry a test

A compiled goal necessarily contains guesses — what you believe the prospect's problem is. The failure mode is to let those guesses harden into assertions the proposal states as fact. The discipline is to treat them as what they are: hypotheses.

So the proposal shouldn't say "your bottleneck is pre-disaster resourcing." It should say "we believe your constraint is X — and here's how we'd verify it in week one." That converts speculation into a discovery hook: more honest, and commercially stronger, because it structures the exact conversion-into-discovery step that wins engagements. It is also the same move our Pre-Thinking framework already builds in — its "first-signal tests," designed to be falsifiable inside two weeks.

This is where the evidence-package rule from Chapter 1 completes: claims about you carry wiki receipts; claims about them carry a test. And the discipline is backed by the market — teams that run pre-RFP discovery win 48% of qualified enterprise deals against 28% for those that skip it.¹⁰ One more habit pays forward: file the prethinks back. A per-prospect dossier page means the next contact — or the next contact with this one — inherits the reasoning instead of re-deriving it.

What to make deterministic, and what to make goal-oriented

The first version of this compiler held all the state in a deterministic harness, with the model executing steps blind. The goal-oriented rebuild shouldn't invert that completely — hand everything to the model and you lose your quality floor. The right cut runs along a line this whole system keeps drawing:

The model gets the goal; the code keeps the gates. The gates are your quality floor; the goal-orientation raises the ceiling. Swap the state-holder for content, never for process.

Showing the rejected candidates is not a nicety; it's part of the schema. Our Discovery Accelerator work found that a reasoning system earns trust precisely by exposing what it rejected and why — the John West Principle: it's the fish John West rejects that makes John West the best.

Why you don't tell the sub-agent about the gates

Running the overnight campaign surfaced a rule worth promoting to doctrine. The orchestrator held a set of quality gates — completeness checks the work had to pass. The instinct is to hand those to the sub-agent so it knows what "done" looks like. Doing so breaks the work.

I told it not to tell the sub-agent about the gates. If you tell it about the gates, it hits the gates instead of doing the work.

That is Goodhart's law, independently derived as agent management: when a measure becomes a target, it stops measuring. It's the same reason ML never lets a model see the test set. The fix is our published Hidden Gates pattern.

The question, industrialised

Step back and the whole architecture is one small habit at scale. The prethink was built to make the machine ask a single question before it started: why am I writing this? North Stars, boot profiles, origin claims, get-behind-it ingestion — they are all that one question, industrialised.

In the next chapter, we watch that question do its most valuable work — not deciding what to write, but shaping which proposal the agent refuses to write, without anyone instructing it to.

Early in the life of this compiler, the lead was the Red Cross in the Philippines. The prethink ran, the searches ran, and the agent produced two proposals. One was the obvious answer. The other rejected the question it had been asked — and nobody told it to.

This chapter is about the difference between an AI that quotes your thinking back at you and an AI whose behaviour your thinking has actually changed. The first is a search box. The second is the thing a senior partner charges for. The Red Cross fork is where the second showed up in production.

Retrieval has two uses the industry treats as one

The trick that produced it was almost accidental. Before the prethink runs, the agent does a few searches over the IP corpus — not to fetch facts, but to get into the right frame. As the source conversation put it: "it pulls the agent into a better mindset — a little bit of random priming, on topic, whatever it thinks it wants to do that day."

That names a distinction the industry usually misses. Retrieval has two jobs:

A few on-topic pulls before the prethink don't inform the agent — they tune it. Everything in context conditions everything generated after it. A Lane Doctrine excerpt sitting upstream changes what the model notices about the prospect before a single fact is used.

The design payload: the boot profile is the priming, done deliberately — mount the strategy-relevant region of your canon before the prethink. But keep a sampled walk in the mix, a temperature knob on which doctrine pages come along. You want the mechanism reliable and the dice intact.

The Red Cross fork, end to end

Proposal one answered the stated frame. The Red Cross is a public-facing NGO, therefore: real-time chat and voice, a customer-facing assistant. The obvious move — the one every template-plus-GPT tool would reach for.

Proposal two rejected the frame. It asked where the value actually lives, and found pre-disaster capability management — resourcing, training, readiness systems: high-uplift, non-customer-facing, deep in the tutorial zone where AI wins cleanly. Not the front desk. The back office, before the disaster. "You could give the organisation a reasonable uplift from it," as the source put it — and no human on the customer-facing frontline to compete with.

The tell was in the shape of the second proposal, not its words. The agent had internalised the Lane Doctrine and the boss-fight rule from the canon — the rule that when sub-second latency and high blast radius stack on the same task, you walk away rather than mitigate.

Don't do the boss fight. Look for the fast lane. Don't compete against the humans.

Knowledge becoming behaviour without instruction

Here is the sentence, from the person who watched it happen, that this whole chapter exists to explain:

I could see the IP frameworks coming alive inside the agent — it's prompt-injecting itself from reading the frameworks and the IP, and it's changing the shape of what it's doing.

Nobody wrote a rule saying "avoid customer-facing voice for this client." The agent read the boss-fight doctrine and the avoidance emerged. The doctrine never appeared in the proposal as content. It appeared as shape — as the decision about which proposal not to write. This is the mechanism worth naming, because it is the strongest possible validation of the idea that a compiled canon is a kernel, not a filing cabinet.

Contrast the two ways to get this behaviour. The instruction-list version is a brittle rule: "avoid real-time customer-facing plays unless…" — and it breaks the moment a client doesn't match the template you imagined. The read version is judgment. Because the agent absorbed the reasoning rather than the rule, it transfers to a hospital, a school system, a mining contractor — situations no rule anticipated. Read doctrine generalises; instruction lists stay brittle.

The canon encodes taste in problems

Notice what proposal two actually is: problem reframing. Not a better answer to the question asked, but a rejection of the question in favour of a better one. That is the single thing template-plus-GPT proposal tools cannot do, and it is exactly the move a senior partner is paid for. It fell out of frameworks conditioning the search space.

Your canon doesn't just encode answers. It encodes taste in problems — which problems are worth wanting.

This is the difference between retrieval and judgment stated at full strength. A retrieval system can tell you what you've said about NGOs. Only a system your doctrine has conditioned can decide that the NGO framing is the wrong one and quietly go looking for the value somewhere else. The canon didn't supply the answer. It supplied the taste that rejected the obvious answer.

How to build the stance on purpose

The accidental version — a few random searches for luck — is reproducible as a deliberate design:

The Red Cross reframe was worth keeping for another reason, too. Filed the right way — situation, move, outcome — it becomes reusable for the next prospect whose problem has the same shape but none of the same words. That filing discipline, and why it is closer to a fifty-year-old inventing method than to a database, is Chapter 4.

Beginning in 1946, Genrich Altshuller did something strange with patents. He refused to read them as solutions. He decomposed each one into the contradiction it resolved plus the abstract move that resolved it — and discovered that thousands of unrelated inventions collapsed into a small set of recurring principles.¹¹ He was doing wiki ingestion by hand, decades before the words existed.

This chapter is about the last discipline of the engine: what to do with everything it generates. Proposals, ideas, half-finished plans, the AI's own speculations. Filed one way, they are clutter. Filed the way Altshuller filed patents, they become a library that makes every future run start from your accumulated judgment.

TRIZ is the right ancestor

The method has a shape worth memorising, because it is exactly the shape of good ingestion: specific problem → abstract problem → abstract principle → specific solution.¹¹ You lift the messy specific into its general form, match on the general, then bring the general solution back down to the specific.

Altshuller's foundational study screened tens of thousands of patents — most reliably put at around 40,000 of the most inventive — and from them derived his 40 inventive principles. (Over the following decades the TRIZ research corpus grew into the hundreds of thousands and, cumulatively, into the millions; the often-quoted round numbers refer to different stages of that long effort.)¹² The payoff was precisely the one we're after: inventors stopped searching for similar solutions and started matching on problem shape.

Two ingestion classes with different fates

There's long-standing advice to file your AI's outputs back for reuse — you run a research agent, it pulls twenty pages and writes an answer, you save the question-and-answer for next time. For a long while that advice sat unused here, because it treats every output the same. TRIZ shows why it should not.

A synthesis is an answer to be cached. A proposal is a move to be generalised. The old advice files the artefact; TRIZ files the lesson of the artefact.

Our published File Back the Walk pattern already covered syntheses — hard-won answers filed as typed, regenerable cache pages. The case is the new type, and it is the deeper one. Its academic ancestor is case-based reasoning, which for forty years has stored experience as situation-features plus solution plus outcome, and — crucially — refuses to generalise prematurely, keeping the specific instances "as they are" until a new problem calls one up.¹³ Unsent ideas and the AI's own speculations file into this class too — marked untested, hypotheses waiting for a client-shaped situation to try them on.

The Red Cross case, filed in full

Take the fork from Chapter 3 and file it as a case. The schema is the whole point — it's what lets a proposal for a disaster-relief NGO surface, years later, for a mining company:

Now a mining contractor comes in: safety-critical, unionised frontline, a public brand it can't risk on a chatbot. Nothing in the words of the Red Cross proposal matches. But the shape matches perfectly — public-facing, contested human lane — so the move transfers: relocate the value to internal, pre-event capability (predictive maintenance, crew readiness, incident-response training). The library handed you the senior-partner move on a prospect it had never seen.

Why RAG can't do this

This is the sharpest form of a contrast we return to often. A retrieval system stores knowledge at the abstraction level it arrived at. A chunk of the Red Cross proposal will never be retrieved for a mining prospect — the surface text doesn't match. Ingestion does something different: it re-levels the knowledge to the abstraction at which it recurs.

RAG stores knowledge at the abstraction level it arrived at; ingestion re-levels it to the abstraction at which it recurs. RAG does similarity; the deconstructed library does analogy — and analogy is the mechanism of every interesting reuse in the history of ideas.

The specificity isn't lost, either — it's demoted down the ladder, pointer intact, so the concrete Red Cross language is one drill-down away when the abstract move needs re-concretising. Compression toward generality, with the receipts kept. Both layers are required: principles (top-down, your canon) say what's generally true; cases (bottom-up, worked examples) say when a move worked and what it looked like on the ground.

Two disciplines make it compound instead of bloat

A library of moves rots into a museum without two rules.

Cases are cheap. Principles are earned.

That is exactly how Altshuller worked: tens of thousands of patents before he trusted forty principles. The wiki already knows the difference between a case and a principle — that's what the edges are for.

A section on diversity: three proposals, not three versions of one

One more discipline earns its place here, because it's where the case library and the goal-run meet. The compiler produces three candidate proposals and shows the two it rejects — the John West move from Chapter 2. But three candidates are only useful if they're genuinely different. The first version enforced that by asking the model to judge difference: "make proposal two different enough from proposal one."

That instinct has a name — maximal marginal relevance, the classic greedy algorithm for diverse selection: pick the best, then pick the best-that's-sufficiently-different-from-what's-already-picked.¹⁴ The upgrade the case library unlocks is structural rather than cosmetic:

Diversity stops being something you hope the model achieves and becomes something the structure guarantees — MMR made structural, and testable.

The engine, closed

Put the four chapters together and the loop is complete. The substrate (Chapter 1) gives the engine what you have. The compiled goal (Chapter 2) points it. Your conditioned canon (Chapter 3) gives it judgment — the taste to reframe. And the case library (Chapter 4) keeps what it learns, filed at the abstraction where it recurs, so the next run starts from your accumulated judgment instead of a blank page.

The conversations were where the insight arrived. The library is where it stays. That's the difference between an AI that answers your question and an engine that gets better at answering it every time you run it.