LatentMAS: multi-agent collaboration that passes hidden states instead of text

The central move: agents pass latent thoughts, not reasoning text

LatentMAS is described as a multi-agent reasoning framework that moves agent collaboration from token space into the model's latent space. The contrast with the usual approach is stated in one sentence. Instead of producing long textual reasoning traces, agents communicate by passing latent thoughts through their own working memory. In a conventional multi-agent setup, an agent that has thought something through has to write that thought out in words, and the receiving agent has to read it back in. Both halves are lossy and both cost tokens. Here the intermediate representation is the hidden state, and the framework's claim is that the collaboration gets cheaper and the reasoning gets more stable as a result. The three headline features follow from that: efficient multi-step reasoning with drastically fewer tokens, training-free latent-space alignment for stable generation, and compatibility with any Hugging Face model and optionally vLLM backends.

What the reported numbers are, and what they are not

The experiments section describes three main tables from the paper, spanning nine tasks across math and science reasoning, commonsense reasoning, and code generation, with Table 1 under the sequential multi-agent setting, Table 2 under the hierarchical setting, and Table 3 on reasoning intensive tasks. The efficiency claim is stated as a reduction of about 50 to 80 percent in tokens and about three to seven times in wall-clock time compared to standard Text-MAS or chain-of-thought baselines. Those are the authors' own figures from their own paper, and the repository does not present them as independently verified results, so a reader should treat them as the paper's claims rather than as a measured fact about your hardware. The gap between the two settings is the interesting part for an adopter, because the sequential and hierarchical arrangements put different pressure on how agents pass state, and the framework supports both.

The repository is a reproduction package, not a library

The repository layout makes the intent clear. There is no package/ or src/ directory and no setup.py, so this is not something you add to a requirements file as a dependency. What there is: run.py as the entry point, models.py, data.py, prompts.py, utils.py, a methods/ directory holding the implementations, a data/ directory, an example_logs/ directory, and an assets/ folder with the figures used in the README. The Getting Started section says the repository provides all code for reproducing LatentMAS, TextMAS and baseline single-agent experiments across a set of tasks including GSM8K, AIME24 and AIME25, GPQA, and the ARC-Easy and ARC-Challenge sets. So the intended use is to clone it, run the scripts, and reproduce the tables. The dependency list is correspondingly short, and it is worth noticing that it is short.

transformers
torch
numpy
tqdm
accelerate
datasets

Training-free means no fine-tuning step, but it also means the backbone must cooperate

The training-free claim is the one that decides the operational cost of this approach. Nothing in the repository needs to be trained, and there is no dataset to curate for a fine-tuning run, which removes the largest cost in adapting a model to a new collaboration scheme. The price is that the alignment between agents has to work with whatever backbone you point it at, since the latent space is the backbone's latent space and two different models do not share one. The framework's compatibility claim, that it works with any HF model and optionally vLLM backends, is therefore a claim about a broad class of backbones rather than about mixing arbitrary ones. The community extensions make the same point from the other direction, with the AVP project enabling agents to share KV-cache and hidden states instead of text, supporting zero-training latent handoff and cross-model transfer, which is an attempt to relax the same constraint.

The ecosystem around the core: five community extensions and one research branch

The README devotes a large section to works built on top of LatentMAS, which is unusual and informative. Science-LatentMAS, by Prof. Markus J. Buehler and the LAMM group at MIT, is on its own branch and extends the framework for scientific modeling and material-system collaboration with flexible agent types. KNN-LatentMAS introduces kNN-based latent retrieval to improve KV-cache usage and stabilise multi-step reasoning. Hybrid-LatentMAS supports heterogeneous collaboration, mixing LLM and non-LLM agents. LatentMAS-SLoRA adds role-specialised, dynamically switchable LoRA adapters. The Awareness Network is a decentralised awareness market product built on the research. The number of independent extensions touching the KV cache, the agent heterogeneity and the adapter specialisation tells you that the community treated the core as a substrate and started pushing on its edges, which is also the best argument for reading the core carefully before depending on it.

Academic positioning: a spotlight paper and a Hugging Face daily paper

The News section dates the project's public history. On 2025-11-25 the paper and the code implementations were released, and the same day the work was featured as the Hugging Face first paper of the day. On 2025-12-15 a batch of community extensions appeared, on 2025-12-20 the Science-LatentMAS branch was announced, and on 2026-02-26 the group published OpenClaw-RL, a fully asynchronous RL framework for training personalised agents from natural conversation feedback, which introduces Binary RL via GRPO and On-Policy Distillation. On 2026-05-01 LatentMAS was accepted into ICML 2026 as a spotlight. The paper is on arXiv as 2511.20639, with slides in the repository and a Hugging Face papers entry. The last push to the repository was on 2026-06-18, there are no GitHub releases, and the licence is Apache-2.0, so the code can be used and modified without restriction, provided the terms are followed.

Where this is weak: a research artefact, not infrastructure

The honest limitations are visible in the structure. There are no tagged releases, so nothing tells you which commit corresponds to a paper result, and the version you clone is the version you get. There is no package structure, so integrating it into a larger codebase means copying files or importing from a checkout, which is a decision a team has to make deliberately. There is no error handling, no configuration schema and no service layer described anywhere in the repository, and the model support is promised rather than enumerated, with the News section promising more model-backbone support to come. The task list in the Getting Started section covers reproducing results across a fixed set of benchmarks. That is a coherent thing to ship and a coherent thing to depend on for a paper reproduction, and it is not the same thing as a component you run in production.

Editorial conclusion

LatentMAS suits a research group that needs multi-step reasoning from a stack of Hugging Face models, wants to avoid the token cost of agents talking in prose, and is prepared to treat an ICML spotlight implementation as a research artefact rather than a supported product. It is the wrong choice if your agents need to be auditable by reading their messages, since the whole point is that they do not exchange text, and a poor fit for a team that needs a maintained library with a stable API, because the repository is a reproduction package for a paper with no tagged releases. Before adopting it, read the paper and the slides linked from the repository, check the Getting Started section for the run instructions, and plan for the fact that the code and the weights have to be matched to a backbone model yourself.

Frequently asked questions

Official sources

1. Gen-Verse/LatentMAS on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README