What you rebuild when you switch agent platforms

A purchase-reconciliation workflow that had been running in production was moved to a different runtime. Prompts, model config and the tool manifest came across, and for two days it ran fine. On the third day a retry counter did not follow, so the workflow resubmitted three documents it had already filed.

Platforms have started selling the execution environment

On September 29 Manus shipped version 2.0, which the company describes as a new architecture rather than a version update: a new agent harness called Cascade, a persistent execution environment called Cloud Computer that you buy per project, and automations triggered by events instead of a schedule. The vendor claims one tested configuration used 23.2% fewer tokens, finished tasks in 28.2% less time and cost 32% less to run, and did not disclose the configuration or the task set (InfoWorld).

Treat those percentages as a direction rather than a selection input, for a concrete reason: without the task set you cannot tell whether the 28.2% came from fewer calls or from easier tasks. The more durable change in the same report is that the execution environment is now sold separately. That makes the machine a workflow runs on a bounded, billable asset with a lifecycle, and anything with a boundary has an ownership question attached.

Gartner senior director analyst Anushree Verma frames it in the same report: the orchestration layer is becoming a larger differentiator, especially for enterprise deployment, but it complements the underlying model rather than replacing it, and the strongest systems pair a capable model with an efficient runtime that uses it selectively. That moves the procurement question. It is no longer which model is best, but which machine the workflow runs on and who owns it.

One number from the same week is easy to skip past: AWS said almost 90% of Amazon’s early agent prototypes never shipped (The Next Web). The distance between demo and production is largely made of operating state, credentials and memory, none of which show up in a demo.

Operating state has four layers, and only one travels well

Treating operating state as a single word is where these evaluations usually fail. Split it apart and there are at least four layers, each harder to carry than the last.

• Task intermediate state: retry counters, completed substeps, the point where a run is parked waiting for human approval. It decides whether the process continues or starts over.
• Artifact and lineage: which run produced which artifact, and which version of the instructions and tools it used. It decides whether you can trace an outcome back to one specific execution.
• Connector credentials and authorization: which credential reads which system, when it expires, who can revoke it. It decides whether the system can be stopped.
• Long-term memory: facts, preferences and corrections accumulated across sessions. It decides whether the agent improves with use or starts from zero every time.

Only one layer leaves on its own. Prompts and model configuration are text and can be copied across in an afternoon. The other three usually take the form of rows in a database table, a credential record or a vector index. They are data rather than configuration, and data was never inside the export button’s obligations.

Sakshi Grover, research director for Asia/Pacific cybersecurity services at IDC, offers a stricter test than any checklist: assess a platform by the systems it can reach, the state it retains, and how quickly that state can be recovered elsewhere. She asks enterprises to establish where prompts, intermediate task state, artifacts, logs, backups and connector credentials are processed and stored, including by model providers and other subprocessors, and states plainly that an export button alone does not establish that an agent’s operating state is portable. For higher-impact deployments she recommends narrowly scoped short-lived credentials, external audit logging, approval gates for consequential actions and a fast revocation path.

Our judgment: ownership of state decides the switching cost

For two years the enterprise question was how much code a model swap would break. That question is losing weight because the thing that actually gets swapped has changed. What gets replaced now is the runtime: another platform, another harness, a move from self-built to managed. In that move the first-order variable is who owns the operating state, not how replaceable the model is.

The moment a platform turns the execution environment into a product, it also collects the state into its own tables. There is nothing conspiratorial here; it is what the architecture requires. Continuous operation, resumable runs and cross-session memory all need somewhere to live, and the cheapest place is the vendor’s own database.

So the acceptance step changes too: reproduce, do not inventory. A compatibility list can name protocols, APIs and SDK versions, but it cannot tell you which column holds your third retry counter. Reproduction has the advantage of being falsifiable. After the rebuild the first workflow either runs or it does not, and what is missing is visible on the spot. There is no third outcome and no room for interpretation.

The counter-argument deserves space. If a task is stateless, single-step and starts from zero each time, which covers a classification, a summary or a formatting job, none of this applies. Switching cost there is close to editing one configuration value, and spending a rebuild test on it is waste. Layered testing earns its cost only on long-running workflows with approval gates that write back into external systems.

Three numbers settle the cost: hours needed to rebuild one workflow, configuration items that have to be redone, and rows of data left behind inside the platform. The first two can be estimated. The third can only be measured, and a rebuild test lands exactly there.

The platforms are making the same move

On the same day, MongoDB launched Atlas Agent Engine at its investor day, folding retrieval, memory and governance into one layer. The company says every action is logged against a real identity and governed by policy that cannot be quietly switched off, and that the product builds on open standards such as MCP and A2A (vendor claim, PR reprint). Handing state, memory and governance to the layer that already stores your data is becoming the default, for the simple reason that the data is already there.

For buyers this means two things. The evaluation target shifts from a model vendor to a data platform: it already holds your data, and with state and memory on top, the migration surface is far larger than a model swap. The other is that the leverage still sits with the buyer. Writing portability into acceptance terms achieves more than asking for an export button later; an export button is a product feature, portability is a contractual right.

Five things to do before you sign

1. Pick a live workflow with a human approval gate and failure retries as the rebuild target. Do not use a demo case; demo cases conceal where state lives.
2. Rebuild it on the target runtime using only public documentation, without asking the incumbent vendor’s engineers first. Where you got stuck, and how often, is the finding.
3. Name each of the four layers: where intermediate state is stored, how lineage is linked, who issues and revokes credentials, whether memory can be exported in a readable format.
4. Walk the revocation path: how long it takes from deciding to revoke a credential to it actually failing, who can start it, and whether there is a bypass.
5. Put those findings into the contract rather than a sales promise: export format for state, an optional rebuild test, and an exit support window, all as acceptance terms.

The whole exercise costs a few days. In return you get a first-hand answer to how many months a platform switch would take, instead of a promise written on someone else’s behalf. If you had to switch runtime next week, could you say where each of the four layers lives? If not, the acceptance is not finished.

The record itself fits on a single page: four rows, one per layer, and three columns for where it lives, how it comes back and when it was last verified, with a signature underneath. It does not need to look good. It needs to be the page you can open the next time someone asks about the runtime, and point at the row that answers the question.

Boundaries and what remains uncertain

Stateless single-step tasks do not need this test. Where credentials already sit in an enterprise vault, the third layer was never inside the platform. During a pilot or a short contract, the check can shrink to the first and fourth layers.

One uncertainty should be stated: the 23.2%, 28.2% and 32% figures come from the vendor, with no published configuration or task set. They are cited here to show that the execution environment has become a product, not to endorse its efficiency.

Sources: InfoWorld, Manus 2.0 with IDC and Gartner commentary, 2026-09-29; The Next Web, OpenAI and Amazon Bedrock Managed Agents, 2026-09-29; PR reprint, MongoDB Atlas Agent Engine, 2026-09-29.