A training gym
for AI agents.

We’re building a training gym for AI agents.

Inside our simulated environments, AI models can practice real enterprise workflows using tools like CRMs, ERPs, and spreadsheets. They can attempt tasks, fail, receive feedback, and improve over time.

The idea came from my work at xAI. I left five weeks ago, and before that, I spent six months on the Grok Enterprise Post-Training team.

One project involved helping Morgan Stanley train Grok on complex financial workflows. For example, we might give the model a balance sheet in which the final number is off by 3% because of a currency-conversion issue. The model then has to investigate the spreadsheet and figure out exactly what went wrong.

This isn’t a one-shot question. Solving it requires multiple steps across different files and tools. Like any machine-learning system, when the model encounters workflows outside its training distribution, its performance drops significantly.

To train the model on these workflows, we first had to interview accountants at Morgan Stanley and identify around 30 tasks they perform regularly. Then we manually created Docker-based sandbox environments containing mock spreadsheets, mock Salesforce data, and all the tools the model needed to complete those tasks.

But out of those 30 tasks, only six were useful for reinforcement learning. Some were too easy, so the model always passed. Others were too difficult, so the model always failed. Only six were near the model’s capability boundary, where reinforcement learning could actually help.

After one round of post-training, those six tasks often became too easy. We then had to create another set of challenging tasks and repeat the entire process.

We encountered the same problem when building workflows for companies like PayPal and law firms such as Gibson Dunn.

At xAI, I proposed automatically generating these environments and continuously testing models to find tasks at the edge of their capabilities. The project wasn’t funded because maintaining thousands of MCP integrations, CLI tools, and simulated versions of constantly changing enterprise software would require a dedicated team.

But my manager strongly believed in the idea, so I decided to leave and build it independently.

We’re now getting feedback from people who worked directly on this problem. Nikunj from the Grok Enterprise Post-Training team is reviewing our iterations, and Boyan, a former colleague who joined Reflection AI, is helping validate our generated data. Mercor has also approached us about using our API to accelerate its simulation-creation process.

The process is still extremely manual.

Mercor has a network of around 50,000 specialists. It asks these specialists to describe approximately 10 tasks they perform in their jobs every day. Engineers then translate those descriptions into simulated environments containing mock data, tools, tasks, and verifiers.

That requires both domain experts and engineers. It is expensive, difficult to scale, and can take months before an environment is ready for training.

We provide ready-to-use, domain-specific simulation environments for training AI agents.

Each environment includes:

• Realistic mock data
• Mock MCP servers and CLI tools
• Training tasks
• Deterministic verifiers
• Different levels of task difficulty

Our key insight is that we can create high-quality environments without requiring a domain expert to manually design every task.

We begin by constructing a simulated world with realistic tools, data, and relationships. We then build a tool-correlation graph that captures how those tools can interact.

From that graph, we generate a valid sequence of tool calls. Because we already know the correct sequence, we can work backward and generate a realistic user request that requires the model to follow that workflow.

We then apply a realism gate: Does this request make sense? Is it something a real employee might ask an AI agent to do?

Because the expected state changes are already known, the verifier is deterministic. We can automatically determine whether the model completed the task correctly.

This lets us generate large numbers of realistic, verifiable training tasks much faster than the current expert-driven process.

We can—and that could be our initial entry point.

But selling one manually built environment only proves that a customer will pay for an environment. It doesn’t validate the most important part of our business: whether we can continuously generate high-quality environments at scale.

The deeper pain point is not creating the first set of tasks. It is what happens after the model trains on them.

Once post-training is complete, many of those tasks become too easy. The customer immediately needs a new set of tasks at the model’s new capability boundary. Today, it can take three to six months to create, implement, and validate the next environment. That slow iteration cycle is also why each environment can cost $40,000 to $50,000.

What customers really want to know is:

“Can you continuously generate new environments and tasks as the model improves? How quickly can you do it, and is the quality comparable to environments designed by human experts?”

That is what we are validating with researchers and engineers at xAI and Reflection AI.

In one of our first experiments, we generated 2,000 domain-specific environments and used them to train a 14-billion-parameter model. In our initial results, the trained model outperformed a much larger DeepSeek model on the MCP benchmark.

We are now presenting those results to AI labs as evidence that automatically generated environments can produce meaningful improvements—not just save time and money.