Short answer: In the AI era, the choice is not build versus buy. It is build, extend, or buy. Build means owning every layer yourself. Extend means building your own agents and customer experience, then extending them with MontyCloud for multi-tenancy, governance, evidence, and specialist capability that changes every month. Buy means running on MontyCloud and putting all your effort into what makes your MSP different: your services, SOPs, and playbooks.
The agentic era is changing what customers expect from an MSP, and what they will pay for. More than 90% of executives view managed services as essential to delivering agentic AI, and AI capability is now the top criterion in choosing a provider, according to the KPMG Managed Services Outlook 2026.
That opens real doors for MSPs. Customers grow as AI drives cloud consumption. AWS programs reward partners who prove AI-driven delivery at scale, and funding, co-sell, and competencies follow that proof. Margins improve when you package compliance, optimization, and remediation as fixed-fee outcomes instead of hours.
It also brings back a familiar question: should you build your own CloudOps platform? For the first time, the answer is not obviously no. But the real cost was never the code. It is what building pulls your best people away from.
In this blog, you’ll learn what a build really takes, what it costs against the opportunity in front of you, and the three paths MSPs are taking.
Can an MSP build its own CloudOps platform with AI?
Yes. AI coding assistants have collapsed the cost of the first stretch of almost any software project. Reading AWS APIs, collecting inventory, building dashboards, drafting a remediation runner: that is now days of work, not quarters. Model Context Protocol (MCP) makes connecting agents to your tickets, docs, and accounts far easier. Point a good engineer and an AI assistant at your AWS estate and you will have something that demos well inside a month. Anyone who says otherwise has not tried recently.
Most MSPs will not start from a blank page, either. They will start on AWS. Amazon Bedrock AgentCore runs and secures agents at scale, the AWS MCP Servers connect them to AWS services, AWS Security Hub centralizes security findings, and Amazon Q Developer helps teams investigate and fix issues. Add the ITSM you already run, and you can stand up a capable agent in a single account quickly. That is a strong starting point, and MontyCloud builds on AWS-native services too. But these services are account-centric by design. They do not give you an MSP operating model: one policy enforced across every tenant, evidence that holds up customer by customer, and customer-facing access that is scoped, traceable, and revocable. That is the foundation layer, and it is the part you would still build yourself.
A demo works because it runs in one account, on data you chose, watched by the person who built it. Production is everything that has to hold when none of that is true:
- Multi-tenancy. Per-tenant identity, least-privilege scoping, and context that provably cannot cross between customers.
- Per-customer configuration. One workflow that behaves differently for a cautious customer and a bold one, without forking it.
- Failure handling. What halts when a run dies halfway, what can be reversed, and who gets paged with a record instead of a mystery.
- Evidence. What the system did, in whose account, under what authority, with whose approval, and whether the outcome actually happened. This is what customers trust.
- Customer-facing access. Dashboards, reports, and self-service automation shared with end customers, scoped, traceable, and revocable.
AI assistants help least here, because this is a design and operating commitment, not a code problem.
What does it really cost to build a CloudOps platform?
Mostly your best engineers’ time, plus maintenance that never ends.
The day you commit to building, your services company acquires a software company. It has engineers, a roadmap, a backlog, a security posture, and an on-call rotation. It does not have a revenue line.
Labor can make up to 80% of an MSP’s total costs, according to Omdia, and AI model and application development is now the hardest skill to find globally, according to the ManpowerGroup 2026 Talent Shortage Survey. The engineers who can build a multi-tenant agentic platform are the same people who would otherwise grow accounts, design services, and deliver the work that earns program standing.
Many builds start because capacity looks free: engineers on the bench, or a small team working evenings and weekends. That capacity is temporary. The bench fills, the weekend team moves on, and the platform still needs an owner.
Build budgets get approved. Maintenance budgets get discovered. Models change behavior between versions, MCP servers update, and AWS ships new services and deprecates old APIs. The agent that passed review in March runs on a different foundation by September. Keeping up takes an evaluation harness, a regression suite, and a named owner with a budget line. If the honest answer is “one talented engineer,” you have not built a platform. You have built a dependency, and it walks out the door when they take another offer.
Specialist capability moves fastest, and an MSP building alone usually learns about changes when the rest of the market does. So ask any platform provider how closely it works with AWS and model providers, and how quickly it absorbs what changes.
The proof bar is rising too, and for AWS MSP Partners it is now the standard. AWS MSP Program Validation Checklist (VCL) 8.0 is the biggest rewrite of the checklist in years: 61 controls across six sections, with AI and agentic controls growing from 2 to 24. VCL 8.0 asks partners to prove their AI and agentic workflows are governed, not just running. It now applies to every MSP Program applicant and renewal, with a transition window for existing partners. Meanwhile, only 21% of organizations report a mature model for agent governance, according to Deloitte’s State of AI in the Enterprise 2026. Evidence rebuilt after the fact from logs written for another purpose is survivable once. It is not survivable as a routine, and it will not hold up in validation.
Which parts of a CloudOps platform should an MSP build?
Only the layer your customers pay for: your own knowledge, including the agents your customers talk to. Think of a restaurant. The building, the power, and the health inspection are the same for every restaurant. The ingredients change with the season, so you want a supplier who knows the market. The recipes and the service are what customers pay for. A CloudOps platform has the same three layers.
- Foundation: multi-tenancy, identity, policy and approvals, containment, evidence, cost attribution, customer-facing access. The same for every MSP.
- Specialist capability: discovery, posture, cost optimization, remediation, MCP servers, and specialist agents. It moves fast and needs constant upkeep.
- Your knowledge: industry services, SOPs, playbooks, risk profiles, QBR templates, and the agents your customers talk to. This is your IP, and it is what customers pay for.
What are the three paths: build, extend, or buy?
MSPs are choosing between building everything, extending their own agents with MontyCloud, or buying the full MontyCloud DAY2 experience.
- Build. You own all three layers, the upkeep, and the people. This fits an MSP that intends to become a software company.
- Extend. You build the agents and the experience your customers use. MontyCloud supplies the foundation and specialist capability underneath, through the CloudOps MCP Server, skills, and specialist agents. DinoCloud is an example. Your team does the building. MontyCloud provides the platform you build on.
- Buy. You run on the full MontyCloud DAY2 experience and put all your effort into your own knowledge.
All three are legitimate. None should be chosen because an engineer had a free month.
Extend example: how DinoCloud built its own AI agent on MontyCloud
DinoCloud, an AWS Premier Partner, faced the same decision. Its managed services practice had grown on a mix of specialized tools, each owning a narrow slice of FinOps, security, or day-to-day operations. “We didn’t want to spend years developing our own tool,” said Franco Salonia, CEO of DinoCloud. “We wanted a generalist operations hub that could deliver value immediately while still letting us plug in specialized ISVs as needed.”
DinoCloud chose MontyCloud as its central operations hub, then put its own engineering where it counts. The team launched Rex, a proprietary AI agent that uses MontyCloud’s CloudOps MCP Server to deliver conversational CloudOps support directly inside customer Slack channels. The results: 30 to 50% faster Mean Time to Resolution, 10 to 25% lower AWS costs for customers, and 70% fewer AWS Console logins.
MontyCloud runs the foundation. DinoCloud owns the agent its customers talk to.
How does MontyCloud fit?
MontyCloud provides the foundation and specialist capability as a governed platform for MSPs, so your engineers can focus on the layer customers pay for. We have operated multi-tenant CloudOps for MSPs since 2019.
Workflows run inside allow and deny lists, against policy evaluated before anything executes, with approval gates on the action classes you designate. You decide what runs unattended and what always waits for a named approver. Policy-driven automation, such as PRM tagging across tenants, runs today. Agent authority to act is earned level by level, against evidence, as our CloudOps Competency Benchmark sets out. When a run cannot finish safely, the platform halts dependent steps, reverses what it can, marks what it cannot, and escalates through your ITSM with the record intact. Evidence is a byproduct of the work, and cost is attributed per workflow, per tenant, and per service, so you can price a service before you sell it.
That is also what VCL 8.0 asks for: AI and agentic workflows that are governed, not just running. MontyCloud is built for governing AI at scale, and our team can walk through the new checklist with you, so you see where you stand today and what is left to close. Wherever you stand, you do not have to start over. We are open by design. Your agents, third-party agents, MCP servers, scripts, ITSM, and security and FinOps tools can all take part. If you have started building, you are not choosing against that work. You remain the trusted advisor to your customers. Our job is to help you prove it.
One boundary we state every time: MontyCloud does not confer, guarantee, or maintain AWS program status, validation, or competency. You earn that. We remove the undifferentiated work of proving what you did.
How should an MSP scope a build before deciding?
Start with an honest checklist. Our checklist covers tenant model and authority, policy and approvals, failure and containment, evidence, customer-facing access, cost, upkeep and ownership, and which layer each piece belongs in.
In the AI era, the decision is not build versus buy. It is build, extend, or buy. And it comes down to where your best people spend the next two years: in the kitchen, or on the menu your customers pay for.
Request a demo to see governed workflows running across multi-tenant customer accounts.
This post references the AWS MSP Program Validation Checklist (VCL) 8.0, released in August 2026, and AWS partner programs as of September 2026. Program terms, controls, and eligibility requirements are set by AWS and subject to change. Always refer to your official AWS partner communications for the most up-to-date details.
FAQs
Should an MSP build or buy a CloudOps platform?
In the AI era, there is a third option: extend. Build your own knowledge layer (services, SOPs, playbooks, and the agents your customers talk to). Buy or source the foundation and specialist capability, since they are the same for every MSP and need constant upkeep.
Can I build a CloudOps platform with Claude Code or another AI coding assistant?
Yes, for the first stretch. Tools like Claude Code, GitHub Copilot, Cursor, and Kiro can get an agent working against one AWS account in days. What they do not give you is the foundation layer an MSP needs in production: cross-tenant policy, evidence by customer, failure containment, and scoped customer-facing access. The checklist helps you scope that part before you commit.
What is the hidden cost of building your own CloudOps platform?
Opportunity cost. The engineers who can build it are the same people who would otherwise grow accounts and deliver billable work. Maintenance also grows as models, MCP servers, and AWS APIs change.
What does it mean to extend a CloudOps platform?
You build the agents and the experience your customers use, then extend them with a platform that supplies the foundation and specialist capability underneath. Your team does the building. DinoCloud extended Rex, its own AI agent, with MontyCloud’s CloudOps MCP Server this way.
Why not just use AWS-native tools?
AWS-native services such as Amazon Bedrock AgentCore are a strong starting point for an agent in a single account. They are account-centric by design, so an MSP still needs an operating layer for cross-tenant policy, evidence by customer, and scoped customer-facing access. That is the foundation layer MontyCloud provides.
Can I use my own AI agents with MontyCloud?
Yes. Your agents, third-party agents, and MCP servers can take part in MontyCloud workflows. DinoCloud’s Rex answers customer questions in Slack through MontyCloud’s CloudOps MCP Server.