First Pass: A Collection of Insights on the world of AI and MSPs

Why We Wrote an Open Source AI Framework For the Industry

Wed, 25 Mar 2026 00:15:59 GMT

Write about something you know. If you don’t know much about a specific topic that will interest your readers, invite an expert to write about it.

One of the reasons AI feels so messy in the MSP world is simple. There isn’t a real framework.

Not a shared one.

Not a practical one.

Not something people can actually ground decisions in.

What exists instead is a mix of vendor narratives, half‑borrowed security models, and a lot of well‑intentioned guesswork. Everyone is trying to build structure at the same time they’re trying to figure out what AI even is in their business.

That’s a hard way to operate.

Most of what I see today isn’t really a framework. It’s paperwork layered on top of uncertainty. An attempt to look organized before there’s anything stable underneath it.

And that’s not a knock on effort. It’s just what happens when there’s nothing solid to anchor to.

This is actually why I ended up writing the Lemhi AI framework at all

Not because I wanted to introduce another abstraction, but because there wasn’t one to start from. There was no common language. No baseline for what “good” even looked like. No way to evaluate tools without starting from scratch every time.

Everyone was picking tools first and trying to justify them later. That’s backwards.

Without a framework, every AI decision feels heavyweight. Every new tool creates debate. Every customer conversation turns into a custom explanation. And every internal discussion becomes philosophical instead of practical.

A real framework does the opposite.

It gives you a place to stand.

It makes tradeoffs obvious.

It lets you evaluate tools against something instead of reacting to them emotionally or defensively.

Once we accepted that a framework was needed, the next decision was obvious. It had to be open .

If this lived behind a product, a paywall, or a consulting engagement, it would immediately lose credibility. It would feel like positioning instead of structure. Another opinionated take instead of a shared starting point.

That was the opposite of the goal.

The intent here is not to “win” the AI framework debate. It is to start it and open it to the community.

Open source forces discipline. Anyone can inspect it. Anyone can challenge it. Anyone can fork it. If something does not hold up in the real world, it gets exposed quickly. That is a feature, not a risk.

It also keeps the framework honest. The moment it turns into a sales asset, it stops being useful as a control system. MSPs already have enough vendor shaped narratives telling them how AI should work. They do not need another one.

So we gave it to the community and have decided to own changes. My take on it? You do not need to believe everything in it. You just need a place to stand.

If you have spent time in cybersecurity, the structure will feel familiar. That is intentional.

CIS works not because it is perfect, but because it respects how organizations actually adopt things. It recognizes that maturity is staged. That not every control matters on day one. That sequencing matters more than ambition. AI adoption follows the same pattern.

There is a massive difference between “we are experimenting” and “this is now part of how work gets done.” Treating those two states the same is how organizations either freeze or move too fast.

So instead of inventing something new, we copied the part that already worked.

What can you expect?

Implementation Groups.

IG1: Baseline – What must exist before AI is considered real

IG2: Scale – What prevents drift as adoption grows

IG3: Advanced – What only matters once AI is embedded into sensitive workflows

This is not about slowing teams down. It is about giving them permission to start honestly where they are.

Pillars

Pillars are not categories for organization. Each one maps to a failure mode we kept seeing in real environments.

Most AI problems are predictable. Missing ownership. Unclear data boundaries. No visibility. No rollback path. Pillars force teams to confront the parts they usually assume away.

What Each Pillar Represents

Each pillar answers a different “what breaks if we ignore this” question:

Strategy & Buy‑In – Who owns AI and why it exists

Policy & Governance – What is allowed, what is not, and how exceptions work

Technical Readiness – Whether the environment can actually support AI

Process Mapping – Where AI fits into real work, not demos

Data Security & Tagging – What data AI can see and what it never should

AI Observability – Whether usage, cost, risk, and quality are visible

Copilot Readiness – How Microsoft Copilot expands safely and deliberately

AI Tooling & Deployment – How pilots become production without chaos

Skipping a pillar usually shows up later as noise, risk, or rework.

What’s Inside Each Control

Every control is written to be executable, not theoretical.

Each one includes:

A clear objective

A concrete requirement

A defined cadence

A named owner

Evidence you can actually produce

Controls are not pass or fail judgments. They are orientation points. They tell you what matters now, what can wait, and what you should not skip.

The point of the framework is simple.

AI should feel boring once it is working. Owned. Governed. Measured. Improved over time.

If it does not, something upstream is missing.

Most MSP Problems Aren’t Technical, and AI is the Least of IT All (In your customer’s mind...)

Wed, 18 Mar 2026 00:16:00 GMT

There are so many good reasons to communicate with site visitors. Tell them about sales and new products or update them with tips and information.

The more conversations I have with MSPs about monetizing AI, the less convinced I am that their biggest problems are technical.

They feel technical. They show up as tool debates, platform decisions, AI comparisons, and architecture questions. What bothers me is everyone treats this AI problem like an engineering problem that just need better tools.

But that’s not actually where things break down.

