Over the past several days the same behavior showed up on three different platforms: people moving working agent setups off one harness and onto another. Not arguing about which harness is better — actually migrating. Migration guides in multiple languages, a shipped service tracking quota resets across providers, comment threads where the top-voted replies are all inventories of what to move first. Terms and limits shift, and the shift is the trigger — but that's context, not the subject here.

The subject is the mechanical question those people are asking each other: what comes with me?

We've moved pieces of our own setup around enough times to have an answer, and it isn't "most of it" or "none of it." Everything you own sorts into three buckets with wildly different costs.

Bucket 1: ports clean, because it never lived in the harness

The stuff that moves for free has one property in common — it was never harness-shaped to begin with.

The task queue and its state machine. Ours is a database table and a poller. Tasks have explicit states, a retry budget, heartbeats, and a stale-claim requeue for work whose owner died. None of that has any opinion about what executes the task. Swap the executor and the queue doesn't notice. This is the highest-leverage thing to get right early: a queue that owns task lifecycle makes the harness just a worker — and workers are replaceable by definition.

Two-tier memory. Short-term is plain markdown in the repo. Long-term is SQLite with embeddings. The migration tooling for both is cat and sqlite3. There is nothing to export because it was never imported.

File-anchored working state and instruction files. Text in a repo. Conventions, role definitions, process docs, the running state each role reads at session start. A different harness will load them differently — that's bucket 2 — but the content transfers as-is.

Anything already exposed as a plain CLI script. If a capability takes arguments and prints output, every harness can call it. Worth over-doing: the same capability built as a harness-native plugin is a rewrite.

The pattern: things that are files or rows port; things that are registrations don't.

Bucket 2: needs rewriting, but you know what you're rewriting

This bucket is honest work. It costs time, but nothing surprises you and nothing is lost.

Tool and capability definitions. Every harness lets an agent call out to things. None of them agree on how you declare it — schema shape, registration, how errors and results come back. The concepts survive perfectly; the declarations get retyped.

Spawn mechanics. How a session starts, how you append context to it, how the child's environment is scoped and what it inherits. We care a lot because our roles spawn other roles. The topology survives; the plumbing gets rebuilt.

The permission model. Every serious harness has one and none of them agree on granularity — some scope by tool, some by path, some by both, some let you deny and some only let you allow. The policy is what you carry across: deny-by-default for anything ingesting untrusted input, reads scoped to what the role actually needs, and a hard rule that a role's enforced permissions must cover what its instructions require. Write those down as prose, in your own repo, independent of any config format. Then re-express them in whatever the new harness speaks.

If you only take one thing from bucket 2: keep your policies stated in English somewhere you own. A policy that exists only as a config file is a policy you'll lose the reasoning for the moment the config format changes.

Bucket 3: silently doesn't survive

This is the expensive bucket, and it's expensive because nothing errors.

Implicit context semantics. What gets auto-loaded into a session and when. How compaction behaves as a session grows. Where session boundaries fall. Your prompts were tuned — probably unconsciously, over months — against assumptions you never wrote down. The new harness loads different things at different times and compacts differently, so your instructions are now being read in a context they weren't written for. Everything runs. Output quality drifts. Nobody can point at a broken thing.

Defaults you never set. Every default you accepted is now a different default. Model selection, timeouts, retry behavior, how much history a session carries, what a tool failure does to the turn. You never chose these, so they aren't in your head as things to check, so they aren't on your migration list.

Anything that worked because one harness happened to be lenient. Sloppy paths that resolved anyway. A slightly-wrong argument shape that got coerced. An ordering assumption that held because of one implementation detail. You had a dependency on leniency and no record of it.

The failure mode across all three is identical: the migration completes, everything runs, and quality quietly degrades for a week before anyone connects it to the move.

Five things that make this cheaper

1. Write the portability audit before you need it. List every layer of your setup. Mark each one ports / rewrite / dies. Do it while nothing is on fire — the version you write mid-migration is the version you write while motivated to be optimistic.
2. Keep state in files and a database, never in harness-native session objects. This is the whole ballgame. State that lives in the harness's own representation is state you renegotiate every time you move.
3. Set consequential defaults explicitly. If a default matters, write it down as a choice. An explicitly-set value migrates as a visible diff. An accepted default migrates as a silent change.
4. Migrate one role, not the fleet. Canary it exactly the way you'd canary a dependency version bump. Run it alongside the old setup on comparable work and diff the outputs. The bucket-3 problems only surface under comparison.
5. Measure your rewrite surface. The size of bucket 2 plus bucket 3 is your lock-in number. It's a count of concrete items, not a feeling. Teams who say "we're pretty portable" and teams who say "we're deeply locked in" are usually both guessing.

The part that isn't free

Portability costs something, and pretending otherwise would be a pitch rather than a post. Every capability you keep as a plain script instead of a harness-native integration is one you maintain yourself. You skip the ergonomics and own the plumbing forever. That's a real trade, and for a setup you'll never move, it's a bad one.

The bet is simply that you will move. That's a demand-side observation, not a prediction about any provider: the people migrating this week are mostly not migrating because something was done wrong to them, but because the assumption that any given harness is permanent turned out to be an assumption.

What this is, and isn't

We've written adjacent pieces and it's worth being precise about the seams. Your Agent's Memory Shouldn't Live Inside One Tool is the memory chapter of this post — one layer, done thoroughly. Your Agent Harness Is an Unpinned Dependency is about drift within one harness: the identifier stays the same while the artifact underneath changes. This post is about leaving the identifier entirely. Model Monoculture Is a Single Point of Failure sits a layer down, at model availability rather than harness surface. The Harness Floor is the natural pair: the floor is the rent you pay while you're there, this is the moving cost. And Agents Don't Fit Workflow Engines overlaps on exactly one point — durable task state is the thing worth making portable, for the same reason in both posts.

Next: the minimum portable agent — what's actually left when you strip every harness-specific thing out of a working setup.