The Border Crossing: How One AI App Puts Another to Work

Chinese version: 中文版

The last essay in this series was about cooperation between companies I own. Several agent-run projects, each sovereign, each with its own constitution — and a visiting CEO that could parachute from one into another, read the local law, do a bounded errand, and come home.

But every company in that story spoke the same language. They were all built inside the same AI app. The visiting CEO could parachute into another project because it was the same species: it could open that project’s files, boot its documents, read its constitution, and act as a local because it was, underneath, running on the same runtime.

This essay is about the harder border. The one between two agent apps that are not the same species at all.

Two workers who cannot see each other

On my machine there are two autonomous coding agents running side by side. One is Claude Code. The other is Codex. Different vendors, different subscriptions, different strengths, different bills. For most of my pipelines Claude Code is the resident CEO — it orchestrates the work, dispatches the sub-agents, reviews the output, and reports to me. Codex is the neighbor.

And here is the wall. These two apps cannot see each other. Claude Code cannot look at Codex’s screen. It cannot read Codex’s running memory, cannot watch its thread, cannot call it like a library. They share nothing but the same laptop and the same filesystem underneath. As far as their live attention is concerned, they are two firms in two different countries, and there is no phone line between the buildings.

For a long time that meant the same thing the last essay opened with: I was the wire. When Claude Code needed something only Codex could do, I copied the request out of one app, opened the other, pasted it in, waited, and carried the result back by hand. A human message bus again — this time not between my own companies, but between two rival products I happen to pay for.

The question of this essay is how to tear that wire out. How do you let the AI running your company hire the AI next door — without you standing in the doorway relaying every sentence?

Why cross the border at all

Before the mechanism, the motive. There are three honest reasons one of my agents reaches across the border to the other, and none of them is novelty. They are all unit economics.

One: the capability is bundled next door. Codex’s subscription includes built-in image generation. On the higher tier it is effectively unlimited — I have already paid a flat monthly fee, and every image it draws costs me nothing more. Claude Code can generate images too, but only by reaching for a metered API that bills me per picture in real dollars. So the arithmetic is not subtle. When my content pipeline needs a cover, an illustration, a diagram — anything made of pixels — the cheapest place in the whole system to make it is the app where image generation is already paid for. You do not buy à la carte what the firm across the street serves at a fixed-price buffet.

Two: capacity and quota arbitrage. Claude Code has a weekly credit ceiling and a limit on how many things it can run at once. Some weeks a long production run pushes those close to the wall. When that happens, work that does not have to run on Claude’s payroll — a batch job, a mechanical transform, anything offloadable — gets pushed across the border to spend Codex’s quota instead, sparing Claude’s for the judgment-heavy work only it should be doing. Two payrolls, one company. A founder who runs low on one budget and has slack in another does the obvious thing and shifts the load.

Three: sometimes the roles flip. Most of the time Claude Code is the CEO and Codex is the contractor. But not always. Some workflows are built the other way around — Codex is the resident main agent, and it is the one that reaches back across the border to put Claude to work. The crossing is not a one-way street from a master to a servant. It is a trade route, and trade runs both directions depending on who has the order that day.

Capability you don’t own. Capacity you’re short on. A role that can reverse. Three reasons, one shape: the smartest thing a one-person company can do is route each task to whichever workforce already covers it.

Why a shared function will not do

The engineer’s reflex is to skip all of this and wire the two apps together with code. Give them a shared library. Have one call the other like a function.

It does not work here, and the reason is not stubbornness — it is that the two apps genuinely cannot see each other’s running state. There is no live object in Claude Code that holds a handle to Codex. There is no socket open between them by default. They are separate processes owned by separate vendors, each with its own private context that the other has no window into.

So you cannot pass a value between them the way you pass an argument inside one program. What you can do is use the one thing they both touch: the disk. The filesystem is the neutral ground — the strip of land both countries border. Anything Claude Code writes to a file, Codex can later read. Anything Codex writes back, Claude Code can pick up. The cooperation has to be built out of files, because files are the only language both apps share.

That constraint is not a limitation to apologize for. It is what makes the whole thing auditable. Every request and every reply is a file on disk you can open and read. Nothing important happens in a channel you cannot inspect.

The border crossing itself

The mechanism is a small, deliberately boring protocol I call the bridge. It has three moves.

First, drop a request. Claude Code writes a request file into a shared inbox: who it’s from, who it’s for, one clear question or task, and — this is the important part — pointers to any files Codex will need to read. Not the contents of those files. Their paths.

Second, ring the doorbell. Writing a file into a folder does not make the neighbor look up. So the bridge fires an explicit wake: it spawns a detached Codex worker and points it at the request. That is the doorbell. Codex now knows there is mail.

Third, wait for the reply, then read it. Codex picks up the request, reads the pointed-at files inside its own private context, does the work, and writes its answer back as a reply file. Claude Code waits for that file to appear and reads it. The reply file — not the doorbell, not a claim of success in some chat — is the verdict.

That last distinction carries more weight than it looks. It is the same rule this series keeps landing on: the artifact is the truth, and self-report is not. Ringing the doorbell tells you the request was dispatched. It does not tell you the work was done. Dispatch and completion are two different events, and only the reply file on disk is allowed to certify the second one. An agent that says “I sent it, so it’s handled” has confused knocking on a door with having the door answered.

The four disciplines of the crossing

A file-based border is simple, which means the discipline has to live in how you use it, not in the plumbing. Four rules make the difference between a clean trade route and a slow, leaky mess.

Pass pointers, not payloads. The request file carries the path to a contract, never the contract’s body pasted inline. This is the oldest motif in the series — pass handles, not payloads — now applied at the border between two apps. Paste a long task description into the doorbell message and you have smuggled the payload into the envelope; keep the envelope to a pointer and the contract file stays the single source of truth, readable and revisable on its own.

