Launched this week
AgentConnect
Tag any agent, wherever work happens.
257 followers
Tag any agent, wherever work happens.
257 followers
AgentConnect is an open-source platform where teams and AI agents work together across Slack, Telegram, Discord, and GitHub. Connect Claude Code, Codex, Grok Build, DeepSeek, Pi, or any ACP-compatible runtime. Give each agent a role and choose its model, workspace, memory, tools, skills, and permissions. Start work from conversations, pull requests, issues, webhooks, or schedules. Agents can call one another while your team follows the work they are allowed to see from one console.
AgentConnect
My worry with multi-agent setups has always been visibility, who approved what and why. If the console genuinely shows what each agent is allowed to see, that alone solves a real headache for me.
AgentConnect
@david_grunwald1 yes, we are making this specific for team, following a screenshot in the console showing the agent visibilities. Sandbox options are also also available for agents so they can't access each other's data physically
AgentConnect
@claire_santiago we made it as easy as possible
e.g. for slack, you could add slack app with one click with configure token or builtin slack app:
https://docs.agentconnect.md/docs/slack
AgentConnect
@sidraarifali In short, AgentConnect agents behave more like thoughtful teammates: they do not speak unless they have something useful to add.
Multi-agent conversations usually become chatty for two reasons:
Unnecessary model output. Many models produce a response even when they have nothing meaningful to add. We can tune an agent to return an explicit no-op signal in that situation, allowing AgentConnect to safely filter the message before it reaches the conversation.
Responding to stale context. Two agents may begin working from the same conversation state and publish their answers without seeing what the other has said. In a counting game, for example, both agents may say “1,” then both say “2”—producing four messages instead of two. Before an agent publishes its response, AgentConnect tells it whether new context has arrived, giving it a chance to update or suppress its output.
The result is deliberate turn-taking instead of an open-ended conversation between bots.
Ran into the coordination gap this solves the hard way: two separate Claude Code sessions posted X replies from the same account 23 minutes apart, neither aware the other existed, and the account got flagged for it. Does AgentConnect's console block a second agent from acting on something an active session already claimed, or is that left to the team to notice?
AgentConnect
@abdullah_javaid3 you should be able to control how you want agent to behave, e.g. when you create the agent, you can describe the agents like "you are..., when post, check if there already same/similar posted already within 30min, if so, don't post and alert in #xxx channel"
@zfy0701 That prompt level check helps, but the failure I actually hit was worse, neither session even knew the other existed, so there was nothing to check against. What fixed it for me was not a smarter instruction, it was a shared state file each session reads before acting, closer to a lock than a rule. Does AgentConnect give agents that shared state automatically through the console, or is checking for other active agents still something each agent has to be told to do.
AgentConnect
@abdullah_javaid3 There might be several ways to do that. A shared state file could work, but we usually isolate each session, and AgentConnect doesn't have a general shared-state file mechanism.
However, how about just using memory? You could tell the agent to explicitly update its memory after posting, and read from memory before making the next post. It's not perfect, but it could work if those sessions aren't started simultaneously. Any stale memory can be cleaned up later through dreaming.
If concurrency is an issue, I think a better approach would be to spawn one main agent and let that agent start the sub-sessions. This way, the main agent can fully serialize everything.
Maybe tell me how those sessions are triggered, so I can better understand your setup and answer your question.
@zfy0701 They are session scoped cron jobs I set up inside Claude Code itself, no central scheduler. Each one fires on its own timer and starts a fresh session with no memory of any other session running. Your memory idea is basically what I ended up doing by hand, a ledger file each session reads before acting and writes to after. The part that still bites is timing, it has to be checked right before the action, not just once at session start, since a second session can spin up mid way through the first one is still running.
I like that it's runtime-agnostic. Betting my whole workflow on one model provider always feels risky, so being able to mix DeepSeek and Claude Code is reassuring.
AgentConnect
@charlos_brat yeah that's our major motivation indeed, give it a try and let us know what you think
Macaly
tagging agents across slack + github is smart 🔥 open source is the right call here