Coding agents need an exit test before purchase

Judge an agent’s exit by the work another agent can resume

Before buying or renewing a coding agent, ask whether another agent can resume its unfinished work without repeating completed changes or reversing a human decision. A receiving agent may write competent code while missing the instructions that tell it which changes to leave alone. Portability therefore depends on what survives the transfer and how much human effort it takes to recover what is lost.

That recovery effort belongs in the purchasing decision because teams build up project decisions, exceptions, skills and integrations around an agent. Skills are reusable instructions for particular tasks, and their usefulness can depend on the tool that runs them. Model choice and a downloadable conversation help with switching, but an exit test shows whether the next agent can continue correctly while the buyer can still negotiate.

A ten-minute migration hid incompatible instructions for almost three months

An apparently successful personal migration shows why an exit test matters. One writer copied an instruction file, renamed it AGENTS.md so the destination tool would read it, and replaced the original product’s name with the new one. The migration appeared complete.

The file was part of a much larger collection of dependencies. In an inventory labeled “Today,” the writer listed global instructions, 114 skill folders, 189 small memory notes distributed across 24 projects, and 73 scripts invoking the original agent’s command-line interface, or CLI. Most skills were installed; the author had written a few. Each part of the collection depended on the original tool in its own way.

The global instructions told the agent how to operate, yet their readable format concealed an incompatible command. When the writer inspected the file “this month,” it had been in the home directory for “almost three months” and still required every model call to use Codex -p. In the CLI the writer describes, -p is short for –profile. Following the instruction literally would treat the supplied prompt text as a configuration profile’s name, directing the call toward a profile that did not exist.

Another retained instruction carried an assumption from the previous environment. The file contained a bold warning against using the former vendor’s API key, even though the destination agent had no relevant reason to access that key. Replacing the product name had left both the old restriction and the incompatible command in place. No error surfaced to draw the writer’s attention to either problem.

The absence of an error helped the file pass an informal inspection under unusually favorable conditions. The writer knew both tools, had written both sets of instructions, had both files open and could inspect both sides. Even with that access, the author eventually described the result as “one person” failing the exit test. The defect gives a concrete reason to examine the surrounding skills, notes and scripts: text can survive a transfer while retaining a meaning the destination tool cannot use correctly.

Model access and task continuity are different capabilities

The same distinction applies to common portability assurances: model choice, standard protocols and conversation export each solve part of the switching problem. The writer describes changing models as something possible in “an afternoon.” Continuing unfinished work also requires carrying forward the decisions and dependencies built around the model. A buyer needs to test how those survive the move.

To illustrate that accumulated work, the writer asks readers to consider six months in a codebase. An agent may have gathered decisions it must honor, approaches it attempted and abandoned, changes it completed, changes it only planned, and permissions and hooks configured around its operation. Hooks are actions triggered by particular tool events. Together with skills, memory notes and CLI-dependent scripts, these elements form working state: the information and dependencies that determine what the agent should do next.

A conversation export carries some of that information, but the receiving agent must distinguish what still applies. An early plan may have been replaced by a later decision, and a proposed change may already be complete. Unless the export makes those differences usable, the receiving agent must reconstruct the task’s current state from the conversation. That can require an engineer who remembers the history.

The systems around the model therefore matter to portability, as InfoWorld has previously argued in its coverage of AI lock-in. Shared governance is advancing through the Linux Foundation’s Agentic AI Foundation, which houses MCP, the Model Context Protocol for connecting AI tools to external systems, and AGENTS.md, an instruction-file convention. Common infrastructure can make tools easier to connect and instructions easier to exchange. A task-level exit test establishes whether those connections also preserve the decisions needed to resume work.

Regulation addresses another part of the switching problem. The writer gives September 2025 as the start of application of the EU Data Act’s cloud-switching rules, and January 2027 as the point from which providers cannot charge for switching itself. Those rules concern data processing services, while their application to an agent’s working state remains uncertain. Buyers should therefore establish what an export preserves during procurement, when they can make continuity a contractual requirement.

Test whether the next agent preserves a human exception

A task-level test needs an outcome that depends on a prior human decision. The writer proposes an illustrative exercise: upgrading an unnamed logging library across a service with a dozen modules. Maintenance work suits the exercise because the agent must understand both the requested change and the history that limits it. A new feature with little prior context would test less of the accumulated state.

The history begins with an assumption the first agent makes on day one, followed by a change of plan after work starts. One downstream consumer still needs the old log format, so the team decides to preserve it for that consumer. The writer places this awkward exception in a meeting in “March,” recorded in a single sentence that nobody marked as a requirement. Its authority comes from the team’s decision, even though the wording looks less formal than the original plan.

To test whether that decision survives, stop the first agent about halfway through the work. In the concrete example, it has migrated seven modules and deliberately skipped an eighth, leaving a note explaining why. The receiving agent must recognize the completed migrations, preserve the intentional exception and continue under the revised plan. Treating the skipped module as unfinished cleanup would reverse the team’s decision.

That reversal could still leave the build passing, which makes code validity an incomplete measure of continuity. In the writer’s hypothetical failure, the receiving agent “fixes” the excluded module because it has lost the reason for leaving it alone. Repeating work during a logging upgrade might be relatively cheap, while similar repetition during a schema migration could cause an incident. The test therefore checks whether the agent preserves the constraints that make a change acceptable.

Run the exit test twice and record human recovery work

To put that test into procurement, the writer recommends reserving a day before signing or renewing and choosing one realistic maintenance task. Keep it simple enough that engineers agree on the correct result, but include a human-decided exception that changes what the agent should do. If the task has no such exception, introduce one. This gives the receiving agent a clear requirement whose survival the team can observe.

