Portable

The property

Portable asks whether identity, skills, context, and work can move. Between machines, between tools, between environments, between organizations, and forward through time.

The question is about artifacts rather than about components. Replaceability concerns whether you could substitute a piece of infrastructure. Portability concerns whether the things you spent two years creating survive that substitution.

How it differs from replaceable

The distinction is worth being precise about, because systems can have one without the other and the failure modes differ.

A system can be replaceable and not portable. Two harnesses are interchangeable, and everything you defined in one has to be recreated in the other. You can switch, and switching costs everything you built.

A system can be portable and not replaceable. Your definitions are in open formats, and only one runtime implements them. The artifacts would move if there were anywhere to move them to.

Both properties together are what produce actual freedom, and they are produced by different things. Replaceability comes from interfaces and abstractions. Portability comes from formats and export paths.

What should actually move

Not everything needs to be portable, and treating everything as though it does produces a system optimized for a migration that never happens. The useful test is whether an artifact could be recreated from knowledge you still have.

Things that must be portable, because they cannot be recreated:

• Agent identity and permissions. What each agent is and what it may do, including the reasoning behind narrow grants.
• Accumulated state. What agents learned: conventions, corrections, open threads. This is the artifact with no other source.
• Skills and procedures. Organizational knowledge that took months to elicit from the people who held it.
• Semantic definitions. What a metric means, which table is authoritative. Recreating these means having the same arguments again.
• Data and its history. Including the snapshot record that makes past answers reproducible.
• Evaluation sets. Real tasks with known answers, which are tedious to assemble and essential for judging anything.

Things that need not be, because rebuilding them is ordinary work:

• Deployment configuration and infrastructure definitions.
• The harness itself, provided the definitions moved.
• Model choices, which change anyway.
• Monitoring dashboards, which are cheap to rebuild and rarely worth migrating.

Degrees of portability

Portability is not binary, and naming the levels makes conversations about it more productive than arguing about whether something is portable.

The gap between the third and fourth levels is the one people underestimate. A published specification with a single implementation has not been tested as a specification. The second implementation is what proves the document was sufficient, which is why counting independent implementations is a better portability signal than reading the specification.

Portability per layer

The four layers have very different portability profiles, and knowing which is which tells you where to spend effort.

Data and semantics is the best served. Open file formats are self-describing and readable indefinitely. Table formats carry schema and history. What does not move automatically is the catalog state, meaning grants and registrations, and the semantic definitions if they live inside a BI product. Those two are the gaps worth closing.

Models and routing is portable at the interface and not at the artifact. Prompts and tool schemas move if written for portability. A hosted model does not move at all, which is the argument for open weights when reproducibility matters.

Harnesses and brokers is the weakest layer and the one where deliberate effort matters most. Almost nothing moves by default. Everything that moves does so because it was expressed in a standards-layer format rather than in harness configuration.

Open standards is the layer whose entire purpose is portability, which makes it the layer to judge most strictly. A standard that is not portable in practice has failed at its only job.

The projection problem

Portability across heterogeneous systems raises a problem that a format alone cannot solve, and the honest handling of it is a design property worth insisting on.

Runtimes support different things. One enforces a tool denylist natively; another has no permission system at all. One supports skills; another does not. A portable artifact moved between them does not mean the same thing in both places.

There are three possible responses and only one is safe. Pretending uniformity, and silently dropping what is unsupported, is the worst: a profile that declares a boundary runs somewhere that ignores it, and the user believes in a control that does not exist. Refusing anything not fully supported is safe and reduces portability to the intersection of every implementation, which is close to nothing.

Projecting and reporting honestly is the third. This capability is native here, this one is approximated, this one is degraded in this specific way, this one is unavailable. The user then decides whether the projection is acceptable for the work at hand.

This is why conformance levels with a requirement to publish what is not implemented are more than bureaucracy. Partial support is fine. Partial support that looks complete is not, because someone will review an artifact, run it elsewhere, and get something different from what they read.

Portability through time

Most discussion of portability concerns moving between systems. The harder and less discussed direction is moving forward through time, into a future where the tools that created an artifact no longer exist.

The data layer solved this decades ago and the lesson transfers. A Parquet file written today is readable in fifteen years because it is self-describing: the schema travels with the data, the encodings are documented, and no external system is required to interpret it. That property was designed in, and it is why the format outlived several generations of the engines that wrote it.

Agentic artifacts mostly do not have this property yet, and the gap is worth naming per artifact.

