Replicating an agent in a second harness

The replica

Our AI PA, called CCL, has run the daily work of Anas, our founder, from the harness of one vendor. An agent is an AI system that works on its own. The harness turns what the AI writes into actions on a computer. Every large AI vendor ships its own. In September 2026 we made a replica of CCL, named CCC, inside the harness of a second vendor, so we would not depend on a single one. The goal was to see how much of CCL the replica could take over, starting from CCL's root, the folder holding everything it was given, and move into a root of its own. We called that move the crossing. Nearly everything crossed, with almost no effort on our part. What stayed behind matters most: the enforcement behind CCL's rules.

Most companies assume such a move will be painless. In early 2026, 542 executives were surveyed and about 90% believed they could move between AI vendors in 4 weeks. Of those who tried, only 42% said the move had gone smoothly, and the remaining 58% ran into breakdowns or far more work than planned. We name this distance the switching gap: what executives expect versus what they get. It consists of agent pieces bound to the old harness, pieces no one had counted. The replica therefore faced 2 questions. First, when an agent shifts to a new harness, which parts follow and which stay behind? Second, does it pay to prepare for a move you may never make?

This note follows the replica across that gap, stopping wherever something needs explaining: what happened, and why. It opens with the risk of depending on a single vendor, then shows the replica turning from helper into rival, which turned the crossing into a genuine test. It then breaks an agent into 3 layers, traces the replica through each, and closes with what stayed behind and with the shared memory of the two agents.

The price of intelligence

An AI model is a rented service, and rented services compete on price: across the 10 months to September 2026, the best intelligence per dollar moved from one vendor to a second, then to a third. In November 2025, one vendor cut the price of its strongest model by 67% while keeping every capability. In February 2026, a rival topped an independent ranking of AI intelligence at under half the running cost of its competitors on that same ranking. In July 2026, a third vendor matched the leader's intelligence at roughly one third of its price. Had movement been possible, that same agent would have been worth more each time on the newer model.

For agents like ours, the ability that matters most, coding skill, has stayed put: one vendor has led that race for months, which argues reasonably for remaining where we are. Our reply is the switching gap. It is made of items nobody has tallied, and tallying them is cheap while nothing rides on the outcome, then suddenly expensive when a cheaper offer makes moving urgent. A replica lets us tally them before that week arrives.

From helper to rival

At first, CCC worked for CCL. CCL passed it pieces of work suited to its setup, briefed it for each, and reviewed the results. Nothing CCC produced reached Anas except through CCL. That arrangement tested little, because a helper borrows its manager's judgment at every brief and so never carries the full weight of what the manager knows.

We therefore rewrote how the agents relate. Since 9 September they have been rivals, each working with Anas directly from its own root. Doing the work well earns the right to be the one he turns to next. A rival receives no briefs, so there is no judgment to borrow, and to compete CCC had to carry everything that makes CCL useful, its rules, its methods and its tools, into a root of its own. Whatever failed to make that crossing would be missing from the replica, and those absences made the replica a real test of what travels. To learn what had to be carried, an agent must be taken apart, bottom to top.

Layer 1: The model

The model is the AI itself: a program that takes in text or images and returns text. It runs on the vendor's computers, charges by use, and holds nothing of yours between requests. Nothing you build lives in it, and nothing you build alters it. Since it holds none of you, the model is the easiest part to swap. CCC runs on the second vendor's model, picked for its ability to read a screen and say what to do there. Nothing of CCL had to leave the first vendor's model, for no part of it ever lived there. We had measured this already: an earlier note recorded swapping the model beneath Grove, the memory both our agents draw on, for one far smaller and cheaper, with accuracy barely shifting. The catch is that a model alone can only write.

Layer 2: The harness

Writing is one thing; doing is another. A model can draft an email, but some other piece must send it. That piece is the harness: the program surrounding the model, which turns its writing into computer actions and rules on which are permitted. Every vendor ships its own, designed around the models it sells, so adopting a new vendor's model usually means adopting its harness too.

