The Visiting CEO: How Agent Companies Cooperate Without a Human Router

Chinese version: 中文版

The first three essays in this series were all about a single company. How to write its constitution. How to staff it with roles. How to open and close its working sessions so it learns instead of just running.

But at some point I stopped having one agent-run company. I had several.

A content channel. An ebook press. A small tool site. A game studio. Each one is a fully formed workflow company in its own right, with its own constitution, its own red lines, its own standing authorization about what the agent may decide alone and what it must bring back to me. Each one boots from its own documents and runs its own CEO.

And the moment you have more than one, a new problem appears that no amount of internal org design solves: how do separate agent companies cooperate with each other?

The chairman becomes a human message bus

For a while, the answer was me.

Say the tool site needed something from the ebook press — a data format aligned, a shared convention checked, a small fix made on the other side. Here is what actually happened. The need would surface inside the first project. I would translate it into a prompt. Then I would physically walk that prompt over: open the other project’s directory, start a fresh agent session there, paste the request in, and babysit it to completion. Then carry the result back.

Every act of cooperation between two of my companies passed through me. I was the router. I was the message bus. I was the diplomatic courier walking sealed envelopes between embassies that could not speak to each other directly.

This works with two projects. It does not work with ten. The chairman does not scale, and a chairman who spends his day copy-pasting requests between his own subsidiaries is not running a group of companies — he is their switchboard.

I needed the companies to cooperate without me carrying the mail.

Why a shared function is not enough

The obvious engineering instinct is to skip the human and wire the projects together directly. Give them a shared library. Expose an endpoint. Let project A call project B like a remote procedure.

For purely mechanical exchange, that is fine, and I do it where it fits. But it quietly misses what makes these projects companies rather than folders of code.

Each project is sovereign. It has a constitution that says what it will never do. It has red lines that can void the whole project if crossed. It has a standing authorization that reserves certain decisions — pricing, brand, publishing, anything irreversible or externally visible — for me and me alone. It has a house style for how work is committed, how the changelog is written, how the next session is handed off.

A dumb interface honors none of that. A function call does not read the other project’s constitution before it acts. It does not know that in this company you never hand-patch an output, or that in that company a credential must never be echoed, or that a certain kind of change always requires the owner’s sign-off. It just executes, like a foreign agent who wandered into another country’s parliament and started passing laws because the door was unlocked.

What I actually needed was not a wire between two buildings. I needed an ambassador — someone I could send into another company who would first read that company’s laws, then do the work as a law-abiding local, and then come home and report.

The visiting CEO

So I built one. In this series’ vocabulary, it is the visiting CEO.

The visiting CEO is a strange kind of employee: it has no company of its own. It carries no constitution, no fixed project, no home turf. It exists only to be dropped into someone else’s company and temporarily act as that company’s acting CEO for the length of a single, well-defined errand.

The whole design rests on one move I’ll call the parachute protocol. When the visiting CEO lands in a target project, it does not start having opinions. It does the opposite of what a large language model instinctively wants to do. Before touching anything, it:

• reads that project’s own root instruction file first — the local law, not any assumption it brought with it;
• follows that project’s own boot sequence, loading the same constitution, workflow, roles, and handoff documents that the project’s resident CEO would load on a normal morning;
• checks the state of the working tree for signs that someone is already mid-shift, and stops if it sees them;
• then, and only then, begins the task — as a temporary citizen of that company, bound by that company’s laws.

There is one rule inside the parachute protocol that matters more than all the others:

When the visiting company’s local rules conflict with the visitor’s own habits, the local rules win.

This is the entire difference between an ambassador and an invader. The visiting CEO does not import its home conventions. It does not “improve” the target project by imposing outside taste. It reads the local constitution and obeys it, even when it would personally have done things differently. Sovereignty is respected by default.

Diplomatic discipline: the four iron laws

An ambassador with real authority is dangerous without conduct rules. Diplomacy is mostly a list of things you do not do in someone else’s house. The visiting CEO carries four.

One: an acting CEO is not the real one. The visitor runs the errand, but it does not make the resident company’s strategic, pricing, brand, or publishing decisions. Anything the local constitution reserves for the owner, the visitor also leaves untouched — it carries that decision home in its report rather than making it on foreign soil. A caretaker keeps the lights on; a caretaker does not sell the building.

