DEV Community: zfy0701

AgentConnect vs. Claude Tag: comparing the two ways to bring agents into team chat

zfy0701 — Tue, 06 Oct 2026 05:15:11 +0000

Since we launched, the question we get more than any other is how AgentConnect differs from Claude Tag. It's a fair question, and worth answering properly.

We started building AgentConnect before Claude Tag was announced. Arriving independently at the same idea — that an agent belongs in the shared conversation where a team actually works, not in a private chat window one person can see — was, if anything, reassuring. Great minds think alike: when a team at Anthropic builds toward the same pattern you're building toward, it's decent evidence the pattern is right.

But agreeing on the pattern isn't the same as building the same product. Underneath that shared starting point, the two differ on questions that matter quite a lot in practice: which agent runs, where it can be triggered from, how many agents work together, and who operates the infrastructure. This post walks through those differences honestly, based on Anthropic's Claude Tag announcement, its current product documentation, and AgentConnect's public documentation, checked on September 22, 2026. Both products are moving fast — Claude Tag is still in beta — so check the primary sources if you're reading this later.

The short version

	Claude Tag	AgentConnect
Built by	Anthropic	Open-source project (Apache 2.0)
Model / runtime	Supported Claude models, including Opus and Sonnet, subject to organization policy	Any ACP-compatible runtime — Claude Code, Codex, Grok Build, DeepSeek, Pi, others
Where it works	Slack (beta), with plans to expand; subscriptions to individual GitHub pull requests	Slack, Telegram, Discord, Lark/Feishu, plus GitHub, GitLab, and Gitea triggers and Linear issue assignment
Agent collaboration	Shared Claude in each channel; identities with scoped tools and memory	Agents with separate runtimes, tools, and permissions that can call one another
Hosting	Anthropic-hosted SaaS	Self-hosted (Docker Compose or Kubernetes) or AgentConnect Cloud
Access control	Admin-scoped channel/tool identities, org and channel spend limits	Separate agent access and session visibility, synced with GitHub/Slack roles, per-agent repo and tool scoping
Availability	Beta, Claude Enterprise and Team customers only	Open source today; hosted Cloud available

If your team is already fully on Slack and Claude Enterprise or Team, and you want one well-integrated Claude that learns your channels, Claude Tag is a short path to that. If you want to choose runtimes from different vendors, work across more than Slack, configure repository-wide event triggers or issue assignments, or keep the whole stack in infrastructure you control, that's the problem AgentConnect is built around.

What Claude Tag is

Claude Tag, announced by Anthropic in June 2026, brings Claude into a Slack channel as a standing team member. An admin grants it access to specific channels, tools, data, and codebases; from there, anyone in the channel can tag @Claude and delegate a task while they do something else. A few things define how it works, per Anthropic's own description:

