#include the Wiki: Building With Strategy Attention-Resident

A product I built came out faster and better than I designed it — and it took me a while to work out why. It wasn't that I queried the wiki harder during the build. It's that I never closed the conversation the strategy lived in. The strategy was still in the room, and everything got built against it.

By Scott Farrell, LeverageAI

Let me start with the thing that nagged at me, because it's the kind of result you should be suspicious of. A while back, one of my very first projects with the wiki wasn't building the wiki — it was using it. I sat down to do strategy: what could I make, what was worth making, where was the opening. Out of that conversation came a handful of ideas, and one of them was a product for the AWS Marketplace. Then, in the same chat, I started building it. Over a couple of sleeps it was done. I built it quicker than I thought I could, and when I looked at it, it was better than I thought it could be.

My first instinct was to credit the model, or the momentum, or luck. But there was something else going on, and I'd underestimated it at the time: I was building it against the wiki as the backdrop. Not calling the wiki more. Not running fresh lookups mid-build. The wiki — and the whole strategy conversation it had grounded — was simply still there, in the context, while I coded. That turns out to be the whole story, and it has a name I'll get to. First, the counter-example, because it shows you what the normal way costs.

The way handoffs normally work — and what they lose

I was on a consulting engagement recently with a big-four firm — I won't name them — and I could not believe what the work actually was. Almost all of it was pulling numbers out of the client's systems and putting them into Excel. And then every meeting was about what the spreadsheets said: how to resync them, whether they were accurate, why last week's number didn't match this week's.

Here's the part that gets me. They were building databases. Schemas, joins, versions, a sync pipeline — that is software development. But calling it “Excel” exempted the whole thing from every discipline that word would have triggered. No tests, no source control, no review, no spec. Because, no. It's Excel. And the meetings weren't analysis — they were humans hand-cranking context and provenance, doing by hand the exact bookkeeping a compiled system does structurally. It's a manual reporting factory, run at partner rates by the people billed as the adults in the room. And the cruelest part: every insight assembled in those sheets evaporates the day the engagement closes. The deliverable dies at the end of the statement of work.

I keep that specimen close because it's the honest picture of how knowledge normally moves between a strategy and a build: through a handoff, and handoffs leak. Someone decides why. Someone writes it down. Someone else — or the same someone, later — inherits the document and builds the what. The context that held the reasoning doesn't travel with the artefact. It's a game of telephone, and we've just learned to accept the loss as the cost of being organised.

A handoff is where the why goes to die. The builder inherits the what, and re-derives the why if they can be bothered — usually they can't.

The #include realization

Now back to the build that went suspiciously well. What I actually did — without thinking of it this way at the time — was treat the wiki like a library in a program. When you write C++ or Python, the first lines include your libraries. You pull in a few tools. And then, in my case, the third include line was everything I'd just talked through in the wiki — the strategy, the frameworks, the reasons. Then I started coding.

The important word in that sentence is then. I didn't hand the strategy off and open a fresh build. I kept coding in the same conversation, with the strategy pages already loaded. And this is the thing I want to be precise about, because it's where the whole wiki idea earns its keep: the wiki is not an active product. It's not answering anything. It's not even an active substrate. It's AI-enabled — the AI brings it alive — but its mode here is presence, not response.

The whole idea of the wiki is not to answer anything. It's not an active product. The AI brings it alive — and sometimes all it has to do is be in the room.

Here's the mechanism, stated plainly. When strategy and build share one context window, the wiki pages loaded during strategy don't need re-fetching — they're attention-resident. Every token of that build was generated conditioned on the wiki-grounded strategy, whether or not another wiki call ever fired. Maybe it didn't make a single fresh wiki call while I coded. Didn't matter. It was in the conversation, and so it was in the attention. This is a familiar move in a different disguise: the wiki as a small, frequent, advisory prior — a nudge — except operating at the attention layer rather than the retrieval layer. Not consulted. Ambient.

That's the difference between “I looked something up” and “I built the whole thing in a room where that something was hanging on the wall.” The lookup is an event. Residence is a condition. And a condition shapes every decision that happens inside it, including the thousand small ones nobody would ever write a lookup for.

Why the spec is the thing that was costing you

So why did the build come out better than I designed it? Because I accidentally deleted the handoff.

Normally, strategy→build crosses a document boundary. You write the spec, the context that produced it dies, and the builder inherits the what while the why stays behind in a conversation nobody reopens. That's the same telephone game as the big-four spreadsheets — except now it's happening inside a single project, between your own strategy self and your own build self. A spec is a compression. It's a lossy compile of the strategy: it preserves the requirements and throws away the reasoning that would have told the builder which requirements mattered and why, and what to do at the hundred forks the spec never anticipated.

Keep the strategy resident and there's no compile step, so there's no loss. The thing that built the app was the same context that had decided why the app should exist. Every fork in the build got resolved by a builder who still had the reasons in view — not a builder working from a flattened list of features. This is what a zero-loss handoff looks like when you push it to its limit: not a better-written spec, but no document boundary at all. Why the conversation can carry all of this in the first place — why access became cheap enough that the chat window is the workspace — is the argument in a companion piece of mine, Conversation Is the REPL; I'll take it as given here and only use the one consequence.

The #include wiki wasn't the third line of the program. It was the linker. The strategy conversation was the header file, and the build compiled against it.

