What Will AI Automation Look Like for MSPs?

AI Automation in MSPs has been a constant topic of conversation. And one could argue, logically so: MSPs became commonplace by embracing automation—scripting, remote management, proactive monitoring for threats. MSPs have grown because of their ability to automate and have even been value-added resellers of automation (think productivity tools, patching, self-healing security solutions).

That said, there are varying visions for what AI will look like in MSP functions going forward. Some envision an all-encompassing role of AI in short order, where almost all front and back-office functions are transformed by AI—and eventually replaced by AI—with the role of MSPs moving to a true strategy and partnership model. Others take a more cautious approach, with certain functions being enhanced with AI, but the human-centric model of support holding as a true differentiator.

I’m a little biased (building Toolqit), but I land closer to the first case I outlined, though with a continuing human-centric focus that MSPs can provide. One thing is for sure though: AI is here to stay, and the current version of AI in MSPs can’t be our end state.

What AI-native solutions look like today

So what do AI-native solutions in MSPs actually look like today? Mostly, newer AI tools focus on triage. The most common use case is matching incoming tickets against previously resolved ones: pattern recognition matches likely (previous) fixes, routes tickets to the right queue, and gets them tagged with the correct priority, type, and subtype. AI is commonly baked into network security solutions as well (anomaly detection, threat scoring), and there are scripting-oriented automation platforms like Rewst that let MSPs build workflows across their tool stacks, though those come at a steeper price point that put them out of reach for a lot of smaller firms.

More specifically, MSPs might use AI-native tools like Thread and zofiQ. Thread, for example, sits on top of PSAs and acts as an intelligent service desk layer, auto-categorizing and auto-prioritizing incoming tickets, transcribing calls, and creating closing notes, and pulling relevant context so that technicians can start with information from previously solved tickets. ZofiQ functions in a similar way, learning from historical ticket data to triage requests, pulling up context from KB articles, etc. Both are quite useful but have a core value proposition of making it more efficient for a technician to get to a solution for more elementary tickets, rather than solving tickets or working with the end-user / end-workspace. Tickets that have diagnostic complexity still require a lot of human back and forth. Beyond triage, AI still hasn’t been widely implemented in other MSP tools.

The problem with AI-enablements on legacy tools

The second focus for AI in MSP functions are AI-enablements; LLM wrappers attached on top of existing legacy software tools used by MSPs, but which weren’t architected to support it. Most of the legacy tools in question (monitoring platforms, documentation, PSAs, etc.) were built in the 90’s and 2000s, where design was focused more around stability and workflow management, not data fluidity or intelligent context retrieval. These tools weren’t designed to connect / communicate with each other in a deep way, and bolting AI wrappers on top doesn’t change that reality.

As a result, MSPs have a fragmented data landscape that makes truly intelligent AI difficult to pull off. It’s very difficult to build a unified data lake when the context (that’s so important for AI-solutions) is scattered across your PSA, RMM, IT documentation platform, backup console, and a handful of vendor portals, each with their own schema, API quirks, and own way of storing context. An article from Auvik mentioned that nearly 50% of MSPs are running 10+ tools to manage client workspaces and that sprawl means there’s very little meaningful information-sharing happening between systems.

There are some exciting new paradigms like MCP-based integrations that are promising in concept but haven’t yet seen real deployment at scale inside these legacy environments. For now, AI in the MSP stack is largely constrained to working within individual tools rather than across them and adding a tool or two that is AI-native for some efficiency gains in ticketing.

Building from the ground up

With my view outlined above, the opportunity appears to be to build from the ground up, rather than to place AI as a top layer on service tools. That’s what we’re building (shameless plug) at Toolqit: the first AI-native service delivery stack for your MSP, which we’ve built from the ground up. Toolqit plugs into MSPs’ PSA and any other tools that MSPs use / continue to use.

Our goal is that eventually most service delivery / front-office tools used by MSPs are through Toolqit itself (to increase context sharing), but we offer plug-ins as well. More to come here (and more available throughout our website), but our goal is simple…to completely turn the number of tools used in MSP service delivery on its head. We hope Toolqit can do this by rebuilding each tool used with AI use cases that have been integrated tastefully on a unified platform, with context sharing across each tool.

The TLDR

MSPs are at their best, in my view, when end users can interface with real humans, and where MSPs can be truly strategic IT partners for businesses. That said, the proliferation of AI is making way for an exciting future where rote tasks, scoping, tracking desktops, and documentation (amongst other functions) will take far less manual work going forward. To add to that, time waste and context switching have an opportunity to not be the chief complaint of technicians—they’ll just need the right tooling.