We had a real bug: retried webhook calls and client M2M transactions with duplicate reference keys were triggering unhandled PostgreSQL duplicate-key violations (23505) in CreditService, crashing the service instead of handling the retry idempotently. I fixed it in Antigravity — caught the 23505 on both debitOrgCredit and grantOrgCredit, returned the current balance instead of throwing, added tests. Good fix; took a few real attempts to land cleanly.
Here’s the part that used to bother me: if a teammate hit that same crash an hour later in Claude Code instead of Antigravity, none of that context would exist for them. They’d burn their own five turns rediscovering a fix that already happened, because the knowledge lived inside one session transcript in one tool.
That’s not an Antigravity problem or a Claude Code problem. It’s what happens whenever a team uses more than one AI coding tool: every fix, every convention, every “oh yeah, we don’t do it that way because X” lives and dies inside one person’s session transcript. Switch tools, and it’s gone. Onboard a new teammate, and it’s gone. Come back to the repo in three weeks, and it’s gone.
We built MemCell — persistent memory infrastructure for coding agents — specifically because we kept hitting this ourselves. This post is a straight walkthrough of how it actually works: how two agents from two different vendors (Antigravity and Claude Code) end up reading from the same memory, how that memory stays versioned with your repo instead of living in someone’s local settings, and what “sharing across projects” does and doesn’t do today.
Skip this if you’ve read the docs. Otherwise, three terms come up a lot below, and it’s worth defining them plainly first:
Project — an isolated memory namespace mapped to a specific repo. By default, nothing crosses between projects. A rule your Next.js frontend learned doesn’t leak into your Python backend’s memory, even if both are connected to MemCell.
Statement — the actual unit of memory. MemCell describes it as “an atomic, verifiable rule about how code in your codebase must behave.” Every statement carries a confidence score and moves through a lifecycle: Candidate (0.40–0.69, still being tested) → Verified (0.70–1.00, actively injected into agent prompts) → or Quarantined (under 0.40, pulled out after it fails a build or contradicts something else).
Two different kinds of “sharing” — this is the part worth being precise about, because the rest of this post is structured around the distinction. Sharing across agents in the same project is automatic — Antigravity and Claude Code both read from and write to one project’s memory in real time. Sharing across different projects is a separate, deliberate action, because project isolation is intentional (more on that in Part 2).
In the project root:
npx memcell connect
memcell connect
Worth knowing what this actually does, because it’s the part that makes the rest of this credible rather than magic: it writes .agents/hooks.json and registers four lifecycle hooks — PreInvocation (memcell hook prompt-submit antigravity), PreToolUse (memcell hook before-act antigravity), PostInvocation (memcell hook turn-end antigravity), and Stop (memcell hook session-end antigravity). Those hooks are what let MemCell inject matched invariants before Antigravity acts, guard against violations mid-turn, and calibrate confidence against the actual outcome afterward. Nothing about this lives outside your repo’s own config files.
Teaching it something:
Let’s work on the failing test case mentioned in the intro below:
The idempotency fix was implemented in credit-service.ts:
Issue fixed.
The Stop hook parses the transcript, and because it has a real test run to calibrate against — red, then green — MemCell had already turned it into a statement by the time I checked the Memory tab a few minutes later:
Worth pointing out what’s not on that card: there’s no field where the agent describes what it thinks it did. The confidence score, the stability multiplier, and the reinforcement count all come from the test runs it just watched pass and fail — not self-reported.
Recalling it: from a completely different agent
Now I switch over to Claude Code — same project, brand new session, and this is the important part: no context from me. I didn’t mention CreditService, duplicate keys, or 23505 anywhere in the prompt:
“I’m about to touch the credit debit/grant logic in CreditService — anything I should know before I start?”
Claude Code surfaces the exact rule Antigravity’s fix taught it a few minutes earlier — the duplicate-reference handling, the PG 23505 catch, the idempotent-return-instead-of-throw pattern — without me explaining any of it. It’s not reading Antigravity’s session transcript, and it’s not reading a shared CLAUDE. I didn’t update it by hand. It’s recalling a statement from project memory that a different agent, from a different vendor, wrote a few minutes ago. Antigravity fixed it once. Claude Code just inherited it for free.
Here’s the question that matters most for a team, and it’s the one with a real, unglamorous answer rather than a philosophical one: how does this stay universal across a team, regardless of which agent each person happens to use?
You commit the hook files. .agents/hooks.json and .claude/settings.json are just JSON living in your repo — MemCell’s own docs describe them as configuration that “can be version-controlled or kept local,” which is another way of saying it’s your call, same as any other dotfile. Treat them the way you’d treat .editorconfig or .gitignore: check them in, and anyone who clones the repo and runs connect inherits the same wiring. Nobody has to manually configure hooks in their own local settings, and the convention travels with the codebase instead of living in one engineer’s machine.
Everything above happens inside one project. That’s deliberate: MemCell’s own platform docs state that “statements learned in one project never bleed into another project unless explicitly shared,” specifically so that conventions from, say, a Next.js frontend don’t quietly leak into a Python backend’s memory. Isolation-by-default is the correct call here — you don’t want an unrelated repo’s rules contaminating your codebase because two projects happened to share a MemCell account.
Click on the “Add to project” button (top-right) and check the box next to the project you want this rule to reach — in this case, a second project called agentreflex — and it’s done. No CLI flag, no export/import step. Worth noting the line at the bottom of that picker too: “Copies with full provenance.” That’s not a throwaway label — it’s the answer to the question the rest of this post keeps coming back to. This isn’t a plain copy-paste of the statement text into a new project with no memory of where it came from; the origin travels with it. There’s also a + new project option right there if the destination doesn’t exist yet, so you’re not required to go create it first in a separate step.
The statement showing up in the agentreflex project.
Zoom out: this post covered two problems that feel like one until you’ve actually hit both. The first: “I fixed this in one tool, and my teammate’s about to re-fix it in another” — solved automatically, in real time, the moment two agents share a project. The second: “this convention belongs in more than one repo” — solved deliberately, one click, with the rule’s origin intact instead of turning into an unsourced copy-paste the second it moves. Neither of these was a solved problem for us six months ago. Both were just the accepted cost of running more than one AI tool across more than one repo.
None of this matters much for a solo developer working alone in one tool — you already remember your own fixes. It starts mattering the moment a team is running more than one agent across more than one repo, because a security requirement, a shared coding standard, or an internal library’s usage convention should only have to be taught once, to one project, and every other project and every other agent that needs it inherits it deliberately — provenance included — instead of every engineer rediscovering it independently, one bug at a time.
If you’re managing multiple repos with a shared team, how do you actually keep conventions in sync? Is it a CLAUDE.md that gets copy-pasted and inevitably drifts out of date? A wiki page that everyone forgets to update? Or just tribal knowledge that disappears when someone leaves? I’m genuinely curious, because before we built this, our own answer was painfully simple: “Nothing — we just keep explaining it, over and over, every time someone new asked.” https://memcell.ai/
We Stopped Re-Teaching the Same Bug to Two Different AI agents. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.