agmsg
Stop copy-pasting between your AI coding agents
406 followers
Stop copy-pasting between your AI coding agents
406 followers
Stop being the copy-paste relay between your AI coding agents. agmsg lets Claude Code, Codex, Gemini CLI, and Copilot CLI message each other directly through a shared SQLite database — no daemon, no network, no Python. Just bash + sqlite3, installed as an Agent Skill. Unlike built-in subagents (single-vendor, ephemeral) or MCP (an agent calling tools), agmsg is vendor-agnostic and persistent. Run several agents — even multiple Claude Code instances — in one room, working together.
agmsg
@fujibee the runaway-loop case is what i'd stress-test first: A asks B to clarify, B bounces it back, and they burn tokens in a clarify-loop with nobody refereeing. the tic-tac-toe demo is the harmless version of the same loop. so the real question is whether the stop condition lives in the protocol, or it's left to each agent's prompt to know when to shut up.
agmsg
@dmitry_isaevski
Exactly the right thing to stress-test — and the honest answer: the protocol is deliberately dumb. agmsg is just the transport (messages over SQLite), it does NOT referee. The stop condition lives in the agent's prompt / monitor setup today, not the protocol. The tic-tac-toe demo works because the game has a terminal state; free-form "clarify-loops" don't, so yeah — two over-polite agents can absolutely burn tokens forever. Practical guards I use: a turn cap, and a "if you're not making progress, stop and ping the human" instruction. A referee/coordinator agent in the room is the cleaner answer. Keeping the protocol dumb is a choice, but it pushes that responsibility up to you.
Survey Anyplace
@fujibee go go! 🚀
agmsg
@satoruitter go go thanks!
@fujibee Brilliant Koichi, congrats on the launch. As you can see, you're not the only codex-claude courier. How do handle context across sessions?
agmsg
@zolani_matebese thank you 🙏 and ha — the courier club is way bigger than I thought. Context across sessions is exactly what the persistence buys you: the room is one SQLite file that outlives any session, so a fresh agent just reads the thread back. agmsg won't summarize or compress it for you (it's dumb transport) — but the full history is right there to re-read or query. Re-seeding a new agent from an old room is the pattern I'm most excited about.
@fujibee This is a fascinating approach to a problem many AI power users are already experiencing.
I'm curious: as agent-to-agent collaboration becomes more common and workflows grow beyond simple message passing into long-running, multi-agent systems, how do you envision agmsg evolving to handle challenges like context management, conflict resolution, task orchestration, auditability, and security—while still preserving the simplicity, vendor-agnostic design, and dependency-free philosophy that seem to be at the core of the project?
agmsg
@md_khayruzzaman thank you 🙏 — and the honest answer is a principle, not a feature list: the core stays a dumb pipe (messages in one SQLite file), and everything you listed lives on top, opt-in, never baked in.
Auditability is almost free already — the whole history is a queryable file you can grep. Conflict resolution / task orchestration / turn-taking I'd rather solve as optional patterns (a coordinator agent, an atomic claim/lease table) than as protocol rules, so you only pay for what you use. Security today is local-file trust (same level as your shell); network/auth would be an explicit layer, never a default.
The day agmsg needs a daemon to do any of this is the day it stops being agmsg. Keeping the floor dumb is the feature — the complexity belongs at the edges, in the agents.
The agent-to-agent message routing is the right abstraction. Instead of shared memory you're treating agents as async message consumers. We've hit context fragmentation when chaining Claude with specialized tools and the copy-paste tax compounds fast. How does agmsg handle partial context handoffs when one agent's output exceeds another's context window limit?
agmsg
@retain_dev Great question — and honestly agmsg doesn't solve it for you. It's transport, so it'll happily store a message bigger than the receiver's window; managing that is on the agents. What works in practice: send a summary + a reference (a key/rowid) instead of dumping raw output, and let the other agent pull detail on demand — the queryable room makes that pull cheap. But agmsg itself doesn't chunk or window, deliberately.
Treating agent-to-agent communication as a first-class primitive rather than bolting it on with shared clipboard or file hacks is genuinely clever. We've run into real pain keeping context synchronized across parallel agent tasks, where state drift creates subtle bugs. How do you handle concurrent write conflicts when two agents message the same SQLite channel simultaneously?
agmsg
@anand_thakkar1 SQLite handles this one for free — writes are serialized (single-writer lock, WAL mode for concurrent reads), so two agents posting to the same channel at once don't corrupt anything; the inserts just get ordered. Each message is a row, ordering is rowid/timestamp. So "nobody drops a message, order stays consistent" is guaranteed at the DB layer. What SQLite does NOT decide is whose turn it is — that's still the agents' problem.
The human courier btw two AIs line made me laugh because that's basically what I've been doing lately. How well does this hold up when more than two agents are involved?
agmsg
@busra_seker1
Ha, glad it landed 😄 — that courier feeling is the whole origin story. It's built for N agents: a "team" is just a room, and you can drop several in. Right now it's running with 5 different agent types and multiple instances in one room. What gets messy past ~2-3 isn't the transport, it's turn-taking — everyone wants to talk at once, so you need light addressing (who's this for?) or a coordinator. The DB handles N fine; the social protocol is the hard part. 🙂
For me the copy-paste isn't even the worst part... it's that the second agent loses the why and confidently rewrites stuff the first one got right. Non-technical builder bouncing between Claude Code and Cursor daily. Does agmsg carry intent across the handoff, or just the code and context?
agmsg
@luca_capone
Honest answer: agmsg only carries what the sending agent actually writes. It's a transport, not a semantic layer — so the "why" survives only if the first agent spells out its intent in the message. It won't magically preserve reasoning the agent kept to itself. In practice that's a feature and a trap: I prompt the sender to lead with intent ("here's WHAT I did and WHY") before the diff. Then the second agent stops confidently rewriting the right thing. Your "loses the why" pain is the exact failure mode I'd watch.
The persistent room is the part I'd actually use day to day, the 'agents talking' framing kind of undersells it! Does agmsg arbitrate turns at all (a lock, a token) or is sqlite just guaranteeing nobody drops a message and ordering stays the agents' problem?
agmsg
@artstavenka1 The latter, exactly. sqlite guarantees durability + ordering (no dropped messages, consistent order by rowid); agmsg does zero turn arbitration — no lock, no token. Whose turn it is stays the agents'/prompt's problem. Deliberate choice: keep the transport dumb, push coordination up to the agents (or a coordinator agent in the room). And agreed — "persistent room" undersells nothing, it's the part I care about most too.
DIY UX Test
The copy-paste shuffle between Cursor, Claude Code and the rest is a real daily tax, so a shared message bus between agents is a smart framing. Does it preserve context and diffs on handoff, or mainly the prompt text?
agmsg
@oleksii_sekundant it carries whatever the sending agent writes into the message — so if it writes the diff + the why, that's what lands; if it only writes a one-liner, that's all that crosses. agmsg doesn't auto-capture diffs or context, it's transport. In practice I have the sender paste the diff + intent explicitly. Upside: it's all just text in a row you can grep later.