No company is going to standardize on one AI platform

Every AI governance product on the market makes the same quiet assumption: that at some point, your company picks.

Pick a platform. Build the agents there. Route the calls through one gateway. Then govern that.

It is a reasonable assumption. It is also wrong, and the way it is wrong is structural rather than temporary.

Count what is already running#

Take a mid-sized engineering org. Not an enterprise. A hundred and fifty people, four squads.

Squad one standardized on Claude Code six months ago. Squad two prefers Codex. The frontend team lives in Cursor. Two staff engineers still run Copilot because it is in the IDE and nobody asked them to stop. Someone in data built an agent on an internal framework that reads from the warehouse every night.

That is the part you can see.

Then there is the part you cannot. The support platform shipped an AI agent in a product update, enabled by default, with access to every ticket. The CRM added one that drafts and sends email. A contractor onboarded last month with a personal ChatGPT account and a workflow nobody approved, because nobody was asked.

Nine agent surfaces, minimum. Four trust models. Zero shared log.

Now ask the question an auditor will ask. Which of those took an action against a production system last Tuesday, who approved it, and can you show me?

This is not a maturity problem#

The comfortable reading is that this is a phase. Companies are early, tools are proliferating, consolidation will follow, and the governance problem gets easier as the count comes down.

The count is not coming down.

It is a function of organizational fragmentation, not of headcount or maturity. A hundred and fifty person company where each squad picks its own tools has the same problem shape as a company of fifty thousand. And the direction of travel runs the other way: every SaaS vendor in your stack is shipping an agent into their own product this year, into a seat you already pay for, without asking you. You did not choose those, and you cannot un-choose them.

Standardization would require every squad to give up the tool they are fastest in, every vendor to stop shipping agents into their own products, and every new hire to arrive with no habits. None of those is happening.

Which makes the migration pitch the wrong pitch#

The market answers this in one of two ways.

The platform answer: build your agents on us. This is real governance, often with real containment, and it works beautifully for the agents you build there. It governs nothing else. The support platform's agent is not moving onto your agent platform. Neither is Cursor.

The gateway answer: route everything through one proxy. Also real, and it governs exactly what routes through it. The engineer who added an MCP server this morning did not route it through you. That is not a compliance failure on their part. They did not know there was a gateway to route through.

Both answers ask the company to consolidate first and be governed second. Consolidation is the expensive half, it is a migration project, and the agents that most need governing are precisely the ones with the least reason to move.

The agents that matter are the ones that never move.

Govern the keys and the doors instead#

There is one thing every agent has in common, whatever platform it was built on, whoever deployed it, whether or not you know it exists.

To do anything that matters to your company, it needs a credential you issued, and it has to arrive at a system you run.

Those are the keys and the doors, and they are already yours.

Scope the key and you control what an agent can touch. Gate the door and you control what it can do. Record both and you can prove what happened. None of that requires the agent to move, to be rebuilt, or even to have been approved in the first place. A tool nobody told you about is governed the moment it presents a credential at a door you own.

Cost falls out of the same model rather than sitting beside it as a separate feature. The model itself is a resource reached through a key. Issue that key per agent and every call is metered and attributed, and a budget stops being a number on a dashboard you read afterwards. It becomes a limit at the credential.

One rulebook. One record. Every agent.

What varies, and we would rather say it first#

The rulebook and the record are uniform. How hard we can stop something is not.

Where you own the key or the door, the decision is enforced. The resource itself refuses what is not allowed. Where all we have is a cooperative hook inside somebody else's tool, it is best effort, it fails open, and a determined agent can route around it. Where an employee uses a personal account on a personal device against a public service, no product can do more than detect that it happened, and any vendor telling you otherwise is selling you something.

The uniform part is the rulebook and the proof. The varying part is the teeth. You should hear that from a vendor before an incident, not during one.

Start with the count, not the decision#

The honest first step is not a platform decision and not a migration. It is a number.

Connect the agents your team already runs, in observe mode, changing nothing. The map of what reaches which system draws itself from what those agents actually do. It is usually available inside a day, and the number is almost always higher than the one people guess.

If you want to see what that looks like against your own stack, talk to us.