AgentMesh: A Config-First Multi-Agent Framework With a Thin Coordination Layer
A Multi-Agent framework that enables AI agents to collaborate effectively, helping you build powerful agent teams for solving complex tasks.
At a glance
- What is it?
- AgentMesh is a Python multi-agent framework from MinimalFuture that defines agent teams in config.yaml and runs them through a CLI, Docker, or an SDK. The coordination model is deliberately simple, and that simplicity is both the pitch and the main constraint.
- Who is it for?
- AgentMesh fits teams that want a multi-agent setup defined in a single config.yaml and launched from the command line, without writing graph code. It is a poor fit if you need a stable API surface: the SDK is at 0.1.5, the README lists WebUI, MCP support, and a remote agent protocol as not yet available, and the 0.1.3 to 0.1.5 gap spans roughly nine months.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 168 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem AgentMesh Targets: Teams Without Graph Code
Most multi-agent frameworks ask you to express collaboration as a graph or a state machine. You define nodes, edges, and the conditions that move execution between them. That is powerful and also a lot of code before your first task runs. AgentMesh takes the opposite position. A team is a list of agents in config.yaml, each with a model, a system prompt, and a set of tools. The AgentTeam object owns task allocation and context management, and you hand it a task string.
The README's own examples make the intended user clear. The template ships with two teams: general_team for search and research, and software_team, described as a development team with three roles that collaborates on web applications. If your problem looks like that, a small fixed group of roles working through a shared task, AgentMesh removes the graph-authoring step entirely. If your problem needs conditional branching, retries on specific node failures, or human approval gates mid-run, the framework's stated abstractions do not obviously cover it, and you would be fighting the design rather than using it.
How the Coordination Layer Works: Agent, AgentTeam, Context, Task
The README lists six core concepts: Agent, AgentTeam, Tool, Task, Context, and LLMModel. The division of labour is stated plainly. An Agent is an autonomous decision-making unit with a role, configurable with a model, a system prompt, tools, and decision logic. An AgentTeam handles task allocation, context management, and the collaboration workflow. Context is the shared information: team details, task content, and execution history.
That is the whole architecture as documented. The README does not describe the allocation algorithm, whether agents negotiate, vote, or are dispatched by a planner, and it does not say how execution history is trimmed when it grows. The architecture diagram is referenced but its contents are not described in text. This matters for evaluation: you can see the seams (team, agent, context) but not the mechanism inside the team. The one behavioural detail the SDK example does confirm is memory. In the single-agent example, after calling run_stream with "My project is named AgentMesh", a later call asking for a project intro is annotated with the comment "Remembers the project name", and the README states that history is retained automatically. So conversation state persists across calls on the same agent object. Whether that same retention applies across agents inside a team is not stated.
Tooling is the other concrete piece. The README names built-in search engines, browser automation, file system access, and terminal tools, and the SDK example imports GoogleSearch and Calculator from agentmesh.tools. MCP protocol support is listed as coming soon, which means the current tool set is what ships in the package.
Getting It Running: config.yaml, main.py, and the Docker Path
Installation is a clone and a pip install. The README gives:
git clone https://github.com/MinimalFuture/AgentMesh cd AgentMesh pip install -r requirements.txt
Browser tools are a separate step and carry a version pin worth noticing:
pip install browser-use==0.1.40 playwright install
The README notes Python 3.11 or later is recommended for browser tools and that 3.7 or later is the minimum. Configuration starts from a template:
cp config-template.yaml config.yaml
You then add an api_key and model settings. The README states support for openai, claude, deepseek, qwen, and others, with recommended model names including gpt-4.1, gpt-4o, gpt-4.1-mini, claude-sonnet-4-0, claude-3-7-sonnet-latest, and deepseek-chat. Ollama appears in the supported models list for local models, though the README excerpt is cut off at that entry.
Execution is argument-driven. The README gives two worked examples:
python main.py -t general_team -q "analyze the trends in multi-agent technology" python main.py -t software_team -q "develop a simple trial booking page for AgentMesh multi-agent platform"
Interactive mode drops the -q flag and keeps the session open, with -l listing available teams:
python main.py -l python main.py -t software_team
The Docker route avoids cloning. You curl the compose file and the config template, then run:
docker-compose run --rm agentmesh bash
Inside the container the commands are identical to the local path. The SDK is a separate install, pip install agentmesh-sdk, and the team example builds an AgentTeam, calls team.add for a PM and a Developer, and finishes with result = team.run(task="Write a Snake client game"). Note that the PM agent in that example is created without a model argument while the Developer passes model=model, which suggests the team-level model is inherited when an agent omits one. The README does not state that rule explicitly, so treat it as an inference from the example rather than documented behaviour.
Where the Design Shows Its Edges
The clearest limitation is the maturity of the surrounding surface. The README marks three things as coming soon: a communication protocol for remote heterogeneous agents, MCP protocol support, and a Web Service section that contains only the words "Coming soon". WebUI and integration with common software are listed the same way. So the deployable surface today is the CLI, Docker, and the SDK. If your plan depends on agents running on separate machines and talking over a protocol, that plan has to wait.
The version history reinforces the point. Releases listed are 0.1.0 in April 2025, 0.1.3 in May 2025, and 0.1.5 in February 2026. A jump from 0.1.3 to 0.1.5 across roughly nine months, with no 0.1.4 or 0.2.0 in between, suggests the project moves in bursts rather than on a cadence. For a framework you intend to build on, that is a planning input.
The second edge is the coordination model itself. Because AgentTeam abstracts allocation away, you get less control over what happens when an agent produces a bad intermediate result. There is no documented mechanism in the README for retrying a single agent, injecting a correction, or pausing the team for review. The single-agent example shows history retention, but the README does not describe how context is bounded. Long software_team runs will accumulate execution history, and nothing in the supplied material says what happens when that history outgrows the model's window.
The third edge is the browser dependency. Pinning browser-use==0.1.40 plus a playwright install adds a heavy, version-sensitive layer on top of the core package. If you do not need browser automation, skip it, but be aware the README recommends Python 3.11+ specifically because of it.
AgentMesh Against LangGraph and CrewAI
The honest comparison is with LangGraph and CrewAI, because all three are Python and all three target multi-agent work. The difference is where the coordination logic lives.
LangGraph makes the graph explicit. You define nodes and edges, and control flow is code you wrote and can inspect. That costs you authoring effort and gives you deterministic branching, which is what you want when a workflow must retry a specific step or route on a condition. AgentMesh puts that logic inside AgentTeam and exposes it through config.yaml. You write less, and you also see less.
CrewAI is closer in spirit: you declare agents with roles and goals and let the crew handle delegation. The distinction that the AgentMesh README actually supports is configuration surface. AgentMesh ships a config-template.yaml with named teams (general_team, software_team) that you run with a single -t flag, and the same file drives both the CLI and the Docker container. That is a concrete operational difference: a team definition is a file you can diff and share, not a Python module. If your team definitions change often and non-Python colleagues need to read them, that matters. If your coordination needs are conditional, LangGraph's explicit graph is the better fit and AgentMesh's abstraction becomes an obstacle.
One thing to weigh against both: AgentMesh's tool layer includes browser automation and terminal access out of the box, which the README presents as built-in rather than as an integration you assemble. That is a real convenience for research and coding tasks, and also a real surface area to secure.
Maintenance, Licensing, and What to Verify
AgentMesh is Apache-2.0. That is a permissive licence with an explicit patent grant, and it does not impose copyleft obligations on your own code. It is not legal advice; if you are redistributing the framework or embedding it in a product, read the licence text and your own counsel's guidance.
Maintenance cost has three components you can see from the repository. First, the framework itself: the 0.1.3 to 0.1.5 gap means you should not expect frequent patch releases, so budget for reading the source when something behaves unexpectedly rather than waiting for a fix. Second, your config.yaml: it holds API keys, so it is a secret-bearing file that needs the same handling as any credential store, and the README's Docker instructions have you curl it from the repository before editing. Third, the browser stack: browser-use==0.1.40 is pinned, which protects you from breakage but also means you are on that version until the pin moves.
Upgrades are the open question. The README does not describe a migration path between versions, and with a jump from 0.1.3 to 0.1.5 the config schema may have shifted. Before committing, verify three things against your own setup: that python main.py -l lists your custom teams after you edit config.yaml, that your chosen model name is accepted by the LLMModel interface, and that the browser-use pin installs cleanly on your Python version if you need browser tools.
Editorial conclusion
AgentMesh fits teams that want a multi-agent setup defined in a single config.yaml and launched from the command line, without writing graph code. It is a poor fit if you need a stable API surface: the SDK is at 0.1.5, the README lists WebUI, MCP support, and a remote agent protocol as not yet available, and the 0.1.3 to 0.1.5 gap spans roughly nine months. Before adopting, run python main.py -l against your own config.yaml to confirm your team definitions parse, and check whether the browser-use==0.1.40 pin works with your Python version.
Community notes