Yesterday I published Two AIs, One Branch, No Human Clipboard, the story of how I connected Codex and Claude so that they could collaborate directly on a real engineering problem. That first post concentrated on the mechanics: one persistent Claude CLI session, one implementation owner, one read-only reviewer, one shared engineering ledger, and a human who no longer had to copy messages between two AI applications.
This is the follow-up I could not write until the branch was almost finished.
What did the two AIs actually do together? Did the dialogue survive contact with architecture, production data, implementation, testing and security? Did the second model add genuine engineering value, or did it merely produce a convincing stream of review prose?
The short answer: Codex and Claude co-designed and reviewed a material-cost service from first principles, connected it to existing planning screens through a compatibility facade, added deterministic AI access, shaped a one-way full-catalog contract for an external quote CRM, found and corrected multiple boundary defects, and kept deployment and activation under explicit human control.
This post describes that journey without exposing customer names, commercial prices, material identifiers, private URLs, credentials or internal infrastructure details. The domain is deliberately generalised. The engineering lessons are real.
The problem was bigger than “which price is correct?”
The platform already had years of ERP-derived sales, stock and procurement data. Its product catalogue also carried historical cost references used by budget planning. The immediate symptom was a familiar one: a catalogue cost could disagree with a newer ERP-observed cost.
It was tempting to patch the displayed number. But that would have avoided the real question:
How should one platform represent several legitimate meanings of “cost” without silently mixing them, losing their provenance, or forcing every screen and external consumer to reinvent the selection rule?
A physical material could have an ERP Standard Price, an ERP Moving Average Price, a transaction valuation, stock-ledger evidence, procurement comparators and a Bill of Material roll-up. A non-physical catalogue line such as training or an on-site service could still be quoteable while having no material cost at all. Historical records pre-dated the newest ERP price-control fields. The planning application needed stable saved values, while a quote CRM needed current typed evidence and its own selling-price policy.
That is not a column-mapping problem. It is a domain boundary.
The architecture the two agents converged on
The final design kept one deterministic material-cost core and gave each consumer an appropriate contract. Internal screens did not have to understand source documents. The external CRM did not receive access to internal databases or interactive APIs. AI could explain and query the same governed result, but it could not perform financial arithmetic in a prompt.
| Boundary | Responsibility | Important constraint |
|---|---|---|
| Existing ERP exports | Supply sales valuation, stock and procurement evidence through existing ETL flows. | No new ERP report or integration was required. |
| Product Master and BOM matrix | Own catalogue identity, governance metadata, approved recipe links and component quantities. | Product Master does not become a second independent cost ledger. |
| Material Cost Core | Normalise evidence, apply a versioned policy, validate unit-of-measure compatibility, roll up BOM material costs, and return coverage/freshness/status. | Deterministic server-side arithmetic; incomplete is an honest result. |
| Internal cost API and facade | Expose the rich result while safely projecting it into legacy unitCost-shaped consumers. | Compatibility lives at the edge, not inside the core. |
| AI tools | Query governed costs and evidence for authorised users. | The LLM explains results; it does not select prices or calculate BOM totals. |
| Immutable catalogue publisher | Build one complete, versioned snapshot and deliver the exact retained bytes outbound over HTTPS. | Publication failure never rolls back a successful ERP ETL publication. |
| Quote CRM | Validate and atomically promote the snapshot, apply its own quote policy, margin and approvals, and retain the selected evidence on the quote line. | No synchronous per-line dependency on the financial platform. |
The blast-radius decision was especially important. Existing Product Catalogue and Budget Plan code could keep consuming a familiar cost shape while the facade gradually changed where that cost came from. The new rich result remained available for consumers that needed provenance, alternatives, coverage or warnings.
The resolution path inside the core
The architecture document also separates the evidence-selection path from the consumer contract. A request first passes catalogue governance, then resolves current price-control evidence, historical fallback or BOM component costs. The output carries explicit status and warnings; a non-material line takes a separate manual-pricing path.
The collaboration timeline
The work did not unfold as “Codex writes a plan, Claude says looks good.” The ledger records a sequence of design debates, owner decisions, implementation reviews and corrections.
| Stage | Codex and Claude activity | Outcome |
|---|---|---|
| 1. Frame the domain | Codex proposed typed cost observations and a rich material-cost result. Claude challenged storage coupling, unit-of-measure handling, freshness and what “complete” must mean. | A stateless deterministic core with explicit complete, incomplete, stale, ambiguous and missing states. |
| 2. Debate source precedence | The agents tested Sales, Stock, purchase-order and goods-received evidence against historical and forward-looking use cases. | Evidence remained labelled; no source was allowed to masquerade as another. |
| 3. Human business decision | The technical debate started inventing a procurement-derived planning average. I stopped it and clarified that the platform should follow the ERP price-control rule, with governed historical fallback where the newer fields did not exist. | The owner decided policy once; both agents reconciled the design and recorded the superseded alternatives. |
| 4. Close architecture | Claude inspected the actual data and code paths, found an inconsistent example that implied an unapproved BOM link, and withheld a clean close until it was corrected. | Architecture and external contract agreed before implementation. |
| 5. Prepare local runtime | The branch was made to run against the modern API backend locally before feature slices began. | Implementation and ETL evidence could be exercised without designing around a retiring runtime. |
| 6. Build in slices | Codex implemented the core, last-known valuation projection, BOM roll-up, internal API, facade, catalogue and budget consumers, deterministic AI tools and inactive external publisher. Claude reviewed every bounded diff. | Each slice received an explicit approve/request-changes verdict and a recorded closure. |
| 7. Reconcile real data | A parallel ERP backfill populated the newer price-control fields. The agents audited the refreshed data rather than assuming the migration had worked. | Coverage evidence matched the intended two-era fallback. |
| 8. Design CRM operations | The agents added immutable staging, idempotent delivery, retained-byte retries, manual publishing and a configurable schedule—while leaving transport disabled. | Code-complete did not mean externally activated. |
| 9. Close non-material pricing | Claude challenged the treatment of service, training and call-out lines. The owner clarified that these must remain quoteable but require manual selling-price entry in the CRM. | Explicit governance distinguishes catalogue-cost items from manual case-by-case items without inferring from names or tiny placeholder values. |
| 10. Govern existing catalogue data | Codex and Claude designed a dry-run-first, idempotent metadata enrichment. They debated deployment order, corrected one another’s assumptions, and preserved rollback evidence. | The same reviewed mapping could be applied safely without rewriting costs or re-mirroring an entire environment. |
| 11. Sweep operational writers | Claude found a theoretical stale full-document write risk; Codex corrected the writer matrix and the owner calibrated the finding against the stable manual operating process. | Real risks were documented without turning a rare operational edge into an unnecessary redesign. |
| 12. Security close-out | Claude agreed that TLS plus a dedicated credential was sufficient for v1, but found that default HTTP redirect behaviour could forward the sensitive PUT body. | The publisher now rejects redirects, and the external contract requires a direct final response. |
Prompt annotation: how Codex asked for useful review
The prompts became more precise as the experiment matured. They did not ask Claude to “review the feature”. They assigned a role, bounded the authority, named the evidence, identified the decision, required a response shape and defined an explicit verdict.
1. The bootstrap prompt
Act as the read-only peer co-architect.
Read the governing repository contracts and the collaboration ledger in full.
Inspect the concrete code paths needed to answer the current decision.
Address Codex directly. Include:
- the strongest part of Codex's position;
- answers backed by files, functions or read-only runtime evidence;
- assumptions you rejected;
- whether the evidence changed your position;
- acceptance criteria;
- at most three focused questions; and
- Next actor: Codex.
Do not edit files, commit, push, deploy or mutate data.Why it helped: Claude had independence and repository access, but not permission to contaminate the author’s diff. The required steelman and position-change sections made disagreement productive rather than theatrical.
2. The implementation-review prompt
Review only the current bounded diff.
Check both sides of every changed interface.
List concrete findings first, ranked by severity.
Distinguish release blockers from expected data-migration gates.
If the slice satisfies the agreed decision, end with:
[Claude]: APPROVE SLICE
Otherwise end with:
[Claude]: REQUEST CHANGES SLICE
and give the smallest required correction.Why it helped: the reviewer could not hide behind general advice. It had to connect a finding to an interface and decide whether the author could checkpoint the slice.
3. The security-review prompt
Review only the outbound pricing-catalog trust boundary.
Distinguish:
- TLS confidentiality and server authentication;
- bearer-token publisher authentication;
- unkeyed digest corruption detection;
- encryption at rest after receipt; and
- optional future mTLS, signatures or message encryption.
Do not invent compliance requirements.
Inspect redirect handling, URL construction, retries, acknowledgement binding,
payload minimisation, logs and configuration gating.Why it helped: the prompt prevented an abstract “encrypt everything” recommendation and focused review on the actual threat boundary. That is how Claude found the redirect behaviour.
Conversation snippets: evidence changed both models’ positions
The most valuable exchanges were the ones where an agent explicitly changed its mind.
Claude corrects itself on procurement timing
[Claude]
Your latest turn corrected a genuine misread on my side,
and the repository evidence backs you, not my earlier position.
The purchase-order availability gate must use the order creation date,
not a promised future delivery date. I withdraw the earlier ordering.This was not politeness. The timestamp controlled whether historical resolution could “see into the future”. A seemingly small field choice would have changed the financial meaning of an as-of-date query.
Codex corrects Claude’s deployment assumption
[Codex]
I agree with the migration mechanism, but repository evidence contradicts
the claim that deployment before the metadata enrichment is behaviour-neutral.
The feature surfaces default active when no build override is present.
There is no production override configured. We need to revise the sequence.[Claude]
I validate that evidence and withdraw the earlier claim.
The sequencing recommendation changes.That exchange is exactly why I wanted two models. Claude found real issues elsewhere, but it was wrong here. Codex did not accept the reviewer’s prestige as proof. It inspected the deployment configuration, rebutted the assumption and sent the issue back for re-review.
The owner stops policy invention
[Owner]
Do not invent a new weighted cost policy.
Use the ERP's own Standard-versus-Moving-Average rule.
When the newer fields do not exist historically, retain the governed prior cost.
[Claude]
ACKNOWLEDGE OWNER DECISION
[Codex]
AGREE — the superseded procurement-first rule remains comparator metadata only.This was the correct use of the human. The agents could discover data and consequences, but I owned the business rule. Once stated, they incorporated it without requiring me to relay their interpretations.
Claude blocks a security gap, then signs off the patch
[Claude]
REQUEST CHANGES
The publisher validates the initial HTTPS URL, but fetch follows redirects
by default. A 307 or 308 can forward the bearer credential and PUT body.
Require redirect refusal and a no-redirect receiver contract.[Codex]
Confirmed. The sole outbound PUT now uses redirect: 'error'.
Every retry preserves the refusal mode and exact retained body.
[Claude]
APPROVE IMPLEMENTATIONThat was a small patch with a disproportionate security benefit. It also illustrates the review loop: finding, independent validation, bounded correction, focused tests, re-review, explicit approval.
How the CRM contract evolved
The first instinct was to expose a conventional catalogue API that the external quote system could call. Live topology and security constraints changed the design. The financial platform did not need another public ingress surface, and the quote screen should not depend on its availability for every product-line lookup.
The agents reversed the integration:
- The financial platform creates one complete, immutable pricing-catalogue snapshot after its governed data refresh.
- It publishes the snapshot outbound over HTTPS to one consumer-owned ingestion endpoint.
- The CRM validates the whole document, stages it under an immutable snapshot identifier and atomically changes its active pointer only after every item passes.
- If validation fails, the prior last known-good catalogue remains active.
- The CRM uses its local promoted catalogue for quotes and stores the chosen snapshot, option and policy version on each quote line.
This preserved a clean separation of concerns:
| Financial platform owns | Quote CRM owns |
|---|---|
| Catalogue identity and governed cost evidence | Which evidence is eligible for a particular quote |
| Typed Standard, Moving Average, historical and comparator options | Margin, approvals and final selling price |
| BOM material-cost coverage and warnings | Local catalogue availability and quote-line evidence retention |
| Snapshot generation, digest, staging and delivery status | Validation, idempotency and atomic promotion |
| Manual and scheduled outbound publication | Manual selling-price entry for non-material services |
One design detail mattered more than it first appeared: service and training lines stayed in the catalogue. They were not assigned a fabricated zero cost, nor excluded from quoting. Their explicit policy tells the CRM that the line is selectable but must receive a case-by-case selling price. This is a much more honest representation than pretending every quoteable thing is a material.
Where the second model added measurable value
| Review finding | Risk avoided | Change made |
|---|---|---|
| Missing observed unit of measure could still look complete. | A numerically valid price could be applied on an incompatible basis. | Completion now requires compatible UoM evidence. |
| Freshness could be inherited from a newer comparator instead of the selected value. | A stale canonical cost could look current. | Freshness follows the selected observation; BOM freshness is conservative across contributing components. |
| An illustrative contract example implied an approved recipe that governance had not approved. | An implementer could turn an example into an accidental business rule. | The example was corrected before the contract was treated as implementation-ready. |
| Non-material catalogue lines still needed a quote contract. | Services could be excluded, shown as free, or assigned placeholder material costs. | Explicit manual_case_by_case governance keeps them quoteable without false cost evidence. |
| A full-document save could theoretically race with another Product Master writer. | Additive governance metadata could be lost under an overlapping stale write. | The agents produced a complete writer matrix, operational safeguards and bounded hardening rather than an unscoped rewrite. |
| Default HTTP redirect following could forward the sensitive request body. | A valid initial HTTPS endpoint could redirect credentials and pricing data elsewhere. | The publisher rejects every redirect and the receiver contract prohibits them. |
The reviewer also added value by not turning every observation into a blocker. When I explained that certain admin writes are rare and the weekly ETL is manually sequenced, Codex and Claude recalibrated the concurrency finding. The final record distinguished a realistic pre-activation hardening item from a production emergency.
That judgement is important. A reviewer who labels every theoretical edge P0 is not safer; it is merely expensive.
What did the AI experiment cost?
Because both tools retained local usage telemetry, I could estimate the model consumption for the main collaboration window rather than inventing a number. The measured period ran for approximately 42 wall-clock hours, from the first persistent Claude architecture turn through the final security-review closure.
| Agent | Uncached or cache-write input | Cached reads | Output | API-equivalent cost |
|---|---|---|---|---|
| Codex, GPT-5.6 Sol | 4.78 million tokens | 232.38 million tokens | 703,800 tokens | US$126.14 |
| Claude Opus 4.8 | 13.85 million tokens, mostly cache writes | 109.40 million tokens | 560,000 tokens | US$206.45 |
| Combined | Approximately 362 million total token events | 1.26 million tokens | US$332.59 | |
The headline token count needs context. It does not mean that the agents consumed 362 million tokens of unique source material. Long-running coding agents repeatedly submit repository instructions, tool schemas, prior conversation and file evidence. Approximately 95% of this experiment's input traffic benefited from prompt caching.
At the standard API list rates published on 26 August 2026, the measured workload represents approximately US$333 of model usage: about US$126 for Codex and US$206 for Claude. If every repeated input token had been charged at the uncached rate, the same traffic would have approached US$1,593. Prompt caching reduced the list-rate equivalent by roughly 79%.
The calculation used the published token categories rather than treating every token equally:
- GPT-5.6 Sol: US$4 per million uncached input tokens, US$0.40 per million cached input tokens and US$20 per million output tokens, from the official OpenAI model pricing.
- Claude Opus 4.8: US$5 per million base input tokens, US$6.25 per million five-minute cache writes, US$10 per million one-hour cache writes, US$0.50 per million cache reads and US$25 per million output tokens, from the official Anthropic pricing.
This is an API-equivalent compute estimate, not an invoice claim. Codex reported a Pro subscription, and Claude CLI also had been subscription-backed with a Teams tier. The actual marginal cash charge could therefore have been zero beyond the subscriptions, or governed by their included usage limits. The estimate answers a different and more portable question: what would this measured workload be worth at standard token list rates?
For business readers, US$333 bought architecture debate, implementation, independent review, migration design, security review and an auditable engineering record across a substantial feature branch. A human team would've taken at least two solid weeks to discuss, debate, code, test and develop the CRM interface. Two AI agents shaved two weeks into two days. For technical readers, the more interesting number may be the 79% caching benefit. Persistent collaboration is viable partly because the platforms do not charge every repeated repository token as fresh input. A human decision-maker still needs to be involved in steering the AI's to achieve practical, workable solutions. The whole CRM API discussion turned a corner when I decided against an API request model and favoured instead, a simple push publish interface. I also had to steer the AIs to stop theorizing on potential risks and instead bias on simple, pragmatic solutions, accepting manageable operational processes. The AIs can go off on tangents hence human input is still critical for AI-assisted building.
The human was not removed—my job improved
The experiment did not make me irrelevant. It moved me to the decisions where I added the most value.
| I decided | The agents decided from evidence |
|---|---|
| What “authoritative cost” means for the business | Where the current fields, writers and deployment boundaries actually live |
| Whether to extend ERP reporting or use existing exports | How to normalise timestamps, provenance, UoM and incomplete states |
| That non-material lines remain quoteable and manually priced | How that rule flows through catalogue, schema, facade and tests |
| When production metadata changes were authorised | How to make the migration idempotent, reviewable and reversible |
| When deployment and external activation may occur | Which code and contract gates must be satisfied first |
I intervened when the agents drifted into a new business policy, when operational reality changed the risk calculation, and when an external activation decision belonged to me. I did not spend time telling Claude which file Codex had inspected or copying Claude’s review back into the implementation chat.
The human remained accountable, but stopped being middleware.
What I would repeat—and what I would change
I would repeat:
- one writer and one independent read-only reviewer;
- a persistent reviewer session instead of isolated one-shot prompts;
- a durable ledger with exact prompts, decisions and verdicts;
- bounded slices with findings-first review;
- explicit owner decisions recorded as superseding technical alternatives;
- re-review after every material correction;
- separate states for implemented, committed, deployed, configured and activated; and
- real data and production-path evidence before declaring a boundary complete.
I would improve:
- Chronology in the ledger. Later decisions were appended around earlier sections as the work expanded. The record is accurate, but a generated timeline view would make it easier to read.
- Automated redaction for public retrospectives. The engineering record correctly contains local paths, material examples and operational evidence; the publication layer should automatically produce a sanitised derivative.
- Reviewer evidence manifests. Each review prompt could be generated from a machine-readable list of changed interfaces, tests and unresolved acceptance items.
- Review-cost telemetry. I can count turns and findings, but I also want to measure how often findings change code, prevent rework or are rejected after validation.
The result
The branch now contains the material-cost domain, historical valuation retention, BOM material roll-ups, an internal API, compatibility facade, updated planning consumers, deterministic AI tools, an external full-catalog snapshot contract, inactive publication operations, governance for material and non-material lines, data migration tooling, operational review and transport hardening.
Just as importantly, it contains the reasons.
The collaboration ledger shows which ideas were proposed, which were superseded, which decisions belonged to the owner, which findings changed the implementation, where one model corrected the other, and why external activation remained separate from code completion.
The experiment therefore answered a deeper question than whether two models can work on the same repository.
Yes, AI agents can collaborate like a disciplined engineering team—but only when we give them more than shared context. They need roles, evidence rules, decision closure, bounded authority, independent review and a human who owns the business outcome.
The novelty was never that Codex could send text to Claude. The novelty was that they could disagree, inspect reality, change position, ask me only for irreducible decisions, and leave behind a system and a record that another engineer could trust.
That is what made it feel less like two chatbots and more like a team.
The experiment in AI building continues...
Publication note: this article intentionally generalises the commercial domain. Example identifiers, costs, customers, URLs, credentials, deployment names and internal infrastructure details have been omitted. The architecture diagram preserves the technical boundaries but not private topology.
Experiment setup: Codex acted as primary engineer and orchestrator. Claude Opus 4.8 at high effort acted as persistent read-only co-architect and independent reviewer through a local CLI session. The human owner retained authority over business policy, data mutation, source control, deployment and activation.
No comments:
Post a Comment