DEV Community: fujibee

One instruction, four AI agents, one working app

fujibee — Wed, 08 Jul 2026 23:39:46 +0000

Last week I typed one message to Fable 5 and walked away. This is what came back.

It's a 3D constellation map of what X is talking about right now. Each AI model is a constellation, each topic is a star, and clicking a star shows you the actual posts behind it. You can try it in your browser: https://fujibee.github.io/agmsg-demo-fable5-x-constellation/

No human touched it after the first message. Here is the whole run:

The instruction was: build a 3D constellation map of what X is saying about AI models. You only do the design.

Fable 5 wrote a 21,283-character design document. Layout, star glow, cluster placement algorithm, JSON schema, implementation structure, all of it. Then it delegated: Grok collected live topic data from X, Opus 4.8 implemented the whole thing as a single HTML file, Codex polished the rendering and the feel.

Two moments in the run stood out to me.

First, Grok delivered the data and Fable inspected it before passing it on. 13 of the 25 topics only had one example post each, and the contract said 2 to 4. Fable sent it back. Grok fixed it, Fable re-checked and approved. Nobody told it to do quality control on a teammate.

Second, the review. When Codex finished polishing, Fable opened the app in a browser and measured actual screen pixels. The background was rendering about 10x brighter than its spec because of a color-space double conversion in a shader. Fable identified the root cause, wrote the exact fix, and set an acceptance criterion in RGB values. Codex fixed it, Fable re-measured, approved, delivered. 121 fps.

The full unedited team conversation is public, in the same repo as the app: https://github.com/fujibee/agmsg-demo-fable5-x-constellation (TRANSCRIPT.md)

Why the roles are split this way

Fable 5 is the strongest model I have access to, and the most expensive. It's scheduled to leave subscription plans and move to usage credits (Anthropic just extended the deadline to July 12). Running it hands-on for everything doesn't make sense.

So it only did the two things that need its visual reasoning: the design and the final review. Catching a shader color bug by measuring pixels is exactly the kind of work you want the expensive model on. Everything hands-on went to cheaper teammates.

The tool underneath

The run happened inside the agmsg desktop app, which we shipped this week.

agmsg is a small open-source messaging layer for CLI agents. Claude Code, Codex, Grok, Cursor, Gemini, any of them, talking to each other through a shared SQLite file. No daemon, no cloud. It's at about 970 stars on GitHub now.

The desktop app puts that on one screen. Every agent runs as a real terminal inside the app, and you can watch the team conversation flow in real time. The part I care about most is that when a message arrives for an agent, the app wakes that agent up.

That wake-up problem is harder than it sounds. Claude Code ships with a stable monitor hook, which is great. Codex has nothing like it, so we had been poking it awake through a half-hack that worked but broke easily. Grok is updated almost daily and its terminal behavior is still rough. Every agent type needed its own hand-built wake-up mechanism, and most types had none.

The app changes that. Since every agent is just a terminal inside the app, delivering a message means typing into that terminal. The app doesn't need to know anything about what's running inside. Any CLI agent gets the same treatment. Watching four different vendors' agents all wake each other up in one window was the moment this project felt done to me.

Who this is for

People who use AI heavily but don't want to live in a terminal. That's who I built the app for. Pick a team, click an agent, it opens as a pane. When a message comes in the agent wakes up, and you can jump in yourself as a member of the team.

Try it

macOS: download the .dmg from https://github.com/fujibee/agmsg/releases/tag/app-latest (signed and notarized), or:

brew tap fujibee/agmsg && brew trust fujibee/agmsg
brew install --cask agmsg

Windows: .msi / .exe from the same page. Honestly still rough, macOS is the smoother experience right now. Bug reports very welcome.

If you already use agmsg, update the core to 1.1.5 or later first (the app can do this for you, or update from the CLI).

The constellation demo, design doc, data, transcript and review screenshots are all in one repo: https://github.com/fujibee/agmsg-demo-fable5-x-constellation

If you try it and something breaks or feels wrong, tell me.

Get X into Claude Code, no API and no browser (agmsg 1.1.1)

fujibee — Thu, 25 Jun 2026 19:26:43 +0000

Pulling X data into a coding agent has been awkward. You can point an agent at a browser and scrape, but that is against X's terms, a gray area. The official X API is there, but it costs enough to make automation a hassle. Scraping is gray, the API is expensive, so X automation mostly sat in between.