That's the upgrade to my own metaphor. I'd been thinking of the wiki as an include line — something you pull in at the top. But an include line just names a dependency; the linker is what makes the reference actually resolve, binding the code you're writing to the definitions it depends on. Residence is the linker. It's why the features came out pointing in the same direction as the strategy, instead of merely satisfying it.

One honest boundary. This works cleanly because it was one person in one context — me, my strategy, my build, one window. A twenty-person team can't literally hold everything in one conversation; some handoff boundary is real for them. Fair. But the lesson runs the other way too: the boundary you can't delete for a big team, you can delete for a solo AI build — and if you re-import the spec-and-handoff ritual out of habit, you're paying the telephone tax voluntarily, for nothing.

How do you write intent for a system whose product is surprise?

There's a harder version of this problem lurking underneath, and it's the one that made me value the wiki in the first place. We're now building applications we couldn't economically build before, and applications for things we couldn't do at all before. And what keeps turning up — the recurring surprise — is answers to questions we didn't know we had. Sometimes we didn't even know there was a question.

So how do you write the intent for a system like that? You can't. Specifying “surprise me with the things I don't yet know I need” is a contradiction — the moment you can specify the destination, it isn't a surprise anymore. The answer is the one I kept arriving at intuitively: you don't specify the destination, you set the foundations. You put in the groundwork you can reasonably expect you'll need, under any future — the safe bet.

That instinct has a finance name, and it's worth saying out loud: optionality. When the payoff can't be specified, you don't buy a fixed outcome — you buy the capacity for unforeseeable outcomes to land somewhere useful. Nobody wrote user stories for the road network or the power grid; you build the substrate precisely because you can't predict what will run on it. Under conditions where the forecasting window is short and the space of plausible moves is exploding — the fog most leaders are now operating in — option-shaped assets are exactly what you should be funding. The wiki's business case was never “it will answer question Q.” It's that every question you can't yet imagine will need compiled context, joined relationships, and provenance — and those are safe bets whatever the question turns out to be.

That's how you write intent for a system whose product is surprise: intent for the capacity, not the answers. Foundations first.

And notice what closes the loop. The reason the resident wiki made that AWS build better is the same reason it's worth funding as a substrate: a body of compiled strategy, present in the room, is capacity waiting to be spent. The same afternoon's wiki went on to seed workflows that didn't exist when it was written. You don't get that from a spec. A spec can only give back what you knew to put into it.

A note on what this compounds on, and what it costs

It would be dishonest to imply the wiki appeared fully formed. It's the output of a loop: I take my thoughts, record them, hand them to an AI, turn them into a conversation, reindex that through the wiki, and carry it into the next conversation — a cognitive exoskeleton that gets a little stronger each turn. Residence is what lets each build stand on all of that at once. (There's a sharper claim buried in that loop — that what you're really keeping isn't the documents but the thoughts, callable again at working fidelity — but that's its own argument, and I've made it separately.) For this piece, the loop only matters as the thing residence draws on. The richer the compiled backdrop, the more a build inherits for free.

The obvious objection is cost: you can't keep everything resident; context windows are finite. True — and you don't have to. You keep resident the handful of pages the strategy actually touched, and the wiki is built at the grain that makes this cheap: a page is a claim with its edges, which is about the size of a single turn in a conversation. A few of those is a small share of a modern context window, and the share keeps shrinking as windows grow. I'm not going to invent a token count for you — the exact arithmetic depends on your model and your corpus — but the shape is clear: you are spending a trivial slice of context to avoid re-deriving, at frontier prices, the most expensive thing you had, which was the strategy. That trade only gets better with time.

The test that turns this from a story into a claim

I don't want you to take “it came out better” on my word. That's an anecdote, and anecdotes flatter the teller. So here's the falsifiable version — the thing I'd actually bet on, and the one experiment that would settle it.

If Arm B comes out just as good, my whole claim collapses and residence is a comfortable illusion. I'd take that bet the other way, and I'd take it with you rather than against you. But the point of stating it as a test is that you don't have to trust me — you can run it on your next build and read the result yourself.

Where this leaves your next build

If you build with an AI in the loop, take three moves from this. First, stop reflexively compiling strategy into a spec. The spec isn't neutral bookkeeping; it's a lossy compile that throws away the why. When you can avoid the boundary, avoid it — do the strategy and the build in one continuous context and let the reasoning stay resident. Second, #include your wiki as a backdrop, not a service. Its strongest mode isn't answering your questions; it's being present while you work, conditioning everything downstream. Load the pages that matter and leave them in the room. Third, fund capacity, not answers. For anything whose value is that it catches surprises, specify the foundations and buy the optionality — don't pretend you can write requirements for questions you don't have yet.

The reason the AWS build came out better than I designed it wasn't a better design. It was that I never made my strategy leave the room, so the build never had to guess at its own reasons. The include line was the least of it. The real move was refusing the handoff — letting the header file stay open while the thing compiled against it.

So next time, before you write the spec, ask whether you need to write it at all. Do the thinking where the building happens. Leave the strategy resident. And then watch whether the thing you get back is merely correct — or whether it also knows why it exists.

Scott Farrell writes on AI strategy, knowledge architecture, and the economics of building compounding intellectual assets at LeverageAI. If your last build shipped every feature and still somehow missed the point, the fix might not be a better spec — it might be not writing one.