Model-as-product has, by now, become model-as-agent.
The unique advantage a model company has in building agents is that it can co-design the agent harness and model inference inside a single team. Every decision on the harness side - how the system prompt is written, how tool calling is organized, how errors are handled - directly affects the cache hit rate, scheduling efficiency, and token consumption on the inference side.
MiniMax's past year of agent work started as an internal Feishu (Lark) bot, evolved into a desktop app called MiniMax Code, and finally closed into a training-and-serving loop: the model trains inside its own harness, serves users through that harness, and user behavior becomes the training signal that feeds the next model. That loop is the core logic of how a model company designs agents.
In his talk at AGI Playground 2026, Vincent Wu, who leads Developer Relations at MiniMax, laid out how a model company sees the relationship between model, inference, harness, and agent, and shared what the team has learned building agents over the past year.
Compiled and edited from his conference talk.
01 · The MiniMax agent began as an internal "Agent Intern"
What I want to share today is how we, inside a model lab, think about agents.
The model is our product; that has never changed. The question is: why does a model company need an agent at all, and how should it design its own? We've spent a year on this and moved through several stages.
The earliest was around May or June of last year, when we built a cloud agent (agent.minimax.com), similar to Manus, with its own Linux sandbox and virtual machine that could build websites for users. It used traditional tool calling, but it could already operate the sandbox and run shell scripts. That one was more of a demo.
What really rooted the agent inside the company was something we called the "Agent Intern." It surfaced as a bot inside our everyday office software. From the start, the Agent Intern wasn't just for engineers - everyone at the company used it: engineering, HR, marketing, finance.
Sales faces prospects in different countries every day, and every message has to read differently, so they had the Agent Intern research each person's background, look at what they'd posted before, and generate personalized copy. The designers' use was more direct: they'd vibe-code in Cursor, resolve design-fidelity issues in a code branch, and hand it to the front-end team. Product and support were messier - the Agent Intern helped PMs handle user-complaint emails, pulling the back-end task trace, judging whether the credit consumption was reasonable, suggesting a refund proportion, and then sending the email to execute it. The compute-platform team used it constantly to analyze alerts, since the alert metrics for large-model inference move very fast. The data-analysis team said it replaced the traditional SQL-writing part of their work; HR used it to search schools and screen résumés, a 10x jump in efficiency. Others used it to write code automatically - finish the requirements list, and the agent writes the implementation entirely on its own.
The most interesting change, to me, was in mindset. One engineer put it well: "What we're really doing is having the agent - our intern - create an intern that can do the job." They were no longer an engineer, but something closer to a leader. We call it an intern for now, but we think one day it will be like a digital employee.
These internal practices pushed the next step. We found the cloud agent wasn't enough - a lot of workflows actually live on the local machine. So we turned it into a desktop app, released as MiniMax Code, which can control the user's computer but doesn't require you to be an engineer to use.
At the same time, we found that the M2-series models - especially M2.1 and M2.5 - worked well with third-party open-source harnesses, mainly OpenClaw and Hermes. We worked closely with those communities to tune the models' performance inside them. The reason is that MiniMax's models are generalist: not just good at coding or math, but also at operating a computer and handling managerial tasks, and cost-effective on top of that.
Which brings us to today: our new model, MiniMax M3, and MiniMax Code.
02 · How the agent helps optimize and iterate on the model
Before I get to how the agent helps with training and serving, let me answer a simple question: what does a foundation-model company actually do? It comes down to two things - train models, then serve them.
The inputs to training are compute, data, gyms (training environments), and training algorithms. The inputs to serving are compute plus inference algorithms. Having the model weights and a few GPUs doesn't mean you can serve the model; there's a lot of hard engineering behind inference serving.
The agent fits into this in two ways. The direct way is to have the model help us with R&D - writing better training algorithms and better inference algorithms.
Start with the direct way. When we released M2.7, we shared that the post-training team's workflow breaks roughly into five steps, of which two - running experiments and analyzing them - can be done entirely autonomously by M2.7. The remaining steps aren't fully automated, but all of them are AI-assisted.
More importantly, the harness code used to do this research was itself written by M2.7. Not by humans. M2 wrote the agent's code, and then, through that agent, carried out recursive self-improvement tasks.
Why does this help so much? Before agents, a researcher's time was serial: propose a hypothesis, run the experiment by hand, spend a lot of time debugging - because these experiments are hard to run - get the result, then propose the next hypothesis. Most of that time wasn't spent thinking of new ideas; it was spent debugging.
With a research agent, the tedious-but-hard work of running and debugging gets taken over. Researchers can spend more time proposing new conjectures and debating the right direction with each other. This is a structural change: it's not that you go faster, it's that you can run more ideas at once.
Direct R&D is only half of it. The more interesting part is the indirect way - using the harness to connect training and serving into a closed loop.
The logic is this: real users do real tasks through MiniMax Code; our harness collects these messy, long-horizon workflow traces and environments; and then, through a lot of data engineering, we turn them into repeatable, scorable gyms for reinforcement learning and other post-training.
Gyms are the next key direction for model training. We've now entered the "era of experience," where it's no longer enough for a model to do well on fixed datasets and fixed math problems; it has to perform in real-world work.
We even have a dedicated team for this. We've hired part-time and full-time experts from fields like finance, law, and medicine, whose main job isn't to label data but to use MiniMax Code and the M3 model within their own professional workflows. That usage becomes real-world, high-value training signal that feeds into the next model's RL training.
That forms a flywheel: the model finishes training, serves users through the harness, collects real usage data, turns it into training signal, and trains the next model. Every turn of the wheel, the model gets better, the data quality gets higher, and the next model gets better still.
03 · What an in-house agent does better than a third-party one
M3 is strong at writing kernel-optimization code. Kernel optimization is the heart of inference serving - the code that binds the model weights to the GPU. Our inference team can use M3 to write better kernel code that serves M3 itself. That's another self-improvement loop.
M3 was itself trained inside MiniMax Code, so it naturally runs better in that harness.
But there's a question fewer people discuss: why should a model company build its own agent harness rather than rely solely on third parties?
Three levels of co-design explain it.
Model-chip co-design is already familiar: design the chip and the model together so the model architecture runs better on the chip. Model-harness co-design is easy to grasp too: the model trains inside a harness, so it naturally performs better in that harness.
But the third - inference-harness co-design - is discussed far less. It means that because both the harness and the inference service are in our hands, the harness can in turn help the inference team optimize serving efficiency.
How? More reliable and cleaner system prompts, progressive disclosure of skills, the right tool-calling patterns, good tool-error handling. These all look like harness-side design decisions, but they directly shape the demand patterns on the inference side. More predictable demand patterns mean a higher cache hit rate, more efficient scheduling, and fewer tokens consumed per task.
This is part of the reason Anthropic doesn't let subscription users run its service inside third-party harnesses. Part of it is branding, but another part is engineering - an in-house harness lets them better control the structure of inference demand.
For users, this means cheaper, faster task execution and fewer errors and rate limits. For us, it means serving more users on the same compute. It's a win-win, and it's something third-party harnesses can't do - they don't have control of the inference side, so they can't do inference-harness co-design.
At our scale, these efficiency gains add up. Compared with relying purely on third-party harnesses, we can reach much higher token throughput.
04 · AGI isn't a single model but the whole closed-loop system
Back to the full picture. The agent helps us on two levels. Directly, it helps researchers write better training algorithms and helps the inference team write better kernels. Indirectly, the in-house harness makes inference serving more efficient while turning real user behavior into training signal.
This loop is tightening. It's worth imagining what the system looks like after it runs for six months, or a year. The model is still the core; from training to serving, everything revolves around the model. The model is still the product. But the harness is now an indispensable link.
My conclusion is that AGI may not be a particular model checkpoint, but the whole closed-loop, recursively self-improving system. You can imagine a day when the entire cycle - from training to serving to data collection and back to training - runs with no human in the loop. The model closes the loop through its own harness and keeps improving itself.
For other model companies, this past year points to at least one thing: the agent isn't an accessory to the model. It's the axle that connects training and serving, the lab and the real world. Design that axle well, and the flywheel turns.