Two: finishing means leaving a trace. If the visitor changed anything, it must record what it did in the local company’s own idiom — the changelog, the handoff note, the commit — written plainly as “a visiting CEO came through, did this, for this reason.” A resident CEO who boots up tomorrow must be able to see that a guest was here and what they touched. Work with no trace is not finished work; it is a mystery left for someone else to debug.

Three: no concurrent brawls. If the visitor finds clear signs of an active session already running in the target project — a working tree full of someone else’s uncommitted changes overlapping its own task — it stops immediately and reports back rather than fighting another agent for the same files. Two CEOs editing the same company at once is not cooperation; it is a collision.

Four: no nesting dolls. The visiting CEO may not dispatch another visiting CEO, or spin up further sub-agents of its own. If the job turns out to need more hands, it says so in its report and lets the caller decide. Delegation that recurses without limit is how a clean errand turns into an untraceable sprawl.

These four are not bureaucracy. They are what let me trust an autonomous agent to walk into a project I care about and act with real authority — because the boundaries of that authority are written down, and they are boundaries about restraint.

Three levels of trust

Ambassadors do not all carry the same mandate. Some are sent only to observe. Some may sign agreements. So the visiting CEO is dispatched with an explicit permission level, and the caller states it up front.

The design bias is deliberately conservative. Unless told otherwise, the visitor assumes it is allowed to fix and record, but not to publish, deploy, or do anything the outside world would see. The larger the blast radius, the more explicit the grant has to be. An ambassador who assumes broad authority is how quiet incidents start.

Clean context is the real prize

There is a second, quieter reason the visiting CEO matters, and it is about attention rather than authority.

Go back to the human-router days. When I carried a request between two projects myself, one of two bad things happened. Either I loaded both companies’ full document sets into my own head to broker the exchange properly — and drowned in two constitutions at once — or I let my main working session reach into the other project directly, and polluted a clean context with a second company’s entire world.

The visiting CEO dissolves that trade-off by working in its own isolated context. It reads the other project’s full library — constitution, roles, workflow, handoff — inside its own private head, does the work there, and brings back only a compressed conclusion. The session that dispatched it never has to load the other company’s documents at all.

And the shape of that conclusion is fixed, because a good report is not a travelogue:

• the verdict first — done, partly done, or blocked, in one line;
• what it changed — the files, the commit, where it left its trace;
• what it found — only the facts and local rules the caller did not already know;
• what it did not do, and why — the things it left for the owner, and the reasons.

The caller does not receive a summary of every document the visitor read. It receives an outcome and a set of pointers. This is the same principle the whole series keeps returning to — pass handles, not payloads — applied now at the boundary between two companies instead of between two steps inside one.

When not to send an ambassador

A capability this heavy is easy to overuse, so it comes with its own restraint.

If you only need one fact from another project — does this file exist, what does that value say — do not send a visiting CEO. Booting an entire acting-CEO protocol to read a single line is diplomatic overkill; a plain read-only lookup is faster and cheaper. The ambassador is for doing law-abiding work in another company, not for peeking through its window.

And if the target project already has a live session running — a resident CEO actively at the controls — you do not parachute a second one in on top. You hand your request to the resident CEO instead, the ordinary way. Sending an ambassador into a country whose government is mid-session is not diplomacy; it is a coup. The visiting CEO is for companies that are currently unattended, not for elbowing a working agent aside.

Knowing when not to dispatch it is part of the design. A tool that respects sovereignty has to include the humility to stay home.

From a company to a federation

The first three essays in this series were about building one self-running company well. This one is about what happens after you succeed more than once.

Because the reward for building a good agent company is that you build another. And another. And soon you are not managing a company at all — you are managing a federation of them, each sovereign, each with its own laws, each needing occasionally to cooperate with the others without collapsing back into a single blob or routing every exchange through your own hands.

The visiting CEO is my answer to that. Not a shared function, which ignores sovereignty. Not a human courier, which does not scale. But a diplomat with a protocol: read the local law, obey it even when you disagree, do the bounded work, leave a trace, and come home with a compressed report — while the company that sent you never has to learn the internals of the company you visited.

One company that runs itself is an achievement. A group of companies that can cooperate without a human message bus in the middle is an organization.

This post extends the Workflow Design Bible. The Bible scaffolds one self-running company; this is about what happens when you run several, and they need to work together. 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.