TL;DR: Decide layer by layer rather than in one go. A routing and cost layer is reasonable to build on open source. Agent identity, policy enforcement, and an audit record your examiners accept require integration with your own policies and review evidence; include that work in either estimate. Whichever way you go, your team still owns the policy decisions: who may approve what, and where an agent has to stop.
Most build-or-buy discussions start in the wrong place, with a license cost on one side and an engineer’s estimate on the other. The question that decides the outcome is narrower: which layer of the stack is your team going to keep maintaining in eighteen months, once the first workflow is live and three more are queued behind it?
Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls as leading causes (Gartner, June 2025). Build-versus-buy choices can affect cost and control burden, but they do not on their own determine business value or eliminate the other cancellation factors.
Key takeaways
-
Split the decision into layers. Routing and cost controls are the most buildable. Identity, policy and audit are the least.
-
Price the maintenance, not the build. Model retirements and protocol revisions arrive on someone else’s schedule.
-
Buying does not remove your policy work. A vendor cannot decide who in your organization may approve a payment.
-
In regulated teams, the audit record is often the layer that slows production approval, because reviewers need to reconstruct what happened for a specific action.
-
A mixed answer is common: buy the governance layer, build the workflows on top of it.
1. Decide layer by layer, not as one purchase
“AI control plane” covers eight or so distinct jobs. They differ enormously in how hard they are to build, so treating them as one decision hides the part that matters.
| Layer | What open source gives you today | What your team still owns |
|---|---|---|
| Model routing and gateway | Mature options. Routing across providers, retries, fallbacks, key management | Capacity planning, provider contracts, upgrade testing |
| Cost controls | Usage metering and per-key budgets in several projects | Attribution to a business owner, caps that hold under load, chargeback |
| Agent identity | Service accounts and tokens, but on-behalf-of access and scoped credentials usually require significant integration work | Mapping an agent's action back to the user who triggered it, short-lived credentials that carry the right scope, audit linkage to the human requester |
| Policy enforcement | Rule engines exist, and are generic | Writing the rules, versioning them, proving which version applied to a given action |
| Retrieval permissions | Vector stores with metadata filters | Applying your existing document permissions at query time, per user |
| Audit record | Logs and traces | An action-level record that meets your audit requirements, retained for as long as your regulator requires |
| Evaluations and monitoring | Good frameworks for offline evals | Test sets that reflect your cases, and the review time to maintain them |
| Registry and kill switch | Thin. Usually built in-house | Knowing every agent that exists, who owns it, and how to stop it without destroying the record |
The pattern across that table: the closer a layer sits to your identity provider, your policies and your auditors, the less any product gives you for free and the more your own context has to be built in. That is true of a bought control plane too. The difference is who maintains the machinery around your context.
Where teams tend to be right
The gateway layer is often a practical place to start building. Routing traffic across providers is well-trodden, the open-source options are active, and the work is close to what a platform team already does with API gateways.
Where teams tend to be wrong
The estimate that goes wrong is the audit record. Writing structured logs is relatively straightforward. Producing a record that shows, for a single action six months ago, which policy version applied, which user the agent acted for, what it retrieved, what it changed, and who approved it is a different piece of engineering. Teams can discover the gap during an audit rather than during planning, which is the most expensive moment to discover it.
2. Building commits you to a maintenance clock you do not control
A build estimate usually covers the first working version. What decides the question is the work that arrives every quarter afterwards, on dates other people set.
Model retirements arrive on the provider’s schedule
Providers publish a deprecation schedule and give notice, but that notice is short compared with a change-managed release cycle. Anthropic commits to at least 60 days before retiring a publicly released model. Its published schedule shows claude-opus-4-1-20250805 deprecated in June 2026 and retired that August, with three more models retired earlier in the year (model deprecations). Sixty days is enough time to change a model string. It is tighter once you add re-running your evaluation set, checking cost and latency against your own cases, and getting a change through review into a release window. Every provider move restarts that cycle on their calendar.
Protocol versions require active negotiation
MCP identifies versions by date. It holds a deprecated feature in the specification for at least twelve months before removal, or ninety days if removal is expedited. A server can reject a version it does not support (MCP versioning). Run your own gateway and you are the one negotiating versions with servers you do not control, and you own the migration when a feature finally leaves.
Your own footprint compounds the load
Each workflow brings tools, permissions, test cases and an owner to keep track of. The spreadsheet that covered three agents stops working as the number grows, and replacing it is rarely anyone’s planned project.
None of this argues against building. It argues for costing a standing team rather than a project with an end date. If you cannot name the engineers who will own this layer a year from now, the estimate is not finished.
3. Buying leaves real work on your side, and it helps to say which
A bought control plane moves the maintenance of the machinery. It does not move these:
Identity integration
Your provider, your groups, your approval chains. Expect this work in either path.
Policy definition
No vendor knows who in your organization may release a payment, waive a fee or clear an alert. Writing that down is your work, and it is usually the part that takes longest in a regulated team because it involves risk and compliance rather than engineering.
Deployment fit
If data has to stay in a region or on your own hardware, verify whether the product supports that requirement before evaluating features.
Evidence your auditors accept
The product can produce a record. Whether your second line accepts it is something to test early, with a real case, before the first workflow goes live.
An exit path
Ask what you keep if you stop: the audit history, the policy definitions, the agent configurations. Get the answer in writing while you still have leverage.
Moring’s AI Control Plane covers the governance layers in the table above, the ones that require the most integration with your identity, policy, and audit evidence. It is designed to run inside your cloud or your own data center, keeping your identity and audit posture where it is. What you avoid is carrying long-term in-house ownership for those layers, for work that shows up in no customer outcome.
4. Five questions that settle it for a specific team
Bring these to the discussion with real answers rather than estimates.
-
What is the deadline on the first workflow? If a regulator, an examiner or a board commitment has a date on it, building the governance layers first often takes longer than the timeline allows.
-
Who owns this in eighteen months? Name people. If the answer is the platform team “as part of their remit”, the build is underfunded.
-
What will your second line accept as evidence? Ask risk and audit to describe the record they want for one specific action. Then check which option produces it.
-
How many workflows will share these controls, and how do their permissions differ? Evaluate how many workflows will share these controls and how their permissions differ. The more they diverge, the more your governance layer has to carry.
-
Where does the data have to live? On-premise and in-region requirements rule out some products entirely, and that is worth establishing before any evaluation.
If most of those answers point the same way, you have a reasonable signal for the decision. If they pull in different directions, the mixed approach in section 5 is worth examining.
5. A common approach: buy the governance layer, build the workflows
The reasoning is about where your advantage actually sits. Your claims process, your credit policy and your alert triage logic are specific to your business and worth your engineers’ time. Token routing, scoped credentials and audit plumbing are the same problem in every regulated company, and none of it shows up in a customer outcome.
It also matches how approval tends to work in practice. A control plane can reduce repeated review work by standardizing controls, evidence, and operating boundaries. That is not the same as approval inheritance: each workflow still needs its own review for purpose, permissions, data exposure, and approval logic. What changes is that reviewers are working from a known control environment rather than reassessing the full operating model from scratch. That difference can affect the pace of the second, fifth, and tenth workflow, and it is worth testing with your own risk function before you commit either way.
6. How to cost this without inventing a number
There is no reliable market price for building a control plane, and any figure quoted without a named source is worth ignoring. What you can do is cost your own case. Price these lines for both options, over three years rather than one:
-
Integration with your identity provider, data platform and ticketing
-
Evaluation sets, and the time to maintain them as models change
-
Human review time per case, which is often the largest ongoing cost
-
Infrastructure and inference, metered per workflow
-
On-call and support for the layer itself
-
Migration work when a model retires or a protocol revises
-
Audit and evidence preparation
For a fuller version of that exercise, including how to estimate before you have production numbers, see what should you budget to run an AI agent in production.
Price it layer by layer and the question usually stops being build or buy. A common split is to build the workflows, because those are yours and nobody else understands them, and to buy the governance underneath, because the audit record is what your examiners read and the part that takes longest to write. If you want to work through your own layers with us, that is what the AI control plane workshop is for.
If you want to work through the layer table against your own stack, bring a specific workflow through the AI Control Plane contact form. For the ownership question, read who is accountable when an AI agent makes a bad decision for the ownership side of the same question.
Sources
-
Gartner, over 40% of agentic AI projects will be canceled by the end of 2027, press release, 25 June 2025
Frequently asked questions
Is it cheaper to build or buy an AI control plane?
It depends on the window you price. Over a single year, a build can show the lower number. Over three years, the comparison usually turns on maintenance: model retirements, protocol revisions, new workflows, audit evidence, and human review effort. Cost both options over a multi-year period and include the engineers who will still own the layer at the end of it.
What is the difference between an AI gateway and an AI control plane?
A gateway sits in the request path and manages traffic: routing to models, retries, keys, rate limits and usage records. A control plane governs the whole lifecycle around those requests: which agents exist, whose permissions they use, which policy version applied, what they retrieved, what they changed, and what evidence remains afterwards. A gateway is one layer inside a control plane.
Can you build on open source and still be audit-ready?
Yes, but the audit-ready part is usually what your team still has to design and maintain. Open-source projects give you traffic management, metering, and tracing. The action-level record, policy versioning, and user-to-agent attribution are usually custom work. Ask your second line to specify the record they need before you estimate the effort.
What breaks first if you run agents without a control plane?
Attribution is one risk to test. An agent takes an action, and nobody can say afterwards which user it acted for, which policy applied, or which version of the prompt and model produced the result. The second failure is scope: access granted for one workflow stays granted after that workflow changes.
Does buying mean you stop writing policy?
No. The product enforces policy and records the enforcement. Deciding what the policy is, who may approve an exception and where an agent has to stop remains your work, and it is worth starting before the technical evaluation rather than after.
