You DO Want AI Training on Your Data

Scott King
Hey everyone. Thanks for joining this episode of The Union podcast. We call it The Union because it’s the union of technology, people, AI, and systems—a combination of it all. I’ve got a new combination today with Chris and John. We’re going to talk about AI and automation.

John, I wanted to talk with you about an RFI we received. We were answering some questions, and one of them led to an unexpected response that required a lot of explanation. What was the question? What do you think they expected us to say, and what did we actually say?

John Michelsen
Yeah, this is a theme we’re starting to hear more often. A lot of folks are assessing how they want to manage or control AI that’s being brought into or built within the organization. One of the questions we received was, “Do you train AI on our data?”

Our answer was, of course we do.

And that triggered the typical response: “Are you stealing my stuff? Are you going to…?”

Scott King
Yeah, isn’t that bad? It’s a reflex. People assume all AI is just GenAI. That’s how they perceive it. They’re used to pasting data into a public LLM and don’t want it consumed. But the question itself isn’t appropriate—of course you want to train AI on your business. That’s how it gets better.

John Michelsen
Exactly. We need to be more nuanced about what “training AI” means. You’re not going to get an AI that understands your business—what we call a cognitive enterprise—unless it learns from your data. Even better, it should learn from the behavior of your people.

In the document, I wrote—diplomatically—something like: not only will I train AI on your data, I’ll do you one better. I’ll train it on your people’s behavior.

Of course, we do all of this with strict safeguards: confidentiality, security, no use in other customers’ environments, never published—just like any sensitive data we handle. We act responsibly.

The issue is people assume all AI is GenAI—fallacy number one. Then they say, “I don’t want custom AI trained on my data.” But in reality, yes, you do. You just don’t realize that’s what you need.

People ask us, “Can you fine-tune a model on our data that’s only ours?” That’s a very limited use case. You rarely want to fine-tune a large language model.

We have to understand the difference between third-party AI—which has no business seeing your data—and AI from a vendor you’re working with. Lock down public access to LLMs, use API keys, put guidelines in place, maybe even add a layer in front of those LLMs to enforce those guidelines. That’s a good approach.

Then there’s AI from a specific vendor—like us. You’ve got to make sure that vendor takes all the standard precautions, especially depending on your use case.

We don’t build AI that makes decisions or solves problems on its own. We use both third-party and our own AI as features or capabilities that can be woven together with people, systems, and your custom AI.

That’s the third type—your custom AI. It’s not truly custom unless it’s learning from your data and your people. When it does that, it understands your perspective today and continues learning to adapt over time.

That’s the magic. When you combine all three—third-party AI, vendor AI, and your custom AI—you get a real platform for transformation. Without all three, you’re going to run into challenges.

You absolutely want to use third-party AI for what it’s great at. You also want to work with vendors who’ve already built capabilities you don’t want to build yourself. But then, there are unique situations—like “is this customer worthy of a discount?” or “can I expedite this order?”

I think in this podcast we’ve shared many examples like that. There are dozens more. These are all tied directly to your use case, your data, your timing, and your organization’s perspective.

John Michelsen
So yes, we will train AI on your data—but it’ll be your model. Your data, your model.

Another question we got was: “What do you do with my data once our contract ends?” It’s like they believe their data ran away and they can’t get it back. They’re ready to post a “lost data” sign—like it’s a puppy that wandered off.

These assessments sometimes feel like traps. Like, “I’m nervous, I don’t want to do this, but I’ll put together an assessment to catch you, so I can say no.”

And then I walked right into it by saying, “Yes, of course we train AI on your data.”

Just to clarify—because I might sound too abstract—you need AI trained on your data. That’s half of what you’re deploying. Without it, you won’t achieve the kind of transformation AI can deliver.

Those who do build on their data will transform in much more meaningful ways. And you want to be one of those organizations—more empowered, not just using third-party tools.

Third-party AI is improving fast, but it will only take you so far.

Chris Kraus
John, one thing we’ve talked about is—why do you categorize emails for intent? Why do you use categorizers versus regressors for decisions?

Let’s use a different example. Everyone’s talking about agentic platforms, where you need multiple agents, each purpose-built for a specific body of work. We do this in Krista all the time.

People often ask me, “Why does the Krista on your website always give such concise, perfect answers about Krista’s functionality?”

It’s because she’s only trained on our website. She’s only read our white papers. She only knows our technical details. So she gives a really specific, positive answer. That’s an agent built to answer questions about Krista.

Now, on the other side, what people need to understand is that you want a categorizer—a machine learning AI—in front of multiple agents.

Say you have one agent that knows about your company. You have another agent that understands accounts payable and vendor payments. A third agent handles accounts receivable and customer payments. A fourth might cover internal HR.

