Hands-On Review: MiniMax Just Dropped Mavis. What Is It?

From Solo Agents to Collaborative Agent Teams

👦🏻 Author: GaKi

🥷 Editor: Koji

🧑‍🎨 Layout: NCon

In the first few months of 2026, every foundational AI model company has converged on the same product direction:

Moving from solo Agents to collaborative Agent Teams.

Two nights ago, Claude Code dropped version 2.1.139. The headline feature was Agent View — type "Claude Agents" in the CLI and every running session appears on screen, with status, blockers, and decision points all visible at a glance.

Looking further back, other players have also poured heavy investment into optimizing their multi-Agent frameworks. The center of gravity for Agent products is shifting downward from the Prompt layer to the Runtime layer.

This morning, MiniMax joined the fray. The MiniMax Agent desktop app got a full upgrade, rebranded as Mavis — "MiniMax as a Jarvis" — complete with a tech blog.

The update centers on two core changes:

First, Agent Teams is now live.

The desktop app supports multiple Agents working in parallel. You can define role combinations like Leader, Worker, and Verifier, then assign an entire team to long-horizon, complex tasks.

Second, TokenPlan and Agent Plan are merging.

One subscription covers CLI, API, and Agent access, bundling all models — M2.7, music, video, voice. Credits are shared between Agent and API usage. Users who were previously subscribed to both plans get an extra free month.

---

Next, we'll walk through a complete multi-Agent e-commerce site build to test-drive Mavis's Agent Teams, sharing our hands-on experience and observations from the tech blog.

Building a Smart Home E-Commerce Site with Mavis

We designed a relatively complex integrated task to see how Agent Team performs on a realistic workflow.

First, download the MiniMax Agent desktop app here:

agent.minimaxi.com/download

After installation, you'll see a default Agent already configured — called Mavis.

The left sidebar of the desktop app shows your Agent list, with each Agent mapped to a fixed role. The system comes with three defaults; adding your own is straightforward — just fill in a name and a role description. You can create multiple Agents at once, then assemble them into an Agent Team.

I added one called Leader. Its job is to break down project workflows, delegate subtasks to other Agents, monitor progress, and control stop-and-deliver checkpoints at each stage.

Each Agent can also be assigned its own working directory. This gives different Agents distinct local contexts, which eventually get stitched together into a unified run.

The task we assigned to the Agent Team was a fairly complete one: autonomous research on the North American smart home market. The workflow spans several workstreams — market research, product information gathering, frontend development, and site deployment — each assigned to different Agents.

Here's the verdict. The most critical update in this desktop release is Agent Teams. Compared to the previous single-Agent mode, it can spin up multiple Agents to execute in parallel, with tighter handoffs between them. One particularly key role is the Verifier Agent, included by default, which reviews how other Agents executed their tasks and flags any issues.

After issuing the "North American smart home e-commerce site" task, the system first inventories all configured Agents, determines which ones are relevant to this task, and assembles them into an Agent Team.

Next comes task decomposition. Mavis slices the overall task into subtasks based on the prompt — for example, assigning market research to Worker Researcher, while frontend development, product data collection, content writing, research, and verification each go to their respective Agents.

Once decomposed, subtasks are first routed to the Leader for initial node review, then read and executed as assigned.

When tasks actually start running, you can see market research, frontend development, and backend development proceeding in parallel. Two other tasks wait for preceding nodes to reach a certain state before launching. For instance, "30 product data entries" doesn't start until market research completes.

The market research report was done in considerable detail. Market size data came from industry reports like Fortune Business Insights and Global Growth Insights; brand and pricing data was sourced from publicly available official information on platforms like Amazon; user pain points were drawn from publicly available user feedback analysis reports. Every data category included a source citation.

Throughout the execution, what stands out is that Mavis placed greater emphasis on "verification" this time around.

Previously, in single-agent mode, one agent served as both executor and reviewer — it would run the task and then self-verify, usually marking itself as passed and moving straight to the next step. If something went off track at any point, the entire downstream chain would derail along with it.

This version operates on a cycle-based logic: after each cycle completes, it triggers a verification checkpoint where a Verifier Agent inspects the entire batch of tasks. In this run, three tasks failed verification — some due to programmatic issues, others content-related. Once flagged, the corresponding agents reworked or redelivered those specific tasks.

