Switch Coding Agents Without Restarting the Project

You are halfway through a fix. The agent has changed three files, one test still fails, and the session either hits a usage limit or starts repeating itself. Starting again feels expensive because the conversation contains an hour of investigation.

Before opening another chat, preserve what that hour produced. The next agent needs the current files, confirmed findings, remaining constraints, and a small next step. It rarely needs to reenact every turn of the original conversation.

This is useful during a model-quality incident, but also during routine quota exhaustion, a client failure, or a change of working environment. You can resume useful work while the original problem is still being investigated.

Decide whether to change the model, the harness, or the session

These are different interventions.

If the dependency installation is broken, changing the model will not install the missing package by itself. If the files are wrong, a fresh conversation still starts with wrong files. Preserve the symptom and choose the smallest change likely to help.

The harness-versus-model explanation is useful when product names make these choices feel interchangeable. Also check the destination's access and billing before beginning; an allowance in one service is not automatically usable in another.

Stop the old writer before handing over the files

Pause the original task and check whether any child task or process it started is still editing the same files. Do not assume that closing a tab stopped everything. If a process must be stopped, identify the one associated with this task rather than terminating unrelated work.

Then inspect the working tree. Preserve the committed revision and the uncommitted diff, including untracked files that belong to the task. Use the repository's normal checkpoint or backup practice. A commit hash alone does not capture the patch currently sitting in the editor.

Leave unrelated work in place. If the handoff requires a clean environment, prepare a separate copy or worktree instead of discarding existing changes. The goal is for the receiving agent to see exactly the state you intend it to continue.

Separate facts from abandoned theories

A long debugging conversation often contains several explanations that turned out to be wrong. A summary can accidentally promote one of them into a settled fact.

Compare these two handoff notes:

The timeout is caused by the database. Continue optimizing queries.

The request times out on the 10,000-row fixture. The query completes in the captured trace, but we have not yet identified the remaining delay. A database bottleneck was considered and is unconfirmed.

The second note gives the receiver something to verify. The first may send it down a path the earlier investigation never established. Both are illustrative examples; the point is to label the evidence, not to make a debugging story sound finished.

For each important finding, link to the file, test, trace excerpt, or observed UI state that supports it. Include failed approaches only when they prevent a likely repeated mistake. There is no need to carry every speculative message into the next session.

A handoff the next agent can actually use

Copy this template and replace the brackets with the current task's facts. Omit sections that genuinely do not apply.

Goal[The result the user needs, with acceptance conditions.]
Starting state[Repository revision or snapshot; branch/copy location.][Uncommitted changes and task-related untracked files.][Environment details needed to reproduce the current state.]
Completed and verified[Changes already made, with file locations.][Checks actually run and their results.]
Still unresolved[Current failure and reproduction steps.][Unconfirmed hypotheses, clearly labeled.]
Constraints and authority[Requirements that must remain true.][What work is authorized and where approval is required.][Other work or files that must be preserved.]
Next bounded step[One useful action with a checkable finish.]
Before editing, inspect the actual files and current diff.Confirm which completed findings still match this state.If the record and files disagree, report the difference.Then carry out the authorized next step and verify its result.

Keep secrets out of the note. Refer to the environment's established credential setup rather than pasting keys. Record dependency versions or fixture locations when they affect reproduction, but do not attach an entire environment dump by default.

The receiving agent's first useful output is a state check: it found the expected changes, confirmed the relevant baseline, and knows what remains unresolved. A polished paraphrase of the handoff without looking at the files has not achieved that.

A concrete example: continue a CSV-import fix

Imagine the original agent has added streaming parsing, but a cancellation check still fails. This is a fictional project used to show the level of detail needed.

A useful handoff might say:

Goal: import a large CSV without freezing the page.Cancellation must stop further row processing.
State: use the saved task checkpoint and attached current diff.Changes touch the importer and its progress display.The large-file fixture is in the task's test-data directory.
Verified: the small-file import check passes.Unresolved: canceling the large-file run still processes more rows.No conclusion yet about whether parsing or queue handling is responsible.
Next step: reproduce the cancellation failure, locate the work thatcontinues after cancellation, and make the smallest relevant fix.Check successful import and cancellation afterward.
Preserve the existing CSV format and unrelated UI changes.This task authorizes local edits and validation; release requires approval.

The new agent can inspect the real diff and run the failing case. It does not have to rediscover why the project needs large-file imports. It also has no reason to treat the original agent's preferred explanation as proven.

After the fix, verify both cancellation and successful import. A handoff is complete when the receiver has produced a checked result, rather than merely acknowledging that it understands the context.

How this maps to Agent.Space

An Agent.Space Workspace keeps ordinary project files available across Sessions. You can use another Session with a supported harness, such as Codex or Claude Code, and select from the model choices compatible with that harness. The project files and the explicit handoff provide continuity.

Those Sessions share files. Each one does not automatically receive a private branch, and simultaneous edits are not automatically merged. For a sequential handoff, stop the old writer first. For experiments in parallel, arrange independent copies or branches before starting.

If you already have a local Codex or Claude Code history, conversation import can preserve a selected history within its original harness. Prepare project files separately: importing a transcript does not upload the repository or convert a Codex conversation into a Claude Code session. To change harnesses, start a new Session against the prepared files and give it the handoff.

That distinction prevents a frustrating kind of “successful migration”: the conversation arrived, but the new agent cannot find the code it is supposed to continue.

Keep a small recovery point during long tasks

At a meaningful milestone, save the working state and update a short task note: what changed, what passed, what remains, and the next action. Use the place your team already keeps task records rather than creating another permanent documentation system.

If the next session becomes unreliable, you then have a recoverable project state instead of a transcript you must reconstruct under pressure. You can still investigate the incident using model-routing records or a regression test, while another agent continues the authorized work.

To try this workflow, open Agent.Space, prepare the project in a Workspace, and give the next Session one bounded task with a clear acceptance check. The first goal is modest: continue from the actual files and finish the next useful piece.

Workflow and examples by Agent.Space. Product behavior checked against the current implementation and existing product guides on September 15, 2026; supported models and access depend on the available configuration.