The self-hosted tiger team.

How does an enterprise decide what to build?

Part 1 made the case for a central LLM behind a governed perimeter, orchestrating a library of deterministic tools that encode the business's logic. I ducked one question any serious reader would ask: how does an enterprise decide what to build?

You have dozens of departments, hundreds of possible business logic artifacts, and finite engineering capacity. Which tools go first? Whose logic gets encoded? Who owns the roadmap? This post answers that.

It's a consulting engagement, minus the slide deck.

The best analogy I've found comes from my old world: twelve years in management consulting before I moved into software. A consulting engagement has a specific shape. It starts with a strategic question, should we exit this business, how do we price the new segment, which SKUs are worth rationalizing. It scopes the analytical work, which usually means pulling data from a dozen systems that don't talk to each other, building models the client couldn't build themselves, running scenarios, and synthesizing across all of it. It hands back a recommendation as a slide deck.

Now compare that to the workflow from Part 1. The LLM takes a strategic question. It queries a segmentation tool, runs a supply chain simulation, runs a price elasticity simulation, synthesizes across all of it, and produces a recommendation. Structurally, that is a consulting engagement. The tools I'm describing are the frameworks and models consulting firms have been building and rebuilding for their clients for fifty years.

I came at it from the other side too, running a bootstrapped startup where we put the entire business into one codebase, product code, website copy, sales content, legal and security policy, so our AI always has the context to act. You can't do that in an enterprise, where the "codebase" is hundreds of systems and thousands of documents. But the principle holds: AI produces good work when it has high-quality, business-aware context to reason over. At enterprise scale, that context is composable, governed tools. Same principle, different container. The difference is that a startup fills its container in a weekend, and an enterprise fills it one function at a time, starting with a question narrow enough that a single team owns the answer.

Every consulting engagement is really two engagements.

Every consulting engagement is really two engagements running in parallel. There's the analytical engagement, meaning marshaling data across functions, building the model, running the scenarios, producing the recommendation. And there's the human engagement, meaning interviewing stakeholders, aligning executives, negotiating trade-offs, working with HR on compensation implications, planning the rollout.

The analytical engagement is genuinely hard. In a large enterprise it can be functionally impossible without consultants, precisely because the data lives in silos, the models don't exist internally, and no single person has enough authority to pull it all together. This is what enterprises pay millions of dollars for. It's also exactly what a well-equipped central LLM can do at near-zero marginal cost, on demand, provided the tools underneath it can actually run the analysis, simulate, and test alternatives, not just surface data. That persistent analytical capability, run inside your own perimeter, is the self-hosted tiger team.

The human engagement is not going anywhere. The negotiation among stakeholders, the alignment with HR on bonus structure, the rollout plan, the tough conversations with executives who don't want to hear the answer. None of this is analytical. All of it requires humans with authority, relationships, and organizational context. An LLM cannot broker a deal between the CFO and the COO. It shouldn't try.

The reframe is not "AI replaces consultants." It's that AI operationalizes the analytical half of what consulting produces, and does it as a persistent capability rather than a one-time engagement.

Each strategic question is a candidate engagement.

Here's where the analogy stops being nice-to-have and starts being operational.

If each strategic question is a candidate engagement, and each engagement suggests a set of tools, prioritization becomes tractable. You don't need a grand plan. You need a list of the strategic questions your organization actually wrestles with, in QBRs, offsites, annual planning, board meetings, and the emails your CEO sends at 11pm, and you work backwards.

For each recurring question, list the tools the analysis would need. Then look across the questions and count. Tools that show up in multiple engagements are the ones you build first. Tools that only show up once, you probably don't build at all, or you build them as one-off analyses rather than durable capabilities.

This is roughly how good consulting firms decide which practice areas and IP to invest in. It's also how good product teams prioritize platform investments. It should be how enterprises prioritize their AI tooling.

One important corollary. The team that builds these tools looks less like a traditional IT function and more like an internal product team with strategy-consulting DNA. Close enough to the business to know which questions actually recur, technical enough to build durable tools, disciplined enough to say no to one-off requests that don't generalize. That's an unusual talent profile most enterprises don't have on staff yet.

Your first engagement should need one tool you don't have.

Prioritization tells you what to build eventually. It doesn't tell you what to build first, and that answer is narrower than most people expect. Earlier I split every engagement into an analytical half and a human half. Your first engagement should have a large analytical half and a small human half: the analysis genuinely hard, hard enough that nobody does it properly today, and the decision belonging to roughly one person once the analysis lands.