The next cycle only begins after the decision is confirmed and submitted. In Cycle 2, Market Research gets re-verified, the frontend portion gets redelivered, and testing continues to fill in the gaps.

"Decision submitted. Cycle 2 launching shortly."

By this round, all frontend pages — homepage, product listings, shopping cart, navigation bar — are complete and verified.

Product data undergoes multiple rounds of testing and revision. The final fields are quite granular: product name, price, data source, website description, plus细分 dimensions like region. Compared to earlier versions, these data points were finalized only after multiple rounds of Verifier checks.

There's another interesting detail worth noting about the actual execution flow.

Traditionally, most agent conversation flows work like this: while the agent is executing a task, you can't interject — if you want to add a requirement, you have to pause and wait for it to stop first.

Mavis handles this differently. While the agent is working, you can check progress, confirm details, or drop new requirements into the conversation at any time. The two streams don't interfere with each other; the agent naturally absorbs new requirements into its current task queue.

The final website turned out quite polished. The overall style features pink color-blocking with bold black outlines — very modern. Functionally, it includes a main login page, main landing page, product introductions, add-to-cart functionality, and an FAQ support section. The product images are real assets gathered by the agent itself, complete with various tags.

On the product side, the agent had already researched mainstream North American brands early on — Google's Nest series, for example. Each product comes with a description, spec tags, pricing, and even links to corresponding external product pages, with one-click add-to-cart functionality.

For checkout, there's a complete demo checkout flow with free-form cart building, plus a lightweight backend database:

Additionally, this version of Mavis supports direct integration with IM tools, and the setup process is straightforward:

Three Notable Points from the Tech Blog, Plus a Subscription Model Change

After running this test, I went through the Tech Blog MiniMax published today in full. The complete blog is on Zhihu, link below:

https://zhuanlan.zhihu.com/p/2037877345634276836

There are some small but notable highlights in the blog that also reflect the team's underlying thinking.

[1] The most critical line: Multi-agent systems are runtime, not prompt orchestration.

Real team collaboration has to answer questions like "who assigns tasks, what happens when someone gets stuck, who signs off when it's done." Prompt layers can only enforce soft constraints — you need a continuously running engine behind the scenes to actually make this work.

MiniMax calls it the Team Engine — essentially the same thing as OpenAI's Agents SDK, Google's ADK, and Claude Code's Agent View.

You could say the center of gravity for Agent products has shifted from the prompt layer to the runtime layer — by May 2026, this looks more like industry consensus.

The impact on users is fairly direct. For the past two years, discussions around Agents have been somewhat led astray by the term "prompt engineering," as if getting the prompt right meant you were halfway done. But when it comes to long-horizon tasks, no matter how detailed your prompt is, it can't stop the model from overflowing or getting confused across multiple steps.

Prompts are more like scripts; runtime is the environment that executes them. A well-organized script means little if the environment is unstable. The fact that vendors are collectively placing heavy bets on the runtime layer this year brings one added benefit for ordinary users: you don't need to know much about prompts anymore, and long tasks still have a shot at running reliably.

[2] A single Agent can't be both referee and player.

Worker and Verifier have opposing objective functions — the Worker wants to finish, the Verifier wants to find flaws — and they don't share context. This design resembles a feedback loop in control theory: two opposing forces constrain quality within a stable band.

The fundamental problem with a single Agent is precisely this: being both referee and player is a conflict that monolithic iteration can never resolve.

This point resonated with me. In many Agent products, the Verifier role feels more like a "courtesy stamp" — that's the closest analogy I can think of.

The Agent validates its own work, but the validation results are often skewed by the model's inherent biases, missing most serious errors and rarely sending anything back for rework.

The reason is simple: it shares the same context and judgment criteria as the Worker, so the Worker's output always looks reasonable from its perspective. Mavis's approach this time was to change the Verifier's objective function to "find problems" and add context isolation.

From another angle, it's like no longer letting a PM self-review within the team. The most direct impact on users is that in real business scenarios, the Agent's work efficiency and the value it delivers become noticeably more tangible.