You wouldn’t want to dump all that data into one agent, because you’d get strange or inaccurate answers. It wouldn’t know the context.

For example, if someone asks about “net terms,” are they referring to accounts payable or receivable? Or is it an HR context—like expense reports or employee reimbursements? Or are we talking about vendor payments?

So you actually want four agentic agents, each focused on their domain. But you also want a categorizer—a machine learning layer in front of them—that routes the question to the right subject matter expert. How do you explain that to someone? That you need to train each agent on its specific subject matter—but before that, you need a categorizer to make sure it reaches the right one?

John Michelsen
This becomes a question of—are you trying to flood your company’s network with a bunch of new UIs for all these little chatbots? You’d have to figure out which one to use for what. Then you reflect that complexity onto your customers. Now they’re interacting with four different parts of your organization, and each one has its own new interface. You don’t want that.

But you do need the nuance. When we’re talking about accounts payable, there are specific ways we want to communicate. We don’t want it to sound salesy—we want precision.

You made a great example: receivables versus payables. The language overlaps so much that a semantic switch could easily send the wrong message. So you have to isolate those domains.

Each requires different instructions, different guidelines, different goals. And because of that, you get better outcomes from the agents you described.

It starts with identifying the context of the incoming dialogue. Maybe it’s based on who the person is, so you know which path to take. Maybe it’s based on the question itself—the email, the message. That gives you the path.

Each path lets you say, “Now I know the specifics. I know the instructions I want to give. I know the personality I want this agent to have. I know the terms and conditions that apply. I know the subject matter where I need to be extra careful—like compliance.”

Sometimes, you don’t want an interesting or creative answer. You want a literal, word-for-word response: “This is what we say when we get this question.” It’s not about phrasing it nicely—it’s policy, compliance, or something equally rigid.

You don’t get that kind of precision unless you classify the interaction correctly. And the truth is, we already do this naturally. We switch context all the time—based on what we’re doing, who we’re talking to, what the topic is. We instantly know the frame of reference, how to speak, and what knowledge to draw from.

AI agents must do the same. And they won’t be effective without it.

You achieve that with a classifier trained on your data. That’s why we build the whole system this way—because only you behave that way with your customers, prospects, partners, and employees. Only you use specific tone and phrasing.

You can’t just find someone else’s agent and plug it in. It might get things right sometimes, but only partially.

And here’s the hard part. When we explain this to customers, they ask, “Why wouldn’t I just ask a GenAI model? Can’t it figure this out?”

Why do I need all this model-building?

Well—you don’t. Krista does it for you. You don’t mind if Krista does a lot of the work, right? Let it do the heavy lifting.

But let’s be clear—why not just prompt a large language model? Two reasons:

First, they’re not that good at this. They lack the nuance of how you speak, what you mean, and how your customers interact with you. They just don’t have that.

Second, they’re not going to get better. There’s no continuous learning. There’s no feedback loop saying, “That’s not how we say it” or “That actually means something else.”

And this is where I usually get into an awkward conversation. Someone says, “Well, I can add that to the prompt. If they say X, it means Y.”

That’s not continuous training—that’s spaghetti code. You just reinvented it in prompt form.

And it falls apart. What if the customer says it slightly differently? You wrote, “If they say quote X,” but they didn’t say that exact phrase. Now what?

Let’s not turn prompt engineering into the next horrifically bad programming language. Let’s use the right tool for the job—especially when the tool is built into a product that anyone can use.

Chris Kraus
Yeah. When you talk about continuous training, it makes me think about explaining this to a customer.

They make payments in the HR system for expense reports and payroll. They also make payments in the accounts payable system. The categorizer provides statistical confidence: “I think this is a question about payroll,” or, “I think it’s about employee expenses,” or maybe, “This is about factory expenses.”

Or it could be paying an electric or water bill. At first, confidence might be low. There could be a follow-up: “Are you talking about paying a home phone bill for a remote employee, or a phone bill for factory number seven?”

But over time, if it’s a categorizer, and you prompt for confirmation—“Did I get this right?”—it gets better. It starts to distinguish the language.

A phone bill and an electric bill are both valid expenses, but the rules are completely different.

John Michelsen
Exactly. A real-world example—we did a voice bot for a public utility company using Krista’s fluid voice delivery.

People call in and say, “My bill’s too high.” First, we have to start with, “Who are you?”

Is this a commercial account or a personal one? Is it the account you’re calling from, or another one tied to your name?

These folks handle it all. And those of you working in call centers—you know how it is. You read transcripts like, “The light’s out on the corner, and you guys didn’t fix it.” The right response is, “Let’s start with your address. Are you even in our service area?”

We’re incredibly powerful machines. Our brains stitch together context effortlessly. Large language models can’t do that. They forget everything after each interaction.

