Some builders bet that AI will be able to assemble any context on demand, so there’s no reason to prepare. I don’t. Assembling a context and knowing its boundary are two different problems, and only the first gets solved by better models. An improviser hands you a confident answer but can’t tell you what it missed. Preparation converts unknown unknowns into known unknowns. My unit for this is a vector: an ongoing thread that knows where it begins and where it ends. The real architecture isn’t prepared versus on-demand, it’s on-demand reasoning running against prepared structure. Structure the spine, improvise the leaves. 

---

I’ve spent a long time trying to build organizations that run themselves, and that work keeps forcing the same question to the surface: how much does a system need to hold, versus how much can it reconstruct on the fly? There’s a split forming among people building with AI, and it comes down to a single bet.

One camp believes the models will soon be good enough to assemble any context you need, on the spot, from raw material. Ask a question, and the system goes and gathers everything (the messages, the meetings, the records), reasons over all of it, and hands you a coherent picture. They contend that the machine will just do it when you ask, so there is no reason to prepare.

I don’t build that way. It took me a while to say why, because the obvious reasons of cost, speed, and repeatability are real but they aren’t the point. The actual reason is that assembling a context and knowing the boundary of that context are two completely different problems. Only one of them gets solved by better models.

When a system improvises a context on demand, it pulls from whatever it happened to retrieve. What it cannot do is tell you what it missed. It has no way to say “this is complete through Tuesday, but the latest batch isn’t in here yet,” because nothing ever established that there was a Tuesday-shaped hole to begin with. The gap only exists if you built a structure that expected to be filled.

For me the value of preparation was never the pre-chewed context. It’s that preparation converts unknown unknowns into known unknowns. An improviser optimizes for the average question and looks brilliant doing it. A prepared structure is insurance against the confident omission. A plan with a missing requirement. A decision made on data that quietly went stale. A commitment nobody can reproduce the reasoning for tomorrow.

I keep coming back to a single unit I call a vector: an ongoing thread of work with its own stakeholders, its own events, its own sources, and, most importantly, its own coverage boundary. The point of maintaining it isn’t to cache answers. It’s to have something that knows where it ends. When I open a vector, I don’t just get what’s in it. I get an honest signal about what isn’t: what’s connected, what’s still pending, how current it is. That signal is impossible to fabricate after the fact. It has to be a property of the structure. And it is, as far as I can tell, the actual substrate a self-running organization stands on.

The on-demand camp isn’t naïve. Prepared structures rot. Someone has to keep them current or they lie to you. And rigid schemas can’t answer the novel, cross-cutting question the way free-form reasoning can. Those are real failure modes, and I’ve walked into both.

But the mistake is treating this as prepared versus on-demand. It isn’t. The right architecture is on-demand reasoning running against prepared structure instead of against raw chaos. You keep the fluidity, derive any state you want, any time, and answer questions you never anticipated. You just derive it from a base that is stable, inspectable, and aware of its own edges. That is strictly better than either pole alone. Once the spine exists, deriving state is cheap. Without it, every question is a fresh act of reasoning over the entire world, and not one of the answers knows what it left out.

So the discipline I hold is simple: structure the spine, improvise the leaves. Prepare the things that are expensive to reconstruct and costly to get wrong, which is the threads, their coverage, and their provenance. Let the model handle the long tail. And build the structure so it tracks its own staleness, so that “prepared” never quietly decays into “confidently outdated.”

The strongest version of my argument isn’t “AI can’t assemble context.” It can and it will only get better at it. The strongest version is this: AI can assemble the context and still not tell you what’s missing. And for the decisions that actually matter, the missing part is what matters.

Being prepared isn’t about distrusting the machine. It’s about wanting a ground truth to check it against. An organization that runs itself has to know the edges of what it knows or it will act on a gap it never saw. Improvisation is a bet that the average case is good enough. Preparation is a bet that one day it won’t be, and that you’d rather know where the edges are before you find them the hard way.

…