On Thursday afternoon, you and your coding assistant start moving your billing to a new payments provider. You agree the goal, rule out the approach that would have meant downtime, correct it twice on how refunds are rounded, and stop with the last few services still to move. Most of what the afternoon produced was decisions.
On Friday morning, a new session knows none of it. You paste in your notes, explain the rounding again and watch it suggest the approach you ruled out the day before. The same happens when a colleague picks the job up in Codex instead of Claude, and again next quarter, when your company moves to a newer model.
To continue, a job needs four things: the goal, the decisions already settled, the corrections and what is left to do. Duplex carries exactly that across sessions, agents, apps and models. It stays current when a fact changes, and for every piece you can see where it came from. The work follows you, instead of waiting for you to rebuild it.
The next session starts where the last one ended.
The next session starts where the last one ended.
Most of a long session is the route to a decision: options weighed, drafts thrown away, dead ends tried and abandoned. The next session needs to know where the route ended, and rarely every step it took to get there.
The usual ways of carrying work forward each help, up to a point. Pasting the whole history back in works well while the history is short, and a notes file is yours to control. But someone has to paste, trim and update, every time, and the notes are only as current as whoever last touched them.
Duplex brings each new session the state of the work instead of its transcript, so the first hour goes on the work itself and not on rediscovering settled ground. When a different agent picks the job up, in another assistant or in one your company built, it starts from the same place.
For every piece, you can see where it came from: which agent, with which model, and when. A decision settled in Claude on Thursday reaches Codex on Friday with its origin in plain view, so nobody has to take it on trust.
The difference grows with the job. The history gets longer with every session, and reading all of it costs more for every question asked, while what the next step needs stays small.
After a few sessions, reading the whole history for every question is still cheap.
Your choice of model stays open.
Models improve, prices change and different tasks suit different providers. The model that writes your best code reviews may not be the one that answers your customers best, and this year’s best model is unlikely to be next year’s. A team that can move freely between them gets the best of each.
What usually makes moving hard is everything built around the old model. Prompts tuned to its habits, examples chosen for it and fine-tunes trained into its weights all stay with the model they were made for. A fine-tune is a sound choice when you want one model changed for good, and that is exactly the catch: change the model, and the teaching starts again.
What Duplex learns works beside the model rather than inside it, so it moves when you do. Move a task to a better model, and the new model starts with everything Duplex knows about the work: the decisions, the corrections and the job in progress. When the work moved to another model family, Duplex needed no retraining at all, and a fine-tuned adapter made the same move in none of six tests.
The model becomes a choice you make on the merits, task by task, whenever a better one arrives. Code review can run on one model and support replies on another, with the same intelligence beside both.
Different tasks suit different models, and Duplex brings each one what it has learned.
What follows you stays current.
Carrying work forward only helps if what is carried is still true, and facts change in the middle of a job. Last week your store accepted returns for 30 days, and on Monday the policy became 14. A history that holds both will sooner or later hand the old one to the model, and the model can’t tell it was replaced.
The common answer is to search: look through the history, or through what a memory feature saved, for whatever looks most like the question. Search is good at finding what was said. But the old policy looks as relevant as the new one, often more, because it was discussed for longer, and a search can’t tell a fact from the fact that replaced it.
Duplex follows the change. When a fact changes, the old one stops guiding the work, and the next session, agent and model get the current one. You can see what it replaced, and when. On a public long-history benchmark, where a fact had changed partway through the history, Duplex answered with the current one 96% of the time.
Sessions end, agents change and models get replaced, and with Duplex none of it costs your team its progress. Whoever picks the job up next, in whatever tool and on whatever model, starts with the goal in sight, the decisions made, the corrections applied and the old facts out of the way. The tools become choices you make for today, and the work becomes something that lasts.