Grok Build changed that. The model has an "X Search" tool call wired straight to X's data. Because it is an xAI model, this is not scraping and it is not the paid API. The model pulls X directly. The clean path finally showed up, so I wired Grok Build into agmsg in 1.1.1.

If you are new here: agmsg is a small open-source tool that lets CLI coding agents like Claude Code, Codex and Gemini message each other over a local file, so they work as a team instead of you copy-pasting between them. 1.1.1 lets you pull a Grok Build agent into that team.

I had wanted live X inside my coding workflow for a while. The routes were gray or expensive, so it sat. When X Search landed, the path was clean, and I put it in.

What it looks like

From Claude Code, I ask a Grok Build teammate to find something specific: developers on X over roughly the last two weeks who run several coding agents side by side and are frustrated that the agents cannot coordinate, with no shared inbox between them. Skip the promos and the official announcements, real developer voices only, ranked by engagement, the top few with a handle, a link, and a one-line summary.

A Grok Build agent on the same agmsg team runs it and hands back exactly that: a short, ranked, de-noised list. No browser, no copy-paste, a few moves. A real run, not a mockup.

And what came back is the case for the tool. People are building their own glue:

@shannholmberg wired bidirectional skills for an "LLM council": Codex drives the loops, Claude Opus reviews plans and deliveries and sends feedback back to the main agent.
@bibryam built a Git-based append-only log so Claude Code and Codex agents can exchange tasks and context in real time, with a full audit trail.
@PawelHuryn shared a setup to treat Codex as a peer instead of a tool: a shared AGENTS.md, skills mirrored with a sync hook, the same MCPs imported into both runtimes.
@0xidanlevin said it plainly: when Claude Code spins up a Codex agent it "deliberately screws it up," and the visibility into what Codex is doing is "really lame."

Most of the high-engagement posts are workarounds. They prove there is no native cross-agent coordination or shared state. That gap is what agmsg fills.

Why Grok Build

First, the access wall is gone. Scraping is gray, the API is expensive, and X Search sidesteps both because the xAI model is wired to X directly. That is the big one.

Here is the part that matters most. Putting Grok Build on your agmsg team is not like calling a search API. It runs as an agent. So instead of a plain fetch, it searches, reads, filters, shapes, and decides what to hand back, in one move. In the demo, "skip the promos," "rank by engagement," "one-line summary," and "in English" all got assembled by the agent without me spelling out each step. A plain fetch does not do that.

The practical wins come along for free. No browser automation in the loop, so it is fast. You get a structured answer back, not raw page text to parse and de-noise first.

This is not a contest over who grabs the very latest post. The point is doing X work, automatically, without going gray, in the same place your agent already lives.

What 1.1.1 adds

