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.

Top comments (0)