Enablement Isn't a Strategy

Finance teams are pulling AI budgets back under central control. In Pigment's Q3 2026 CFO Index, 83% of respondents said consumption-based AI costs came in above expectations. A U.S. Bank survey released in September found 51% of U.S. finance leaders exceeded their AI budget over the prior year. Forrester reports enterprises postponing 25% of planned AI spend to 2027.

Release cadence has not slowed to match. New agent frameworks and tools arrive monthly, many marketed on how quickly any team can spin up its own group of agents.

Inside most enterprises, those two trends meet in the same place: a platform and operations team asked to enable everything, and a finance team asking what any of it delivered.

The dollar amount is rarely the core problem. The problem is that nobody decided what the spend is for.

Most enterprise AI programs measure enablement by activity: tools approved, seats active, releases adopted, pilots launched. Those numbers are easy to collect and easy to report upward. They say nothing about whether a business outcome moved.

Under activity metrics, chasing every new release is the rational choice. Teams that adopt quickly look productive. Teams that pause to define a use case look slow. Nobody is being careless; the measurement system rewards motion over results.

The predictable outcome is duplication. Without defined problem areas, several teams independently build similar agents, retrieval pipelines, and integrations against the same unprioritized problem. Each effort looks like innovation locally. Across the organization, it is the same work paid for three times, with three versions left to maintain.

This is not a new failure. Organizations saw the same pattern with uncoordinated data marts and microservice sprawl. AI accelerates it, because the tools lower the cost of starting something without lowering the cost of maintaining it.

The fix is to assign innovation to lanes before enabling more tools. The model has four parts.

Start from a capability map of the architecture the organization is building toward. Leadership selects a small number of lanes, each tied to a problem area with identified strategic value.

Each lane gets a cross-functional team, a defined problem set, and a discovery backlog where ideas and project proposals land. Teams deliver in quarterly building blocks that add up to a longer-term vision. A new idea goes to the lane that owns that problem instead of starting a parallel effort.

Lanes do not build shared infrastructure. A platform team builds and runs the broad capabilities every lane relies on: a model gateway, a capability registry, evaluation harnesses, and observability and cost monitoring.

The platform team does not approve projects. It builds the shared capabilities projects depend on. This mirrors the stream-aligned and platform team pattern described in Team Topologies, applied to AI capability delivery.

Lanes do not wait for the platform. A team can ship a deliverable before the registry exists; the platform team onboards it once the registry is working.

Lane work also tells the platform team what matters most. When two lanes solve the same infrastructure problem separately, that problem becomes a platform priority. Lane and platform priorities are set in the same quarterly planning session, so staffing and sequencing stay aligned.

Convergence only stays cheap if lanes build in compatible ways from the start. Before any platform capability exists, every lane commits to a short list of conventions:

These cost little up front. They turn later onboarding into a configuration task rather than a rewrite. Standards first, infrastructure second.

A lead architect connects the pieces by maintaining the reference architecture, the conventions, and the decision records, so every lane builds toward the same connected system.

Measurement follows from the structure. Trace tags tie token cost to a workflow and a lane, and each lane reports cost and outcomes against its own charter. That moves AI ROI from an annual estimate to something tracked every quarter.

This model trades one set of problems for a smaller, more visible set. Six are worth planning for.

Most routing decisions in this model come down to four questions.

The evaluation lane is a small, time-boxed group that tests new releases against a problem an existing lane already owns. Each evaluation ends in one of three outcomes: adopt into a lane, revisit next quarter, or drop.

Waiting on a new release does carry a cost. Skills lag, and competitors may learn first. But that cost is usually smaller than the cost of unfocused adoption across the organization, and a deliberate evaluation lane captures most of the learning. Engineers can still explore new tools on their own projects. The enterprise roadmap is where focus matters.

Use one charter per lane. Fill it in before the lane starts, and revisit it each quarter. The examples are hypothetical.