Open Source AI Agents for MSPs vs Vendor Agent Marketplaces

On July 21, 2026, Pax8 announced its Agent Store, the centerpiece of a "Managed Intelligence" push that lets partners build an agent once and deploy it across every client tenant, then earn revenue on the consumption each agent drives.

Channel press called it a move that will reshape MSP services. Read the mechanics a second time and a familiar shape shows through. You build inside the store, you bill through the store, and the automation that runs your service delivery lives on infrastructure you do not own.

That is the SaaS lock-in playbook, running one layer up. Vendors spent a decade locking MSPs into RMM and PSA tooling. Agent marketplaces move the dependency to the automation layer that sits on top of that tooling, and it is stickier up there, because an agent encodes how you deliver service. Your triage logic. Your escalation rules. Your remediation steps. Lose access and you are not just swapping a tool. You lose the decision-making you spent two years teaching a machine.

This post answers a narrow question on purpose: which AI agents should an MSP run, and who owns them when the contract ends. It is not another tour of what agents do in service delivery. The point here is ownership, and where open frameworks beat a marketplace, and the rows where buying still wins.

What an AI Agent Is in an MSP Context

An agent is not a chatbot and it is not a script. A script runs the same steps every time. A chatbot answers a question and stops. An agent takes a goal, decides which steps to run, calls tools to act on the world, checks the result, and loops until the goal is met or it hits a guardrail. In an MSP shop that means reading a ticket, pulling asset data from the RMM, deciding the fix, applying it or drafting it for approval, and closing the loop back into the PSA.

That capability layer is well-trodden ground, so we will keep it short here and point you to the breakdown of what agents run in MSP service delivery instead of repeating it. What matters for this decision is simpler: the agent is where your process turns into software. Own that software and you keep the process. Rent it and you rent the process too.

Vendor Agent Marketplaces vs Open Frameworks

The channel has two answers to "how do I put agents to work," and they pull in opposite directions.

On the vendor side, the marketplaces arrived fast in 2026. Pax8's Agent Store hit general availability in July with multi-tenant orchestration and consumption billing. ConnectWise pushed agentic features through its Asio platform and the Sidekick assistant plus RPA, landing most of it in the ConnectWise Pro tier. Kaseya's Cooper line began shipping genAI features across IT Glue and Autotask, built on the Model Context Protocol. The pitch is the same across all three: pre-built agents, one console, revenue share, no engineering required.

On the open side, the general-purpose agent frameworks matured to the point where a competent technician or a small dev can stand one up in a weekend. These are not MSP products. They are building blocks. You supply the goal, the tools, and the model, and you own everything you assemble. The OpenMSP directory of open-source tools is the wider map; the agent layer is the newest room in that house.

The difference is not open versus closed as a slogan. It is who holds the automation when you decide to leave.

Open Source AI Agent Frameworks Worth Knowing

These are the frameworks an MSP can build on today. None of them ship with a tenant model or a billing engine, so the marketplace convenience is real and this is where you pay for independence with engineering time. Read the maturity column before you fall in love with any of them.

One honesty note the marketing around these tools skips: n8n ships under a fair-code license, not an OSI-approved open-source one, so read its terms if resale is your plan. And protocol support moves monthly. The reason it matters is the next section.

Vendor Marketplace vs Open Framework

Put the two models side by side across the things that decide whether you regret this in 2028.

Neither column is the winner in the abstract. The marketplace trades ownership for speed. The open stack trades speed for ownership. What tips the call is how central the automation is to your margin, and how much it would cost you to rebuild it somewhere else. Which brings us to the part that most Agent Store coverage skips.

The Lock-In Analysis: What You Can and Cannot Take With You

This is the core of the decision, so slow down here. When you build an agent inside a vendor marketplace, four things get created, and they do not all belong to you when you leave.

Prompts and workflow logic are the first. The instructions that tell the agent how to triage a ticket or handle a patch exception are usually editable inside the console but not exportable in any portable form. You can screenshot them. You cannot lift them into another system and press play. Run history is the second. Every action the agent took, every decision, every outcome, is a dataset you would kill for when tuning the next version, and it typically stays in the vendor's database. Export is read-only at best.

The third is integration wiring. The connections from the agent to your RMM, PSA, and documentation are built against the vendor's connectors. Leave, and every one of those connections has to be rebuilt against a new system. The fourth, and the quiet one, is training and tuning signal. If the marketplace improves its agents using aggregate partner data, your corrections are feeding a model you will never take with you, and possibly one your competitor down the road is renting too.

