One platform app with several agents behind it, instead of one process, one Slack app and one set of tokens per bot<\/p><\/li>\n
Separate identities for several users, instead of one shared login on one machine<\/p><\/li>\n
A real control plane, instead of a bot that ran operational shell commands from the chat<\/p><\/li>\n
Versioned daemons with controlled upgrades<\/p><\/li>\n
Sessions that survive a restart, each with its own workspace, instead of one directory shared by every thread<\/p><\/li>\n
Conversations and threads as core concepts, not adapter patches<\/p><\/li>\n<\/ul>\n\n
We also tried replacing the whole thing with Hermes. Its demo covered most of what we wanted: loops, proactive messages, a kanban board and memory, all built in. We moved a rebase bot onto it and ran it for a day. The biggest problem was that it had no team layer: who may use which agent, who may see its sessions, which repositories and tools an agent may touch. There was no permission model; the whole thing assumed one user. Beyond that, its own harness and Claude Code ran interleaved inside one task, and without the coding agent's cache and resume, every turn re-sent the full context, so latency and cost were both high. When something failed, we could not tell which layer had failed. This describes the version we tried at the time; Hermes has changed a great deal since.<\/p>\n\n
Two decisions from that time have not changed: permissions are part of the platform, not a feature to add later; and we keep the harness engineers already run locally, so that any behaviour seen in a channel can be reproduced in a terminal.<\/p>\n\n
We built the connecting layer ourselves, on ACP, and open-sourced it a month later as AgentConnect.<\/p>\n\n
\n \n \n What the agents do now\n<\/h2>\n\n
The production organization was created on a Sunday in July. By Tuesday six agents were running, the same jobs people had been running from personal scripts, now each with a name, a channel and a machine. Today:<\/p>\n\n
- \n
About thirty agents: one generalist, the rest specialists<\/p><\/li>\n
Running on seven of our own machines plus a managed pool<\/p><\/li>\n
Connected to Slack, Telegram, Discord and Linear<\/p><\/li>\n
Twenty-odd scheduled jobs<\/p><\/li>\n<\/ul>\n\n
The generalist is connected to the development channel, direct messages and Linear. It can check out the team's repositories on demand, and anyone can mention it. Small changes are done right in the Slack thread: describe the problem, it edits the code, opens a pull request and runs the checks, and a person glances at it in the thread and merges, without opening a terminal.<\/p>\n\n
Each specialist owns one kind of work, with its own repositories, tools, channels and schedules, and permissions scoped to that work.<\/p>\n\n
![\"The](\"https:\/\/media2.dev.to\/dynamic\/image\/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto\/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fyvto2n52e8zg5ceahkca.png\")
<\/a><\/p>\n\nDesign documents and meetings.<\/strong> One agent owns documentation. Design discussions mention it in the development channel; it reads the current system and the existing design documents and proposes a path, colleagues add constraints in the thread, and it revises. Once the discussion settles, it opens a pull request that writes the conclusion into the matching design document under
docs\/<\/code>, reviewed together with the implementation. Every meeting is transcribed. We do not use the transcription service's own summaries; the raw transcript goes into a separate repository, the agent writes the summary there, and then updates the related issues and design documents in the other repositories.<\/p>\n\nThe documentation repository is organized by project, and each project has two parts, design documents and meetings:
\n<\/p>\n\n\nagentconnect\/\n\u251c\u2500\u2500 design-docs\/ # reviewed as PRs\n\u2502 \u251c\u2500\u2500 agents-collaboration-design.md\n\u2502 \u2514\u2500\u2500 daemon-centric-architecture.md\n\u2514\u2500\u2500 meetings\/ # one pair per meeting\n \u251c\u2500\u2500 2026-06-12-agents-collaboration-kickoff.txt # raw transcript\n \u2514\u2500\u2500 2026-06-12-agents-collaboration-kickoff-summary.md # written by the agent\n<\/code><\/pre>\n\n<\/div>\n\n\n\nInspection and alerts.<\/strong> One agent walks the cluster every morning and posts a report to the alerts channel. A few others each watch one class of service in a business area for latency and versions. When an alert lands in the channel, the on-call agent picks it up in the same thread: it checks Grafana metrics, looks at pods and logs, and compares against recent changes in the repository. Kubernetes and Grafana are MCP services, registered once at the organization level and enabled per agent. How each class of event should be handled is written as a skill in the repository: which metrics to check first, the common causes, what it may handle on its own and when it must call a person. When the procedure changes, the skill changes, and every on-call agent uses the new one from the next run. Whether it is an incident is the engineer's call.<\/p>\n\n
Cross-model code review.<\/strong> Every pull request gets a first pass from the review bot, which leaves inline comments and posts its own check. The same review bot can switch runtime and model per pull request, and different models notice different things. Running on Codex, it reproduced a bug in one pull request<\/a>: editing a scheduled task's time before saving dropped the saved task's identity. It requested changes, and approved once the fix landed. Running on Claude, it approved another pull request<\/a> and listed exactly what it had not verified and was leaving to CI. For a deeper look, someone mentions a reviewer on a stronger model.<\/p>\n\n
![\"The](\"https:\/\/media2.dev.to\/dynamic\/image\/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto\/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fzarfme1bajp41kkg66af.png\")
<\/a><\/p>\n\nReleases.<\/strong> Every merge to main produces a release candidate; a stable release points the release branch at a chosen commit. What happens after the release is the agent's job: confirm the release succeeded, read the pull requests between the two stable versions, group related pull requests into one feature entry, call out behaviour changes and upgrade notes separately, write that as the Summary at the top of the release page, and then comment on and close each issue the release fully fixed. The Summary on v2.8.0<\/a> came from this; the Features list below it is the generated changelog. The procedure is a skill, so the rules are the same whichever agent runs it.<\/p>\n\n
The upstream fork.<\/strong> We maintain a fork of an upstream runtime adapter: the upstream tag plus a pile of our own patches. The patches carry logic, so when upstream refactors, the job is not resolving a few lines of conflict. It is understanding what upstream changed and what our patch was for, then re-implementing the intent on the new base. The whole thing goes to a coding agent: an upstream release or a schedule starts it, it reads both sides' changes, decides which patches are still needed, which upstream has absorbed and can be dropped, and which need rewriting, makes the changes in its own worktree, runs typecheck, tests and build, opens a pull request, and posts what needs a human judgement to the channel. That repository now has fourteen rebase branches, one per upstream version, with the check results beside each. Merging and publishing are done by a person.<\/p>\n\n
![\"The](\"https:\/\/media2.dev.to\/dynamic\/image\/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto\/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F0pyhiemhhpqkrmo1coer.png\")
<\/a><\/p>\n\nCustomer group support.<\/strong> A support agent answers questions in customers' Telegram groups and escalates what it cannot answer to an engineering channel in Slack. The groups get a lot of spam, so each message is scored first; only messages under the threshold reach the support agent, and the rest go to a moderator agent. Replies about a specific account are confirmed by a person before they go out.<\/p>\n\n
![\"The](\"https:\/\/media2.dev.to\/dynamic\/image\/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto\/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fcypbcjgbjh2u08fq0uhl.webp\")
<\/a><\/p>\n\nThe generalist can reach many repositories and sits in public channels, private channels and direct messages at once, so permissions cannot be skipped. We handle them in three layers.<\/p>\n\n
The agent itself: who may change its configuration, which repositories and tools it may touch, who may use it in which channels, and which agents may call it or be called by it, each set separately.<\/p>\n\n
Sessions: who may read a session follows the membership of the place the conversation happened. A session in a private channel is readable only by people currently in that channel; whoever leaves the channel can no longer read it. Direct messages stay private. There is no separate list to maintain.<\/p>\n\n
![\"Session](\"https:\/\/media2.dev.to\/dynamic\/image\/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto\/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fd4n0sfak4m7pazoogljw.png\")
<\/a><\/p>\n\nMemory is layered by where the conversation happened: what was said somewhere is remembered there. What an agent learns in a public channel goes into the shared layer, a private or external group gets its own layer, and a direct message gets that person's layer. When it answers, the agent loads only the memory the current conversation is allowed to read.<\/p>\n\n
Operations that need approval send an approval card by direct message to the agent's editors, rather than letting anyone in the channel approve.<\/p>\n\n
\n \n \n Where the context lives\n<\/h2>\n\n
What an agent produces has to be kept somewhere the team and the other agents can find later, with access still controlled by where it came from.<\/p>\n\n
Design documents live in the same repository as the code, under
docs\/<\/code>, with implementation status and links to issues and pull requests. The project instructions file says where the documents are and that a change to a design and its implementation go in the same pull request. The product repository has gone from 35 design documents at open-sourcing to 100 now. A reviewer reads the linked design document directly instead of asking the author to explain it in a meeting. Anything beyond a single repository, runbooks and architecture decisions, goes into the organization's knowledge library: owners publish it, it is versioned, and agents look it up on demand.<\/p>\n\nHow to handle a class of alert, how to write a release description, how to rebase the fork: each is a skill file, imported once and enabled per agent. Once, after the agent that checks the price list every day posted its report, a colleague asked in the thread whether it had failed to find the matching skill. It confirmed it had not found it and had instead done a read-only comparison following the channel's earlier practice. The colleague pointed out the skill was in the repository. The agent found it, confirmed its earlier search had skipped hidden directories by default, and recorded the problem in its working conventions for later runs.<\/p>\n\n
An agent's workspace is a Git repository, so what one agent writes, any agent's next session can read; the daemons on colleagues' own machines use the same repositories. Tickets are maintained by the agent doing the work: updated as it progresses, closed when done, linked to the documents and pull requests.<\/p>\n\n
The local Claude Code and Codex memory mechanism is unchanged; we only point the memory directory at a Git repository, with hooks that pull at session start and push at session end, so it is the same memory across machines and harnesses. The platform agents' memory is a separate system, layered by conversation source as described above. Merging the two is something we may do later.<\/p>\n\n
\n \n \n What's next\n<\/h2>\n\n
Today's agents are triggered by a mention, a schedule, a pull request or issue event, a webhook, or a judgement (is this spam, which agent should take it), and they do the one thing the trigger specifies.<\/p>\n\n
Proactive agents. Make the agent more like a teammate: it checks the things it is responsible for and proposes before acting. For example, it notices that a just-merged pull request changed behaviour and the matching design document was not updated, and proposes a documentation pull request in the development channel; or the same question has come up three times this week in a customer group, and it proposes writing the answer into the docs. It acts only once a person approves. This is in preview.<\/p>\n\n
Computer use. Some things have no API, only a desktop app or a browser. Register a machine as a Computer, grant it to specific agents, and they can take screenshots, click and type; a person watches the live screen in the console and can take over at any time. Also in preview.<\/p>\n\n
Joining meetings. Today a meeting is recorded, transcribed and processed afterwards by the documentation agent. Further out, the agent joins the meeting as a participant: it can be asked questions during the meeting, and decisions get written back to design documents and issues on the spot rather than afterwards. This has not started.<\/p>\n\n
AgentConnect is open source under Apache 2.0 and deploys with Docker Compose or Kubernetes. If you hit a problem, open an issue; if you find it useful, you are welcome to star the repository.<\/p>\n\n
https:\/\/github.com\/agentconnect-md\/agentconnect<\/a><\/p>\n\n
https:\/\/docs.agentconnect.md<\/a><\/p>\n\n","category":["ai","agents","opensource","productivity"]},{"title":"AgentConnect vs. Claude Tag: comparing the two ways to bring agents into team chat","pubDate":"Tue, 06 Oct 2026 05:15:11 +0000","link":"https:\/\/dev.to\/agentconnect\/agentconnect-vs-claude-tag-comparing-the-two-ways-to-bring-agents-into-team-chat-npa","guid":"https:\/\/dev.to\/agentconnect\/agentconnect-vs-claude-tag-comparing-the-two-ways-to-bring-agents-into-team-chat-npa","description":"
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.<\/p>\n\n
We started building AgentConnect before Claude Tag was announced. Arriving independently at the same idea \u2014 that an agent belongs in the shared conversation where a team actually works, not in a private chat window one person can see \u2014 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.<\/p>\n\n
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<\/a>, its current product documentation<\/a>, and AgentConnect's public documentation<\/a>, checked on September 22, 2026. Both products are moving fast \u2014 Claude Tag is still in beta \u2014 so check the primary sources if you're reading this later.<\/p>\n\n
\n \n \n The short version\n<\/h2>\n\n