One of the hardest tensions in an enterprise AI programme is deciding what should come first: the platform or the use case.
The platform argument is strong. If every team connects directly to a model, creates its own security pattern, builds separate monitoring and handles support differently, the organisation quickly accumulates fragmented AI implementations that are difficult to operate and govern. The use-case argument is equally strong: if the programme spends too long building a sophisticated reusable platform before anyone can demonstrate a useful business outcome, sponsorship and momentum can disappear.
I encountered exactly this tension while leading delivery of a reusable enterprise LLM capability and its first customer-service use case.
Both extremes can fail
A platform-first programme can become technically impressive but commercially abstract. Teams spend months building model serving, storage, pipelines, identity, observability and deployment capability, but the organisation still cannot point to a workflow that has materially improved.
A use-case-first programme can fail in the opposite direction. The first team moves quickly, proves something valuable and then discovers that the implementation is tightly coupled to one model, one environment or one team’s way of working. The second use case has to rebuild the same foundations.
Neither outcome is especially attractive. The delivery challenge is to keep the platform sufficiently reusable without allowing the platform itself to become the programme’s only visible outcome.
The first use case should shape the platform
The approach I prefer is to use a real operational use case to expose which platform capabilities are genuinely required. In our programme, the first major use case was customer-service call and chat summarisation.
That immediately made several platform questions concrete. The capability needed model serving, identity, storage, integration, monitoring and a route into the operational workflow. It also needed a safe way to handle generated output, which is why agents retained the ability to review, correct or approve summaries before information was saved to customer records.
Those requirements were more useful than trying to design an abstract “complete” AI platform in isolation. They created a clear test for platform work: did this capability materially help make the first use case safe, operable or easier to extend?
Reusable does not mean universal on day one
There is often pressure to design the perfect common platform before the organisation knows enough about its future AI demand. I think that is usually unrealistic.
Reusability should mean making sensible decisions that reduce unnecessary coupling and make the next use case easier, not predicting every future requirement. A model-agnostic API layer was important in our programme because it meant consuming applications did not have to integrate directly with one specific serving implementation. Identity and observability were important because they would be needed repeatedly, and operational support mattered because a reusable service has to be owned after launch.
Those were foundations worth protecting. Other components could evolve as actual demand became clearer.
Sequencing is a programme decision
The difficult part is not identifying that both platform and use-case work matter. It is deciding what gets priority when the same specialist teams are needed for both.
That requires a joined-up view of dependencies rather than separate backlogs. If the first use case cannot progress because authentication is missing, identity becomes a use-case dependency rather than simply “platform work”. If a platform component has no near-term consumer and does not remove a material future constraint, it may not deserve the same urgency.
That distinction helps move the conversation away from competing team priorities and towards the capabilities that unlock programme outcomes. It also gives sponsors a clearer explanation of why some foundation work is essential now while other technically useful work can wait.
Business value should create the next platform investment
The first use case in our programme supported an estimated opportunity of approximately 9,000 agent hours per month. That forecast helped create a meaningful value case for the wider capability, but it was not enough on its own; the platform still needed to prove that it could support the use case safely and operationally.
Once a use case starts demonstrating credible value, the conversation about reusable foundations becomes easier because investment is connected to something concrete. The programme can then ask what capability is needed next to support adoption, resilience or the next use case, rather than continuing to build an open-ended platform roadmap.
That creates a healthier cycle than either building a platform in search of a problem or launching isolated AI features with no sustainable foundation.
The answer is not platform first or use case first
The answer is to sequence the minimum platform foundations required to make a valuable use case safe, operable and reusable enough to justify the next step. That requires discipline because both sides will always have reasonable arguments for doing more.
The programme manager’s job is to keep the technical foundations and the operational value case connected closely enough that neither gets too far ahead of the other.