We did not start with “build an AI platform.” We started with a simple MSP question:
Can AI help technicians resolve tickets faster, without sacrificing safety or control?
The fastest way to test that was the OpenAI Playground, a low-friction place to experiment with prompts and models before you build anything.
What we found was exciting and frustrating in the same hour. Which brings me to the best phrase I have seen for this era of AI.
Researchers describe AI’s capabilities as a “jagged technological frontier.” AI can be excellent at some tasks, and then fail at other tasks that look very similar to humans.
That mapped perfectly to MSP work:
So our mindset became: validate what AI is great at, then build guardrails around everything else.
The Playground gave us a fast learning loop. We could make small changes and immediately see if the output improved.
The knobs that mattered most:
This is where you set strict rules like:
For MSP ops, consistency beats creativity most of the time. Lower temperature, shorter outputs, more structure.
This was the big unlock for MSPs. So much of the truth lives in exports and logs, not in the model’s general knowledge.
We exported sign-in logs and asked the model to do what good engineers already do, but faster:
The results were legitimately useful. Especially for turning raw telemetry into a narrative a tech can act on.
We did the same with Ninja exports:
Again, the model was great at turning noisy lists into operational summaries.
One thing became obvious quickly. LLMs are language models. They are not a reliable calculator.
If you need totals, rates, billing math, compliance thresholds, or anything you will present to a customer, treat that as code. Hard-code calculations in Python. Let AI interpret and explain the output, but do not let it “do the math” in production.
Even when the Playground outputs were strong, it still looked like this:
That is not a workflow. That is a side quest.
And side quests do not survive a busy service desk.
This is where MSPs are different from almost every other IT environment.
An internal IT team might standardize on a small stack. MSPs often support dozens of tools internally, and then interact with hundreds of software applications across client environments.
That creates a brutal math problem for AI adoption.
If every workflow depends on a different portal, API, permission model, and data format, then “just build an AI assistant” turns into building and maintaining dozens of one-off integrations.
Even if you can prove value in the Playground, taking it to production means:
That is a big lift for any MSP, and it is exactly why generic chat tools do not stick. The challenge is not ideas. The challenge is operationalizing them across a wildly heterogeneous stack.
Once you validate that AI can help, the next question is not “can we keep prompting.” It is:
Can we operationalize this safely, consistently, and at scale?
This is where working with a product company becomes the pragmatic choice.
Playground is great for learning. Production requires:
It is not enough to be correct. You need to prove what happened and what changed.
A prompt that works today can break tomorrow because:
A product can enforce structured inputs, safe defaults, and consistent outputs.
To make AI usable day to day you need:
Without that, it stays a gimmick. Impressive, but not operational.
Playground made the value obvious. It also made the limitations obvious.
So we built Junto to bring those capabilities into the workflow technicians already live in.
Junto is an AI helpdesk command center that:
If you have validated AI is helpful, Junto is the “get it into the game” layer.
You can learn more at juntoai.com.
If you are curious, start where we started.
That journey is exactly how we got here.
If you want to see what this looks like in a real ticket flow, visit juntoai.com.