[3] Multi-Agent setups incur three types of costs that single Agents never face: handoff costs (information must be reorganized between Agents), sharing costs (full sharing blows up the context window), and aggregation costs (there's no shortcut to synthesizing ten outputs into one coherent deliverable).

Multi-Agent without structure, without validation, without stopping conditions just parallelizes uncertainty. So Team isn't the default option — it's a strategic option. The more complex the task, the longer the chain, the higher the risk, the more worthwhile it is to deploy a Team.

Sending an Agent Team to fix a typo is a waste.

This is one of the more candid sections of the tech blog. The multi-Agent concept has been discussed a lot over the past year, and the intuitive appeal is "more Agents, smarter system." But as the paper Cost of Consensus noted, unstructured multi-Agent setups can consume 2-3x the tokens of single-Agent self-correction, without necessarily improving accuracy.

By spelling this out themselves, MiniMax is essentially reminding users: Team is a tool with higher costs and higher returns, and it belongs in the right scenarios. This willingness to draw boundaries feels more reassuring than piling on features.

It won't encourage you to run everything through Team, but it will help you identify which tasks merit it and which ones a single Agent can handle just fine.

---

Subscription Restructuring

Coinciding with this Agent Teams launch, MiniMax merged its two previously separate subscriptions — TokenPlan and Agent Plan — into one, a bit of streamlining.

The changes after the merge, as I understand them, are as follows:

[1] One subscription, all endpoints connected. CLI, API, and Agent desktop — all callable under the same subscription.

[2] All models included. M2.7, music, video, and voice — all core models are bundled into this single subscription.

[3] Shared Credits. The same quota can be freely allocated between Agent and API. If you want to run a long task through Agent today and build a custom tool with API tomorrow, the same quota is yours to distribute.

[4] Previous dual-subscription users get one free month. A little extra perk for existing users.

Viewed alongside the Agent Teams launch, the logic is fairly clear.

Multi-Agent collaboration is inherently more expensive than single-Agent — we already covered the three new cost categories: handoff, sharing, and aggregation.

If the two subscriptions remained separate, users would hesitate before every Agent Team run: will this long task burn through my Agent Plan quota? Should I save some for API development? Getting too granular with the math makes people afraid to use the product freely.

After the merge, that math gets much simpler.

Behind one subscription, the logic of model payment (API, CLI) and product payment (Agent desktop) is unified, with quota freely movable across both sides. You can run concrete tasks through Agent Team, then use the remainder via API for fine-tuning — same Credits, self-allocated, no account-switching, no budget-splitting.

For developers and power users, this raises the freedom bar by a notch: how capabilities get used, and when, is now a decision left to users.

For MiniMax, it's also a pragmatic choice: rather than letting users weigh two billing systems back and forth, combine them into one pool, reduce decision friction, and users will actually feel free to use the product.

---

🚥

In the week of May 2026, Claude Code launched Agent View; MiniMax launched Agent Teams. Looking back, there's OpenAI's Agents SDK, Google's ADK, AWS's Agent framework.

Virtually all foundational AI model vendors, at nearly the same moment, have collectively shifted attention to "how a group of Agents can collaborate stably."

When single-Agent ceilings on long-horizon tasks are already being hit, the next differentiation will almost certainly come from runtime.

These are the new dimensions of Agent product competition in 2026.

Back to Mavis's update itself — after running through the full e-commerce demo and reading the tech blog, what stood out was the prominence of the Verifier. Over the past six months, "verification" has been an optional module in most multi-Agent products.

In this version, Mavis hard-codes it directly into the Cycle: mandatory verification after every round, with retries if it doesn't pass. It looks like they're adding cost to themselves, but in practice, stability on long-horizon tasks actually improved.

The old single-Agent problem of "being both player and referee" gets solved at the architecture level, not through prompt patches — and efficiency may have actually improved as a result.

Another tangible change: Mavis now feels more like a persistently online work group. While Agents are running, users can jump in anytime to add new requirements, and the Leader automatically routes them to the right Worker. This is technically difficult to pull off, but the difference in user experience is significant.

Overall, Mavis is taking a "heavy runtime" approach as MiniMax's answer to the "multi-Agent collaboration" direction.

Whether this answer is complete or actually good to use — I'd recommend trying it yourself.

Link:

agent.minimaxi.com/download

Crossing is looking for independent writers to cover AI product and model reviews.

If you've written pieces like "Hands-on with PixVerse C1" or "Hands-on with LibTV," please reach out to zeo0811@gmail.com. Your email should include: ① a brief bio, ② AI review articles you've written.

We offer competitive rates. Looking forward to observing and documenting the AI era together 🎪