The buyer should choose the task because its history determines what the exercise tests. The writer argues that a vendor-selected demonstration can favor new work with little history, avoiding earlier decisions that make continuity difficult. A buyer-controlled maintenance task brings those decisions into the demonstration. Does the receiving agent understand which changes the team has authorized?

Once the task is selected, let the original agent complete roughly half of it and request whatever the product claims is its work export. The export should carry requirements, decisions, completed actions and remaining steps. Give the receiving agent only the exported material, without access to the first session’s memory. Prefer a different vendor’s agent as the destination; a fresh session without the original memory provides the minimum separation.

Before that agent continues, decide what the engineer will observe and how to record it. Track repeated changes, returning assumptions and the survival of the human exception, then use a stopwatch to measure human context reconstruction. Whenever an engineer must answer from personal memory, record the answer as context the export failed to supply. This turns an impression of migration difficulty into a record of specific recovery work.

The writer organizes the evaluation into “Four things,” separating task-history losses from dependencies that may break during transfer. Keeping those categories distinct helps engineers identify the repair each failure requires. It also lets buyers compare runs without reducing the result to a single pass-or-fail judgment.

The dependency check extends beyond task history to the mechanisms that let instructions run. Inspect instruction files for vendor-specific commands, skills for tool-specific formats, hooks for events tied to one product, and credentials for product-specific scope. An instruction may be understandable and still fail because one of those mechanisms differs in the destination environment. The writer reports that, in personal experience, this dependency list can exceed what the contract would lead a buyer to expect.

With those observations defined, run the exercise twice because the destinations answer different questions. A new session inside the same product tests whether it can resume its own work through the claimed export. A second run across vendors tests the effort involved in leaving. A strong result inside one product tells the buyer about internal continuity, while the cross-vendor run supplies evidence for an exit decision.

Use the same reporting fields for both runs: Task; export size; changes repeated; retired assumptions brought back; human minutes; broken dependencies. Under each field, record what happened, including the decisions or dependencies that required repair. Export size becomes meaningful alongside what the receiving agent recovered from it. The report describes the switching friction for a task whose correct outcome the team already understands.

Separate model differences from missing state

Interpreting that report requires allowing for differences in the receiving model. A skill tuned to one model’s behavior may work differently on another even when its file transfers perfectly, and an export standard cannot remove that mismatch. The proposed evaluation measures switching effort without requiring identical behavior or zero-cost switching. Engineers should distinguish model-dependent behavior from missing decisions, lost completion state and broken operational dependencies.

Those distinctions make recovery effort useful in a commercial discussion. An engineer may need to adapt a skill, repair an integration or reconstruct a decision before work can continue, and each activity adds to the cost of leaving. Recording the activity shows the buyer which dependency needs attention and what improvement to request. An imperfect transfer can impose a real cost even when no vendor has done anything wrong.

Put the demonstrated export into the contract

The test report gives the buyer a basis for asking the vendor to demonstrate the actual export before signing or renewing. Use the buyer’s task and the export format that would be available on exit, then inspect its contents field by field while observing the receiving agent. A substitute format or a different task would test different conditions. The demonstration needs to match the transfer the buyer may later have to perform.

Begin the inspection with the information that determines the receiving agent’s next action. Ask whether decisions and completed actions are represented separately from chat, so another tool can identify the current state without treating every earlier statement as equally active. Then ask whether memory and skill formats are documented well enough for another tool to read them. These questions connect the export’s structure to its practical use.

The writer argues that serious vendors have already considered these questions because larger customers have raised them. A response confined to open-model claims and a protocol specification still leaves the task-continuity questions unanswered. The live exercise gives the vendor a concrete way to answer them. It also gives the buyer specific export behavior to address in the contract.

Contract terms must preserve access to that behavior on “the day the contract ends.” Ask how long the accumulated state will remain accessible, which export format will be available at termination and what charges will apply. Those answers determine whether the tested procedure remains possible when the commercial relationship ends. A sales demonstration helps only if the buyer can later obtain the state needed to repeat the transfer.

Access terms matter because negotiating conditions can become less favorable at departure. The writer expects most teams at renewal to have less control than in the personal migration, where one person understood both tools and had full access to both systems. The outgoing vendor may control the accumulated state and have little incentive to improve the export. Buyers can address that dependency while continuity requirements can still affect the contract.

The agreement and test report should also stay connected as the product changes. Keep the report with the contract and repeat the exercise at renewal, because an export tested “last year” may differ from the one available “today.” The writer applies the same principle previously raised in a discussion of green AI testing dashboards: a test loses value as evidence of current behavior when it is never repeated. Renewal should include a fresh result for the product version and export the team would actually use.

Final thoughts

A coding agent’s value includes the work another tool can continue after it leaves. If a transfer loses human decisions, repeats completed changes or requires engineers to reconstruct project history, the business inherits a switching cost. Model choice and downloadable conversations do not establish how large that cost will be.

Before committing, ask the team to demonstrate a handoff using a maintenance task with a known exception. Measure the human effort needed to restore missing context, and distinguish lost decisions from broken integrations and differences in model behavior. The result gives procurement and engineering a shared basis for judging whether the cost of leaving is acceptable.

Use that evidence to negotiate export requirements, access after termination and any applicable charges. Repeat the test at renewal. The objective is not a cost-free exit, but a demonstrated exit whose requirements and costs the business understands before it becomes dependent on the product.