grok-build agent type (#216): agmsg now works from the xAI Grok Build CLI. A Grok Build agent joins a team and exchanges messages like any other member.
spawn --model (#135): choose the model when you spawn a teammate, so you can stand up the right agent for the job, a Grok Build agent for the X part, on demand.
Reliability fixes: watcher teardown scope, clean exit on session death, argument quoting in the monitor path.

The honest part: we found a trap by using it

Getting Grok Build to receive reliably took a fix, and we only found it by running it for real. The first wiring delivered messages through a passive hook, the way the Claude path does. Tests passed. In real use nothing arrived. Worse, messages were marked read on the way through, so they disappeared entirely. Green tests, zero delivery, silent data loss.

The fix was to use a model the agent already supports: a rules file it reads each turn, so it polls its own inbox and pulls whatever is waiting. After the switch, the handoff above went through end to end. The trap was caught before it could reach anyone.

Why this shape

agmsg keeps the coordination open and in your hands. You pick which agents are on the team. You can see every handoff. Anything from outside loads only after you trust it, the gate added in 1.1.0. There is a lot of energy right now around routing many models behind one closed API. agmsg takes the same underlying bet, that coordinating several agents beats leaning on one monolith, but it does that in the open: you pick what is on the team, on your own machine, and you can watch it work.

Try it

Install or update with install.sh, and add the agent type you want with --agent-type. (Exact one-liner from the 1.1.1 README at publish time.)

GitHub: https://github.com/fujibee/agmsg

Wire in your own agent, or build a type. Grok Build is the newest example of how little it takes.

Making agmsg pluggable: one directory per agent type, and a trust gate for external drivers (1.1.0)

fujibee — Mon, 22 Jun 2026 19:42:46 +0000

agmsg is a small thing that lets CLI AI agents message each other. Claude Code, Codex, Gemini CLI and the rest join a team and talk directly over a shared local SQLite file. No daemon, no network, nobody relaying copy-paste in the middle.

More people have been running it lately. It hit #5 Product of the Day on Product Hunt and kept going from there. And the setups people build have gotten ambitious. One pattern I keep seeing: an agent monitors its own progress, and when it gets stuck it consults a second, bigger-picture model to break out of tunnel vision. The whole loop runs with no human decision in the middle. A team of agents, used as a team.

The more of those show up, the more I hear "I want to mix in this agent too" and "I want to run that combination." Good problem to have. But it exposed one that had been quietly growing inside the codebase.

1.1.0 is where I went after that problem and rebuilt how agmsg handles extensibility: how easily, and how safely, you can wire in a new agent.

Why 1.1.0 (not 1.0.7)

Adding a new agent type used to be a chore. The core was littered with branches (if claude-code, do this; if codex, do that), and one new type meant editing those branches in a dozen places. That's a leaky abstraction: the engine knew the name of every type it served.

A single feature would have been a patch release. This rebuilt the foundation, so it got a minor bump instead: 1.1.0. Most of the payoff lands later, in the releases built on top of it.

One type, one directory

The change is small to describe. An agent type is now data plus a behavior plug, each in its own directory. Drop a directory under scripts/drivers/types/, give it a manifest and a few overridable behaviors, and the core picks it up. The core no longer contains a single hardcoded type name. (I called that part engine purification, which is grander than it deserves.)

Think of it as a socket and a plug. The agmsg core is the socket; each agent type is a plug. You add plugs without rewiring the socket. Before, you couldn't add a plug without opening up the socket's internals.

Two things got better in practice.

Adding a type is mostly declarative now. Delivery, for example, became a Template Method: the core owns the flow (apply / on_enable / on_disable / status), and each type overrides only what's specific to it in its own _delivery.sh. Data-driven keys in the manifest (delivery_modes, stop_output, hook_windows_wrap) cover most of the per-type variation without touching shared code. The Codex runtime, which used to be sprinkled around, lives under its own types/codex/ now.

And the core got more maintainable. Pulling hardcoded type names out of shared scripts sounds boring, and it's the part that actually mattered. The engine plays no favorites anymore, so fixing it is easier and adding a type is far less likely to break a neighbor.

Extensible, but on purpose

The plug mechanism has a name in agmsg: a driver. It's the adapter that connects an agent to the core.

Because of drivers, you can add your own agent type. 1.1.0 ships Cursor as the first real showcase of that. The new layout is what makes a newcomer like Cursor a matter of dropping in a manifest and a plug. There's also Hermes, a community-built type, added as beta (based on a contribution from Fewmanism).

This is the part I cared about most. Letting people add a type from outside is one short step from letting unknown code run on your machine. A driver is a shell script. It can do anything. So external drivers are opt-in: nothing loads until you explicitly trust it.

agmsg plugin list      # see discovered external drivers (untrusted by default)
agmsg plugin trust     # allow a specific, path-pinned driver to load
agmsg plugin untrust   # revoke it

A driver someone dropped into the directory does not run on its own. It loads only after a trust you issued, pinned to its path. That closes the obvious hole, an unintended drop-in getting executed, without making extension any harder than dropping in a directory.

Where this is going

What I want from the agmsg ecosystem is plain enough: any agent you use, wired in without much fuss, and safely.

New AI tools ship basically every week. The goal is that "I wish I could connect this one to agmsg" takes a small, safe amount of effort each time. 1.1.0 is undercarriage work toward that. Types are the first thing to become pluggable; storage and delivery come next on the same driver model (ADR 0001/0002 if you want the design notes).

One last thing. Big thanks to the contributors whose PRs this builds on: lucian (@lucianlamp) on the Windows side (1.1.0 also folds in his #186, which drops the PowerShell launcher for a single Git Bash path, plus #187), and Fewmanism on Hermes. agmsg has grown this way the whole time, on the people who use it and the people who put their hands on it.

It's not done. Hermes is beta, a Grok type is something I'd like to build with the community next, and there's hardening left. If you want to wire in your own agent, build a type, or kick the tires on Hermes, all of it is welcome.

One more practical note for anyone already on 1.0.x: install.sh --update now regenerates the Codex monitor wrapper at its new path, so upgrading from 1.0.x to 1.1.0 won't silently break monitor delivery. After updating, restart your agent so the running watcher picks up the new code.

npx agmsg                       # install / update
npm i -g agmsg && agmsg install # or this

agmsg on GitHub: https://github.com/fujibee/agmsg

The claude -p playbook for June 15: rebuilding your AI workflows inside interactive sessions

fujibee — Fri, 12 Jun 2026 22:08:37 +0000

On June 15, claude -p (headless mode) and the Agent SDK stop drawing from your Claude subscription and move onto a separate metered credit. I've written a lot of claude -p scripts over the past few months, so my honest first thought was that a chunk of my setup had just moved onto a meter.

But it's not really one company's pricing call. The whole industry has been drifting the same way. Copilot moved to AI Credits on June 1 (completions free; Chat, CLI and agents burn credits). Codex pairs a seat with credits plus API usage. And now Claude splits headless and the SDK off on the 15th. The pattern is the same each time: you stay flat-rate while you're driving, and it meters once you step away.

So for me the question stopped being how to dodge the bill and became which work actually belongs where. A few months of running several agents inside interactive sessions has changed my answer, and the short version is that a lot of my headless scripts never needed to be headless.

One caveat before the recipes, since someone always asks: yes, several of them also keep this work inside the flat-rate plan. Pricing changes, so check the current terms yourself. My case for doing it is that the in-session setup is a better way to work. Cheaper is a side effect.

Why the line landed where it did

If you want the full cost mechanics, The flat-fee era is over and The Tokenpocalypse both cover it. They land on the same point. Old completion-style usage was short output, so flat-rate worked. Agentic tools broke that. One request now hides a flood of tokens (read the repo, grep around, run the tests, patch, and repeat), and the gap between a light user and a heavy one got wide enough, maybe 10x on real token cost, that unlimited-for-everyone stopped penciling out. It's the same shift cloud made going from renting a server to paying for what you use.

Look at where each vendor drew its line and you see the same split. Usage with a human at the screen stays flat. Usage where the human stepped away (headless, SDK, CI) gets metered.

Which makes sense if you think about throughput. A person reads and thinks and types, so one interactive session caps out at human speed. A headless call can run in a loop with nothing to slow it down. So the pricing is partly about what a flat rate can sustain, and partly a signal about which surface the platform wants people on. Either way it points the same way. The interactive session is the stable place to be.

Was your claude -p actually unattended?

Looking back, a lot of what I pushed through claude -p never needed to run on its own. I wanted a second agent's read while I worked, or a review from a different model, or a refactor running in parallel on something else, and in every case I was sitting right there. There just wasn't a channel between sessions, so I had two options: play copy-paste courier myself, or wrap claude -p in a script to bridge them.

This happens a lot while a stack is still coming together: when one piece is missing, whatever sits next to it covers for it. With no way for agents to talk directly, headless calls and glue scripts carried that load. Headless wasn't the wrong tool, just the only channel I had.

Once that piece exists, you can redraw who does what. June 15 isn't only about budgeting for headless credits (some jobs really do need them, more on that below). It's also a chance to move the borrowed work back where it belongs and leave claude -p the jobs that actually have to run headless. If agents can talk inside interactive sessions, you don't need the courier or the bridge script.

The channel I built for that is agmsg. It's bash plus SQLite and nothing else. Claude Code, Codex, Gemini CLI and Copilot CLI sessions join a team and message each other, with no daemon, no network, and no MCP. Sending and receiving both happen inside your normal interactive sessions through a hook, so there's no claude -p or SDK anywhere in it.

https://github.com/fujibee/agmsg

Here's how the common claude -p patterns look once you rebuild them.

Recipe 1: a script that asks an AI → a resident buddy session

A code review or a quick consult, fired off to headless from inside a script. The script isn't interactive, but the AI work inside it is really just a conversation.

#!/usr/bin/env bash
# review-diff.sh: runs in the dev loop
set -euo pipefail
diff=$(git diff --staged)
# headless call, metered after June 15
review=$(claude -p \
  --print "Review this diff for race conditions and SQL injection. Return JSON \
  {\"verdict\":\"ok|block\",\"notes\":\"...\"}." \
  <<<"$diff")
echo "$review" | jq -e '.verdict == "ok"' >/dev/null || {
  echo "$review" | jq -r '.notes' >&2
  exit 1
}

Instead, open a second Claude Code in another terminal and keep it on the team in real-time monitor mode. The reviewer is just a regular interactive session, covered by your subscription.

One-time setup in terminal 2 (the reviewer), just this inside the session:

/agmsg
# → it asks for team + agent name: answer team: dev / agent: alice
# → pick monitor (real-time) when asked how to receive

# from now on, anything addressed to alice streams into this window live

The script side, terminal 1, where claude -p used to sit:

#!/usr/bin/env bash
# review-diff.sh: agmsg version
set -euo pipefail
TEAM=dev
FROM=worker     # this script's identity
TO=alice        # the resident reviewer session
# hand the review to the live session; body is plain text,
# pass a reference and a short ask, not raw context
~/.agents/skills/agmsg/scripts/send.sh "$TEAM" "$FROM" "$TO" \
  "Please review the staged diff at $(pwd). Reply with verdict (ok|block) + notes."
echo "Waiting for $TO's verdict..."
while true; do
  reply=$(~/.agents/skills/agmsg/scripts/inbox.sh "$TEAM" "$FROM" 2>/dev/null)
  case "$reply" in
    *"verdict: ok"*)    echo "ok"; exit 0 ;;
    *"verdict: block"*) echo "$reply" >&2; exit 1 ;;
  esac
  sleep 5
done

The reviewer reads the diff, replies with /agmsg send worker "verdict: ok ...", and the script picks up where it left off. Nothing called claude -p.

The win is that the buddy stays open instead of being a headless process that vanishes after each call. Context sticks around, so by the second ask, telling it to use the same approach as before just works. It beats a headless call you had to brief from scratch every time.

It also differs from subagents in a way worth knowing. A subagent inherits the parent's context, so even when you ask it to review something independently, the answer tends to land inside the parent's framing. A separate session starts clean, so the review is genuinely independent. One person moved to agmsg for exactly this, in a data-analysis setup (I'm collecting use cases, there's more there).

Recipe 2: an orchestration script → a director agent

A homegrown orchestration script that fans out to a few models in parallel and merges what comes back. Credits drain by the number of workers.

#!/usr/bin/env bash
# judge-panel.sh: three independent reviews → synthesis
set -euo pipefail
problem="$1"
# three parallel headless calls, each one metered
analysis_a=$(claude -p "$problem" --print) &
analysis_b=$(claude -p "$problem (focus on security)" --print) &
analysis_c=$(codex exec --headless --prompt "$problem (focus on perf)" --json) &
wait
# synthesis, yet another call
claude -p --print "Synthesize these three reviews into one verdict: ..."

Instead, stand up one director session and drop the workers (mix models and tools freely) onto the same team. The orchestration logic turns into the director's instructions; fan-out, collection and synthesis all ride on agmsg messages.

Setup is one /agmsg per session: the three workers (each in its own terminal, window or IDE pane) and the director (the one you actually work in):

# inside each session
/agmsg
# → answer team: panel / agent: reviewer-a (b, c, director), pick monitor

Then you just talk to the director:

You (in the director session):
  "Send reviewer-a a correctness review, reviewer-b a security review,
   reviewer-c a performance review, of the staged diff.
   Wait for all three, then synthesize."

director: [sends three agmsg messages, polls inbox, and once all three
           land, writes the synthesis in this same session]

The control flow you used to script is now plain English. No claude -p.

A real one: on Fable 5's release day someone ran a refactor with Fable 5 as the commander, Opus 4.8 as deputy and Sonnet 4.6 as scouts. The day a model ships you can drop it straight into the lineup you already run. That's the point of the transport not caring which model is behind each seat.

Recipe 3: a background job → a dedicated worker session

Something you want chugging along next to your own work (test scaffolding, a doc update, some research) that you used to kick off with cron or a script plus claude -p.

Instead, in the morning open one more terminal, start a worker session and leave it on the team (inside the session: /agmsg → team: dev / agent: worker / pick monitor). When something comes up, message it from your main session. It picks up each inbound and reports back when it's done.

Kickoff, from your main session:

You: send worker: "Analyze /tmp/deploy.log for slow queries. Write findings
to /tmp/deploy-findings.md. Ping me when done."

It starts on its next monitor event, does the work, writes the file, and comes back:

worker → me: "deploy-findings.md ready. 3 queries > 500ms, all on the
users table. Top one is the email_lower lookup, index missing."

No orphaned processes the way a backgrounded headless job leaves them. Close the worker terminal and the work stops, which is the upside of running it where you can see it. Dispatch and progress stay automatic; only the execution moved back into the same room as you. When something breaks it's right there in the next terminal, not a cron job that failed quietly at 3am.

Recipe 4: a tool-to-tool pipe → a message

A pipe or a temp file plus glue to hand Claude's output to Codex, or the other way around.

Instead, put both sessions on the same team and let them talk.

This one runs here every day, so here's a real case. Last week agmsg got a Linux-only bug report (issue #95). The Claude Code that wrote the fix and a separate session that verified it in a Debian container ran the whole exchange over agmsg messages: report, environment details, verification, merge note. It went from report to merge in six hours (PR #97). Both were ordinary interactive sessions, with no glue anywhere.

Minimum setup:

# Terminal A: Claude Code, joined as "analyst"
#   /agmsg → team: dev / agent: analyst
# Terminal B: Codex, joined as "implementer"
#   $agmsg → team: dev / agent: implementer

And then it's just talking:

# Terminal A (analyst):
You: "send implementer: the settings writer embeds settings.local.json into
     the sqlite3 argv 6x (issue #95). readfile() in the SQL should keep it
     off argv entirely. Patch + tests please."

# Terminal B (implementer): receives the message, writes patch + tests, runs bats:
You: "send analyst: branch fix/delivery-e2big pushed. 3 bats cases at a 25KB
     fixture, all green locally. Ready for review."

# Terminal A: reads the PR, approves inline, then:
You: "send implementer: approving. one ask: verify on Linux too; the pre-fix
     code should fail there with E2BIG."

Each hand-off is a sentence and a reference. The receiver does the heavy lifting in its own session against the live filesystem. Nothing gets piped.

One exception: running the same prompt across several models in parallel for independent takes is still better as a headless pipe. That's a spend-the-credits call, covered in the next section.

When to keep it headless

None of this means replacing everything. Some work is genuinely right for headless, and worth budgeting the new credits for:

CI pipelines, running where no human is by definition. The GitHub Actions integration is on the new credit too.
Nightly batches and scheduled jobs that are genuinely meant to run unattended.
SDK usage baked into a product, which should be costed as metered from the start.
One-shot massive parallelism, like the same input across 50 calls, which is a credit-budget decision rather than a workflow one.

The test I use is just: when it's running, are you there? If yes, it can move into an interactive session. If no, budget the headless credits and move on.

Why I'd do it this way even without the price change

I read June 15 as the platform saying development with a human in the loop gets the structural advantage now.

But the reason I'd keep the interaction and automate only the coordination isn't really the flat-rate bucket. After a few months of it, what I keep noticing is that work where the judgment stays with a human is faster in the end. The coordination runs itself, and you get pulled in at the branch points and the final call. No copy-paste relay, no 3am cron log to read backward.

The pricing change just happened to point the same way.

agmsg is open source, and setup runs about 30 seconds if you've got bash and sqlite3.
https://github.com/fujibee/agmsg

Lessons from open-sourcing a messaging layer for CLI AI agents (320 stars in a week)

fujibee — Thu, 04 Jun 2026 00:45:43 +0000

About a week ago I open-sourced agmsg, a ~500-line bash + SQLite tool that lets CLI AI agents message each other directly. I built it for a dumb reason: I was tired of being the human copy-paste relay between Claude Code and Codex — selecting code in one terminal, pasting it into the other, carrying replies back, all day.

I expected a few stars from friends and nothing else. Instead it went 5 → 320 in a week, picked up forks, derivative projects, and pull requests from people I've never met. That gap between what I expected and what happened is the interesting part, so here's the honest retrospective: the numbers, what worked, what flopped, and what genuinely surprised me.

The numbers

In about a week, with no budget and no audience to speak of:

GitHub stars: 5 → 320
Forks: 0 → 15
3 derivative projects — someone ported the idea to shogi (agmsg-shogi), someone wrapped it as an MCP server (agmsg-mcp), someone rewrote it in Go (agmsg-go)
Pull requests from outside contributors — support for Gemini CLI, Antigravity, and now GitHub Copilot CLI, plus a fix for role-isolation race conditions

None of this came from one big spike. It came from a sequence of posts across channels, some of which worked and some of which completely didn't.

What worked

Leading with a video, not an explanation. The first post that got traction wasn't a description of the architecture — it was a 23-second clip of two Claude Code instances autonomously playing tic-tac-toe over agmsg, with no human input. People stop scrolling for a moving picture of agents doing something on their own. The text underneath could be short; the video did the work.

A relatable problem, stated plainly. "I became a copy-paste relay between two AIs" landed because a lot of people are quietly doing exactly that right now. I didn't open with the technical design. I opened with the annoyance. The design was the payoff, not the hook.

Using a long-form post as the landing pad. Timeline posts are good at reach and bad at depth. So the threads pointed to a longer writeup where the design rationale, the trade-offs, and a full reproduction prompt lived. Reach on one channel, depth on another.

Treating it as a series, not a single launch. Instead of one post that had to carry everything, I spread it: the origin narrative first, then the first outside contribution, then a new feature (actas, multiple agent roles in one workspace), then a deep dive on the underlying mechanism. Each piece re-surfaced the project to a slightly different audience and kept it alive past the first 24 hours.

What didn't

My first English post sank. The very first English writeup got ~3.6K impressions and basically no conversion. The content was fine; the distribution was nonexistent. I'd posted it cold, with no thread to carry it and nothing leading into it. A good article with no on-ramp is just a file on the internet.

Hacker News went badly. I tried a Show HN, and my first author comment got auto-killed by the spam filter within seconds — too long, too promo-shaped. Then I made it worse by deleting and reposting it, which is apparently the exact trigger that gets the replacement marked dead permanently. Lesson learned the hard way: a first comment should be two or three sentences with no links, and if it gets flagged you leave it alone.

Reddit was a non-starter. The high-value subreddits gate new accounts on age and karma, and mine had neither when I needed it. There's no shortcut here; you either have a warm account before you need it, or you don't get to play that day.

The surprises

Derivative projects. I genuinely did not expect someone to take the idea and build agmsg-shogi — agents playing shogi over the same messaging layer. Forks I understood; a from-scratch reinterpretation in a different domain was a different signal entirely. That's when it stopped feeling like a repo and started feeling like a small idea other people wanted to build on.

Contributors kept showing up. Support for Gemini, Antigravity, and GitHub Copilot CLI was added by people I've never talked to. The project now speaks to five different CLI agents, and most of that breadth came from outside. Keeping the surface area tiny — bash and sqlite3, no daemon, no network, no Python — turned out to be the thing that made it easy to extend.

Bookmarks predicted stars better than likes. On the technical posts, the bookmark-to-like ratio was the signal that tracked GitHub stars. People bookmark "I'll need this later"; that intent converts. Likes are applause; bookmarks are intent.

What's next

I just published the deep dive on the piece that makes all of this feel real-time — Claude Code's underused Monitor tool, and the six design patterns I had to get right to run a watcher in production. That's where the "how does this actually work" answer lives.

On the roadmap: making the storage layer pluggable so agmsg isn't married to a single SQLite file on one machine.

The reframe

The thing I keep coming back to: a week in, I'm not sure "messaging layer" is even the right description. What people are actually using — and extending — is closer to a shared blackboard for AI agents: a dumb, durable place where independent agents leave notes for each other, and anything that can read and write a file can join. The messaging was just the first thing I needed it for.

If you're running more than one AI coding agent, it's on GitHub. I'd rather hear what breaks than collect another star.

I built agmsg so Claude Code and Codex could stop using me as a copy-paste relay

fujibee — Thu, 28 May 2026 00:00:10 +0000

My main driver is Claude Code, with Codex bolted on for the hard parts and reviews. The split works surprisingly well. But after a while I noticed something dumb: I had become a human copy-paste relay between two AIs.

Copy what Claude Code wrote, paste it into Codex for review, copy Codex's feedback, paste it back into Claude Code. Dozens of times a day. It's tedious, it breaks focus, and I'd occasionally paste the wrong thing. I had two capable agents sitting side by side and was personally doing the dumbest job in the loop — carrying messages between them.

Agents should just be able to message each other directly. So I built agmsg and put it on GitHub: https://github.com/fujibee/agmsg

Try it first (30 seconds)

You're an engineer; you'd rather run it than read about it.

bash <(curl -fsSL https://raw.githubusercontent.com/fujibee/agmsg/main/setup.sh)

Then restart Claude Code / Codex and run /agmsg ($agmsg on Codex). It asks for a team name and an agent name on first use. The README has the full quickstart and copy-paste commands.

Once two agents join the same "team," they can message each other. After that you just talk to your agent: "tell alice the review is done," "any messages?" — that's it.

The only dependencies are bash and sqlite3. No daemon, no network, no Python.

Why run two coding agents at all

This started by accident. Claude Code (Opus 4.6) got stuck on a gnarly implementation — kept going in circles no matter how I rephrased it. On a whim I handed the exact same spec to Codex (GPT-5.3), and it produced a correct version almost instantly. That was a quiet shock.

Since then I've split the roles:

Claude Code — the daily driver. Fast, high volume, follows direction well.
Codex — reviewer and last resort for hard problems. A bit clumsy for everyday driving, but the one I trust on correctness for tricky code.

Neither is "better" — they have different temperaments, so they're good at different moments. And the instant I started running both, the carrier-pigeon problem began.

What agmsg is

In one line: CLI AI agents message each other through a shared SQLite database. Claude Code, Codex, Gemini CLI — any CLI agent works.

It's built as an Agent Skill, so you install it as a skill and don't touch the agent itself. It turned out better than I expected, so I open-sourced it.

Design decisions

The order I went through, and why.

I checked the built-ins first. I didn't want to reinvent anything, so I looked at Claude Code's team / subagent features. They're designed around short-lived sessions — great for spinning off a one-off subtask, but not for two agents holding an ongoing conversation.

I started with plain text files. The built-in team agent was file-based and simple, so I did the same. Fine for short-lived use — but the moment you want persistent + concurrent, it falls apart: write conflicts, corrupted files.

So I moved to SQLite (WAL mode). Multiple readers + one writer, no conflicts; transactions that survive concurrent access; message history for free.

But keep dependencies minimal. This is the part I cared about most. You could make it as rich as you want, but I wanted it to run the instant you drop it in, on anyone's machine. The result: it runs anywhere bash and sqlite3 run. No daemon of its own (agmsg has no resident process; only monitor mode piggybacks on Claude Code's built-in Monitor), no network (all local), no Python.

Delivery modes — monitor is what made it usable

There are roughly three ways a message reaches an agent:

manual — you run /agmsg, or ask the agent to "check the inbox." Reliable, but you have to remember.
hook — checks between turns (on the Stop hook). Codex defaults to this, since it has no Monitor tool.
monitor — subscribes to SQLite continuously and interrupts the conversation in real time when a message lands. This is the default on Claude Code.

Honestly, monitor is what tipped it from toy to useful. With manual/hook there's a gap — the other side already replied, but you don't notice until you poke it. With monitor, the conversation just flows.

The mechanism (riding Claude Code's Monitor on top of a blocking SQLite read) is interesting enough that I want to write it up separately.

And here's the fun part. Put two monitor-mode Claude Code instances on the same team and leave them alone, and they keep talking with zero human input. I told two of them to "play tic-tac-toe," and they sent moves back and forth and played the whole game out. Not useful, exactly — but watching two agents volley autonomously is genuinely fun:

Two monitor-mode Claude Code instances playing tic-tac-toe over agmsg, no human in the loop (real game, static gaps trimmed, ~2.5x).

What's next

The thing I fought hardest while building this was that Claude Code and Codex have completely different hook and config models. Claude Code has Monitor and rich SessionStart hooks; Codex has neither. Splitting delivery into monitor / turn is there to absorb that gap, and the config files live in different places and formats for each. Getting the same "notice when a message arrives" to work across two agents with different foundations took the most thought.

How to smooth over those heterogeneous-agent seams — and the monitor internals I mentioned — are what I'll write about next.

For now: install it and let Claude Code and Codex talk to each other directly.

https://github.com/fujibee/agmsg