Fixing the Bottleneck in Enterprise AI with Tommy Guy (CEO of Enderis, ex Research at Microsoft)

As Director of Research at Microsoft, Tommy Guy led fine-tuning and agent evaluation work for Copilot Studio. Training data was the problem he kept coming back to. Make a task too easy and the model has little to learn. Push the difficulty too far and it may never find a successful answer to learn from.

Tommy is now Founder and CEO of Enderis, a startup working on agent alignment. He sat down with Olga, Toloka’s CEO and founder, to talk about the partnership with Microsoft, what it taught both teams about training and evaluating agents, and why so many enterprise AI projects stall before they ship.

Editor’s note: This conversation was recorded before Tommy’s company changed its name. In the video, he refers to it as Prussic; it now operates as Enderis.

Data on the edge of what a model can do

Copilot Studio lets businesses build their own agents. Those agents often have to work with complex enterprise software that has little public documentation. Some of these systems are so configurable that, as Tommy puts it, “no two Salesforces are the same in the world.” His team knew early on that reinforcement learning would be needed to improve performance. The hard part was finding the right data.

The breakthrough came over a conversation with Olga in the Microsoft cafeteria. RL data needs to sit “right on the horizon of what that model can do.” Tommy explains: “If it’s too easy, you don’t train. If it’s too hard, you can’t train.” Toloka’s data went on to become “the backbone” of the team’s reinforcement learning efforts.

The team was also early to a shift that is now common across the industry. They weren’t trying to make a model better at everything. They wanted it to be better at specific customer tasks. That opened the door to smaller, cheaper models that could match a large model’s performance where it mattered. “I think everybody’s caught up to that cost consciousness,” Tommy says.

Why fully synthetic data still falls short

Tommy has tried more than once to automate the creation of training data. In one experiment, he gave Claude examples that had become too easy and asked it to make them harder. Some of the revised tasks ended up with two valid answers, but the grader accepted only one. Correct responses were marked as failures, so the tasks looked more challenging than they really were.

“Your data looks Goldilocks, but it’s not,” he says.

Realism is a problem too. Synthetic data often has different statistical properties from what agents see in production. “Real emails are short. Real emails don’t have punctuation,” Tommy notes. Models resist reproducing that kind of messiness. In a hybrid pipeline, the most valuable human contribution may not be inventing scenarios. It may be making the data look like real human output.

Verification is the hard part

Olga summed up a theme that ran through the conversation: generating anything is now easy, and verifying it is hard. “Every project starts with finding those we call QA, the highly trusted human experts,” she says. Until that layer exists, automation has no reliable check. Human-written data needs the same scrutiny, since people fall into familiar patterns too. As Tommy puts it, with purely human data “QA does not go away. It’s just different.”

Grading open-ended tasks is especially demanding. Someone asking for a rental income projection won’t say which spreadsheet cell should hold the answer, so the evaluator has to understand the output before it can check it. AI graders can help, but in Tommy’s view an evaluator that is 80% correct isn’t good enough. False positives and false negatives make training more expensive and blur the signal. “You don’t know anymore if your product is broken or if your grader is broken,” he says, and when his team investigated, it was often a coin flip which one it was.

One fix is to break grading into a series of simple yes-or-no questions the model can answer without guessing at intent. Olga added that the choice of grader shapes everything upstream of it. Forcing tasks to have exact, deterministic outcomes changes which cases get selected and how the data is produced.

“Fine-tune for what?”

Many companies now offer RL as a service. Tommy argues the underlying mechanics have become a package: if you have the GPUs, adjusting model weights is solved. “Building the evals did not get easier,” he says. For most companies the return on fine-tuning isn’t there yet. The reason isn’t the training. It’s that building data that moves the model in the right direction is still very hard.

Often the simplest problem is the biggest one: nobody told the agent what they wanted. Take an agent managing a CEO’s calendar. How long should a one-on-one be? It depends on the company’s culture, and an urgent request from the chief legal counsel may get as much time as it needs. A human chief of staff knows these things. The agent has to be told. “There is an answer that you had in your head,” Tommy says. “You’re making the agent guess.”

He compares this to how a Boeing 747 gets built. No single person knows how to build the whole plane, but thousands of people together do, and most of what they know was never written down. Automating work means drawing that knowledge out of the people who carry it.

When evals define the product

That’s the gap Enderis is built to close. Working with forward-deployed engineers and subject matter experts, the team builds offline test suites tailored to each agent. These tests work like end-to-end tests in classic software and run every time the agent changes. “The evals become the definition of your product,” Tommy says.

The aim is to draw out unwritten rules naturally, without asking people to write long specifications. An expert reviews what the agent did, spots something wrong, and explains why. That explanation becomes a test. Many experts will never hear the word “eval.” They’ll just know they are finally telling the agent what they really meant.

Tommy also explained why Enderis plans to work with Toloka: the team pushes back. “You’re opinionated,” he says. “The customer is not always right.”

Putting the data to work with ThinkingBox

At Microsoft, Tommy’s team ran its RL jobs through ThinkingBox, a lightweight agent harness of about 200 lines of Python, with features such as user impersonators. Toloka delivered data in the format ThinkingBox expected. The team then realized it could swap in the real orchestrator and run the same evals against the live product, turning its training data into a way to test the product.

Microsoft has open-sourced ThinkingBox along with ThinkingBox-Bench, built in partnership with Toloka. The benchmark has 507 tasks across five business domains. Some are tool-heavy, such as retail returns; others, like insurance, focus on interpreting policy documents. Different models led on different task types, and fine-tuning sometimes improved one area without moving another. Inside Microsoft, the set became a go-to holdout, known among the team as the “Toloka 500.”

The benchmark has held up. When the team started, GPT-4.1 scored around 14%. Today’s leading models, including Opus and Fable, score in the 80s. That spread shows the data hit the right difficulty level, and that there is still room to improve. As Tommy told Olga, Toloka’s challenge is that “every time you do your job well, doing your job again gets harder.”

Watch the full conversation

Watch the full interview to hear Tommy and Olga discuss Goldilocks data, the limits of AI graders, buy-versus-build decisions, and why evals may become the clearest definition of what an agent is supposed to do.