Context is the hard part.

How do you actually get there from here?

Part 1 and Part 2 laid out an architecture and an operating model. A central LLM behind a governed perimeter, orchestrating a library of composable tools that encode business logic. Prioritize which tools to build by treating each recurring strategic question as a candidate engagement. Let the tool library compound.

Both posts assumed a starting condition that most enterprises don't have. They assumed the business logic to be encoded already exists in some retrievable form. In reality, most of it doesn't. It lives in the heads of experienced functional leads, in spreadsheets nobody can maintain, in slide decks nobody has looked at in a year, and in the folk memory of the organization. Making any of it queryable by an LLM is real work.

So the question I ducked in Parts 1 and 2, and that any serious buyer will ask, is: how do you actually get from where you are today to the vision I described?

Fair warning: I don't think there's a clean answer. But there are patterns worth naming, and there is a specific trap worth avoiding.

Don't lead with a data foundation project.

Enterprises will look at Parts 1 and 2 and reach for the natural next move: "We need to make our entire business AI-legible. Inventory every system, codify every piece of business logic, then build the tools on top." Don't. This is the data warehouse project of the 2010s wearing new clothes, and it fails the same way: no visible value for two-plus years, every function has to change before anything materializes, boil-the-ocean scope means nothing ships, and the business changes faster than the substrate can be built. You spend three years building a beautiful "AI-ready enterprise" that nobody uses, because by the time you're done the questions have changed and the political capital is gone.

The mistake is subtle. Data foundation work isn't wrong; leading with it is. It has to develop alongside real use cases, not ahead of them. Snowflake's own implementation guidance says as much: "The data and governance foundation should develop alongside the portfolio."

So start with a use case, not the data. Pick one strategic question your organization actually wrestles with, something that matters, recurs, and has obvious value if you answer it well. Part 2's test applies here: a large analytical half, a small human half, one tool you don't have and one you already do. The marketing spend reallocation from Part 2 is the shape to look for, and OKR alignment is the shape to avoid until the library exists. Do what a good consulting engagement would: figure out the tools you need, interview the people who do this work manually, build the one or two tools the engagement absolutely needs, ship, measure, and learn. Then do it again with the next engagement, and the next. The tools compound, and, this is the key point, the context accumulates as a byproduct.

A rule of thumb from Dataiku's transformation guide: if a pilot can't ship in eight weeks, it's not yet scoped as a pilot. Break it down further. Shipping something small and useful, quickly, is what keeps this from becoming another multi-year data initiative that dies in a budget review.

The hard part is making each function legible.

Every function will eventually need to go through its own transition to become legible to a central LLM. Marketing will need to write down how it actually thinks about customer segments. Finance will need to codify what "revenue" actually means. Supply chain will need to formalize the priorities behind its trade-offs. HR will need to make its compensation logic queryable.

Most of this knowledge currently lives in three places: in the heads of functional leads with fifteen-plus years of experience, in spreadsheets with cryptic formulas nobody can maintain, and in slide decks from strategy offsites that no one has opened since.

Making it legible is real work. It looks a lot like the internal knowledge management projects consulting firms have been trying to sell for decades, except with a better delivery mechanism at the end.

The good news is that the tooling for this has gotten much better than it was even two years ago. Modern LLMs happily accept stream-of-consciousness dictation and turn it into structured documentation. A functional lead can talk into a mic for an hour and get back a solid first draft of "how we think about pricing decisions" in markdown. What used to require a consulting team writing memos now requires a functional lead willing to talk out loud.

Even then, a document isn't a tool. Writing down how pricing works gets you a description the LLM can read. It doesn't get you something the LLM can run a scenario through. The harder step is turning that logic into an executable tool, a forecast, a simulation, an optimizer the LLM can invoke, feed new assumptions, and re-run. Extracting the knowledge is slow. Engineering it into something the LLM can actually use is slower, and it's the part that separates a real decision-making capability from a better search box.

But, and this is the sequencing point again, you can't lead with this work. It's too abstract, too internally-focused, and it won't survive the first budget review. You have to earn the right to do it by shipping valuable use cases first. Function-by-function legibility is the payoff of a running program, not the entry ticket.

Governance has no universal answer.

I said in Part 2 that governance is unavoidably political. Whoever controls the tools controls the answers. There is no clean theoretical answer to this that survives contact with real organizations.

What I've come to believe is that governance can't be designed up front. It has to emerge from real use. When Marketing and Sales disagree about "customer segment," you find out fast, and you have to actually resolve it, or design the tool to hold both definitions and reconcile at synthesis time. When Supply Chain and Finance want different assumptions in the forecast, someone has to arbitrate.

The best enterprises will treat these disputes as productive, not as blockers. Every disagreement surfaces a real business ambiguity that the organization was already living with. The tool just makes it explicit. Some organizations will resolve them by executive fiat. Others by cross-functional committee. Others by letting each function have its own version of the tool. There is no universal right answer here, and don't let anyone sell you one. The governance model you land on will reflect your culture, your incentives, and your existing power structures more than any framework a vendor hands you.

Don't stall the program to design perfect governance. Ship something. Watch the disputes emerge. Let the resolution patterns tell you what your governance model actually is.

This takes years, not quarters.

Now the honest part. This takes years. Not "twelve to eighteen months, per Gartner." Actual years.

A rough shape:

• Year 1: one or two engagement types, four to six tools built, small internal team learning the operating model. First real value delivered.
• Years 2-3: four to six engagement types, tool library reaches critical mass, function-by-function legibility work begins in earnest. Some functions are now materially faster at strategic questions than they were.
• Years 3-5: most strategic engagements run through the tool library. Most functions have made themselves legible. Governance patterns are established, even if they were never formally designed.
• Year 5+: this is just how the organization works.

If someone tells you they can compress this timeline meaningfully, they are either selling you something you shouldn't buy, or they're going to build you something that doesn't compound. Both outcomes are bad.

The good news is that even the first year produces real value. You don't have to wait until year five to see returns. The compounding just gets better every year, and the organizations that start now will have accumulated three to five years of tool library and functional legibility by the time slower competitors are still evaluating vendors.

The whole vision, in one paragraph.

Between the three posts, here's the vision in one paragraph:

Build a central LLM behind a governed perimeter. Give it access to a library of composable, deterministic tools that encode your business's specific logic. Prioritize which tools to build by looking at your recurring strategic questions and building the tools those engagements need. Start with one or two high-value use cases, not with a data foundation project. Let context accumulate function by function as a byproduct of shipping. Let governance emerge from actual use. Accept that this takes years.

This is a real transformation, not a productivity upgrade. It requires patience, sustained executive sponsorship, and a specific kind of internal team that most enterprises don't have on staff yet. Most enterprises won't do it. The ones that do will build compounding advantages over the next five years that the ones that don't will find increasingly hard to catch up to.

The path is not easy or fast. But the alternative is renting the analytical scaffolding of your strategic decisions from consultants forever, or worse, making those decisions without it. Neither is a good long-term posture.