Every platform spec names the same primitives: compute, data, security, identity. The AI era adds one more - and the team that should build on it is the business, not central IT. Here is the missing layer, and why it belongs in the platform.
TL;DR
For decades, enterprise technology defaulted to centralize - one team, one toolset, one place to build. That made sense when the hard part was technical complexity. AI moves the hard part to operational context: what “approved” means, which exceptions matter, how a particular business actually decides. That knowledge lives in the business, not in a central technology function removed from the work. So the operating model is shifting - IT builds the platform, the business builds the agents. The catch: the usual platform spec - compute, data, security, identity - is missing a primitive. If the business is going to build AI agents at scale, the platform also owes them a way to check those agents can be trusted. Call it a verification capability: built in, not bolted on later.
A platform team at a growth-stage company walked me through their architecture recently. Compute, data, security, identity - each a defined layer with an owner, a roadmap, and a budget. Their conventional software is tested the way you would expect: continuous integration, code review, the usual gates. Then I asked how a business team checks whether an AI agent built on the platform can be trusted before it ships - that its outputs are accurate, that it has not drifted, that it does what the use case requires. The answer was a single engineer’s evaluation notebook, rebuilt for each project and thrown away after the demo. Not because the team is careless, but because evaluating AI agents was never scoped as a platform capability. It lives wherever someone happens to have time to hand-roll it.
When the platform owner is too far from the work
For decades, enterprise technology had one default: centralize. Centralize the team, the tools, the development. That worked when the binding constraint was technical complexity - expensive, specialized, hard to staff, and wasteful to duplicate across fifty business units. Centralizing was how you avoided fifty teams reinventing the same hard thing.
AI moves the binding constraint. The hard part is no longer the technology; it is operational context - what “approved” means in procurement versus legal, which exceptions matter in one workflow and not another, how a specific business actually makes a decision. That knowledge lives inside the business. The problem with pulling the build into a central technology function is not only that it is slower. It is that the thing gets built wrong. People removed from the use case cannot see the requirements the customer never managed to put into words, so they build to the requirement that was written down rather than the one that was meant. Distance from the work does not just delay the work; it mis-specifies it.
The operating-model adjustment the more effective enterprises are now working through follows from that: IT builds the foundation, the business builds the agents. Most enterprises are not doing this yet, and that gap is part of the problem.
The reason the build belongs in the business is proximity, not ideology. The business is closest to the customer and the use case; it holds the tacit requirements that never reach a written spec; and it is the part of the organization that actually has to be enabled for AI to change anything. Centralizing the platform is right - everyone rowing the same way, with the same boats and the same oars, not each crew carving a private channel. But rowing in sync is not the same as rowing to one mandated destination. The platform standardizes the equipment; it still has to leave the business room to steer - to be creative, to fit its own use case.
Guardrails that flatten every team to a lowest-common-denominator output are a race to the bottom, not a platform.
So you centralize the platform, decentralize the build, and scale the build by inner-sourcing: shared, reusable components the business teams extend for their own use cases instead of each starting from zero.
That split is right. The usual definition of “platform” is just too narrow.
Compute, data, security - and one more
Most platform conversations name a familiar set of primitives (“common services”) IT owns: compute, data, security, identity. Audit, secrets, and observability belong there too - the things every team would otherwise rebuild, badly, in fifty places. If the business is going to build AI agents on top of that platform, the platform owes them one more: a way to check that an agent can be trusted, before and after it ships.
By that I mean a built-in capability - peer to identity and secrets in the platform’s spec - that lets any agent built on the platform be evaluated, attested, and monitored against the dimensions its use case demands. Not a policy. Not a committee. A capability the agents call, the way they call identity. Three parts:
A use-based scoring rubric. Which dimensions should an agent be measured on, given what it is used for? A low-stakes drafting assistant and an agent that touches client money are not held to the same bar. High-stakes engineering worked this out decades ago - the verification-and-validation standards used in aerospace, defense, and large-scale construction treat evaluation as use-based, not one-size-fits-all - and the newer AI-governance frameworks are converging on the same idea from the AI side (both described and linked at the end). The platform should expose this as a rubric a team can actually run, not a document it reads.
Sealed-test-set evaluation. How does the platform let an agent be scored against a fixed test set it never gets to see or memorize? That is the difference between a real evaluation and a demo. It should be a platform feature, not a one-off notebook a single team builds for one presentation and then abandons.
Model-risk telemetry. What was attested, by whom, when, against which version of the agent and which version of the data? This is ordinary engineering audit, applied to AI work, and it is what lets you reconstruct later what the system actually did.
These are platform-owned. The agents built on top do not implement them; they use them.
This is not AI governance in the policy sense
There is a real policy-and-board layer above the platform - risk officers, model-risk committees, regulatory attestation. That layer matters, and it is not what I am describing. The verification capability sits inside the platform, the same way identity sits inside the platform even though there is a separate identity-governance function above it. The two are complementary; neither replaces the other. The risk of confusing them is that the verification capability gets handed to a committee, which then writes a policy the business teams cannot actually run their agents against. Putting it in the platform is what makes it runnable.
Where this comes from
The pattern is recognizable from two directions. The engineering verification-and-validation tradition - the standards aerospace, defense, and construction have used for decades - worked out use-based evaluation long before AI. The AI-governance frameworks now emerging are doing the same work from the AI side and landing on similar primitives. Industrial engineering organizations that have built real internal AI discipline already run something close to this, even when they do not call it a platform primitive. The move is simply to name it, so the next platform spec includes it.
What this means for your next platform spec
IT builds the platform. The business builds the agents. That operating model is right. The platform’s spec just needs one more line. Compute, data, security, identity, audit, secrets - and, for an enterprise where the business builds AI agents at scale, a verification capability. Without that line, “the business builds the agents” stops being safe at the second agent.
Verification is a primitive, not a check. Build it into the platform; bolted on later, it does not pass an audit.
The companies that build it in are the ones that scale into regulated markets without an architectural rewrite.
References Engineering verification and validation
NASA, Standard for Models and Simulations, NASA-STD-7009B (2024), https://standards.nasa.gov/standard/NASA/NASA-STD-7009 (scores how credible a model is before it is allowed to drive a high-consequence decision; verification is graded, not assumed). U.S. Dep’t of Def., Documentation of Verification, Validation, and Accreditation (VV&A) for Models and Simulations, MIL-STD-3022 (2008) (the defense template for documenting how a model was checked before anyone is allowed to trust it). IEEE, IEEE Standard for System, Software, and Hardware Verification and Validation, IEEE Std 1012-2016 (2017), https://standards.ieee.org/ieee/1012/5609/ (the engineering standard for checking a system against its requirements and its intended use, with rigor scaled to the stakes). BIMForum, Level of Development (LOD) Specification (2023), https://bimforum.org/resource/lod-level-of-development/ (the construction-industry rule for how complete and reliable a design element must be before anyone builds from it).
AI governance
Nat’l Inst. of Standards & Tech., U.S. Dep’t of Commerce, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (2023), https://www.nist.gov/itl/ai-risk-management-framework (the U.S. reference for naming and managing AI risk across a system’s life cycle). Int’l Org. for Standardization & Int’l Electrotechnical Comm’n, Information Technology - Artificial Intelligence - Management System, ISO/IEC 42001:2023 (2023), https://www.iso.org/standard/81230.html (the international standard for how an organization governs the way it builds and runs AI). Org. for Econ. Co-operation & Dev., Recommendation of the Council on Artificial Intelligence, OECD/LEGAL/0449 (2019, amended 2024), https://oecd.ai/en/ai-principles (the intergovernmental baseline for trustworthy AI that many national rules now track). U.S. Dep’t of Def., Responsible Artificial Intelligence Strategy and Implementation Pathway (2022), https://www.ai.mil/ (the defense approach to building and fielding AI responsibly).