Can your work survive a change of tools?

An export can open successfully and still leave you unable to continue the work. The files are present, but a relationship, an editable source or the reason for a decision has gone missing. For anyone choosing tools for a project expected to last, that distinction matters more than the presence of an Export button.

I want people to be able to choose a tool because it serves their work, with a reasonable route out when that changes. That does not require every tool to have the same features.

A transfer worth testing

In an illustrative case, a team is planning an exhibition in a specialized design application. Its project contains floor plans, artwork dimensions, notes about which pieces can travel together and decisions about accessibility. The application offers useful drawing features, and the team has good reasons to use it.

At the end of the project, someone saves a PDF of the final plan. It looks correct. But when the exhibition moves to a different room, the next designer needs to change the arrangement. The PDF doesn’t explain which dimensions were approximate, which objects are linked, or why an apparently convenient route was rejected.

A better handoff keeps the editable source and exports the essential plan and item data in forms a second tool can use. It includes the decisions needed to make responsible changes. The team tests this by asking another designer to adjust a representative part of the plan without relying on the original application or the original designer’s memory.

The test might reveal losses worth accepting. Perhaps decorative effects need to be rebuilt, while dimensions and relationships remain usable. Or it might reveal a serious dependency: an export has flattened the whole plan into an image. That finding should inform the choice of tool and the cost allowed for a future move.

The W3C’s guidance on data formats recommends standardized machine-readable formats suited to the intended use, with multiple formats where useful. Suitability is doing real work in that advice. Choosing a familiar file extension doesn’t establish that the information needed for the next task has survived.

The useful limits of portability

Reducing everything to plain text would be a poor reading of this principle. An image, a recording or a detailed design can carry information that a text summary loses. A specialized native format may preserve valuable editing capabilities. Keeping it alongside useful exports can be a better choice than forcing all work into the least capable common format.

Nor does a common format guarantee common behavior. Two AI agents may read the same project instructions and still interpret them differently. Their available tools, permissions and execution behavior may differ. Moving the records gives the next agent something to work from; it doesn’t prove that the next agent will execute the same task correctly. That requires a check of the actual task in the new setting.

Some dependencies are expensive to remove. A team may reasonably accept one because of capabilities it needs, provided it understands the cost and preserves what it can. “Portable” should describe an observed ability to continue specified work, with stated losses. It should not stand in for a claim that everything is interchangeable.

There are access limits too. The fact that several tools can read a file does not mean every tool is authorized to receive it. A handoff has to preserve the restrictions on private material as well as the material itself.

Choose a task you might need to perform after leaving the tool. Try it from the export and the accompanying records. Write down where you get stuck. That gives you a concrete dependency to address, price into the decision, or knowingly accept before more of the project depends on it.