“Put together a long-form piece on Agent Teams for me — grounded in 2026 data, and delivered as both Markdown and HTML.”For a long time, this is the kind of request you would hand to a capable AI assistant. It would start typing immediately and push a wall of text back into the chat. The flow feels good, but the moment the bar on the deliverable rises, the gaps appear. Who actually does the research? Who fact-checks? Who lays the document out? And next time you come back, will the system remember any of the traps you hit today?
1. Why an Agent Team
You can keep iterating on Skills and push a single agent to deliver well on a given task. But one agent finishing the work alone always means that agent is acting as both player and referee. That contradiction is the entire reason we built Agent Team. Agent Team takes a complex task that used to live entirely inside one agent and reshapes it into a process with a front office, a back office, sign-off, and memory. The user still sends one message. Behind the scenes, the system decides whether the task should be split, which roles can run in parallel, which outputs must be verified, and which lessons should be saved. Back to the example.“Put together a long-form piece on Agent Teams for me — grounded in 2026 data, and delivered as both Markdown and HTML.”A single agent might pull this off — like a teammate sitting next to you. You ask “how can we polish this paragraph?” and it edits on the spot. You point out a formatting issue and it goes to fix it. But a few problems show up. A single agent stops when you least expect it. A common pattern: the agent has seven things to do. After three changes it pauses to report — “I’ve done items 1, 2, and 3; should I keep going on the remaining five?” Why? Models suffer from context anxiety. Training a model to handle truly long-running work takes serious money, time, and algorithmic effort. The model’s own judgment about when a task is “done enough to stop” stays fuzzy.
2. How the industry is doing multi-agent today
3. MiniMax Agent Team: tighten the multi-agent loop, give each agent more freedom inside it
Our Agent Team is a multi-agent system led by one main agent. It breaks a complex task into several jobs that can run in parallel, hands them out to a batch of agents, and bakes adversarial quality gates into the loop — all driven by deterministic code rather than vibes. We took inspiration from Ralph Loop and the Harness school of thought. The model’s context is precious. Splitting tasks and classifying responsibilities lets us isolate the context for each step, which raises the quality of the whole pipeline.
- Leader translates a user goal into a task structure.
- Worker runs the actual sub-tasks. Different workers can carry different tools, contexts, and output requirements. One worker handles research; another edits code. The value of a worker is specialization. The clearer the role, the easier its output is to reuse, compare, and check.
- Verifier turns “done” into “ready to ship.” It checks sources, coverage lists, risk boundaries, and pushes back on a worker’s result with revision requests.
task / dispatch / spawn tool, hands over a prompt, and waits for a sub-agent to return a chunk of text or a summary. That mechanism fits short-lived, low-risk, exploratory work — have another model search files, summarize material, sanity-check an idea, generate a few candidate answers. Background sub-agents exist today, but the agent-to-agent communication is still one input and one output. Real conversation isn’t supported, and live escalation of problems and contradictions isn’t either.
To make a team run reliably, we built the Team Engine: a state machine that manages every agent’s run cycle, where one cycle is a Session. Team Engine moves each task through producing → verifying → done. When verifying fails, it wakes the producing node up again to revise. Throughout, the Leader receives status updates from the engine, can actively check on a specific task, and can even push extra prompts to a producing or verifying agent that’s currently running. Collaboration stops being a single function call and becomes multi-turn interaction with both proactive push and on-demand pull.
Every Team run carries long-term value. The experience from this run gets saved as memory or distilled into a Skill, so each agent gets sharper at understanding the user, working with the user, and finishing the job efficiently.
3.1. Core scenario: IM access, async execution with a fast acknowledgement
IM has a strange constraint. When you send a message, you expect a reply in seconds. But plenty of tasks naturally take minutes or hours: research, meeting notes, slide decks, a code test run. If the system makes you wait for the final result, the experience turns into “the agent disappeared in the chat thread.” A single agent gets stuck between two bad choices. Reply fast with a shallow answer, or finish the work properly and leave the user in the dark for a long time. Worse, the IM thread keeps moving. The user might add a follow-up, switch topics, ask a separate question. If the long task and the live chat share one context, the system can’t stay responsive and can’t keep the background work clean of the new messages. This lines up with what Google’s A2A protocol describes for long-running tasks, status updates, and human-in-the-loop, and with the Anthropic Managed Agents post making the point that “session is not the model’s context window.” Long tasks need a recoverable session log as an external context object. The industry consensus is converging on the underlying logic for IM async execution. When a task spans multiple message rounds, multiple tools, and multiple agents, you cannot rely on any single model context staying intact the whole way. The system has to persist task state, event logs, file artifacts, and decision records as recoverable objects. Agent collaboration is stateful, long-running work.3.2. Core scenario: Coding Harness
The Agent Team project owes a lot to the Harness school of thought. Harness pushes one step beyond “the agent writes code”: the agent should follow the full development lifecycle. Code lives on a branch. Execution runs in a sandbox. Edits show up as diffs. Tests can be re-run. Reviews leave a record. Failures can be replayed. When it makes sense, the work gets split across different roles. The agent’s stop conditions get bound to deterministic, observable external systems. Splitting coding work into Developer / Tester / Reviewer An engineering-grade Coding Harness needs at least four roles.- Leader is the control plane. The first call it makes is whether the task is even worth a Team: fixing a typo or swapping a constant is cheaper for a single agent or a small script; cross-file understanding and exploring multiple plans in parallel is what justifies a Team. Then it decides granularity — read the code first or not, explore options in parallel or not, write a reproducer test up front or not, retry how many times after failure, when to escalate to a human.
- Developer implements. It carries an explicit brief: requirement, relevant files, project constraints, and the things it must not do. Its output is more than prose. It includes the rationale for the change, the risks it sees, and how to verify.
- Tester turns “looks like it works” into “we have external evidence.” It locates the existing test entrypoints, compresses failing logs, and writes minimal reproducers when needed. The point is to stay tool-grounded: verification comes from a command, a test, an executable check.
- Reviewer and Tester aren’t interchangeable. Tests answer “does the existing verification pass?” Review asks “should the change look like this at all?” It checks abstraction boundaries, compatibility, error handling, new dependencies, permission expansion, secrets in logs. Reviewers can fan out: a general reviewer for maintainability, a security reviewer for inputs / credentials / network boundaries, a domain reviewer for business semantics.
3.3. Core scenario: parallel information retrieval and research
A single agent doing research hits familiar problems: slow, context that gets polluted or hostilely injected, evidence chains that get lost in the buffer, biased framing of the question. Agent Team’s value here is to split research into parallel information channels and merge them into structured conclusions through verifiers and synthesizers. We focused on building a trustworthy research pipeline — fast research that still escapes the framing of any single agent, gathering and verifying information from multiple angles and from both sides of the question. How an independent verifier reduces citation errors and factual hallucinations The verifier first checks whether sources are re-checkable. Formal sources should sit on stable URLs: official pages, conference pages, the author’s blog. Search caches and aggregator pages can serve as leads to find the real source; they shouldn’t carry the weight of a formal claim. The verifier also checks whether sources have gone stale, and whether counter-evidence exists that would invalidate the claim.3.4. Core scenario: pipeline-style office-document writing
The seductive illusion when a single agent writes a document is: if the model can write, it can deliver. You say “make me a report / Excel / PDF” and the agent generates a wall of text, then tries to do layout, format-checking, and bug-fixing in one shot. Short documents survive that approach. The moment you move to a long report, a formal contract, a financial spreadsheet, the cracks open: content planning, citations, structural consistency, chart objects, headers and footers, export quality — all crammed into the same context and the same execution loop. Agent Team takes the result from “produced” to “delivered” Multi-agent collaboration breaks document delivery into verifiable stages. Planner defines the document’s goal and structure. Writer handles the body. Formatter handles layout and the file object. Evaluator independently checks content, format, and file integrity. The split turns “document generation” from a one-shot text generation into something closer to a CI/CD build pipeline: each step produces an intermediate artifact, each step has a check, each step can retry locally on failure.4. Hard parts and lessons during the build
4.1. The context costs that team collaboration creates
Once a group of agents starts collaborating, a new class of cost shows up: handoff cost, sharing cost, aggregation cost. None of them go away by giving the model a bigger context window. Handoff cost is what it takes to reorganize the same information for the next agent. The research agent comes back with a few dozen web pages and hands off to the writing agent — the writer needs a pre-digested research document, with the raw pages already filtered down. The writer in turn hands a draft to the format-check agent. We handle this with two artifacts: (1) readable handoff files, and (2) a shared bulletin board across multiple agents. Workers communicate slowly and without interruption through file paths plus summaries, which keeps upstream content out of every downstream context. Sharing cost is the price of letting every agent see everything. Each extra shared block costs every worker tokens on every turn. When an agent runs into a problem mid-execution, it should write that into memory the right way so the lesson can broadcast to every running and queued agent. We maintain shared information through three channels:- In-agent memory: one experience for that agent — future runs of the same agent get a hint, and a currently running run can be notified immediately.
- The agent-to-agent communication CLI: an agent can talk directly to another running node and interrupt it.
- The bulletin board mentioned above; compared to (1) and (2), it holds larger volumes and lets other agents pull what they need on demand.