Every harness splits into 2 halves. One is the vendor's machinery: the loop that executes the model's actions, together with the permission system deciding what the model may touch; the vendor supplies that machinery, and no one rewrites it. The second half covers the formats the vendor sets for your writing. The instruction file holds the permanent orders the model reads at every start. The skills are pages of instructions, one per type of task, plus the shortcuts that call them into use. What you place in these formats is yours, while the format itself belongs to the vendor. A file written in one vendor's format is read only by that vendor's harness, never by another, so everything stored that way must be rewritten during a move. This rewriting is a move's visible cost.

CCC did the rewriting itself. On 9 September it read everything held in CCL's root and produced, in a root of its own, a fresh version of every item, spending roughly 6 hours at it. Counts taken on 18 September show CCL's instruction file as 3 files, 1,762 words in total, joined in a form the second harness cannot parse, while CCC's is 1 file of 214 words. The 8 skills CCL uses, 7,462 words, became 11 skills of 2,587 words, recomposed rather than paired one to one. Among them, the method published as Cue, the skill behind our demonstration films, went from 766 words to 269. CCL's 90 shortcuts fell to 0, since the second harness takes natural language instead. The rewriting had its snags. 3 settings pointed to files that were not there. The first health check kept reporting all was well, though it was only a small program whose job was to confirm the installation, so CCC rewrote it to search for the actual files.

The rewriting gave something back as well. It forced the question of which parts of CCL's instructions were essential. CCC's instruction file fell from 897 words at first draft to 368 by the close of 9 September, then to 214 by 18 September, a quarter of the starting point. What was cut were fixed examples, layout rules, and numbers treated as universal laws.

Layer 3: The setup

The setup is everything you have built above the model and harness: your memory, your rules, your tools, your records. It is the piece that belongs to you. The survey's authors traced the failed moves to small adaptations nobody had written down, on the assumption they were temporary. The first lesson about a setup: a piece you are unaware of cannot be moved. Everything else travels or stays according to the form it takes.

Every harness must let the model execute programs, because that is how an agent does its work. Each harness therefore hands the model the same door a person at a keyboard has: somewhere to enter an instruction and watch the computer run it. Engineers call this door the shell. Anything written as a plain program or file crosses it under any harness, since a vendor format never held it. This is what we name the shell bridge: the one door every harness shares, which is why most of a setup crosses without rewriting.

Most of CCL crossed by that route, though not all of it. Grove was not copied at all, and 1 running copy now serves both sides. Company and person records made the same crossing, along with 106 service scripts, the small programs by which an agent reaches its tools, counted on 9 September. No password or key ever entered CCC's root, since each stays beside the script that calls it. The permissions of the harness decide how wide that door swings, and for the crossing we granted CCC the same reach as a person at a keyboard. Under the default setting, which confines the model to a single folder and keeps it off the internet, those 106 scripts would have failed to run. Our own internal index of earlier talks with the agent, out of which Recall grew as our product that keeps earlier conversations verbatim, also demanded work. CCC kept its conversation logs in the second vendor's format, which that index could not parse until we wrote a reader for them on 10 September.

The enforcement gap

Most of what we built crossed by that route. What did not cross is the part that gives a rule its force: enforcement. An agent can be made to follow a rule in 2 ways, by being told or by being stopped. To tell it, you write the rule down as prose it can read, such as: nothing leaves the company without approval. It tends to obey such prose, though not always. To stop it, you install a small program that examines each action before it runs and halts any action that would violate the rule. We call that program a gate. Prose is a notice hung on a door, and a gate is the lock fitted to that door. A notice can be carried to any house, and so can a lock, yet the lock was shaped for the old door.

A gate must inspect each action in advance, so something has to tell it that an action is on its way. The harness alone is first to see each action, since it performs them all. It therefore sends a signal ahead of every action, and the gate runs on hearing one. The gate's program is an ordinary one and crosses the shell bridge as any ordinary program would, but the signal does not, for it belongs to the vendor's harness. On a move the program travels with you, yet the new harness signals in its own way, so the gate hears nothing and never runs.

