Multi-Model AI Is the Default: What Project Managers Need to Govern Now
In production AI deployments, 59% of agentic token usage now routes across multiple models from different providers. Most project teams’ governance frameworks, cost-tracking processes, and accountability structures were built around a single AI provider - and they have significant gaps when workflows span Anthropic, Google, and others. This is a project management problem, not a technical one.
Something shifted in how AI is actually being used at scale, and it happened quietly enough that most project governance frameworks haven’t caught up.
Vercel published production data from their AI Gateway in May 2026 - not survey responses, not predictions, actual traffic from teams running AI workflows at scale. Fifty-nine per cent of agentic token usage routes across multiple models from different providers. Anthropic accounts for 61% of spend (higher-cost tasks requiring frontier reasoning). Google accounts for 38% of requests by volume (high-frequency tasks where speed and cost efficiency matter more than raw capability). The two don’t add up neatly because they’re measuring different things - and that’s exactly the point.
The multi-model era isn’t coming. It’s already the operating model for teams serious about production AI.
Which creates a specific problem for project managers: every governance framework, cost-tracking process, and accountability structure I’ve seen built around AI in project delivery assumes a single provider. One model. One cost line. One set of data handling policies. One vendor relationship.
That’s no longer the reality, and the gap between the governance you have and the system you’re actually running is a delivery risk.
Why Teams Are Running Multiple Models
The short answer is economics and performance. A six-to-one cost differential between a frontier model and a capable budget model isn’t a marginal consideration, it changes the architecture.
The practical logic: use frontier models (Claude, GPT-5) for tasks that genuinely require sophisticated reasoning - complex risk analysis, carefully calibrated stakeholder communication drafting, ambiguous scope assessment. Route high-volume, lower-stakes tasks to faster, cheaper models - meeting note extraction, template population, structured data formatting, status report assembly from a consistent input format.
This isn’t a workaround. It’s the design. Real ROI from production AI comes from routing intelligently based on cost, quality, and latency requirements - the same way a PM thinks about resource allocation. One model for everything is no longer the assumption.
But intelligent routing creates invisible complexity. If you don’t know which model handled which task, you don’t know where an error came from. You don’t know what data was processed under what terms. You can’t reconstruct the audit trail. And you definitely can’t answer the question your programme sponsor is increasingly likely to ask: what AI systems are we actually running on this project?
The Governance Gaps That Open Up
Cost attribution. A single-provider AI budget is straightforward - one line, one invoice, one approval. Multi-model routing scatters cost across providers, often on consumption-based pricing that makes monthly totals unpredictable. Without deliberate cost attribution by task type or workflow, AI spend on a project becomes a number no one can explain.
Quality standards. Most AI quality governance is implicit - it assumes a particular model’s capabilities and failure modes. When tasks route to different models based on cost or load, those implicit assumptions break down. An output that would be reliable from a frontier model might be unreliable from a budget model handling the same task. The governance framework needs to specify standards by task type, not by model.
Data handling. Provider data policies vary - on retention, training use, jurisdiction, and enterprise data agreements. A team running workflows across Anthropic, Google, and an open-weight model deployed in their own infrastructure has three different data handling regimes potentially active on the same project. The question of which data can go through which provider requires an explicit answer, not an assumption that whatever the default settings are is fine.
Accountability. When something goes wrong - an incorrect risk summary, a stakeholder communication with wrong data, an agent action that shouldn’t have been taken - the audit trail needs to trace back to which model processed which input and produced which output. In a single-provider world, that’s relatively straightforward. In a multi-model workflow, it requires deliberate logging that most teams haven’t set up.
What PMs Need to Know (and Ask)
You don’t need to make the routing decisions - that’s engineering and architecture territory. But you do need to understand the stack, ask the right governance questions, and make sure accountability doesn’t fall into the gaps between providers.
Before a multi-model workflow goes into production on your project, get answers to these:
Which tasks route to which models, and is that decision documented? What are the quality standards for each task type, and are they model-agnostic? What data is processed by which provider, and is that consistent with your project’s data handling requirements? How is cost tracked per workflow, and who reviews it? If something goes wrong, how do we trace which model produced the faulty output?
None of these require technical expertise to ask. They’re the same questions you’d ask about any system running on the project - what is it doing, who’s responsible for it, and what happens when it fails?
The Governance Update
The multi-model shift happened faster than governance frameworks could follow. That’s not unusual - it’s the same pattern as cloud adoption, BYOD, and SaaS proliferation. The tooling moves first; the accountability catches up.
The difference here is that AI workflows are increasingly making consequential decisions on projects - surfacing risks, drafting stakeholder communications, synthesising programme status. The higher the consequence of the output, the more important it is that the governance framework applies regardless of which model produced it.
The first step isn’t a major governance overhaul. It’s an audit of whether your current AI governance - however formal or informal it is - was designed with a single-provider assumption, and where that assumption breaks down when the reality is multi-model.
Most project teams will find the gaps are real. Most of them are fixable with a few deliberate decisions and a small amount of documentation. The teams that make those decisions now are significantly better positioned than the ones that discover the gaps in a post-incident review.
Frequently Asked Questions
What does “multi-model AI” mean for project management teams? It means the AI workflows running on your project are likely using more than one model from more than one provider - different models for different task types based on cost, capability, and speed. As of May 2026, 59% of production agentic token usage runs across multiple providers. Most project governance frameworks don’t account for this yet.
How do I track AI costs across multiple providers in a project? The first step is making the routing architecture visible - which tasks go to which models. From there, implement cost tagging per workflow or task type rather than by model alone. Most enterprise AI gateways (including tools like Vercel’s AI Gateway) provide per-request logging that can be aggregated by project or workflow. Budget forecasting needs to account for the consumption-based pricing variability that comes with multi-model routing.
Do different AI providers have different data policies for project information? Yes, and significantly so - on data retention, training use, jurisdiction, and enterprise agreement terms. A project team routing work across Anthropic, Google, and an open-weight model has three potentially different data handling regimes active simultaneously. This needs an explicit policy decision per provider and per data type, not a default assumption.
What AI governance questions should a project manager ask before deploying AI agents? At minimum: which tasks route to which models; what quality standards apply per task type; what data can go through which provider; how AI costs are tracked and attributed; and how you’d reconstruct the audit trail if an agent output caused a problem. These questions apply regardless of whether you’re running one model or five.
Does your current AI governance framework know which models are running on your project - and which data they’ve seen?
Yes, AI helped me to write this :)