Even though that’s changing a bit. A few days ago, I had an interaction where Grok referred to a previous conversation. It said, “You’re still working on that problem from a few days ago…”

I thought that was impressive. What I think happened is that it prompted itself with short summaries of prior conversations. It probably guessed the connection and pulled that context in.

That was cool. But for a utility company with millions of customers, that’s not realistic. You don’t get that level of continuity.

What we do is put classification in front of the conversation.

We say, “You want to talk about your power bill. But before we do that, there are certain things I need to know.”

That can be designed effectively if we classify all inbound activities. Call centers already do this. They have a pie chart or dashboard showing the types of issues they receive. Then there’s the “other” category—millions of unpredictable things they still have to handle.

But using the 80/20 rule, they can usually say, “I can solve this problem—but I need this information from the customer first.”

If we do that work upfront—before launching a retrieval-augmented generation solution or any orchestration—we’ve already solved most of the context problem.

We’ve solved the things that usually cause failures by doing what we already do naturally.

When someone says, “How can I help you?” we begin applying classification in our heads. They say, “The light’s out.” And we immediately think, “OK, let me gather what I need before I even open a screen.”

Scott King
John, you guys covered a lot, and I’ll sum it up like this—humans are better at lateral thinking than computers or LLMs.

We can think sideways because we understand context.

Chris, in your example with payments—accounts payable, accounting, expenses—if those departments each deployed their own agents, and there wasn’t any lateral thinking, then each would just handle its narrow task.

That defeats the purpose of a classifier. A classifier is supposed to route a request to the right agent. But if I have too many agents and no classifier, it breaks down.

I worry people will build it that way—siloed—and miss the opportunity to have AI learn across the business.

Chris Kraus
Absolutely. People won’t remember that there are four agents or how to reach them.

People can’t even remember how to open outlook.office.com to check their email, or to go to office.com.

So expecting them to remember five or six different agents, or different web pages for each one—it’s not going to work.

You need specialized agents that act as subject matter experts, but you also need a categorizer that routes requests on the user’s behalf.

All of these agents should be on the same platform. That way, they share the same look and feel and have a consistent personality.

For example, one might say, “I can do this,” while another says, “I can’t.” But they still feel unified to the user.

You want a common agentic platform across disciplines. But it’s essential to have the “traffic cop”—the categorizer.

In the old days, when we walked into office buildings, there was a receptionist who knew everyone and every department. You’d ask, “Who do I talk to?” and they’d point you in the right direction.

That’s what your AI categorizer needs to be.

John Michelsen
Where does he come up with examples like that? How do you come up with an analogy like that?

A couple of quick things to add. First—even if we do know outlook.com, and we do know the four agents—we’re going to have 40.

How do we keep informing people and getting them to remember? “No, it’s not 20 anymore, it’s 21.” “There’ll be another one on Thursday.”

This is us trying to catch up to technology, but it’s not helping us. It’s technology not understanding people. That’s the opposite of what we want.

We need something that insulates users from constant change. We call that human friction.

We’re trying to solve for human friction while delivering rapid technology change. And Chris’s example shows how failing to solve for friction introduces even more complexity.

We’re just going to keep overloading people—“No, don’t go there anymore, now it’s this.”

We talked to a customer a couple of months ago who said, “We solved our human friction problem.” They put up a screen with 18 gray boxes, each with a couple of words.

“You just go here and figure out which agent you want.” They didn’t even describe them as agents—they were all AIs.

You click one, and it takes you to the right place. But they looked identical.

“Well, that one’s commercial real estate for this, and that one’s commercial real estate for that.”

I thought, okay… case closed?

They were actually pretty comfortable with it—until we pointed out that, in a couple of years, there’ll be 800 boxes on that board.

They solved the problem for the moment, but introduced an approach that won’t scale.

This isn’t, “I’ll retire and someone else can deal with it.” We’re talking 24 months, and you’ll have 800 of these.

And Scott, you’re right—get all this work under one umbrella. You can leverage many systems and third-party AIs, but if you’re not orchestrating them together, there’s no shared context.

And without shared context, the software can’t develop the kind of lateral thinking you described.

If everything’s siloed, and an AI agent is supposed to solve a customer support issue—but all it knows is how to manage tickets and a few documents—it lacks the organizational context to drive better outcomes.

Better support, fewer returns, increased survey participation—those require broader awareness.

That’s why we’ve built Krista Enterprise Understanding.

It’s powerful when our AI orchestrates other AIs—third-party and custom AI from our customers—because it has a wide understanding of the organization.

Let’s say you’re in customer support, but you want to position the product differently.

Can we present it a new way in sales? “Oh, I didn’t realize that’s what I was supposed to be doing with it.”

The agent crosses silos to solve problems.

That’s why we always say: the sum is greater than its parts. But if you treat everything as one-offs, all you have are disconnected parts—no synergy.

