AgentConnect: An Open-Source Multi-Agent Platform That Puts Claude Code, Codex and Your Team in the Same Thread

The problem it targets

AgentConnect is an open-source platform released under the Apache-2.0 license. Its goal is to let people and several AI agents work together inside the conversations and workflows a team already uses. The README opens by calling it "the open-source, multi-agent alternative to Claude Tag", with the tagline "@ any agent". The promise is that wherever work happens, your agents work alongside your team and each other, and learn as they go.

The pain point behind this is easy to recognize. Most coding agents still behave like personal tools that live in one person's terminal. Teammates cannot see what the agent is doing. They cannot take over a session or review its output. The context the agent builds stays on one laptop. So every team ends up writing the same glue code: message channels, cron jobs, credential handling and context stitching. AgentConnect's bet is that this glue should be a platform, not a per-team project.

Core architecture: three components, two planes

The architecture section of the README describes three components. The first is the Daemon. It runs placed agents over a daemon-owned ACP connection (the Agent Client Protocol), owns workspaces and session state, keeps direct connections to chat platforms, runs schedules, and sends model-provider traffic directly from the machine it runs on. The second is the Relay, which is optional. It accepts callback-based ingress and web chat, proxies centrally managed MCP and OpenConnector access, and forwards message ingress straight to the owning daemon. It has no durable storage. The third is the Control Plane with its Web UI. It manages authentication, configuration, placement, permissions, metadata and observability. It stores explicitly approved organization knowledge and skill revisions. In all other cases it proxies bounded reads to the daemon on demand.

The key design choice is the split between a data plane and a control plane. Live platform messages and ACP update streams stay on the daemon and relay path. Apart from approved organization knowledge and bounded skill bundles, the Control Plane stores coordination metadata. It does not store message bodies, attachment bytes, pending Dream proposals or ACP session streams. The README also states the failure model plainly: if the Control Plane is briefly unavailable, established sessions and daemon-local schedules keep running. Only new assignments and configuration changes wait until the daemon reconnects. That is a pragmatic answer to the question every platform team asks first: what breaks when the control service goes down?

Technical idea one: runtime neutrality through ACP

AgentConnect does not tie itself to one agent runtime. Claude Code, Codex, Grok Build, DeepSeek, Pi and any other ACP-compatible runtime run side by side. Each agent has its own runtime, model, workspace, tools and machine, and each can be configured on its own. The README says that changing one runtime does not rebuild the workflow around it.

ACP acts as a common socket. Because the daemon talks to every agent through the same protocol, the layers above it, such as routing, permissions and memory, do not need a custom version for each tool. For a team that already mixes several coding agents, this is easier to maintain than wiring a separate chat bot for each one.

Technical idea two: Decisions and Jev routing

The second mechanism worth attention is reusable Decisions, powered by Jev from TypeSafe. A Decision answers three questions: when should an agent respond, which specialist agent should receive a new conversation, and which runtime and model should a new session use.

The README gives two concrete scenarios. In issue and support triage, Jev routes a new support conversation to the right specialists, and people and agents investigate in one shared thread while the fix and its verification stay visible from start to finish. In customized code review, Jev selects the reviewers for each new GitHub pull request and picks the runtime and model for each review session. General, architecture or security reviewers can each carry their own instructions, repository access, tools and sandbox policy.

In effect, this adds a configurable policy layer between "who does the work" and "what does the work", instead of burying those rules inside a bot script.

Memory, knowledge and boundaries

Each agent gets its own memory and skills. Teams can also publish reviewed Knowledge that every agent can find on demand, and the deployment guide mentions optional Mem0 configuration. On the control side, the README lists explicit boundaries: who can see each agent and session, which repositories and tools an agent may use, and which other agents it may call. Work can begin from a message, an issue, a pull request, a webhook or a schedule.

Other use cases in the README include support that crosses trusted workspaces (a Telegram conversation that pulls in engineers from a Slack workspace and returns the answer where it started), recurring operations that surface exceptions to people, and keeping private forks current by letting agents assess upstream changes, prepare and test updates, and bring them to the team for review.

Deployment

There are two self-hosting paths. The fastest is Docker. Clone the repository and run `docker compose up -d --pull always`. This starts the Web console, the Control Plane, the Relay and PostgreSQL. Open `http://localhost:3000`, add a daemon from the console, run the command it generates, and create your first agent. The default stack listens only on 127.0.0.1 and uses a local no-auth mode meant for evaluation.

For clusters, an official Helm chart ships with every release under the same version number, at `oci://ghcr.io/agentconnect-md/charts/agentconnect`. A separate Setup Server runs on loopback at port 8091. It configures browser authentication through Logto, the GitHub, Slack, Google and Lark or Feishu apps, the sign-in methods you show, and preset-agent behavior. The repository also ships a setup skill so Claude Code, Codex and similar tools can walk you through installation as an interactive tutorial. Development needs Node 24.12.0 or newer and pnpm 11.

Ecosystem and adoption impact

For developers, the main value is moving agents from a personal terminal to a shared team space. In one Slack thread, a person can take over, review or correct an agent's work.

For enterprises, the combination of Apache-2.0 licensing and self-hosting means agent execution and workspaces can stay in an environment the company operates, which matters to compliance-sensitive teams. Running several runtimes side by side also reduces dependence on any single model vendor.

Limitations and open questions

One point needs to be stated clearly: the README publishes no benchmarks, latency figures or cost data. This article therefore makes no performance claims. The following points are worth weighing during an evaluation.

First, the default stack is an evaluation mode with no authentication. Production use requires proper auth, public URLs and the Linux sandbox requirements described in the OSS guide. Second, agents that call other agents can multiply cost and widen the blast radius of a mistake, so permission boundaries and the call graph need deliberate design. Third, Decisions depend on Jev, an external component whose maturity and replaceability should be assessed separately. Fourth, the README does not detail Claude Tag itself, so readers should check official documentation before treating the comparison as like for like.

Outlook

If multi-agent work becomes routine, the bottleneck will move from the ability of a single agent to organizational questions: routing, permissions, memory and observability. AgentConnect places its bet on that layer, and it does so as open source, self-hostable and runtime neutral.

Whether it becomes a standard depends on how fast the ACP ecosystem grows and on whether the community develops mature practices for security and cost control. For now it is a credible reference implementation that a team can try and judge on its own evidence.