Why Thread Doesn’t Train on Your Data and How That Makes the AI Better

One of the first questions I get when people see Thread is about data.

Specifically: What data do you train on?

It’s a fair question. Most AI products today are built on the idea that more historical data makes the system smarter. Tickets feel like the obvious source. They’re full of real decisions and real service work.

But early on, we realized something uncomfortable.

Training AI on past service desk data doesn’t fix the problem. It just automates it.

The two paths you can take

When you’re building AI for service delivery, you really have two choices.

You can look at how things have been done in the past and try to train a model on that behavior. Or you can step back and start from first principles — defining how work should be done, regardless of how messy things have been historically.

We tried the first approach. It didn’t work.

The data was inconsistent. Priorities varied by technician. Rules were applied differently depending on the day, the customer, or who was on call. Training on that data just reproduced the same variability at scale.

That’s not intelligence. That’s acceleration.

Why historical tickets are a bad teacher

Tickets aren’t written to teach. They’re written to survive the moment.

They’re full of shortcuts, partial context, and one-off decisions that made sense at the time. Over months and years, even the best service desks drift away from best practices.

If your goal is consistency, reliability, and scale, that’s a terrible foundation to build on.

All training on that data does is give you more of what you already have.

What first principles actually looks like

Instead of asking AI to learn from the past, we asked a simpler question: what is the service desk trying to achieve?

Think about onboarding a new technician. You don’t hand them five years of tickets and say, “Figure it out.” You explain priorities. You explain escalation. You explain what good service looks like.

That’s first-principles thinking.

You start with the rules and the intent, not the history.

This is where ITIL fits in

A lot of people assume first principles means ignoring frameworks like ITIL. It’s the opposite.

At the core of ITIL, prioritization is based on impact and urgency. That’s not complicated. The problem is applying it consistently in the real world.

Humans forget rules. They interpret them differently. Under pressure, they take shortcuts. That’s not a failure — it’s just reality.

AI doesn’t forget. Once you define the rules, it applies them the same way every single time. In practice, that means ITIL is enforced more consistently by AI than it ever was by humans alone.

The moment everything changed

Early versions of Thread experimented with training on historical data, just like everyone else. The results were inconsistent and hard to improve.

When we stopped training on tickets and focused instead on enforcing what should happen, accuracy jumped almost immediately. More importantly, the decisions started to make sense.

We compared AI decisions to human decisions across real tickets. What we found surprised us. Humans were wrong more often than we expected. Not because they were bad at their jobs, but because consistency at scale is hard.

AI is good at consistency.

Tell us how you want the business to run

That realization changed how we built Thread.

We don’t ask customers to upload years of historical tickets. We ask them how they want their service desk to operate going forward.

What matters? What doesn’t? How should priority actually be assigned?

The AI learns those rules and applies them relentlessly. That’s why accuracy is high out of the box and improves quickly — often into the 90% range within days.

It doesn’t matter how things have been done. What matters is how you want them to be done.

Training versus learning

There’s a difference between training and learning.

Training looks backward. It repeats behavior, good and bad. Learning moves toward an ideal state by applying rules and improving through feedback.

We don’t train AI on customer data because service delivery shouldn’t be constrained by yesterday’s inconsistencies. By starting from first principles and grounding everything in proven frameworks like ITIL, we’re building AI that actually makes service better — not just faster.