Native AI tools are impressive. They’re also built for a world that doesn’t match how MSPs actually work. Here’s where custom solutions still earn their keep.
I want to ask my AI assistant a simple question: “What’s the server name for Contoso?”
Then I want to follow up: “Pull the Azure SQL connection string for Fabrikam.”
Then: “Is Woodgrove’s Exchange server responding?”
Three questions. Three different clients. Three different systems. One conversation.
Copilot can’t do this. Not because the AI isn’t smart enough – it is. But because Copilot lives in Microsoft’s world, one tenant at a time, with no concept of the multi-client reality that defines managed services.
This is the gap that native AI tools can’t close. And it’s where custom solutions still earn their keep.
The Multi-Tenant Blindspot
Here’s the fundamental disconnect: Copilot was built for enterprises. One company, one tenant, one environment. The AI learns your organization’s context and gets better at helping you navigate it.
MSPs don’t work that way. We’re not one company. We’re a dozen companies at once, sometimes more. Every client is a different tenant, different environment, different set of systems, different tribal knowledge about how things work and who to call when they don’t.
The context switch happens constantly. A tech finishes a ticket for one client and immediately jumps into another client’s environment. A dispatcher routes tickets across fifteen different companies in an hour. I might answer a question about Contoso’s network, then pivot to Fabrikam’s cloud infrastructure, then troubleshoot Woodgrove’s on-prem Exchange – all before lunch.
Copilot doesn’t understand that world. When I ask “what’s the server name,” it doesn’t know which client I mean. It can’t reach into IT Glue to pull documentation. It can’t check ConnectWise for related tickets. It can’t query the client’s Azure tenant for resource details.
It’s not a limitation of the AI. It’s a limitation of scope. Copilot sees what Microsoft shows it. For MSPs, that’s a fraction of the picture.
Cross-System Blindness
The multi-tenant problem is compounded by the cross-system problem. Our operational reality spans:
Documentation systems. IT Glue, Hudu, or whatever you use to store network diagrams, passwords, procedures, and client-specific knowledge. This is where “what’s the server name” actually gets answered.
PSA platforms. ConnectWise, Autotask, Halo – where tickets live, where time gets tracked, where client relationships are managed. When something breaks, the context is here.
Microsoft 365. Email, Teams, SharePoint – yes, Copilot shines here. But only within a single tenant at a time, and with no awareness of what’s happening in the other systems.
Azure and cloud infrastructure. Resource groups, virtual machines, SQL databases, networking configs. Different for every client. Often across multiple tenants and subscriptions.
Security tools. Sentinel, Defender, third-party SIEM platforms. Sometimes the client is on Google Workspace instead of Microsoft, and your security team needs to evaluate that environment too.
On-prem systems. The client who still runs Exchange on-prem. The legacy line-of-business app that can’t move to the cloud. The network equipment that predates anyone’s memory of why it was configured that way.
Copilot can’t see across these boundaries. It can summarize your emails brilliantly, but it doesn’t know there’s an open P1 ticket in ConnectWise related to the email thread. It can draft a response to a client, but it can’t check IT Glue first to see if there’s a known issue with their VPN that explains the complaint.
The AI is smart. The integration is shallow.
Insight vs. Action
There’s another gap that matters: the distance between knowing and doing.
Copilot can tell you things. It can summarize a document, draft a response, suggest a meeting time, analyze a spreadsheet. It’s genuinely good at this. The insight layer works.
But taking action – actually doing the thing – requires integration that doesn’t exist natively.
“Move this ticket to Sarah’s queue.” Copilot can’t do that. ConnectWise isn’t in its world.
“Create a calendar block for the Fabrikam maintenance window and notify their IT contact.” That’s Outlook plus ConnectWise plus maybe IT Glue for the contact info. Copilot can create the calendar block, but the rest requires custom work.
“Check if the Woodgrove backup job ran last night.” That’s reaching into their RMM or backup platform, parsing the results, and reporting back. Copilot doesn’t know those systems exist.
The “last mile” from insight to done is where most native AI tools stop. They can recommend. They can draft. They can summarize. But executing across systems – that’s on you to build.
The MSP-Native AI That Doesn’t Exist
Let me describe the AI assistant I actually want.
It understands that when I say “Contoso,” I mean the client, not a general concept. It knows Contoso’s environment – their servers, their cloud resources, their key contacts, their open tickets, their quirks and history.
It can reach into IT Glue and pull their network documentation. It can check ConnectWise for recent tickets. It can query their Azure tenant for VM status or their M365 tenant for user issues.
When I ask “is their Exchange server responding,” it doesn’t tell me how to run a ping test. It actually runs the test – or triggers the workflow that does – and tells me the result.
It handles context switching naturally. “Now check Fabrikam’s SQL database” doesn’t confuse it. It knows Fabrikam is a different client with different credentials and different systems, and it pivots accordingly.
It knows my team. When I say “assign this to the networking specialist,” it understands who that is based on our skill assignments and current workload.
And critically, it learns from how we work. The dispatch patterns, the escalation paths, the client preferences we’ve developed over years. Not generic best practices – our practices.
This AI assistant doesn’t exist as a product. Microsoft isn’t building it because it’s too niche. The MSP vendors aren’t building it because the AI infrastructure is complex. The AI companies aren’t building it because they don’t understand the MSP operational model.
So we build it ourselves.
The Building Blocks Are There
Here’s the encouraging part: the pieces exist. The assembly is on us, but we’re not starting from scratch.
Large language models understand natural language, reason through problems, and generate coherent responses. Claude, GPT 5.2, and others are all genuinely capable of the conversational intelligence we need – and they keep getting better. The model wars are good for us because the ceiling keeps rising.
Model Context Protocol (MCP) and similar approaches let AI systems connect to external tools and data sources. Instead of the AI being blind to your systems, you can give it eyes and hands.
APIs everywhere. ConnectWise has an API. IT Glue has an API. Microsoft Graph gives you access across M365 tenants. Azure Resource Manager lets you query infrastructure. Your RMM probably has an API too. The data is accessible – it just needs to be connected.
Workflow platforms like n8n and Power Automate can bridge the action gap. The AI decides what needs to happen, the workflow platform executes it. Ping a server, update a ticket, send a notification – the automation layer handles the doing.
Your existing infrastructure. You probably already have credentials stored securely, tenant relationships mapped, client data organized. The context already exists in your systems. It just needs to be made available to an AI that can use it.
The challenge isn’t technical capability. It’s integration work, security considerations, and the patience to build something that fits your specific operation.
My Current Workaround (And Why It Doesn’t Scale)
Here’s the thing – I can actually do most of what I described. Today. Right now.
We’re Microsoft Partners. We have GDAP set up across our client tenants. The access is there. Copilot just isn’t ready to use it the way we need.
So my workaround is Claude Code running on PowerShell 7. I can write a script on the fly that queries one client’s Azure tenant, then pivots to another client’s M365 environment, then pulls data from a third. I’ve built APIs for some clients and apps – not all of them, just the ones I need in the moment. When I need something new, I build it on the fly.
It works. I can ask “what’s the server name for Contoso” and write the query to get it. I can check Fabrikam’s Azure SQL configuration. I can ping Woodgrove’s Exchange server. The multi-tenant, cross-system reality I described – I’m living in it, solving problems this way every day.
But here’s the gap: I can’t expect my techs to do this.
It’s completely unrealistic. Not everyone can spin up a PowerShell script on the fly to query Graph API across tenants. Not everyone can troubleshoot authentication issues when GDAP permissions don’t cooperate. Not everyone can write the API integration in the moment they need data.
This isn’t a criticism of my team. It’s a recognition that my workaround requires a specific technical skillset that shouldn’t be a prerequisite for getting answers about client environments. A dispatcher shouldn’t need to write code to find out which tech worked on a client’s network last week. A technician shouldn’t need to understand OAuth flows to check a server’s status.
The capability exists. The access exists. What’s missing is the packaging – turning “I can code my way to the answer” into “anyone on the team can ask and get the answer.”
That’s what we’re actually building toward.
What We’re Actually Building
This isn’t theoretical. We’re working toward exactly this kind of system.
The foundation is the data layer – making client context available in a structured way. Which client, which systems, which credentials, which documentation. An AI can’t help with “Contoso’s server” if it doesn’t know what servers Contoso has.
The connection layer comes next. MCP servers or similar integrations that let the AI reach into ConnectWise, IT Glue, Azure tenants, and other systems. Not just read access – write access where appropriate, with proper guardrails.
The conversation layer ties it together. A chat interface where questions get answered and actions get taken. Natural language in, useful results out. Context maintained across the conversation so “now check the other client” works without restating everything.
The learning layer is the long game. Capturing how decisions get made, what patterns work, which approaches fail. Building institutional knowledge into the system over time.
We’re not there yet. But each piece is achievable with current technology. The gap is narrowing.
When to Build vs. When to Wait
Not everything needs a custom solution. The honest assessment:
Use native AI when: The task lives entirely within one platform (summarizing Outlook emails, analyzing Excel data). Generic recommendations are useful (draft responses, meeting summaries). The scope is single-tenant and doesn’t require cross-system context. Speed matters more than precision.
Build custom when: Multi-tenant context is essential (MSP client operations). Cross-system integration is required (ConnectWise + IT Glue + Azure). Actions need to happen, not just insights. Domain-specific knowledge matters (your dispatch logic, your client relationships, your escalation paths). The native tools literally can’t access what you need.
The test is simple: can Copilot see the information and take the action? If yes, use it. If no, you’re in custom territory.
The Realistic Timeline
This isn’t a weekend project. Building an MSP-native AI assistant is measured in months of incremental progress.
Phase 1 is proving the concept – can we get an AI to query IT Glue for client documentation? Can we connect it to ConnectWise to pull ticket data? Small integrations that demonstrate the approach works.
Phase 2 is expanding scope – more systems connected, more actions available, better context switching between clients. The assistant becomes genuinely useful for specific tasks.
Phase 3 is daily workflow integration – the assistant isn’t a separate tool, it’s part of how work gets done. Dispatchers use it. Techs use it. It’s embedded in the operational rhythm.
Phase 4 is the learning layer – the system gets better because it’s used, not just because we update it. Patterns emerge from real work.
Microsoft might build some of this eventually. The big AI players might wake up to the MSP market. But waiting means falling behind organizations that figured it out themselves.
The Bigger Picture
Episode 1 of this series was about connectors – recognizing when native integrations can replace custom builds.
Episode 2 was about agency – when AI moves from informing to acting, and the trust journey that requires.
This episode is about scope – understanding where native AI tools hit their limits and custom solutions become necessary.
The through-line is practical AI adoption for organizations that don’t have the luxury of generic solutions. We work in a multi-tenant, cross-system, action-oriented world that the big AI products weren’t designed for.
That’s not a complaint. It’s a recognition that the most valuable AI implementations will be the ones built to fit specific operational realities. The organizations that build those implementations will have capabilities their competitors don’t.
Copilot is impressive. So is Claude, GPT 5.2, and the rest of the rapidly evolving AI landscape. But impressive isn’t enough when your work spans systems these tools can’t see and clients these tools don’t understand.
The gap between what native AI offers and what MSP operations require is where custom solutions earn their keep. Not because we enjoy building things, but because the alternative is waiting for vendors to understand a market they’ve never prioritized.
We’re not waiting.
This concludes the “Going Past Chatbots” series – three perspectives on practical AI adoption: knowing when native tools are enough, building trust for AI that takes action, and recognizing where custom solutions still matter. The common thread: AI works best when it fits how you actually operate, not how vendors imagine you should. Read the previous post: Going Past Chatbots: When AI Agents Replace Workflows