AgentScope: The Erlang-for-Agents Framework Nobody in the West Has Heard Of
Twenty-six thousand stars, two thousand forks, and a distributed-first architecture that ships fault tolerance at the message layer. The most popular multi-agent framework you have never seen a single tweet about.
If you follow AI agent tooling on Twitter, you have heard of LangGraph, CrewAI, and AutoGen. You have probably also heard of Letta, Smolagents, and Atomic Agents by now, assuming you have been reading the right people. Here is a name you have almost certainly not heard: AgentScope. It has 26,000 GitHub stars. It has 3,000 forks. It was built by Alibaba’s DAMO Academy, released as Apache 2.0, and just shipped version 2.0.1 on June 5. It is the most popular multi-agent framework in China and, for practical purposes, invisible to the English-language AI tooling discourse. That invisibility is interesting not because AgentScope is a hidden gem you should drop everything to adopt. It is interesting because the architecture it chose, message-passing distributed agents with fault tolerance at the runtime level, is the architecture most Western agent frameworks are still talking about as a future milestone.
The core idea is not complicated to describe but it is genuinely different from what most Python agent frameworks do. In LangGraph, agents are nodes in a graph and they communicate by sharing state through the graph’s channels. In CrewAI, agents are objects in a process and they communicate by passing structured task outputs back to a coordinator. In AgentScope, agents are independent processes that send messages to each other through a message bus. Each agent has an address. Each message has a sender, a recipient, and a typed payload. The agents do not share memory. They do not share a graph. They do not coordinate through side effects on a shared state object. They send messages. The runtime handles delivery, retries, timeouts, and routing. If you have ever written Erlang or Akka or worked with the actor model, this will feel immediately familiar. If your entire mental model of agent frameworks is LangChain wrappers around OpenAI function calls, it will feel like a different category of software.
The distributed story is where AgentScope separates from every Python-first agent framework in the Western ecosystem. Agents can run on separate machines. Not separate threads, not separate Docker containers on the same host, but genuinely separate boxes with different IP addresses. The message bus handles routing between them. When Agent A on machine 1 sends a message to Agent B on machine 2, the runtime serializes the message, sends it across the network, and delivers it to Agent B’s inbox. If Agent B’s machine is down, the message queues. If Agent B is overloaded, the runtime applies backpressure. If Agent B never responds, the runtime hits a timeout and notifies Agent A. None of this requires the agent developer to write networking code, queue management, or timeout handling. The runtime does it, the same way Erlang’s OTP does it for processes and Akka does it for actors. The agent developer writes agent logic. The runtime handles distribution.
This is the architectural difference that matters. Most Western agent frameworks are single-process by design. They assume all agents live in the same Python process on the same machine, sharing the same memory space and the same event loop. You can scale them by running more copies of the entire process behind a load balancer, but each copy is an island. Agents in copy A cannot talk to agents in copy B without you building that plumbing yourself. AgentScope was designed from the start for a world where agents live on different machines and need to coordinate across network boundaries. The message-passing architecture is not a feature bolted onto a single-process framework. It is the foundation the framework was built on.
The Studio is the other piece that distinguishes AgentScope from its Western counterparts, and it is worth describing because it solves a problem most frameworks ignore until version three or four. AgentScope ships a visual Workstation, a web-based drag-and-drop environment where you compose multi-agent topologies by placing agent nodes on a canvas and wiring them together with message channels. You can configure each agent’s model, system prompt, tools, and memory from a panel. You can run the entire topology with a button and watch messages flow between agents in real time, with full tracing of every LLM call, tool invocation, and inter-agent message. The Studio is not a gimmick. It is the fastest way I have seen to prototype a multi-agent system without writing orchestration code, and it generates the Python script for the topology you built so you can take it from prototype to production without a rewrite. The closest equivalent in the Western ecosystem is LangGraph Studio, which is tied to LangGraph Cloud and requires a paid plan for team use. AgentScope Studio is bundled with the open-source framework and runs locally.
The model support is what you would expect from a framework built at an organization that has to support every model Chinese enterprises actually use. OpenAI, Claude, Gemini, DeepSeek, Qwen, Llama, Mistral, GLM, Yi, and essentially every model with an OpenAI-compatible endpoint. The 2.0 release added a unified model abstraction that normalizes these providers behind a single interface, plus YAML config files for mainstream models so you can swap providers by changing one line. The 2.0.1 patch added Agent Team support, which lets you group agents into named teams and treat the team as a single addressable unit on the message bus. An agent outside the team sends a message to the team address and the team’s internal routing logic decides which member handles it. This is the actor-model equivalent of a process group, and it is a pattern that shows up naturally when you start building agent systems with more than a handful of participants.
The framework also ships MCP support, RAG primitives, and a middleware system that lets you intercept agent messages for logging, rate-limiting, permission checking, and content filtering. The permission system is worth calling out separately because it is one of the few examples I have seen of an agent framework treating access control as a first-class concern rather than a footnote. Each agent has a permission set. Each tool has a permission requirement. When an agent attempts to invoke a tool, the runtime checks the permission before executing the call. This is the kind of thing that sounds like enterprise overengineering until the first time your agent tries to run DROP TABLE because an LLM hallucinated a SQL query.
The reputation question is the one I want to address directly because it is the first thing a Western practitioner will ask. Alibaba is a Chinese company. AgentScope is developed primarily by researchers at DAMO Academy in Hangzhou. The code is Apache 2.0, fully open source, with all development happening on a public GitHub repository. The documentation is available in English and Chinese. The 2.0 release was a ground-up rewrite that cleanly separated the framework from any Alibaba-internal dependencies. The supply-chain question for any Chinese-origin open-source project is whether it will still be maintained in six months. AgentScope has been shipping consistently since January 2024, with twenty-three releases in the past twelve months and a contributor graph that spans both academic and industry contributors across multiple organizations. The commit velocity is higher than most Western agent frameworks I track. The bus-factor risk is real in the sense that the core team is concentrated, but it is no higher than the bus-factor risk for a startup-funded agent framework with three engineers. You should make your own judgment about supply-chain trust, as you should for any dependency that touches your LLM calls and your tool execution. The technical architecture does not depend on any Alibaba cloud service. It runs on your infrastructure.
The comparison that structures itself is with the Western agent frameworks that have attempted distributed multi-agent coordination. AutoGen, from Microsoft, has a group-chat pattern where agents communicate through a shared conversation managed by a group-chat manager. It is conceptually similar to AgentScope’s message-passing model but implemented as a single-process pattern with no native cross-machine distribution. CrewAI’s hierarchical and sequential process types are coordination patterns inside a single process. LangGraph’s multi-agent patterns all assume agents live in the same graph on the same runtime. AgentScope is the only framework in this comparison where putting agents on separate machines is a design goal rather than a future roadmap item. The cost of that decision is that AgentScope requires you to think in terms of message-passing and addresses rather than shared state and graph edges. The benefit is that your multi-agent system scales horizontally without a rewrite.
The question the article title is designed to provoke is whether an architecture that treats agents as distributed message-passing processes is actually better than the shared-state graphs that dominate Western agent frameworks. The honest answer is that it depends on the problem. If you are building a single-agent system with a few tools, you do not need distributed fault tolerance. You need a clean function-calling loop and maybe some durable execution, which is why we covered Restate on Tuesday. If you are building a multi-agent system where agents coordinate across organizational boundaries, need independent scaling, and cannot tolerate a single process failure taking down the entire coordination topology, AgentScope’s architecture is not a nice-to-have. It is the difference between a system that works and a system that works until it does not. The message-passing approach is the right architecture for distributed systems. The only question is whether your multi-agent system is actually a distributed system or just a single process with multiple prompt templates.
The framework choice is not binary. You can adopt AgentScope for the multi-agent coordination layer and use Smolagents or Atomic Agents for the individual agent implementations. AgentScope’s agent abstraction is pluggable, and the message bus does not care what framework produced the message as long as it conforms to the message type. The architectural bet AgentScope makes is that agents will become distributed systems and coordination will become the hard problem. If that bet is correct, the frameworks that solved distribution first will have an architectural lead that is difficult to close. The Western agent framework ecosystem is converging on this realization, but it is converging from a starting point of single-process Python and shared-state graphs. AgentScope started from the other direction. It started with the message bus and added the agents later. Sometimes the order in which you solve the problems determines the shape of the solution.
AgentScope just hit 2.0.1. The documentation is at docs.agentscope.io. The repo is github.com/agentscope-ai/agentscope. Apache 2.0. Twenty-six thousand stars, almost none of them from the people you follow on Twitter. The architecture is worth studying even if you never adopt the framework. It is the clearest articulation I have seen of what agent frameworks look like when they are designed by distributed-systems engineers instead of prompt engineers. The two disciplines are going to have to learn to talk to each other. AgentScope is one of the few frameworks that started the conversation from the distributed-systems side of the table.
If this was useful, forward it to one engineer who needs less noise in their feed.