And we all know, when you bring it together, the value multiplies.

So going back to the beginning: yes, we will train lots of AI on your data.

It’s your AI. It’s not useful to others. Sure, someone might want to steal the IP, but the AI itself reflects you—how you think, your capabilities, how your organization makes decisions.

John Michelsen
We’re bringing that mindset into Krista—solving problems.

We do a lot with AI, but this is one of the most interesting areas.

With enterprise-wide context, our agent can solve problems that most people wouldn’t think are even solvable by AI.

Because it has that broad perspective.

Actually—our CEO, Michael—he spends half his time in front of Krista AI asking it questions and forwarding the answers to everyone.

I get two or three a day. We all do.

 Scott King
He told me he asked Krista how to do my job—and then sent it to me. It was hilarious.

John Michelsen
Yeah. He asks Krista how he should do his job, and then sends the answer to himself. I mean, he reads it, but that’s exactly what I’m talking about.

He actually sent me what Krista recommended for his role, and it aligned perfectly with the strategy I see him developing.

The only way Krista could have understood that strategy is by having context across sales, customer success, and deep awareness of the product roadmap.

We never described the strategy the way the AI reflected it back to us.

That enterprise context—where you can ask the system, or better yet, the system can solve problems proactively with that level of understanding—is incredible.

It brings together all three types of AI: Krista’s built-in capabilities, third-party GenAI, and bespoke AI that transforms your specific business outcomes.

Scott King
Yeah, and tying it back to what you said about prompts—someone might say, “I’ll just add context to the prompt.”

But to come up with an answer about strategy like that, you’d need an incredibly long prompt. You’d have to provide so much data.

And that content is being consumed automatically. No one manually inputs that data—Krista does. That’s super cool.

John Michelsen
Exactly.

What would I need to solve that problem? I might need to know the project’s backlog, the payment history of the customer, the last few meetings we had, and what was discussed.

Any number of things could be relevant—and the fact that all of that is woven together in a way that lets the system not only answer curiosity-driven questions (which is really underselling it)…

We’re not just asking out of curiosity. We’re seeking useful answers—answers we can act on. But even more powerful is when AI asks itself the question to solve the problem for you.

That’s when you elevate execution.

Of course, I’d be remiss not to say—it all has to happen within guidelines and guardrails.

You need transparency reports, confidence scoring, and everything tracked and explainable. That’s fundamental to how Krista operates—and it should be, whether you’re using Krista, building your own solution, or buying from someone else.

In my view, this is the logical next step.

And if you’re still thinking, “I can just get my little siloed tool working and avoid integration,”

John Michelsen
Then I think you’re going the wrong way.

I’ve spent 30 years in IT, watching people say, “Let’s see how little we have to connect this to anything else.” Then we end up with people rekeying data or importing files.

That has to stop.

Scott King
Yeah, and I think one of the first 10 episodes we did was called You’re Going the Wrong Way.

You’re describing exactly what we said a couple of years ago. If you’re still doing things the way you’ve always done them, you are going the wrong way.

You’ll end up with 800 disconnected agents. And now, they’re not even on annual contracts—they’re month-to-month.

It’s going to feel like a game of Tetris, trying to make all these things fit. But instead of speeding things up, it’ll slow you down.

Your technical debt will skyrocket. We should put a tariff on technical debt. That should be next.

John Michelsen (46:00.802)
Yeah. Talking about overload…

You triggered one more thought. I know we’re kind of meandering in this episode, but that 800 agents thing—it’s not necessarily a bad thing.

You do want all that capability.

But you better have orchestration—and it can’t be people doing the orchestration.

Going back to episode one or two: people are your current integration strategy.

Everyone’s got tons of tech, and we need to leverage even more. But if we keep integrating the old way—manual, disconnected—we’ll be three times the cost and one-third the speed of competitors.

We all want to deploy tech faster.

Even in our business, we use agents inside our programming IDEs, in data science, in research—everywhere.

And if we didn’t, we’d be moving at a velocity that doesn’t keep up. It would absolutely limit our ability to operate and grow.

Everyone needs to do this.

The key point is: if people are your AI integration layer, that’s the clearest sign you’re going the wrong way.

To make this work, you need a fabric—an orchestration layer. That’s Krista’s mission: to handle that orchestration.

That’s also why bespoke models matter—because they can act without humans needing to sit in between every step saying “yes,” “no,” “go,” “stop,” “enough,” or “not enough.”

Eventually, AI should absorb your organization’s perspective and make those decisions—within guardrails, confidence scoring, and full transparency.

Scott King (48:27.301)
All right, appreciate it, guys. We’ll wrap it up—we could keep going forever.

Thanks for talking through why we actually do want to train AI on our data.

Until next time, see you later.