Compare that to an open stack. The prompts sit in version control. The run history writes to a database you host. The integrations run through the Model Context Protocol, which the Linux Foundation now stewards as the de facto standard for agent-to-tool connectivity, with more than 18,000 community servers and adoption from Anthropic, OpenAI, and Google. Standardized connections are the whole point. Swap the model, swap the host, keep the wiring. Portability stops being a migration project and becomes a config change. The debunking of open-source MSP myths covers the fear that this is all too fragile to trust; the short of it is that the standard layer is now boring, which in infrastructure is the highest compliment there is.

Integration Reality: Wiring Agents to RMM, PSA, and Helpdesk

An agent that cannot touch your tools is a demo. The work that separates a slide from a running system is the integration, and it is the same work whether you buy or build. The agent needs read and write access to the RMM for device state and remediation, to the PSA for tickets and time, and to the documentation or helpdesk for context.

In a marketplace the vendor ships those connectors and you accept their scope. In an open stack you wire them yourself, increasingly through MCP servers that expose each tool as a standard interface the agent can call. That is more setup on day one and far less rework on the day you change platforms. If you want the concrete wiring, the walkthrough on connecting an AI agent to an RMM and helpdesk shows the moving parts end to end. The lesson from the shops already doing this is blunt: the model is the easy part, and the integration is the job.

Data Residency and Client-Data Exposure

Every agent run moves client data somewhere. A ticket body has names, network details, sometimes credentials a user pasted where they should not have. When the agent runs on vendor infrastructure, that content transits the vendor's tenant and, depending on the terms, their model provider's too. For a shop with clients under HIPAA, CMMC, or a cyber-insurance data-handling clause, "where does the ticket text go" is not a philosophical question. It is a line item in an audit.

Open frameworks do not make compliance free, but they hand you the controls. You pick the model host, including a private or regional endpoint. You decide what gets redacted before it leaves your network. You keep the logs on your side of the line. That is the argument big MSPs are quietly acting on while staying quiet about it: control over the data path is worth more than the convenience they gave up to get it.

A Working Example: Ticket Triage on an Open Stack

Make it concrete with one workflow most shops would run first: first-line ticket triage. A ticket lands in the PSA. An n8n workflow catches the webhook and hands the ticket to a LangGraph agent. The agent reads the body, classifies the issue, and pulls the affected device's status from the RMM through an MCP server. For a known pattern, say a stuck print spooler, it drafts the remediation and either applies it under a guardrail or routes it to a technician for one-click approval. It writes the classification, the action, and the time back to the PSA and closes the loop.

Every piece of that is yours. The classification prompt is a file in your repo. The run log writes to your database. The RMM and PSA connections are MCP servers you can point at a different platform next year without touching the agent logic. Build the same flow in a marketplace and it works just as well on Tuesday, but the prompt, the log, and the wiring all live in a console you are renting. Same output, different owner. The AI and open-source combination is the margin lever OpenMSP has been mapping all year, and triage is the cleanest place to prove it in your own shop.

Build vs Buy by MSP Size

Ownership is the right default, and it is not the right answer for everyone. Here is the honest split by shop size, with real buy rows, because a table with no buy rows is a sales page.

The dividing line is not size for its own sake. It is whether the automation is generic or is the thing clients pay you for. Generic work, like drafting reply templates or the routine IT operations automation many shops already run, is fine to rent. The workflow that encodes your specific service delivery, the one a competitor cannot copy because it took you years to tune, is the one you never want living on someone else's server.

The 24-Month Cost Model

Convenience has a price and it compounds. Below is a rough two-year model for a 200-endpoint book running roughly 3,000 agent actions a month. Treat the numbers as a shape, not a quote, and swap in your own volumes before you decide anything.

The marketplace wins on month one and the open stack wins on the two-year line, and both statements are true at once. If your consumption is low and stays low, the marketplace may never cross over. If volume climbs, per-run billing is the meter you cannot turn off, and the crossover arrives faster than the demo suggested. Model your real numbers. The point is that "free to start" and "cheaper to own" describe two different timelines, and the vendor only shows you the first one.

Who It Fits

The marketplace fits the shop that needs agents working this quarter, runs modest volume, and would rather pay a meter than staff a build. The open stack fits the shop with dev capacity, real volume, and a service process worth protecting. Most MSPs in the middle will do both, and the skill worth building is knowing which workflow goes where.

What does not change with shop size is the thing the Agent Store coverage keeps out of frame. Whichever you choose, the automation layer is where your process becomes software, and software you do not own is a process you are renting back from someone who can reprice it. Vendors already ran this play on RMM and PSA. The agents are the next layer up. Decide who holds it before the contract does.