That fate met the gate that stopped CCL sending anything out of the company without approval. The program behind it is an ordinary script, one CCC can reach across the shell bridge, and what stayed behind was the signal that starts it running. It is 1 of 4 small programs CCL wires to its harness signals. Of the other 3, one scans text after it is written, one scans the tool list when the agent starts, and one reminds the agent how to reason at each task. In CCC, all 4 stay silent, and the rule the gate enforced reached CCC only as prose inside its instruction file. Our crossing records say plainly that a written instruction is not a gate. We name this the enforcement gap: when a gate runs on a vendor's signal, a change of vendor strips the rule of its enforcement. Where the rule also exists as prose, the prose crosses and reads the same, yet no mechanism stops the action and none reports the loss. A gate can be wired onto the new harness, though only by someone who already knows it went quiet. The lasting repair follows from the same facts: a gate kept outside the harness that calls it has a narrower view, taking in only what travels through it, yet it depends on no harness at all.

One memory, two agents

A shared memory brings its own difficulty, since CCL and CCC both work from Grove. Had 2 agents each written their updates into a single shared memory, each would have kept its own account of the facts, until the memory split into 2 versions of the same work. From 9 September onward, writing to Grove became CCL's job alone, and both agents read it. Grove has an agent of its own, the one that records every change: it takes its directions from CCL and reads both agents' conversations, while CCC does no more than read. The collaboration predates the rivalry. On 7 September, still acting as CCL's helper, CCC examined Grove and twice challenged the repair plan CCL proposed before the two agreed on one. Anas required CCC's agreement before the repair went ahead.

Where a gate belongs was another lesson from the shared memory. CCC was supposed to do no more than read Grove, yet our check found nothing enforcing that: a query meant only for reading could still write, and the rule had never been more than a sentence. On 11 September we built the gate for that rule inside Grove itself, in the harness where Grove's agent runs, so that lookups cannot write, no matter which agent issues them. The gate runs on the first vendor's signal, because that is where Grove's agent operates. It lives beside the tool it guards rather than beside the caller, so neither CCL nor CCC can get around it. Airlock, our firewall for agents, goes further still: its network gate stands at the network edge rather than inside an agent, and runs the same under either harness.

One more leak had stood open since day one. CCC's harness arrived carrying its own built-in memory, already switched on and ready to take notes. For 6 days it stayed on, until we turned it off on 11 September. A second memory readable by a single agent is precisely the division Grove exists to prevent. That is why the same reasoning had led us to switch off the built-in memory CCL came with. This is what we name convenience capture: a vendor feature that stores part of your setup, quietly and in its own format, and binds you through it. No one chooses lock-in; it arrives convenience by convenience.

What travels

The 2 questions from the opening now have answers. What follows you is your setup, every part of it stored as plain programs and files, and a replica shows you cheaply which of your pieces were stored that way. Everything bound to the vendor stays behind. The visible part gets rewritten, which cost CCC one day of work. The part you cannot see is the switching gap, found by testing before you are forced to move, and within that gap, what matters most is the enforcement, because nothing reports its loss.

So this is how we build now. Each tool starts life as a plain program or file, and only gains a vendor-specific format layered thinly above it. Memory sits in one place every agent can reach, and a single agent does the writing. The built-in memory that each vendor ships stays switched off. Every rule that matters gets written twice: once as words the agent reads, and once as a gate in the code. A rule that has to hold no matter which harness calls it gets its gate beside the tool it guards, or at a boundary owned by no vendor. Gates that remain tied to one vendor's signals are now listed in the settings file of that vendor, and that inventory is what will silently stop working after a move. The replica also stays up as a rival, since it reveals, before we depend on it, what does not travel.

4 terms join the field-note series in this note: the switching gap, then the shell bridge, then the enforcement gap, and finally convenience capture, each defined at the point of introduction above.

The model is a rental, and the harness is the vendor's property. The setup is yours as long as you hold the form it is written in, and a rule stays yours only while enforcement lives in something you hold.