AgentsMesh
Orchestrate isolated terminal coding agents across your own machines from one control plane.
Per-dimension scores and reasoning
Evidence: README claims mTLS and JWT for runner, but no implementation details for least privilege; user confirmation (human takeover) mentioned in Autopilot, but default behavior unclear; data flow transparency: architecture diagram shows control/data plane split, but no data flow or storage details; sensitive data: private credentials and BYOK mentioned, but no encryption details; dependency security: go.mod lists many dependencies, but no vulnerability scanning or version pinning; external effects: runner executes arbitrary terminal commands, but no sandbox restrictions; rollback: worktree sandbox and recoverable mentioned, but no concrete rollback mechanism; source attribution: no publisher verification. Deductions: these aspects are only asserted, lacking concrete implementation or evidence.
Evidence: README and CI workflows are consistent; architecture and component naming consistent; many dependencies, but no availability guarantees (e.g., mirroring or caching); failure messages: CI has error handling, but no user-facing failure message design. Deductions: self-consistency is good, but dependency availability and failure messages lack concrete evidence.
Evidence: README clearly identifies target users (teams) and scenarios (multi-agent scheduling), lists supported agents; capability boundaries: control/data plane split and runner features described, but no explicit limits; trigger precision: Autopilot has iteration caps, but no trigger conditions; environment fit: supports multiple platforms (Linux/macOS/Windows) and deployment modes, but no detailed configuration guide. Deductions: some aspects are described, but lack detail.
Evidence: README structure is clear, includes quick start, architecture, project structure; install notes: dev.sh and manual setup provided, but no detailed production deployment steps; naming stability: component naming consistent, but no API stability guarantee; examples and FAQ: quick start examples, but no FAQ; known limitations: not explicitly listed; license: BSL-1.1 clear, but no commercial license details; versioning and changelog: CI and release process, but no changelog; maintenance responsibility: no explicit maintainers. Deductions: some aspects present, but lack completeness and detail.
Evidence: output usability: Web/Desktop/iOS consoles, real-time terminal streaming; marginal value: solves multi-agent management problem, unique value; cost-benefit: BYOK and self-hosting, but no pricing or performance data. Deductions: cost-benefit lacks data support.
Evidence: README claims (e.g., mTLS, isolation) lack code references; cross-source verification: CI and tests exist, but no external verification; fact-inference separation: README distinguishes problem and solution, but does not explicitly mark inferences. Deductions: lack of traceability and external verification.
- Publisher identity is unverified; use with caution.
- Security claims (e.g., mTLS, isolation) lack code-level evidence; further review needed.
- Many dependencies without vulnerability scanning or version pinning; supply chain risk.
- Runner executes arbitrary terminal commands; ensure controlled environment.
- License is BSL-1.1; production use requires commercial license; ensure compliance.
What does this agent do, and when should you use it?
AgentsMesh is a self-hosted execution and orchestration platform for AI coding agents. Its Go services comprise Backend, Relay, and Runner: Runner executes isolated AgentPods on user machines, Backend manages identity, scheduling, tickets, and runner certificates, and Relay carries live terminal traffic. Each pod has a separate Git worktree, branch, private credentials, and PTY, reducing interference between concurrent tasks. Web, Electron desktop, and iOS clients share a Rust business-logic core and expose terminals, multi-pane workspaces, Kanban tickets, and collaboration topology. The platform supports Claude Code, Codex CLI, Gemini CLI, Aider, OpenCode, and other terminal-based agents; it documents both a Docker-based local stack and self-hosted deployment guidance.
An operator creates an AgentPod from the Web, Desktop, or iOS console, and AgentsMesh schedules it to a chosen or available self-hosted Runner. The Runner connects to Backend through gRPC with mTLS, creates an isolated Git worktree sandbox at sandboxes/{pod}/workspace/, provisions a branch, private credentials, and a PTY, then runs a terminal-based coding tool. Terminal bytes flow through the stateless Relay WebSocket data plane to clients, while Backend manages pod lifecycle, organizations, users, tickets, billing, and runner PKI. Pods can be linked through Mesh and Channel, where they communicate using @mentions; Autopilot sends a next instruction when a pod becomes idle and retains iteration and decision history.
- An engineering lead maintaining several repositories can install Runners on internal machines and dispatch parallel fixes, tests, and implementation tasks to separate pods.
- A development team that uses Claude Code, Codex CLI, and Gemini CLI can launch and observe those terminal tools from one console.
- A developer who cannot risk concurrent agents changing the same checkout can assign each task to its own Git worktree, branch, and credentials.
- A solo operator running long unattended coding jobs can use Autopilot to continue an idle pod, while retaining the option to take over manually.
- A team managing engineering work on a Kanban board can bind a Ticket to a pod and follow its progress and MR/PR status.
What are this agent's strengths and limitations?
- Runners can be installed across multiple user-owned machines, keeping code in the user's infrastructure while scheduling pods by capacity.
- Each pod receives a dedicated Git worktree, branch, PTY, and private credentials, which directly isolates concurrent coding work.
- The architecture separates orchestration from terminal transport: Runner-to-Backend control uses gRPC with mTLS, while stateless Relay handles terminal streaming.
- A shared Rust business-logic core serves Web, Electron, and iOS clients, while the built-in agent list spans several terminal coding tools.
- The full local development stack explicitly requires Go 1.24+, Node.js 20+, pnpm, and Docker, adding operational overhead compared with a standalone CLI.
- Runner authentication uses a browser flow; headless environments need the separate
--headlesslogin path. - The hosted workflow requires Git-provider connection and BYOK, leaving model API costs and key management with the user.
- The repository is licensed under BSL-1.1; its README states that production use requires a commercial license until the change date.
How do you install or deploy this agent?
For the hosted path, run curl -fsSL https://agentsmesh.ai/install.sh | sh on each target machine, then run agentsmesh-runner login. On a headless machine, use agentsmesh-runner login --headless; for a self-hosted server, add --server https://your-server.com. After authentication, provide your own AI API keys (BYOK) and run agentsmesh-runner run to bring the machine online as a Runner. For local development, run git clone https://github.com/AgentsMesh/AgentsMesh.git, change to AgentsMesh/deploy/dev, and run ./dev.sh; the documented prerequisites are Go 1.24+, Node.js 20+, pnpm, and Docker.
How do you use this agent?
Once a Runner is online, create an AgentPod in a Web, Desktop, or iOS console and either select a Runner or allow scheduling from the available pool. Choose an installed terminal-based tool such as Claude Code, Codex CLI, Gemini CLI, Aider, or OpenCode, assign work, and watch its terminal stream from the pod workspace. For an always-on Runner, run agentsmesh-runner service install followed by agentsmesh-runner service start. After the local development stack starts, the Web Console is at http://localhost:3000 and the API is at http://localhost:80/api; check deploy/dev/.env for actual dynamically allocated ports.
FAQ
Is it limited to one model provider?
Where do code execution and terminal traffic occur?
How are concurrent agents prevented from overwriting one another?
sandboxes/{pod}/workspace/.Can it be self-hosted instead of using the hosted service?
deploy/selfhost/ deployment path, and its local development stack can be started from deploy/dev with ./dev.sh.