Claude, Codex, and a shared system of work

• ai
• agents
• software-development
• engineering
• coordination

I did not need Claude and Codex to have a better conversation. I needed them to share a system of work.

TL;DR

I am building a system for the moment more than one coding agent is working on the same product.

• Claude and Codex can each do meaningful work. The problem starts when their work overlaps, depends on the same decision, or changes the same part of the system.
• Messages are not enough. A handoff file can explain what another agent did, but it cannot establish what was authorized, who owns the next move, or whether the result is acceptable.
• The work needs one shared record. Both agents should read the same outcome, boundaries, dependencies, decisions, and acceptance evidence.
• The human remains the operator. Agents can coordinate and execute within their boundaries. A human decides when the direction changes and whether the combined outcome should be accepted.

The system is not an agent chat room. It is a shared place where Claude and Codex can work on the same product without losing accountability.

I have been thinking about a practical problem that is arriving faster than most teams expect.

What happens when Claude and Codex are both working on the same product?

Not sequentially. Not as a novelty. At the same time.

Claude may be investigating an unfamiliar part of the codebase while Codex is implementing a related screen. Claude might be reviewing a migration while Codex is changing the API beneath it. Both can read code, write code, run tests, propose designs, and return a plausible answer.

At first, that looks like pure leverage.

Then the work overlaps.

One agent has found a new path through the system. The other has already started extending the old path. Both approaches are defensible. Neither agent should silently decide the architecture for the whole product just because it happened to get there first.

I did not want the answer to be: open another terminal window, ask one agent to write a summary, carry it to the other agent, read two long messages, make a call, and carry the answer back again.

That turns the human into a message bus.

So I started building a different kind of coordination system.

They are not interchangeable workers

Part of the reason this matters is that Claude and Codex do not behave the same way.

In my workflow, Codex has been especially useful for user experience work: looking at a screen as a person would, questioning visual hierarchy, refining interaction details, and iterating until an interface feels coherent. It is a strong partner when the question is, What should this experience feel like?

Claude has been especially useful for implementation work: tracing a codebase, carrying a technical plan through multiple files, reasoning about data and backend behavior, and turning an approved direction into working code. It is a strong partner when the question is, How should this system be built?

Those are not permanent or universal labels. Both agents can design, implement, test, and review. Their behavior also changes with the task, the context they receive, and the tools available to them.

But treating them as interchangeable loses useful leverage. If Codex discovers that a flow is confusing and Claude is implementing the supporting system, they need a way to share the decision without either agent silently becoming the owner of the whole product.

That is why the system records an agent’s role on a piece of work. The point is not to put agents in narrow boxes. It is to make their different strengths deliberate, visible, and coordinated.

The first version of the problem is deceptively simple

The obvious solution is a shared directory full of handoff files.

That is useful. It gives agents awareness of one another. One can write, “I changed the upload path,” and another can read it before making a conflicting change.

But awareness is not coordination.

A message answers one question:

What did the other agent do?

A product still needs answers to harder questions:

• What outcome are both agents trying to create?
• Which approach is actually approved?
• What is each agent allowed to change?
• Who owns an overlap?
• Which dependency changes the order of work?
• What evidence proves the combined result is acceptable?
• Who makes the call when two reasonable approaches disagree?

A folder of messages cannot answer those questions on its own. It preserves a conversation, but it does not govern the work.

That distinction is where the system I am building begins.

One product needs one shared record

The core idea is simple: Claude and Codex should not coordinate by passing notes about work. They should coordinate through the work record itself.

Every meaningful change has one durable home. It begins with the outcome the human wants, becomes specific enough to authorize, gives an agent a bounded assignment, captures the evidence produced, and ends with a human verdict.

Here is the smallest version of the record:

feature: unified-media-uploads

outcome: >
  Posts and social publishing use one durable file reference so images are
  stored, retrieved, and cleaned up through the same path.

boundaries:
  - Preserve existing published posts.
  - Do not change authentication or storage-provider configuration.
  - Escalate before changing the public upload API.

work:
  - agent: codex
    responsibility: review the upload experience and propose a clearer flow
  - agent: claude
    responsibility: trace the current path and implement the approved system change

acceptance-evidence:
  - Existing post images still render.
  - New post and social uploads reference the same file record.
  - Migration and regression tests pass.

decision:
  status: pending
  question: Approve the proposed migration path?
  recommendation: Approve it, then allow Claude to implement the bounded change.

