Claude and Codex Can’t Talk to Each Other. Usable Let Them Collaborate Anyway.

I started on Thursday morning, using Claude to build native iOS and Android applications for Usable.

By this weekend, the apps had become substantial. They had authentication, workspaces, chat, search, offline support, push notifications, sharing, store material and a very large test suite.

But they were not in TestFlight or the Google Play test track.

The product was largely there. The release was stuck.

There were several branches, red and cancelled CI runs, overlapping pull requests, store requirements, old task records and a long trail of conversations with different coding agents. Each individual session had made sense while I was in it. Looking at the project as a whole had become much harder.

So I tried an experiment.

Preparing a shared memory

I had used Claude for most of the development. Whenever I explicitly asked the agents to save implementation learnings, decisions and status updates as fragments in Usable, Claude did that well. The same was true when I told it to consult Usable before solving a problem.

The problem was that I had not made this retrieve-and-write-back loop mandatory throughout the development process.

Too much of the work happened without every agent first consulting what the project had already learned and without every completed task writing its new learning back to Usable. Claude followed those instructions when they were given. They simply were not given consistently enough.

That missing discipline helped create the messy end state: useful knowledge was scattered across conversations and worktrees, task statuses had drifted, and some conclusions had become stale as the code moved on.

Before attempting the release endgame, I asked every active Claude agent to record where it had reached and what remained.

That created something important: a durable project memory outside any single conversation, model or coding tool.

Then I asked both Claude and Codex to assess the entire project independently.

Two independent assessments

The prompt was deliberately broad: inspect the repository, GitHub, CI history and the newest Flowcore project fragments in Usable, then tell me the real state of the project.

Claude and Codex approached the problem differently.

They agreed on the central conclusion. The applications were feature-rich, but the project was not continuously green or ready for store delivery. Several release requirements still lived in unmerged work, and the project records presented a cleaner picture than reality.

But the value was not in the agreement.

It was in what each assessment found that the other missed.

Claude’s audit found two local worktrees containing uncommitted changes that existed nowhere else. A routine cleanup could have destroyed them. It also reconciled stale task statuses, release documentation and the order in which several overlapping pull requests needed to be handled.

Codex challenged the description of the product as “feature-complete.” The task slices might have been completed, but several requirements in the original product specification were still missing or had never been explicitly de-scoped.

It also looked more closely at some production-derived API fixtures. Claude had treated them mainly as a repository-confidentiality concern. Codex traced them into the iOS application’s resource build phase.

That changed the severity completely.

The issue was no longer merely that sensitive fixture data existed in a private repository. A normal iOS archive could potentially include it in the distributed application bundle.

That became a release blocker.

The useful part was the disagreement

At this point I did not simply choose the assessment I liked best.

I asked Claude to read Codex’s assessment from Usable.

Claude changed several conclusions.

It withdrew the claim that the project was PRD-complete. It accepted Codex’s evidence that most of the changing iOS failures were more consistent with an overloaded CI simulator than with many independent product bugs. That changed the recommendation from chasing tests one by one to sharding the suite while separately investigating the one failure that appeared consistently.

Claude also added findings it had missed, including the absence of required branch protection and the fact that the release workflows had never actually produced and uploaded artifacts.

Then I asked Codex to read Claude’s reconciled assessment.

Codex changed its priorities too.

The stranded worktrees became the first preservation task. The production-derived fixtures became a hard “no release dispatch” gate. A support URL that led unauthenticated users to a login page became a store-readiness problem. Codex refined the integration strategy for the overlapping pull requests instead of treating each one independently.

Neither agent produced the final answer alone.

The useful result emerged through independent inspection, disagreement, verification and write-back.

From assessment to coordinated work

Codex then converted the reconciled state into a dependency-ordered release programme in Usable Tasks.

The work was no longer a loose checklist. Each task had acceptance criteria, dependencies, verification steps and links back to the project memory that explained why it existed.

And the process has already produced concrete results.

As I write this:

• the two vulnerable worktrees have been preserved as remote branches and draft pull requests, without merging their stale changes;
• the public support page and the association files needed for iOS and Android links are live with unauthenticated access;
• the main correctness repair has been merged;
• the post-merge iOS run produced an honest result instead of being hidden by a timeout: 131 of 132 UI tests passed;
• the remaining failure was narrowed to a test assumption about traversing a lazily rendered settings list, and a focused correction is being verified;
• stale project documentation and task states have been reconciled; and
• two additional store prerequisites—verified Android link coverage and account-deletion handling—have been made explicit rather than being discovered during submission.

The applications are still not in TestFlight or the Google Play test track.

That is the final test of this process, and I do not want to claim the outcome before it exists.

But the collaboration has already moved beyond producing an impressive report. It has preserved work, changed priorities, prevented a potential data exposure, improved the release plan and driven verified implementation.

What Usable did—and what it did not do

Usable did not reason about the project.

Claude and Codex did that.

Usable also did not replace the repository, GitHub, CI or live service checks. Those remained the sources of current operational truth.

What Usable provided was the durable layer between them:

• a place to record decisions and their reasoning;
• a way to preserve implementation learnings beyond one session;
• a shared project state that different toolsets could retrieve;
• a medium for one agent to challenge and improve another agent’s work;
• and a write-back loop that made the improved conclusion available to the next task.

Claude and Codex never shared a chat or context window. They collaborated asynchronously by reading and updating the same organisational memory.

That distinction matters.

The goal is not to make one enormous conversation that every agent must inhabit. It is to make the relevant learning available wherever the next piece of work happens.

It was not automatic

There is an important limitation in this story.

The workflow still requires discipline.

Agents need clear instructions to retrieve relevant memory before planning, to distinguish durable learning from temporary status, and to write verified results back after implementation. Without those habits, even a very capable model will solve the problem in front of it and leave much of the value trapped in its session.

The memory also needs maintenance. Old task states and stale summaries can mislead future work if live evidence and newer decisions are not given priority.

So this is not a story about adding a memory tool and watching autonomous collaboration magically emerge.

It is a story about creating an operating system for collaboration:

inspect current reality → retrieve prior context → decide and execute → verify → write the learning back

Usable makes that loop possible across models and tools. The working discipline makes it reliable.

The larger lesson

AI models will continue to improve, and the tools around them will keep changing.

An organisation may use Claude for one project, Codex for another and something entirely different six months from now.

If the knowledge remains trapped inside each tool, every change creates another restart.

The models are rented. The organisation’s memory should be owned.

What happened in this project is a small but concrete example. Two toolsets that cannot speak directly were able to build on, test and correct each other’s work because the project’s memory lived somewhere neutral and durable.

The real measure is not whether an agent remembers a conversation.

It is whether the organisation can carry what it learned into the next decision, the next task and the next tool.

I will write a follow-up when the applications reach TestFlight and the Google Play test track—or when the process teaches us something else that changes the conclusion.

For now, the experiment has answered one question for me:

Claude and Codex do not need to share a context window to collaborate.

They need access to the same trustworthy memory.