AgentConnect 團隊如何把智能體從個人終端遷移至團隊頻道

In six months, a team of under ten went from editor autocomplete to about thirty agents with standing jobs, from cluster checks and code review to releases, fork maintenance and customer support, plus the permissions and context sharing around them.

Over the past few months, AI has fundamentally changed how our team works. Much of our recurring work is now genuinely automated by agents: the daily cluster inspection and alert analysis, pull request review, maintenance of an upstream fork, release notes, and answering questions in customer groups. We are an engineering team of fewer than ten people.

A year ago

A year ago, "using AI" meant an editor with AI in it: completions, rewriting a function, explaining unfamiliar code. Everyone used it, and nothing about how the team worked changed. The output was still a diff on someone's machine. Nobody else saw the conversation, and there was nothing in it worth seeing.

We did not build anything around it. The models were not yet at the point where you could hand them a task and walk away.

The turning point was Claude Opus 4.6. It was the first model we used that was worth building around: give it a task and it runs commands, reads the results and keeps going. Within weeks Claude Code and Codex were everyone's daily tools.

Then people started giving them work other than code. A production error: let an agent take the first look. An upstream release: let an agent upgrade our fork. Inspect the cluster every morning. Take customer questions. Within a month every engineer had accumulated a pile of their own glue: shell scripts, cron entries, a bot token in a dotfile, a prompt that stitched together the context the agent needed.

Two problems

The first was duplication. When we compared what each of us had written, it was nearly the same: how messages get in and out, how to schedule, where credentials live, how to assemble context. Everyone had done it once, and each copy only ran on its owner's machine.

The second was lost context. The most useful part of a session is usually not the final diff but the process in the middle: what was tried, what failed, why this fix over that one, which dashboard had the answer. All of it sat in one person's terminal and was gone when the session ended. When someone else needed it, the only way to get it was a meeting.

Two weeks of Slack bots

In June we tried the most direct approach: a set of Slack bots built on the open-source OpenACP, changed so that each thread in an existing channel became one session.

Someone mentioned an agent in an incident thread, the rest of the team watched what it was checking, and asked follow-up questions in the same thread. Colleagues outside engineering started using the bots too; a mention in Slack is all it takes.

Then came two weeks of patches, all about threads: carrying the earlier thread into a mid-thread mention, backfilling messages the bot had missed, stopping bots from triggering each other in a loop. The software had no concept of "a conversation with several people and several bots in it", and we were bolting one on.

One platform app with several agents behind it, instead of one process, one Slack app and one set of tokens per bot
Separate identities for several users, instead of one shared login on one machine
A real control plane, instead of a bot that ran operational shell commands from the chat
Versioned daemons with controlled upgrades
Sessions that survive a restart, each with its own workspace, instead of one directory shared by every thread
Conversations and threads as core concepts, not adapter patches

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.

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.

We built the connecting layer ourselves, on ACP, and open-sourced it a month later as AgentConnect.

What the agents do now

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:

About thirty agents: one generalist, the rest specialists
Running on seven of our own machines plus a managed pool
Connected to Slack, Telegram, Discord and Linear
Twenty-odd scheduled jobs

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.

Each specialist owns one kind of work, with its own repositories, tools, channels and schedules, and permissions scoped to that work.

Design documents and meetings. 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/, 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.

The documentation repository is organized by project, and each project has two parts, design documents and meetings:

agentconnect/
├── design-docs/                                   # reviewed as PRs
│   ├── agents-collaboration-design.md
│   └── daemon-centric-architecture.md
└── meetings/                                      # one pair per meeting
    ├── 2026-06-12-agents-collaboration-kickoff.txt          # raw transcript
    └── 2026-06-12-agents-collaboration-kickoff-summary.md   # written by the agent

Inspection and alerts. 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.

Cross-model code review. 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: 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 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.

Releases. 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 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.

The upstream fork. 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.

Customer group support. 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.

The 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.

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.

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.

Memory 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.

Operations that need approval send an approval card by direct message to the agent's editors, rather than letting anyone in the channel approve.

Where the context lives

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.

Design documents live in the same repository as the code, under docs/, 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.

How 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.

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.

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.

What's next

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.

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.

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.

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.

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.

https://github.com/agentconnect-md/agentconnect

https://docs.agentconnect.md