Launched this week
agmsg
Stop copy-pasting between your AI coding agents
394 followers
Stop copy-pasting between your AI coding agents
394 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.
the sqlite-as-message-bus choice is the part i like — no daemon is the right call. the thing i'd worry about with multiple claude code instances in one room is two of them grabbing the same task before either writes back. how do you handle the claim/lock step?
agmsg
@qifengzheng no daemon was non-negotiable, glad that lands 🙏 and you've found the real gap: agmsg has no claim/lock primitive — two instances can absolutely grab the same task. Today I solve it socially (a coordinator agent hands out work, or an "I'm taking X" message + addressing). You could lean on SQLite for a real claim (an atomic UPDATE ... WHERE status='open' as a lease), but agmsg doesn't ship that — it's transport. A claim/lease table is the most-requested thing I'm chewing on.
@fujibee atomic update-where-open gets the claim cheap. the gnarly part is reclaim when an instance dies mid-task — lease ttl + heartbeat pulls coordination back into what you're positioning as pure transport. curious how you square that.
agmsg
@qifengzheng You found the actual design bet 😄 agmsg is single-machine by scope — no network, the floor is a local SQLite file — so liveness doesn't need TTL + heartbeat: the OS already knows. The actas exclusivity lock works this way today: a stale lock is reclaimed when its owner session no longer maps to a live process (checked via kill -0). PID recycling is the known wart (#67).
A claim/lease table would follow the same pattern — atomic update-where-open for the claim, exactly as you said, reclaim via process liveness instead of heartbeats. Coordination stays a thin GC over OS facts, and the transport stays dumb. If agmsg ever crossed machines you'd be right, TTL + heartbeat would drag coordination into the transport — which is a big part of why multi-host is out of scope.
And yes — social coordination first, cringe later. Will ping you when the lease primitive lands; you asked for it first.
@fujibee social coordination is what every distributed-system doc warns against and what every shipping product ends up trying first. it's only embarrassing in retrospect once the lease primitive lands.
AISA AI Skills Test
clever approach using SQLite as the message bus — no daemon overhead, just files. the multi-agent coordination problem is real and only getting worse as people start running 3-4 different AI tools on the same codebase. curious whether you've seen patterns in how people split tasks across agents vs using one agent for everything.
agmsg
@ozandag Thanks — keeping it to files was the whole point. Add a daemon and you're maintaining infra just to pass messages.
On the split: two patterns have stuck. Role split — one agent implements, a different model reviews (CC writes, Codex picks it apart). The win isn't parallelism, it's that different models fail differently. And subsystem split for genuinely independent work, coordinating through messages instead of through me.
But honestly most people still use one agent for everything, and that's usually right. Multi-agent earns its keep when you want an adversarial second opinion, or the task fans out cleanly.
the vendor-agnostic positioning is the right call but curious what the actual message format looks like and whether agents from different vendors interpret it consistently. Claude Code and Codex have different context windows, different tool use patterns, and different ways of handling instructions. a message that makes sense to Claude might be interpreted differently by Gemini CLI depending on how it's formatted. is there a message schema or is it unstructured text that each agent interprets in its own way
agmsg
@ansari_adin
Great question — it's deliberately thin. The envelope is structured (from, to, team, timestamp), but the body is just text. No enforced wire schema.
Consistency doesn't come from the format — it comes from onboarding. Each vendor gets a small skill/prompt teaching it the same protocol: how to read its inbox, who to address, when to reply. Claude, Codex, and Gemini converge on behavior because they're told the same conventions, not because the bytes are rigid.
You're right that a message obvious to Claude can read differently to Gemini — in practice that just rewards being explicit about who you're addressing and what you expect back (good hygiene for humans too). I've considered an optional structured envelope for handoffs (task id, expected reply), but kept the core unstructured on purpose — that's what lets it work across tools that agree on nothing else.
been playing the copy-paste courier between claude code and codex for months - feels embarrassing in hindsight. the sqlite approach is just right, no extra process to manage and the whole thread is right there to inspect. curious how turn-taking holds up with 3+ agents but the 2-agent case is exactly what i need
agmsg
@galdayan ha, the "embarrassing in hindsight" part is universal — that's literally why I built it 😄. 2-agent is the rock-solid case, exactly what you need. 3+ works on the transport side (sqlite handles N fine), but turn-taking gets messy — you start needing light addressing (who's this for?) or a coordinator agent. The DB scales; the social protocol is the hard part.
Love this, being the copy-paste relay between Claude and Codex is so real. When you run several agents in one room, how do you keep them from talking over each other or looping?
agmsg
@ianhxu Thanks Ian! Two layers: the floor and the protocol. The floor (the SQLite log) gives you strict ordering — every message is an ordered row with an explicit from → to, so agents aren't shouting into a shared channel; they react to what's addressed to them. Loops are a protocol concern: the kickoff prompt carries the stop condition ("max N exchanges", "reply DONE when finished") — agmsg won't cut a conversation off for you. In practice we run an 8-agent team this way, and explicit addressing + a done-signal convention keeps it surprisingly civil. Much like a human group chat, honestly.
The "sitting between two systems being their courier" framing is painfully accurate - I do this every day with Claude + a browser-driving agent. Shared SQLite over MCP is the right primitive: zero dependency hell, persistent across sessions, and you can grep history later. Following.
agmsg
@david_marko that courier feeling is exactly it 🙏 one tiny correction — agmsg isn't over MCP, it's standalone (just bash + one sqlite file), which is what kills the dependency hell you mentioned. But you nailed the rest: persistent across sessions, grep the history later. Thanks for following!
Nice idea. The useful part here is not just agent-to-agent messaging, it’s making the handoff reviewable.
For this kind of workflow I’d want to see the boring details: message history, which agent changed what, failed handoffs, and a clean way to replay or inspect decisions after the fact. Shared SQLite feels like a reasonable simple starting point.
agmsg
@kevinzrzgg
You're pointing at the part I'm most interested in. Because it's all just SQLite, the message history is already queryable and replayable after the fact — you can reconstruct who said what, to whom, when.
The "which agent changed which file / failed handoffs" layer is where I want to take it next — right now you get the conversation, not a structured audit of actions. Tying messages to actual diffs is the obvious step. Appreciate you naming it; it's the boring-but-important stuff that makes this usable past a demo.