The point is not YAML. The point is that both agents begin from the same intent, the same boundaries, and the same definition of success.

Codex can investigate the experience and propose a clearer flow. Claude can trace and implement the approved system change. Neither needs to guess whether the other agent’s local decision is now the product decision.

The record is not a task list

A conventional task list says that work exists. That is useful, but it is too weak for agents that can act.

The shared record needs to connect five things:

Intent → authority → execution → evidence → human verdict

Intent explains what should become true and why it matters.

Authority says what a particular agent may do, where it must stop, and when it needs to return for a decision.

Execution records what happened without pretending that activity is the same as progress or acceptance.

Evidence gives the operator something inspectable: tests, a demonstration, a measurement, a review finding, or a reproducible result.

Verdict is the human decision to accept, redirect, reject, or stop the work.

This is what lets Claude and Codex share a product without turning either of them into the source of truth.

Claude and Codex should coordinate through boundaries

There are two kinds of overlap that are easy to confuse.

A product dependency means one outcome genuinely needs another first. The new social-publishing flow cannot be completed until image storage has a stable path. That affects product order.

An execution collision means two agents may touch the same code, data, or external state. Claude may be reviewing the upload model while Codex is changing it. That affects safe execution.

The system needs to show both.

If it only shows tasks, an overlap appears late as a merge conflict or a confusing review. If it shows product dependencies and execution collisions separately, the operator can make the right kind of decision: sequence the work, change a boundary, choose one design, or let both agents proceed.

The agents do not need to negotiate every detail with each other. They need clear room to make ordinary decisions—and a visible path back to the operator when a decision exceeds that room.

Agent updates should be compressed

A shared record can still fail if agents fill it with pages of narration.

The operator should not have to reconstruct the work from terminal output, a list of files read, and a play-by-play of every failed attempt. The details should remain available, but they should not be the default reading.

I want an agent update to look more like this:

## TL;DR
Codex implemented the approved storage path. Claude reviewed the migration and
found no conflict with existing published posts.

## Decision needed
No decision needed.

## Critical assumption
Embedded images created before 2024 remain readable during migration. The current
regression test covers the known legacy format.

## Evidence
- 42 migration and upload tests passed.
- One existing post and one new social upload rendered correctly.
- Full migration report: /work/FEAT-042/evidence/migration-report

And when a decision is needed:

## Decision needed
Approve the public API change from `image_data` to `file_id`.

## Recommendation
Approve the new endpoint and keep the old field read-only for one release cycle.
This avoids breaking existing clients while giving all new uploads a single storage path.

This is not about forcing agents to be terse for its own sake. It is about giving the human the information needed to exercise judgment without becoming a full-time reader of agent transcripts.

The full design, diff, test output, and investigation remain available when the operator wants to inspect them. But the default update should make the decision clear.

The operator is not a bottleneck

This model is sometimes mistaken for asking permission at every step.

It is the opposite.

Within a bounded assignment, Claude or Codex should be able to investigate, make ordinary implementation choices, run tests, revise an approach, and deliver evidence without waiting for a human to approve each keystroke.

The operator comes back into the loop when it matters:

• the scope must expand;
• a new risk or dependency appears;
• the agents find two materially different approaches;
• the work changes the intended product outcome;
• the evidence does not meet what was agreed.

That is not micromanagement. It is the division of responsibility that makes autonomy safe.

An agent can be highly capable and still not be the person who decides whether a product trade-off is acceptable. The operator may be a developer, founder, product lead, or technical lead. The title is not important. The accountability is.

Why build a system instead of a protocol?

A protocol of shared files and shortcut commands can be a good starting point. It is much better than pretending parallel agents will coordinate by accident.

But a protocol leaves too much work in the human’s head.

Someone still has to remember which handoff is current, whether a decision was made, which agent is authorized to continue, and whether the final result met the original need. The more agents and changes you add, the more this memory problem becomes the real system.

I am trying to make that system explicit.

Claude and Codex should be able to see the same work, understand their own boundaries, discover relevant decisions, and leave evidence behind for the next agent or the human operator. The operator should be able to see what is happening without reading everything and make a decision without recreating the context from scratch.

That is the bet.

As coding agents become more capable, the constraint will not be their ability to produce implementation. It will be whether we can keep their work connected to one outcome and remain clear about what we have accepted.

Claude and Codex do not need a better way to chat. They need a shared system of work.