AgentConnect — the open-source, multi-agent alternative to Claude Tag

zfy0701 — Wed, 26 Aug 2026 12:00:00 +0000

AI agents have gotten genuinely good at the work itself—writing code, chasing down bugs, reviewing pull requests. The hard part is teamwork: whose machine is the agent running on? How does anyone else chime in? Who can see how far the work has gotten? And how do multiple agents work with each other?

Today, we’re introducing AgentConnect: an open-source platform where teams and multiple AI agents work together across Slack, Telegram, Discord, GitHub, and GitLab.

AgentConnect lets you bring Claude Code, Codex, and other ACP-compatible agents into the tools your team already uses. Give each agent a role, configure what it needs, and start work from a conversation, code review, webhook, or schedule.

Here are a few highlights:

🤝 Multiple agents, one team

Run multiple ACP-compatible agents side by side.
Let agents collaborate through shared conversations and agent-to-agent calls.
Configure models, workspaces, memory, MCP servers, skills, and sandbox policies per agent.

💬 Work where your team already works

Trigger work from code reviews in GitHub or GitLab, webhooks, or schedules.
Connect agents to Slack, Telegram, and Discord.
Continue conversations across platforms—even between Slack and Telegram.
Configure and follow your agents from one console.

🔐 Fine-grained access control

Control agent access separately from session visibility.
Sync permissions with GitHub and Slack.
Decide which repositories, tools, and other agents each agent may access.

🏠 Open source and self-hosted

AgentConnect is licensed under Apache 2.0 and can be deployed with Docker Compose or Kubernetes. Agent execution and workspaces stay in the environment you operate, while one console helps your team manage agents, integrations, access, and sessions.

Both the open-source and hosted versions of AgentConnect are available today. We’d be grateful to hear what you build with it and how your team approaches multi-agent collaboration. And if you like what you see, give AgentConnect a star on GitHub.

GitHub → https://github.com/agentconnect-md/agentconnect
Website → https://agentconnect.md
Documentation → https://docs.agentconnect.md
Video → Watch the two-minute introduction

Why we built AgentConnect

zfy0701 — Tue, 25 Aug 2026 17:39:24 +0000

It started with writing code

Like most teams, we started simple: everyone ran Claude Code or Codex in their own terminal and used it to write code.

The agents kept getting better, so we started giving them other jobs. A production error? Let an agent do the first pass of analysis. An upstream dependency shipped a new release? Let an agent upgrade our binaries. Daily health checks. First-pass review on incoming PRs. A customer question in the chat? Let an agent draft the answer.

Somewhere along the way, our agents crossed the line from “coding tool” to something much closer to a working member of the team.

An agent is not “an API call to a model.” The model may run at a provider — the agent itself is a real process that checks out your repos, runs commands, and holds your credentials.

Where that process runs, who can see it, and who can direct it — that’s where the real questions start.

Where the personal-terminal model breaks down

The problem showed up quickly. Our agents were doing team work, but they still lived like personal tools — in one person’s terminal. Teammates couldn’t see what an agent was doing, couldn’t take over a session, couldn’t review its output, and whatever context it had built up stayed on one laptop.

So everyone wrote ad-hoc glue for their own use case: message channels, cron jobs, credential handling, context stitching. Then one day we compared notes — we were all writing nearly identical code.

Most teams using agents hit this stage sooner or later: the agent capability is ready-made; what’s missing is the layer that connects it to how a team actually works. And everyone keeps rebuilding that layer from scratch.

Three requirements we couldn't compromise on

We looked hard at the existing tools — personal assistants like OpenClaw, agent workspaces like Raft, and Claude Tag. Each is good at what it aims for. But we kept coming back to three requirements, and nothing satisfied all three at once:

Team-level collaboration and permissions. Multiple people and multiple agents in shared conversations — with per-member visibility and separate trust boundaries where needed. The agent analyzing production errors and the agent answering customer questions shouldn’t have to run on the same machine or share the same privileges.
Work stays where work already happens. Our alerts, CI notifications, customers, and integrations live in Slack and Discord. A separate workspace for agent collaboration — however well designed — means a second IM and a migration. We wanted agents to join our channels, not the other way around.
Control over runtimes and infrastructure. Which model, which runtime, which machine — those choices should stay ours. And the platform itself should be open source, so we can extend it for our own use cases instead of waiting on a vendor.

So we built AgentConnect: an open-source platform for teams to run and manage agents together. The principle behind it: we don’t invent a new place for collaboration — we bring the agents to where it already happens.

What that looks like in practice

Here’s the kind of workflow this enables — and the reason we say “AI team” rather than “AI tool”:

A customer reports a payment failure in the #customers channel.
support-agent, running on Claude Code, triages the problem and hands the incident off in the same thread.
payments-agent, running on Codex on a different machine, reproduces the bug and opens a pull request.
support-agent closes the loop in the original thread.

The workflow remains visible in one thread from start to finish, including the handoff and the machine boundary.

AgentConnect provides the connective tissue: identity, routing, permissions, placement, triggers, and delivery. Each agent has a stable, named identity, backed by the runtime you choose — Claude Code, Codex, or any ACP-compatible runtime. Agents live in Slack, Discord, Telegram, and Lark; work can also start from GitHub or GitLab events, generic webhooks, and schedules. Permissions decide which members — and which agents — can see what. Memory, when enabled, lets an agent retain context across sessions. And through OpenConnector, an open-source connector gateway, agents can act on third-party services without putting provider credentials in the agent process.

Execution stays on your infrastructure

Agent execution and workspaces stay on infrastructure you control. The Control Plane never sits on the live message path and never stores message content; callback-based ingress may pass through an optional, non-persisting relay.

Established sessions keep running at the edge during a Control Plane outage; new assignments and orchestration resume when it reconnects.

Where this is going

We believe the next phase is helping teams carry context forward without flattening access boundaries. An authorized agent can retain and surface relevant decisions from the channels, repositories, and systems it is allowed to access, so teams don’t have to reconstruct the same context every time. That layer should be open source and provider-neutral — a team’s context shouldn’t be entrusted to any single vendor.

Try it

If your team is at the “everyone is writing their own agent glue” stage — we turned that glue into a platform. Open source under Apache 2.0, self-hostable today.

DEV Community: AgentConnect