In today’s newsletter:
Turn your agents into a team that works toward shared goals.
How top AI teams scale to 1,000+ agents.
Turn your agents into a team that works toward shared goals
Most of us still glue our agents together by hand. One writes the plan, another looks at the data, a third ships the change, and we sit in the middle passing context around.
Rowboat is an open-source, self-hostable layer that turns those agents into a team working toward shared goals.
It can bring Claude Code, Codex, and Hermes into one team. Any agent that supports MCP can join too, so you stop being the glue between your AI agents.
You send one message, and a super agent:
Decides which agents the job needs
Asks your permission and creates them
Hands each one a task
Lets them pass work along in threads
Builds the result with them on a shared whiteboard
What makes it different:
Runs on the subscriptions or API keys you already have
See every handoff, and step in whenever you want
Or let Rowboat host your agents, if you’d rather not run servers
Free to use
The video above shows it in action. We loaded nine weeks of product data for a sample app into PostHog, then asked why new users were dropping off after week one. Hermes found where they dropped off in PostHog, Claude Code found why in the user feedback, and Codex built the dashboard.
(don’t forget to star it ⭐)
How top AI teams scale to 1,000+ agents
Cognition wrote in April that multi-agent systems work best when “writes stay single-threaded.”
This implies that while many agents can think in parallel, only one of them should save to shared memory.
Shared writes are risky for a concrete database reason, known as the lost update, in which two writers save the same record and the second save silently erases the first, with no error on either side.
For a developer running Claude Code and Codex in parallel on shared memory, this turns parallelism into a liability, because the more those agents write at once, the more of their saved work can potentially disappear.
Today, let’s understand why this happens, the typical solutions and their problems, and how Omnigraph (open-source), a graph database with the Git model built in, solves it, followed by a hands-on walkthrough with Claude Code and Codex.
Why shared agent memory loses writes
Agent memory updates are usually read-modify-write cycles, where an agent loads a record into its context window and later writes back whatever version the model produced.
So consider a shared project graph where Claude Code and Codex read the sessions component at the same moment, when it says Redis and has no owner.
Claude Code finishes first and saves the store as Postgres, while Codex, still working from its earlier read, sets the owner and saves its own copy of the record.
Codex’s copy still says Redis, so its save puts sessions back on Redis and erases Claude Code’s update. Both agents report success, and nothing in the logs shows that one of them was overwritten.
Agents make this worse than human users do.
A person editing a record usually changes one field and saves only that field, but an agent typically writes back the entire record it read earlier, so any field another agent updated in the meantime gets reset to the old value.
There are three common ways to fix this, and each has some trade-offs:
Single writer → one agent owns every write and the others send it suggestions, which keeps memory correct but caps the whole system at the speed of that one agent.
Locks and optimistic version checks → a conflict only fires when two writers touch the same record, so a version check would have rejected Codex’s stale save in the above case. Both still guard one record at a time, though, while an agent’s task usually spans several records and several steps, and neither leaves a diff to review or a history to audit.
Last write wins → every agent saves freely, and the latest save overwrites the rest, which keeps everyone fast and is exactly how Claude Code’s update disappeared in the above example.
Collectively, these fixes also miss isolation.
An agent working through a multi-step task needs its own workspace, a diff of what it changed, a review before that change is pushed, and a record of who changed what.
Code faced the same problem when many engineers edited one codebase, and version control solved it without making anyone wait.
In Git, each engineer works on an isolated branch, a diff shows exactly what changed, and a merge compares both sides against the commit they started from, called the merge base, so a change built on an outdated version gets caught before it lands, while the history keeps every step.
Agent memory needs that same versioning model, and that model is implemented by Omnigraph.
How Omnigraph applies the Git model to agent memory
Omnigraph is an open-source graph database, written in Rust under the MIT license, with the Git model built in, so agent memory gets branches, diffs, merges, and history.
Each agent writes to its own branch, so no agent waits on another, and nothing reaches main until a merge compares that branch with its merge base.
If main has changed the same record since the branch was created, the merge refuses the write, publishes nothing, and tells the agent to refresh and try again.
The binary also ships an agent skill, so Claude Code and Codex can drive branches and merges from plain-English prompts.
To test it, we started both agents together on two tasks that touch the same record. The recording below is the real run, with help-page lookups trimmed:
Claude Code and Codex running in parallel, each on its own Omnigraph branch.
Step 1: The CLI and the agent skill
The CLI installs with one script, and skill export writes the skill where Claude Code and Codex look for it:
curl -fsSL https://raw.githubusercontent.com/ModernRelay/omnigraph/main/scripts/install.sh | bash
omnigraph skill export ~/.claude/skills/omnigraph
omnigraph skill export ~/.agents/skills/omnigraph
Step 2: An agent-written schema
To demonstrate the usage of Omnigraph, we created shared data, which is a small project graph seeded with two components, sessions and billing.
Since it has Omnigraph skill, Claude Code wrote its schema and seed from one prompt, then created the graph on main, as shown below:
The only detail worth knowing is @key on each slug, which gives every record a stable ID that merges compare across branches:
Step 3: Claude Code and Codex on separate branches
Here, we gave Claude Code a multi-step task.
We asked Claude Code to record that sessions moved from Redis to Postgres.
To do that, it added a new decision, linked it to the component and the open issue, marked the old decision as superseded, changed the store to Postgres, and closed the issue. All six writes landed as one commit on its own branch, claude, as shown below:
At the same time, we asked Codex to set the owner of sessions to platform-team. This was a one-field change, and Codex made it on its own branch, codex, as shown below:
Both branches started from the same commit of main, so Codex’s branch still reads store: redis.
Step 4: Diff review and a fast-forward merge
Before Claude Code’s branch goes into main, we can review exactly what it changed.
Omnigraph compares the branch with the commit both branches started from, so the diff shows only Claude Code’s six writes and nothing else, as shown below:
Since nobody had changed main after the branch was created, the merge is a fast-forward. That means main simply moves up to Claude Code’s commit, so all six writes are pushed together.
This is the part a regular database doesn’t give you. A row lock protects one record at a time, but it can’t show you a multi-step change as a single diff or let you approve it before it goes live.
Step 5: The merge check refuses the stale branch
Next, we tried to merge Codex’s branch. Its diff shows only the owner change, but the merge still fails, as shown below:
The merge fails because both main and the codex branch changed sessions after the two branches were created. Omnigraph reports this as a divergent_update, publishes nothing, and tells Codex to refresh its branch, as shown below:
With no version check, a full-record save from Codex would have put sessions back on Redis, even though decision dec-12 says it moved to Postgres.
Omnigraph checks conflicts per record, not per field, so it refused this merge even though the two agents changed different fields. A false alarm costs one retry, while a stale merge that goes through quietly leaves a wrong fact in memory.
Step 6: Refresh, retry and snapshot reads
Next, we sent the merge result back to the same Codex session. Codex read the latest main, opened a new branch called codex-2, and made its change again, as shown below:
This time, the merge is a fast-forward, and main keeps both agents’ work. Old versions also stay readable. A query with --snapshot set to the original commit still returns Redis and no owner, as shown below:
Step 7: Only a reviewer can merge into main
Up to here, an agent could still merge its own branch into main without anyone checking it. Locally, nothing stops that. The --as flag only names who made a change, and any agent can type any name.
To lock main, we ran Omnigraph as a server, omnigraph-server, and gave each agent and the reviewer their own access token. With tokens in place, the server knows who is making each request.
Next, we added a policy. Omnigraph writes its policies in Cedar, an open-source language for writing access rules. Our rule says that agents can write on their own branches, and only the reviewer can merge into main.
Then we tested it. Claude Code’s token could still write on its branch, but its attempts to write to main or merge into it came back as HTTP 403, which means access denied, as shown below:
The reviewer’s token then merged the branch. So agents still work in parallel, but nothing reaches main until a person approves it.
What we ran here was local, with one developer and two agents.
The same race happens at a much larger scale. Picture a company where many people and their agents read and write one shared database, such as a support bot, a coding agent, and an analyst’s agent all updating the same customer records.
There, one stale write can spread wrong facts into every tool that reads that data.
Omnigraph’s model holds up at that scale too. Every person or agent works on its own branch, each change shows up as a diff someone can review, and only merges checked against the latest main go live.
You can find the Omnigraph GitHub repo here →
(don’t forget to star it ⭐)
👉 Over to you: How do your agents handle two writes to the same record today?
Good day!