"What happens if we move two million from this channel to that one?" is a question marketing is asked every planning cycle and answers with last year's numbers and an argument. It needs one tool you build: a model of what actually drives volume, that can be asked questions it has not been asked before. And it needs one you already have: the margin model finance maintains, which turns volume into revenue, cost, and profit. You are not building the second one. You are making a spreadsheet that already exists callable.

The reason to connect them is the answer neither gives alone. The mix model says the reallocation lifts volume four percent, and on its own that ends the conversation. The margin model says the volume it lifts is trade promotion volume, which carries a thinner margin, so the reallocation that grows the business shrinks its profit.

Here's how that decision gets made today. Marketing runs the mix model and comes back with a reallocation that lifts volume. FP&A looks at it and points out what it does to margin. Marketing revises. Another meeting. Somewhere in the third or fourth round everyone is tired, and the plan that ships is the one that survived the last round of objections.

Nothing in that loop is wrong. The answer is knowable, and two competent teams get there. What it costs is options. Every iteration is a meeting, so you get three of them, not fifty. Marketing doesn't bring the best plan to FP&A. It brings the first plan it thinks will survive FP&A.

With both models callable, marketing runs those iterations alone, in an afternoon. Try the shift into trade promo, watch margin fall, try it against a different channel mix, see what holds. Fifty versions instead of three. The meeting with FP&A still happens, and it should. What changes is that it starts from a plan already tested against finance's own model, so the conversation is about whether to do it rather than about what it does.

The meeting stops being about what the plan does and starts being about whether to do it.

A starter engagement stops at the point where a third function has to agree with the answer. That's the line between a decision and a negotiation. And the tool doesn't retire when the engagement ends: the demand baseline underneath the mix model is the first input to launch sizing, to promotional planning, and to every question about what the business is going to sell next year. Some of these tools you can buy rather than build, which is worth knowing before you staff a team. The ones nobody sells yet are the reason we built River.

OKR alignment, once the library exists.

Now the destination, which is emphatically not where you start. Consider OKR alignment across a large enterprise. Every department has its own goals, most of which were set independently. Some contradict each other: marketing has been told to grow leads while product has been told to protect margin. Bonus structures are tied to metrics that don't roll up cleanly to the enterprise objectives leadership cares about. Every year, someone spends months untangling this, and the deliverable is a slide deck that starts drifting the moment the org restructures.

Run through the tool library, the engagement looks like this. The LLM pulls the current KPI and OKR inventory across the organization. It queries a dependency graph tool that maps how each metric relates to every other, which goals share underlying drivers, which contradict, which cascade to which. It runs a target simulation that tests what happens under different cascading structures and models the second-order effects on service, cost, and margin. It queries the compensation model that maps bonus structures to metrics, and identifies where bonuses reward behavior that contradicts the proposed OKRs. Then it synthesizes: here are the contradictions in the current system, here are three cascading options, here's what each does to service, cost, and margin, and here's what compensation would need to look like under each. Every quantitative claim traces back to a tool the business trusts.

Then the humans take it from there. The CFO and COO still have to negotiate the trade-offs. The CHRO still has to work through what changes in bonus structure require board approval, union consultation, or notice periods. What goes away is the six weeks of analytical scaffolding that used to have to happen before those conversations could even begin.

Notice what this engagement costs. Four tools, every function in the company, and a human half that runs through compensation, the board, and in some geographies a works council. By the standard in the previous section it fails badly as a starting point, and that's the point. Most of those tools, the KPI inventory, the dependency graph, the target simulation, are the accumulated output of engagements that came before it. You don't fund an engagement like this. You arrive at it.

A serious analytical engagement, for the cost of a query.

Once you start looking, most of what strategy teams and consultants do fits this pattern. Portfolio rationalization and capital allocation. Pricing strategy. M&A integration. Cost restructuring. Market entry. Sales territory design. Supply chain redesign. Talent strategy. You don't need to build tools for all of them at once. Pick the two or three engagement types that come up most often, build the tools they share, and let the library compound.

The most valuable capability enterprises can build over the next few years isn't a better model or a bigger data warehouse. It's the ability to run a serious analytical engagement, the kind that used to require a case team and six weeks of calendar time, on demand, for the cost of a query. Consultants will still do what they've always done best: sit in rooms with executives, broker hard conversations, and shepherd change through organizations. What changes is that the analytical scaffolding underneath those conversations becomes a persistent, queryable asset the enterprise owns rather than rents.

If you're figuring out where to start building the tool library from Part 1, "what would a really good consulting engagement need?" is the best question I've found.