• Skills age well. Markdown with a documented frontmatter convention is readable by a person with no tooling at all, which is the strongest form of durability.
• Profiles age well for the same reason, provided the artifact declares which specification version it targets. Without that declaration, a future reader has to guess what a field meant.
• Graphs age well as documents and less well as executable things, because they reference tools and systems that may not exist later. A graph is still readable as a record of intent, which is often what you want from it years afterwards.
• Accumulated state ages worst. It refers to systems, people, and situations that change, and a fact recorded three years ago with no timestamp or provenance is worse than nothing because it is confidently stale. This is the strongest argument for state entries carrying confidence and source rather than being plain text.
• Traces age only as well as their format. Recorded in a standard tracing format, they remain readable by general tooling; recorded in a bespoke shape, they become unreadable when the viewer is retired.

The practical habit is small: declare a version in every artifact, timestamp anything that describes a state of the world, and prefer text formats a human could interpret without software. All three cost nothing at write time and are impossible to add later.

Testing it

Portability that is never exercised is a claim rather than a property, and the tests are cheap.

1. Load your skills in a second harness. Once. See what activates and what does not.
2. Run one agent profile through a broker onto a second runtime. Read the projection report rather than only the outcome.
3. Read a table with an engine you do not normally use. Format compatibility claims are easier to make than to verify.
4. Export everything and try to reconstruct. The most revealing test and the one nobody runs. Take the exports and ask whether a new environment could be stood up from them alone.
5. Check that your evaluation set is itself portable. An evaluation harness that only runs against one provider is a portability gap in the thing you use to measure portability.

The organizational dimension

Portability is usually discussed as a technical property and it is also an organizational one, in ways that matter more than the technical framing suggests.

Knowledge held in one person's head is not portable. When they leave, it leaves. A skill that captures the same procedure moves to whoever needs it, which is a form of portability that has nothing to do with formats.

Definitions held in one team's tooling are not portable across teams. A metric definition inside one group's BI project cannot be used by another group's agent, so the second group defines their own, and the organization now has two answers to one question.

This is worth naming because it changes the justification. Making artifacts portable is often argued for on the basis of hypothetical vendor changes, which are easy to discount. The immediate benefit is usually internal: definitions that move between teams, procedures that survive turnover, and agents that a colleague can pick up. Those benefits arrive whether or not anything is ever migrated.

Practices that preserve it

1. Definitions in files, in version control. The single most effective practice. Product state does not move; files do.
2. Prefer formats with independent implementations. Count them rather than reading the specification.
3. Keep accumulated state exportable. Memory and learned state are the irreplaceable artifacts. Check the export path before you depend on the store.
4. Declare versions in artifacts. An artifact without a stated specification version becomes ambiguous the first time the specification changes.
5. Treat extensions as decisions. Using an implementation-specific extension is sometimes right. Record that you did, and what stops working if you move.
6. Insist on honest projection. When a tool maps your artifacts onto something else, prefer the one that tells you what it dropped.
7. Test annually. A portability check once a year catches drift while it is still cheap.

The cost, stated plainly

Portability is usually argued for and rarely priced, which makes the argument less persuasive than it should be. The costs are real and worth naming.

You work at the intersection. A portable format supports what multiple implementations support, which is less than the best of them offers. Accepting that means occasionally declining a capability that would have been useful.

Artifacts need maintenance. Skills go stale, profiles reference systems that changed, graphs point at tools that were retired. Portable artifacts are code-adjacent and need the same validation and review, which is ongoing work that product state does not require because the product enforces its own consistency.

Versions need tracking. Each specification adopted is one more thing with a version, a deprecation policy, and a migration path.

The benefit is contingent. The payoff arrives if you migrate, if a vendor changes terms, if a team splits. None of those may happen, and the cost is paid regardless.

This asymmetry is why portability loses arguments in the moment. The counter is not to argue harder about hypothetical migrations but to notice the benefits that arrive immediately: definitions that move between teams, procedures that survive turnover, artifacts a new colleague can read, and review by people who could not review a product configuration. Those accrue whether or not anything is ever migrated, and they are usually the stronger case.

What it is not

Portable is not the same as identical. An artifact moved to a runtime with different capabilities may behave differently. The goal is that it moves and that the differences are known, not that they do not exist.

Portable is not the same as standard. A format can be standardized and unportable if no second implementation exists, and an informal convention can be highly portable if everything reads it.

Portable is not free. Portable formats work at the intersection of what implementations support, which means giving up some capability that a proprietary format would offer. That trade is worth making for artifacts you cannot recreate and often not worth making for everything else.