Send a fresh envoy each time. The bridge could, in principle, keep reopening one long-running conversation with Codex. It must not. I learned this by measuring it. Resuming one bloated thread — hundreds of megabytes of accumulated history — took over ten minutes to answer a single question, and a single image task run down that same aging thread had burned through more than a million and a half tokens. The same job on a brand-new thread finished in under a minute for a fraction of the cost. History does not compound into wisdom here; it compounds into weight. So each errand opens a clean thread, does its work, and lets the line close.

Never forge credentials. A thread’s identity comes back from the neighbor when the neighbor creates it — you record what Codex actually returns, you never invent an ID to look organized. And no secrets cross the border. The request carries the task and the pointers; it does not carry keys, tokens, or anything that would be dangerous sitting in a plaintext file in a shared folder.

Verify by the neighbor’s work, not the neighbor’s word. When the errand is an image, “done” does not mean Codex said done. It means the picture exists at the path the contract named, at the size the contract demanded. The resident CEO checks the output on disk before it believes the job is finished — the same landing-on-the-artifact reflex the whole pipeline runs on.

The image case, in full

The clearest use of the crossing is also the one that pays for itself every single time: pixels.

When my blog needs a cover, Claude Code does not generate it. It writes a formal image contract — a file that spells out the exact prompt, the palette, the aspect ratio, the output path, the naming, and where to report back. Then the bridge does its one job: it hands Codex a pointer to that contract and rings the doorbell. Codex reads the contract, runs its built-in image generation, saves the file exactly where the contract said, and writes its report.

There is a trap here worth naming, because I walked into it. You cannot shortcut the contract by pasting the image prompt straight into the doorbell message. The bridge’s consultation channel treats a wall of image-prompt detail arriving in a plain request as something it should refuse — and rightly so, because that is exactly what a leaky, untraceable image request looks like. The discipline is not bureaucracy for its own sake. The contract file is the one legitimate way to ask for a picture, and the pointer to it is the only thing that should travel.

The payoff is the whole reason the border exists. The cover of the post you are reading right now was drawn this way — a contract dropped, a doorbell rung, an image returned — on a flat monthly plan, for zero additional dollars, while this same session kept writing these words. The most expensive-looking part of publishing turns out to be the free part, because it was made in the building where it was already paid for.

Managing the neighbor’s standing staff

Delegation handles the one-off errand. But the border has a second, quieter door, and it is about the neighbor’s scheduled work rather than its on-demand work.

Codex, like my other companies, runs standing automations — jobs on a clock that fire without anyone asking. And from Claude Code’s side, I can manage those jobs directly: edit what a scheduled job is instructed to do, change when it runs, pause it, or wake it back up. It is the ability to walk into the neighboring firm’s back office and adjust the shift schedule, without waiting for a human to do it in the other app’s interface.

The one rule that makes this safe is the same one that makes any scheduled agent safe, and I learned it the hard way in a different project: a scheduled instruction must point at a document, not embed the procedure. The temptation is to write the whole workflow into the job’s standing prompt so it’s “self-contained.” Do that and it rots. An embedded copy of a procedure once drifted badly enough to invent a field name that did not exist, silently drop a required step, and write a wrong deadline into three separate places — all because the real procedure had moved on and the pasted copy had not. The fix is to make the standing prompt short and make its first act be read the real procedure file in the repo, and obey it over any older memory. The file is the truth; the schedule just shows up on time and does what the file currently says.

And there are doors in that back office you simply do not open. The neighbor’s credential file and its global configuration are off limits, full stop — you can adjust the shift schedule, you do not touch the safe or the wiring. A configuration you edit takes effect at the job’s next start, not the run already in flight; changing the schedule never means yanking a worker off the floor mid-task. Restraint, again, is most of the design.

Knowing when to stay on your own side

A border this useful is easy to overuse, so it comes with its own no.

Do not cross for a single fact. If all you need is whether a file exists on the other side or what one line of it says, booting the whole bridge to find out is theater; a plain look is faster. The crossing is for handing real work to the neighbor, not for peering through its window.

Do not resume a bloated history to save a few seconds of setup. The fresh envoy is cheaper than the familiar one almost every time, and the exceptions announce themselves.

Do not smuggle the payload into the envelope, and do not believe the neighbor’s word over the neighbor’s work. Every one of these temptations is the same temptation — to skip the discipline because the shortcut looks fine this once. It is fine this once. It is the tenth time that leaks.

The market, not just the company

The first essays in this series were about building one self-running company well. The last one was about a federation of companies I own, cooperating through an ambassador. This one steps outside the federation entirely.

Because eventually the cheapest, most capable place to do a piece of work is not inside anything you built. It is another AI app, with another vendor’s bill and another vendor’s strengths, sitting on the same machine and unable to see your side of the wall. Cooperating across that wall is not org design anymore. It is trade — conducted in the one currency both parties can read, which is files on a shared disk, moved by a protocol strict enough to trust.

One company that runs itself is an achievement. A federation of them that cooperates without a human router is an organization. And an agent that knows how to hire the app next door — to route each task to whichever workforce already covers it, and to do it without you carrying the mail — is something closer to a business operating in a market. Which, in the end, is the only kind of business that lasts.

This post extends the Workflow Design Bible. The Bible scaffolds one self-running company; this essay is about what happens when the cheapest way to get work done lives in another AI app entirely, and your agent has to hire across the border. It is open source under MIT: github.com/preangelleo/workflow-design-bible.

Watch more first-principles field guides on Wiki4What, or read the essays at blog.wiki4what.com.