What I hear most often isn’t “this tool doesn’t work.”

It’s “we’re not sure what to use.”

Or “we’re still testing a few things.”

Or “we don’t really know how to talk about this with customers yet.”

That last part matters more than people want to admit.

A lot of this came up in recent coffee chats. Someone will say they’re looking at Copilot, but also using ChatGPT, and then another AI product their vendor just showed them. They’re trying to decide which one to standardize on, whether they should offer multiple options, or whether they should even be selling AI at all yet.

None of that is a technical limitation. It’s a clarity problem.

MSPs don’t lack tools. They lack conviction.

Every option sounds plausible, and in a lot of cases they ARE plausible. Every vendor has a story. Every demo works in isolation. And because everything might be important, nothing gets fully committed to.

So teams keep evaluating. They keep experimenting. They keep waiting for the moment when it all becomes obvious. And in the meantime, selling AI feels hard.

But that is absolutely not because customers don’t want it. But because MSPs don’t know how to explain it without talking tools. That’s the part I think a lot of people miss. Selling AI isn’t hard because the technology is complex... iIt’s hard because the narrative is unsettled.

If you’re not clear on what AI is in your stack, what problem it actually solves, and where its limits are, then every sales conversation turns into a ramble. You hedge. You over‑qualify. You list tools instead of outcomes.

Customers feel that.

And when the story isn’t clear, trust doesn’t form. Deals stall. AI gets positioned as “interesting” instead of “necessary,” or they go on their own way and solve their own problems. AI isn’t a particularly difficult one to self-service, so that’s the path of least resistance.

That’s not a sales failure. That’s a prioritization failure.

Most MSPs don’t need better pitch decks or smarter demos... They need stronger filters.

They need to decide what they believe. They need a default answer. They need to say no to a lot of things so the yes actually means something.

That’s where ecosystems start to matter.

An ecosystem reduces choice. It forces consistency. It gives your team shared language instead of a dozen different explanations depending on which tool someone last tried.

When the internal story stabilizes, selling gets easier. Not slicker just clearer. Most MSP problems aren’t technical. And most MSP AI sales problems aren’t either. They’re narrative problems. They’re clarity problems. They’re commitment problems.

AI didn’t create that. It just exposed it. And until that’s addressed, no new tool is going to make AI easier to sell. It’ll just add another option to an already crowded list.

This is where my skepticism keeps leading me.

The real question isn’t how do we sell AI? It’s what are we actually willing to stand behind?

Once that’s clear, the rest starts to quiet down.

In an AI World Full of Noise, I’m Being Skeptical on Purpose

Wed, 11 Mar 2026 00:16:00 GMT

The new season is a great reason to make and keep resolutions. Whether it’s eating right or cleaning out the garage, here are some tips for making and keeping resolutions.

I’ve been labeled skeptical a bit recently around AI. I’m fine with that.

But it’s worth saying what that skepticism actually is (and what it isn’t).

I’m not anti‑innovation. I build things for a living. I like new ideas. I like progress. I like when technology actually moves the ball forward. What I’m against is noise. And right now, MSPs are drowning in it.

Every cycle brings a new framework, a new model, a new set of tools, a new abstraction layer that promises to “change everything.” The language is confident. The diagrams are clean. The demos are impressive. And yet, when you step back, a lot of it doesn’t survive contact with reality.

That’s where my skepticism comes from. I’ve been in this space for 15+ years. I know what the beginning of a cycle looks like. It often follows the same patterns and the same experimentation. And for a decade and a half, it’s mostly landed in the same ending position, whether cloud, cyber, or AI: repeatable and monetizable at scale.

I don’t start by believing vendors. I don’t start by assuming the abstraction is necessary. I don’t start by trusting that because something is popular, it’s useful. I start by asking a much more boring question: Does this actually hold up when you try to run it, scale it, support it, and charge money for it?

Most things don’t fail because they’re bad ideas. They fail because they’re fragile, expensive, hard to explain, or impossible to operationalize. Or they only work under perfect conditions that never exist outside a demo. And in today’s era, with the break neck speed that things get done, none of that is acceptable.

I think a lot of people miss this. Especially in AI.

There’s a temptation to treat intelligence as magic instead of infrastructure. To stack more layers, more orchestration, more cleverness on top, and assume value will appear. But intelligence that can’t be repeated, governed, or monetized isn’t progress. It’s a science project, and its irresponsible if you’re doing it in your customers environments.

Healthy skepticism is how you protect yourself from that.

It forces you to slow down and separate what’s interesting from what’s durable. What sounds smart from what actually compounds. What helps one team ship a demo from what helps an organization operate at scale. And it’s the exercise you need to stop feeling so overwhelmed with the noise.

This is where my head goes with it: if something can’t be explained simply, deployed repeatdely, and improved incrementally, it’s probably not ready.

So yes, I’m skeptical. On purpose. Because skepticism is how you calm the noise. And once the noise is gone, the real work can start.

Look forward to sharing more of my learnings soon! (They’ll be a little less skeptical, I promise)