Hysen Labs
Open-source project
agentconnect-md/agentconnect avatar
agentconnect-md

agentconnect

The open-source, multi-agent alternative to Claude Tag. @ any agent, wherever work happens, your agents work alongside your team and each other, learning as they go.

151 stars13 forksTypeScriptApache-2.0
DEEP OPEN-SOURCE ANALYSIS

A multi-agent platform that runs AI agents inside team chat tools

AgentConnect is an Apache-2.0 platform that lets teams run multiple AI agents together across Slack, Telegram, Discord, Lark, GitHub, and GitLab.

What AgentConnect connects

AgentConnect positions itself as an open-source, multi-agent alternative to Claude Code's slash mention workflow, and the README states the tagline plainly: multiple agents, one team, in the tools your team already uses. The platform brings AI agents into shared workflows on Slack, Telegram, Discord, Lark, GitHub, and GitLab. People and agents collaborate in the same conversations, and agents can call one another as work moves forward. The README is explicit that each agent can carry its own model, workspace, memory, MCP servers, skills, repository access, and sandbox policy, so different roles are configured independently rather than sharing one flat configuration. Fine-grained controls separate who may use an agent from who may see its sessions, while a single console keeps the team's agents, integrations, and permitted work in view. The agent runtimes named in the documentation include Claude Code, Codex, Grok Build, DeepSeek, Pi, and any other ACP-compatible runtime. Channels extend to Slack, Telegram, Discord, Lark or Feishu, and webchat, while triggers include GitHub and GitLab events, generic webhooks, and schedules. The product goal is to stop agents from living only in individual terminals and instead place them where the team already works. The documentation also lists example workflows such as shared issue triage, customized pull request review, and cross workspace support conversations, which show how the routing maps onto everyday team tasks.

How the architecture is organized

The README documents a daemon-centric architecture with three named components. The daemon runs placed agents over local ACP, owns workspaces and session state, maintains direct platform connections and schedules, and sends model-provider traffic directly. An optional relay accepts callback-based ingress and webchat, proxies centrally managed MCP and OpenConnector access, and forwards message ingress to the owning daemon without durable storage. The control plane plus web UI manages authentication, configuration, placement, permissions, metadata, and observability, and it stores explicitly approved organization knowledge and skill revisions while otherwise proxying bounded daemon reads on demand. Live platform messages and ACP update streams stay on the daemon and relay data plane. The README notes that, apart from approved organization knowledge and bounded skill bundles, the control plane stores coordination metadata rather than message bodies, attachment bytes, pending proposals, or ACP session streams. If the control plane is temporarily unavailable, established sessions and daemon-local schedules continue, and new assignments and configuration changes resume after reconnection. That failure model is part of the documented design rather than an afterthought, and the README points to a longer architecture document for the full message paths and trust boundaries. The control plane stores coordination metadata rather than message bodies, which keeps private conversation content out of the long term state even while sessions run.

Getting a local stack running

The README gives a self-host path that starts the web console, control plane, relay, and PostgreSQL with Docker Compose. The commands clone the repository, change into the directory, and run docker compose up with the pull always flag in detached mode. After that the operator opens the local console at port 3000, adds a daemon from the console, runs its generated command, and creates a first agent. The default stack listens only on 127.0.0.1 and uses local no-auth mode for evaluation, so it is meant for a trusted machine rather than a public deployment. A Kubernetes path exists through the official Helm chart published to the GitHub container registry on every release. The development section lists concrete requirements, Node 24.12.0 or newer and pnpm 11, with Docker required for the control plane integration tests. Common tasks are exposed through pnpm scripts: install, dev to run all packages in parallel, build, typecheck, lint, format check, and test, plus filtered commands that target a single package such as the daemon, control plane, or web. The README also links to an OSS guide covering authentication, public URLs, Linux sandbox requirements, provider apps, image pinning, secrets, and optional Mem0 configuration for teams that want to run the stack in production.

Editorial conclusion

AgentConnect is released under the Apache-2.0 license and was last updated on GitHub on 2026-08-24, with 151 stars recorded at the time of the snapshot.

DEEP OPEN-SOURCE ANALYSIS

Official sources

Community notes

Community notes