It's multiplayer. There's one Claude per channel, shared by everyone in it — not a private session per person. Anyone can see what it's doing and pick up where the last person left off.
It learns over time. Claude builds context from the channels it's in, and can pull in context from other channels and data sources it's been granted access to (it doesn't report from private channels).
It takes initiative. With "ambient" mode on, Claude proactively surfaces relevant updates and follows up on threads that have gone quiet, without being asked.
It works asynchronously. You hand it a task and move on; it can also schedule and pursue work autonomously over hours or days.

Access is scoped per admin-defined "Claude identity" — a model set up for sales work doesn't share memory or data access with one set up for engineering. Admins set organization- and channel-level spend limits and can audit everything Claude has done and who asked for it.

Claude Tag replaces the previous Claude in Slack app and is in beta for Claude Enterprise and Team customers, starting on Slack with Anthropic's stated intent to expand to more places over time. Its model choices include Opus and Sonnet, subject to Anthropic's available models and organization policy. Users can switch models within a thread or set a channel default, where permitted. Claude Tag can also subscribe to an individual GitHub pull request and respond to comments, failed checks, or merges on that PR.

What AgentConnect is

AgentConnect is an open-source platform (Apache 2.0) for the same underlying job — letting a team delegate work to agents in the conversations and tools they already use — built around three choices that Claude Tag, being a single-vendor Slack feature, doesn't need to make: which agent, which channel, and who hosts it.

Any ACP-compatible agent. Configure agents to run Claude Code, Codex, Grok Build, DeepSeek, Pi, or any other agent that speaks the Agent Client Protocol. Choose the runtime and model per agent across supported providers.
More than one place to work. Connect agents to Slack, Telegram, Discord, and Lark/Feishu, and trigger them directly from GitHub, GitLab, and Gitea pull requests and issues, or from a Linear issue assignment — in addition to webhooks and schedules.
Specialized agents that collaborate. Give each agent its own role, runtime, model, workspace, memory, tools, and skills, and let agents call one another as part of a shared workflow. For example, a support agent can ask a payments specialist to inspect an incident, then use the findings to respond in the shared conversation.
Boundaries that separate access from visibility. Decide who can use an agent, who can see its sessions, and which repositories, tools, and other agents it can reach — synced with your existing GitHub and Slack roles rather than managed as a separate system.
Self-hosted or hosted. Run the whole stack — including agent execution and workspaces — in infrastructure you operate using Docker Compose or Kubernetes, or use AgentConnect Cloud's console while still pointing it at daemons you run.

We build AgentConnect, so take the framing with that in mind — but every claim above is drawn directly from the public documentation linked throughout, not from how we'd like it to be read.

Where the two overlap

Both products are built around the same basic shift: an agent that lives in a shared conversation rather than a private chat window, that teammates can see and pick up after each other on, and that an admin can scope down to specific tools and data. Both let an agent work asynchronously and report back where the team is already looking. If your team hasn't tried this pattern yet, either product will feel like a meaningfully different way of working than a personal chatbot tab.

Where they differ

Model and runtime choice. Claude Tag lets teams choose among supported Claude models, including Opus and Sonnet, within their organization's policy. AgentConnect lets you choose both the runtime and model per agent across providers, and run different runtimes side by side. This matters if you already have a runtime preference, want to compare providers on the same workflow, or don't want a single vendor's roadmap to be your team's roadmap.

Where agents can be triggered from. Claude Tag's user-facing interface is Slack. Its PR subscriptions wake on activity on an individual GitHub pull request, but do not provide repository-wide triggers such as every newly opened PR. AgentConnect connects the same agent roster to Slack, Telegram, Discord, and Lark, and — separately — starts agents from configured GitHub, GitLab, and Gitea pull request and issue events, and from Linear issue assignment. The difference is the available entry points and event scope for starting work.

How agents collaborate. Claude Tag shares one Claude within each channel, and administrators can configure separate identities with scoped memory and tools for different uses. AgentConnect lets teams bring several specialized agents into the same conversation or configure agent-to-agent calls across separately configured runtimes, tools, and permissions. That flexibility adds configuration and coordination; teams whose work fits a shared Claude in each channel may prefer the simpler setup.

Access control shape. Claude Tag scopes a Claude "identity" to a set of channels and tools, with organization- and channel-level spend limits and an audit log. AgentConnect separates who can use an agent from who can see its sessions, and separately scopes which repositories, tools, and other agents each agent can reach — synced with roles your team already manages in GitHub and Slack, rather than a parallel permission system.

Deployment and openness. Claude Tag is a hosted feature of Claude Enterprise and Team — there's no self-hosted option, and the source isn't open. AgentConnect is Apache-2.0 licensed; agent execution and workspaces stay in the environment you operate whether you self-host the full stack or use AgentConnect Cloud's console.

Where Claude Tag has the edge

If your team is already standardized on Slack and Claude Enterprise or Team, Claude Tag is close to zero setup — no infrastructure to run, no daemon to install, and it's the most tightly integrated route to Anthropic's own models and ambient behavior tuned specifically for them. For a team that has no interest in running infrastructure, wants one well-supported agent rather than a roster to configure, and works entirely inside Slack, that's a legitimate and simpler answer.

Where AgentConnect has the edge

AgentConnect is built for teams that don't want to make Claude Tag's implicit choices for them: teams that want to compare or mix agents and models, that work across more than Slack, that trigger agents from pull requests, issues, or Linear tickets as often as from chat, that need agents on different runtimes to call one another with distinct tools and permissions, or that need to keep agent execution inside infrastructure they control for compliance or data-residency reasons. None of that requires giving up the core pattern — an agent working in a shared, visible conversation — that made Claude Tag worth building in the first place.

Getting started

Both are worth trying against your team's actual workflows rather than deciding from a comparison alone. AgentConnect is open source and self-hostable today, with a hosted Cloud console if you'd rather not run the daemon yourself.

GitHub → https://github.com/agentconnect-md/agentconnect — if you find this useful, a star helps others find it too.
Website → https://agentconnect.md
Documentation → https://docs.agentconnect.md

Reusable, testable decisions for agent orchestration with Jev

zfy0701 — Tue, 29 Sep 2026 11:11:52 +0000

Choose when agents act, which agent handles the task, and which model to use.

A support channel has questions, bug reports, follow-ups, and the occasional “thanks, that worked.” With several agents available, your team needs to decide which messages deserve a response and who should handle them. The same judgment comes up when assigning an issue, choosing a reviewer, or picking a model for a new task.

AgentConnect now supports Jev, TypeSafe’s judgment model, as a general decision engine for your agents. You define a question and the criteria for answering it. Jev evaluates the context, and AgentConnect uses the answer according to the rules you configure.

We call these reusable questions Decisions. A Decision can return Yes or No, choose a category you define, or score something on your scale. For example: does this message need a reply, is this a technical or billing question, or how complex is this task? You can reuse the same Decision in several places, with each place choosing what to do with its answer.

For a support agent, you can configure a “Needs reply” Decision to trigger on requests for help and skip greetings and acknowledgments. It considers the earlier conversation as well as the latest message. You can add it from the channel row in the agent’s Integrations tab and choose which answers should trigger a response.

A category Decision can limit responses to technical questions, as in this example:

With shared-bot routing in Slack, a “Support category” Decision can send new conversations to different agents. Technical questions can go to an engineering agent, and billing questions to a support agent. Your team defines the categories and who handles each one. You can also chain Decisions: check the category first, then judge the customer’s frustration before bringing in a specialist.

We use this in the Ask AI panel on our documentation site, too. It connects to an agent through the agent chat API, with a Decision that judges whether a visitor’s question is about AgentConnect. When the Decision declines a question, the panel explains what it can help with. You can use the same setup for a documentation assistant or support widget on your own site.

The docs assistant declines two unrelated requests, then answers a question about AgentConnect.

That same approach works across other parts of your team’s work:

Issue triage and code review. In GitHub, GitLab, or Gitea, choose which watching agents handle an issue or pull request (merge request on GitLab). A question about the review focus can select a security reviewer for authentication changes or an architecture reviewer for a data model change.
Runtime and model selection. Choose an agent’s runtime and model when a new session starts. Map task complexity scores to your preferred models, or use the “PR author” example for cross-model review: have Codex review a PR written by Claude, and Claude review one written by Codex. Existing sessions keep their original selection.

Agents can also ask Decisions themselves while working. Attach a Decision under Tools & Skills → Decisions, and the agent can supply context and use the answer—for example, classify a ticket before choosing how to handle it. Its existing permissions still determine which actions it can take.

To create your first Decision, open a Playground conversation with one agent and describe what you want to judge. The request below asks for the same judgment as the built-in Needs reply example, and the same flow works for any question your team needs:

Create a Decision called Support requests. Use Jev to answer Yes when someone asks for help, and No for greetings, thanks, or casual conversation.

Review the proposed Decision and its arguments before choosing Approve and run.

The agent drafts the Decision and submits it for your approval. Review its name, model, question, and criteria in the proposed arguments, then choose Approve and run to save it or Deny to reject it. Nothing is applied until you approve. Once saved, open the Decision from the Decisions page and use Try with an example to test it against a sample conversation. You can inspect the answer and probabilities, adjust the criteria, and try again. The channel and routing editors also let you preview what your rules would do with a sample message. You can create Decisions manually or start with examples such as Needs reply, Support category, PR focus, and Task complexity.

Agents running on AgentConnect Cloud can evaluate Decisions using organization credits. For your own daemons, add a TypeSafe (Jev) API key under Infra → Provider keys.

Explore the documentation, and star AgentConnect on GitHub to support the project.

Introducing Linear support

zfy0701 — Fri, 18 Sep 2026 11:59:17 +0000

AgentConnect now supports Linear. Bring Claude Code, Codex, and your other agents into the issues where your team tracks its work.

Open an issue and choose AgentConnect from the Assignee menu. Your agent picks up the issue description and starts working. Its plan, tool calls, and progress stream back into Linear.

Your agent can post results as issue comments and update the issue’s status.

You can reply in the same session to add context, ask a follow-up, or stop the work from Linear.

One agent can work across multiple Linear teams, and one workspace can have several agents with different tools and instructions.

For setup and configuration, see the Linear integration guide.

Resources

Introducing Gitea support

zfy0701 — Tue, 15 Sep 2026 13:04:27 +0000

AgentConnect now supports Gitea (GitHub and GitLab are already supported). Bring Claude Code, Codex, and your other agents into issues and pull requests on gitea.com or a self-hosted Gitea instance.

Choose which repositories an agent should follow and when it should start: on new issues or pull requests, on updates, or when mentioned. Several agents can work in the same repository. Mention an agent by name to give it a task, or request the bot as a pull request reviewer.

Agents reply in the issue or pull request. For code review, they can comment on specific lines, approve a pull request, or request changes. A commit status on the pull request shows the agent’s run state and links to its session.

Gitea 1.23 or later is required. For setup and configuration, see the Gitea integration guide.

Resources

Grep beats LSP? Why coding agents ignore your fancier tools

zfy0701 — Mon, 31 Aug 2026 04:28:09 +0000

Why would a coding agent ignore a retrieval interface that returns more precise results?

I explored this question in a small study comparing lexical search with grep against LSP-backed semantic navigation. I expected semantic navigation to reduce noise and save tokens. Instead, agents often stayed with grep. When I forced them to use the semantic path first, task success sometimes fell.

This is a question of LLM-friendliness. A tool is not friendly to a model merely because its results are precise. It must return enough context for the next step and present that context in an interface and output shape the model can use directly. Familiarity may also matter: the model may have learned similar action paths during training. The interface properties can be evaluated directly. Training support is a hypothesis consistent with these results, not something this study proves.

The result is not a general argument against LSP. The protocol includes capabilities far beyond code navigation, and this study tested only a small subset. Instead, the results point to a broader engineering problem: a model does not use tools in isolation. It uses them through a harness that defines the available actions, their names, their inputs, and the context returned to the model.

In this post, I describe how code retrieval affected both code-finding and editing tasks, why grep had an advantage in some conditions, and what this means for agent platforms.

A model and its familiar tool loop act as one capability surface.

Comparing two code retrieval interfaces

I compared two ways for an agent to retrieve code context. grep performs lexical search: it finds matching text. The tested LSP-backed tools perform semantic navigation through references, definitions, and document symbols, allowing them to distinguish a real function call from the same word in a comment.

The pilot covered three Claude models, several Python and TypeScript repositories, and multiple task types. I measured token use only when both approaches completed the task successfully. This controls for a common evaluation error: a failed run can appear efficient simply because it stopped early.

On simple code-location tasks, all three models chose the semantic tool only 0% to 6% of the time when both tools were available. Forcing a semantic-first path reduced success from 100% to 89% in that arm.

Reference-completeness tasks produced a different result. When asked to find every caller, the models chose semantic navigation 45% to 57% of the time. The LSP-backed path reached 1.00 precision, compared with 0.76 for grep, by removing false matches. However, recall stayed near 0.66 in both arms. Semantic navigation did not find more true calls. The remaining limit came from how thoroughly the agent worked, not from retrieval precision. For the stronger models, the precision gain also came with higher token use rather than a saving.

The model doesn't blindly prefer grep — it routes by task

Share of semantic (LSP) tool calls when both grep and LSP are available and the agent chooses freely.

Legend: Opus 4.8 (blue), Sonnet 4.6 (magenta), Haiku 4.5 (green).

Same models, same free choice — the routing flips with the task. On localization and rename the agent almost always reaches for grep; on reference-shaped work it reaches for the LSP about half the time, unprompted. The action distribution is task-shaped, not a blind habit.

Task	Opus 4.8	Sonnet 4.6	Haiku 4.5
Localization	0%	4%	6%
Reference-completeness	45%	50%	57%
Multi-file rename	3%	—	—

The codebase was also important. On a clean TypeScript repository, LSP-backed navigation produced no F1 gain and used 16% more tokens. On a noisy TypeScript repository, it improved F1 by 0.246 and used 12% fewer tokens. The useful predictor was lexical noise, not whether the language had strong static types.

Codebase noise determines the value of semantic navigation

Accuracy gain from semantic retrieval on reference-completeness (ΔF1 = LSP − grep). Bar colour encodes how noisy grep is on that repo; prec = grep’s precision there.

Legend: blue means grep is clean here; magenta means grep is noisy here.

Two repositories in the same language, opposite verdicts. On clean remeda the LSP adds nothing — grep already resolves every reference correctly, so semantic retrieval is pure overhead. On noisy hono it adds +0.246 F1. The predictor is how badly grep's precision degrades on that codebase, not whether the language is statically typed.

Repo	Language	grep precision	ΔF1 (LSP − grep)	Token cost
remeda	TypeScript	1.00	+0.000	+16%
hono	TypeScript	0.51	+0.246	−12%
requests	Python	0.76	+0.072	+19%

These results are conditional rather than categorical. The agents did not simply “always use grep.” Their routing changed with the task, and the value of LSP-backed navigation changed with the repository.

Tool interfaces change agent behavior

The tested LSP-backed tools initially returned only a location: a file path, line, and column. The agent then had to open the file to inspect the code. grep, by contrast, usually returned the matching line immediately: src/auth.ts:42: return validateToken(token).

I changed the semantic-navigation response to include source text in a similar shape. The semantic backend and the set of references stayed the same; only the information returned to the model changed. Pass@1 on the rename tasks rose from 0.67 to 0.83, while follow-up file reads fell from 15.2 to 3.2 per episode.

Returning source context improves semantic navigation

Multi-file rename, Opus 4.8, pyright with a pre-warmed index. Same semantic backend in both LSP arms — only the output shape differs.

Legend: grep (blue), LSP — locations only (magenta), LSP + inline context (green).

Returning locations forces the agent to go read each site; returning the line inline does not. Attaching ±2 lines of source to every reference cut follow-up file reads 15.2 → 3.2 — below grep's own 4.3 — and lifted pass@1 from 0.67 to 0.83. The retrieval backend never changed; only the shape of what came back.

Arm	pass@1	Site recall	Tokens	Follow-up reads
grep	1.00	1.000	2,451	4.3
LSP — locations only	0.67	0.930	4,131	15.2
LSP + inline context	0.83	0.958	3,336	3.2

This result illustrates a principle that Anthropic also emphasizes in Writing effective tools for agents: tools are interfaces for non-deterministic agents, so the context they return is part of the design. A semantically correct tool can still create a poor agent workflow if each result requires several extra actions to interpret.

The output change does not prove that post-training data caused the improvement. It may also have helped simply because each response contained more useful information. However, the result is consistent with a broader hypothesis: models learn concrete action patterns, not “tool use” in the abstract. A familiar loop—prompt, tool call, readable result, next action—can be part of the capability observed in practice.

Why lexical search had an advantage

Interface familiarity is only part of the explanation. Lexical search also had a real structural advantage for some tasks.

A semantic reference is only one kind of text match. A rename may also need to update comments, docstrings, configuration, or strings. find_references will not return those by design, while grep can.

semantic references ⊂ textual occurrences

For text-wide edits, grep can be the better retrieval tool even for a model with perfect training on LSP-backed navigation.

This gives us two explanations for the observed behavior:

Structure: some tasks need textual completeness, which the tested semantic-navigation methods do not provide.
Distribution: the model may have more practice with familiar tools and result shapes.

The first explanation follows directly from what the tools retrieve. The second is a hypothesis consistent with the routing and output-format results, but this study did not manipulate training data and therefore cannot prove it.

Structure explains when grep is better. Distribution explains why familiar paths still win.

The harness is part of the system

Here, I use harness to mean the runtime around a model: the instructions placed in context, the tools made available, their input schemas, the shape of their results and errors, and the loop that decides what the model sees next.

This surrounding system can materially change behavior. Anthropic’s work on effective harnesses for long-running agents shows the same idea at a longer time scale: the model alone is not enough to make reliable progress across sessions. Environment setup, progress artifacts, and verification routines affect what the agent can accomplish.

The same principle applies within a single tool loop. When post-training includes agent trajectories, the harness defines the prompts, tool calls, results, and recovery paths in those examples. A model trained through repeated use of read, grep, edit, and bash may learn policies that depend on those interfaces. Moving the same model into a different tool layer can therefore change its effective capability.

agent capability = model × harness

This is why benchmark results for a model do not always transfer unchanged to a different runtime. Supporting the same model is not necessarily the same as reproducing the same agent. Tool selection, signatures, output formats, and error behavior can all affect the policy the model follows.

Preserving native runtimes with ACP

This is one reason my team and I built AgentConnect around native coding-agent runtimes. AgentConnect does not place Claude or Codex models inside a shared, generic tool loop. It runs runtimes such as Claude Code and Codex on the user’s own machine, where each runtime keeps its native tools and normal prompt-to-tool workflow.

AgentConnect communicates with these runtimes through the open Agent Client Protocol (ACP). ACP standardizes the boundary between a client and a coding agent, including session setup, prompts, streaming updates, tool-call updates, cancellation, and permission requests. It does not require every runtime to expose the same internal tools.

One open boundary. Each agent stays on its home turf.

This separates two concerns. At the outside boundary, a common protocol lets AgentConnect provide team channels, triggers, schedules, session history, collaboration, and control across multiple agents. Inside that boundary, Claude Code can continue to work like Claude Code, and Codex can continue to work like Codex.

The goal is not vendor lock-in. ACP provides an open boundary across runtimes. Our design principle is to preserve the tool surface each model already uses well, then add coordination around it.

Practical guidance for adding tools

These findings do not mean that teams should avoid LSP, MCP, or new agent skills. The study found a clear precision gain from LSP-backed navigation in noisy code, and a small response-format change removed most follow-up reads. The practical lesson is to evaluate a new retrieval interface as part of the full agent loop.

My recommendation is to start with the native tool surface, then apply the following checks when adding a new capability:

Test real tasks at equal accuracy. Do not celebrate lower token use if success also fell.
Measure whether the agent calls it. Availability is not adoption.
Return enough context for the next decision. A result like path:line:content may work better than a bare location object.
Keep a native fallback. Semantic and lexical search solve different problems.
Route by the task and the codebase. A noisy repository may benefit from semantic navigation. A text-wide search may still need grep.
Reinforce the new trajectory when it matters. A prompt can introduce a tool, but it may not create a reliable policy for using it.

As Anthropic notes in Building effective agents, successful agent systems often rely on simple, composable patterns. More tools do not automatically produce a more capable agent; tools must be distinct, understandable, and useful within the model’s workflow.

Conclusion

The study shows why “better retrieval” cannot be evaluated outside the full agent system. An interface can be more precise and still use more tokens. It can return correct locations and still create unnecessary reads. A small change in output shape can make the same semantic result much easier for the model to use.

For teams building agent platforms, the implication is straightforward: evaluate the model and harness together. Preserve the interfaces that already support reliable behavior, and test changes against real tasks before assuming that a more sophisticated abstraction will help.

For the full experimental setup, task definitions, and results, see Does a Language Server Save Tokens for Coding Agents?.

This is the product principle behind AgentConnect: use an open protocol to connect agents, while keeping each model together with its native runtime and tool loop.

This is a preliminary pilot with small task sets, a few repositories, three Claude models, and two to three rollouts per cell. I tested LSP-backed navigation through references, definitions, and document symbols; I did not test textDocument/rename, diagnostics, or code actions. A rename-capable LSP might perform differently on the refactoring tasks where grep did best. The edit tasks were local and are not standard SWE-bench scores. These findings are useful signals, not a final verdict across all models, tools, and codebases.

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.