There is a version of platform advice that is unhelpful to anyone actually shipping: build the governance framework, the identity model, the telemetry standard, and the cost allocation scheme, and then build your first agent. Nobody does this, and they are right not to. You cannot design an operating model for a portfolio you have not started.
The useful advice is narrower. You do not need heavyweight process before your first useful application. You do need to avoid the specific choices that quietly assume the first agent will be the only one.
The moment the arithmetic changes
One team making local decisions for one agent is fine. Every choice is reversible, the blast radius is one system, and the people who made the decisions are still in the room.
Ten teams operating dozens of agents is a different problem, and not because anyone did anything wrong. Each team chose a governance approach, a telemetry convention, a model-routing policy, a credential practice, and an administrative experience. Every choice was locally sensible. Collectively they are fragmentation, and there is no moment at which anyone decided to fragment.
This is the arithmetic that catches organizations out: at portfolio scale, repeated local freedom becomes enterprise complexity. The cost does not arrive gradually. It arrives when someone first asks a question that spans applications -- what do our agents cost, who can use them, what data do they touch -- and discovers the answer requires ten investigations.
What is expensive to standardise later
Not everything needs deciding up front. These are the ones that get dramatically harder once each project has its own answer:
Identity
Specifically, the model of an application's end users. If three applications each invent their own notion of who a user is and what they may do, unifying them later means renegotiating permissions with three sets of stakeholders while everything is in production.
Telemetry conventions
Traces that cannot be correlated are traces that cannot answer portfolio questions. The convention is cheap to set early and painful to retrofit, because retrofitting means touching every application.
Provider policy
Which models are approved, who holds credentials, what happens on failover. When this lives in application code, changing a provider becomes a coordinated release across every team rather than a configuration change.
Knowledge ownership
Who decides what a knowledge base contains, and who approves a source. Assigning this after the fact means auditing content whose provenance nobody recorded.
Cost attribution
If spend cannot be attributed to a capability from the start, the first budget conversation becomes forensic accounting.
What can safely wait
Plenty. Approval workflows, formal stewardship roles, portfolio reporting, chargeback models, and most process can arrive when there is something to govern. The distinction is whether the thing is a decision embedded in code or a practice layered on top. Embedded decisions are the expensive ones.
A useful test: if we added a second team next quarter, would they be able to adopt our approach, or would they reasonably invent their own? If the honest answer is the second, you have found something worth deciding now.
Decide once where variation adds little
Enterprises benefit from local experimentation, but not every decision differentiates the business. Logging formats, credential handling, audit conventions, and failover behaviour are better settled centrally -- and central decisions should stay configurable and revisable rather than hardcoded into every application.
That is the real return on platform investment, and it is not the one usually cited. It is not that individual tasks get easier. It is that the organization has fewer decisions, fewer tools, and fewer operating models to keep in its collective memory.
Build the first agent. Just do not let it quietly become the template nobody chose.