An Organization Cannot Upgrade Mid-Execution

An autonomous organization does not change one thing at a time. A workflow definition evolves. An agent receives a new implementation. A tool changes its request contract. Memory gains a field, a knowledge representation is revised, or a policy is replaced. These changes can be deployed separately, and often should be. But a business execution that began under one set of assumptions can remain active while all of them change around it.

That creates a runtime problem, not merely a release-management problem. The relevant question is not whether every service deployed successfully. It is whether the organization can prove that every participant in a particular execution interpreted commands, state and authority under compatible contracts.

“The unit that must remain compatible is not the component. It is the business execution.

Component versioning is necessary but incomplete

Established systems already address important parts of this problem. Temporal states that pinned workflow executions run on the Worker Deployment Version where they started. Its Worker Versioning capability became generally available in March 2026, and Continue-as-New boundaries can provide a controlled point at which certain long-running workflows move to newer code.

Kubernetes CustomResourceDefinitions can serve several API versions while designating one for storage. Conversion webhooks translate objects between requested and stored versions. But changing the designated storage version does not automatically rewrite existing objects: a separate migration or rewrite is needed before an old stored version can safely disappear.

Confluent Schema Registry makes compatibility an explicit property, offering backward, forward, full and transitive modes. The transitive modes matter because they compare a candidate against all applicable earlier versions, not just its immediate predecessor. The familiar expand–migrate–contract pattern follows the same discipline for incompatible interfaces: let old and new representations coexist, move consumers, then remove the old path.

These are strong component-level precedents. Yet each governs a different surface: workflow code, API resources, event schemas or interfaces. None, by itself, establishes that a workflow, the agents it calls, their tools, their memory, their knowledge and their applicable policies are mutually compatible for one business case.

Define an organizational compatibility envelope

An organizational compatibility envelope is an explicit, observable bundle of versions that a governed runtime binds to a business execution. Its contents should be concrete: the workflow definition and version; participating agent implementations; tool interface contracts; memory and knowledge schemas or representations; and the policy artifacts relevant to decisions and effects. The exact inventory will vary by organization, but it must be sufficient to explain how the execution interpreted the world.

The envelope is not a claim that all components share one release number. It is a compatibility declaration. A workflow at one version may be permitted to call an agent at another, using a particular tool contract and schema version, under a specified policy set. A different combination may be forbidden even if every individual component is healthy and deployed.

• Give every envelope a stable identifier and record it with the execution from its first durable step.
• Declare allowed combinations rather than inferring compatibility from deployment timestamps or package versions.
• Record the evidence used to admit a new envelope: compatibility checks, tests, approvals and known limitations.
• Make the bound envelope observable to operators, auditors and recovery processes.
• Treat policy artifacts as part of the bundle. Code compatibility does not determine whether an action remains authorized.

Migration is a governed transition, not a background side effect

New work can enter a new envelope gradually. Existing work has three honest options. It can remain pinned to its original envelope until completion. It can cross at a declared migration boundary, such as a workflow continuation or a business checkpoint. Or it can be transformed into a new envelope through an audited converter. The choice depends on the execution’s duration, state, risk and external commitments.

A migration boundary should name both the source and target envelopes, the state being carried forward, the transformation applied, and the evidence that admitted it. This matters because conversion is not inherently lossless, reversible or semantics-preserving. A converter can map fields while changing meaning, dropping context or making an old policy decision impossible to reconstruct. Those properties must be tested and evidenced for the specific transition.

The expand–migrate–contract pattern becomes more demanding at organizational scope. Expand means introducing the new contracts, representations and runtime capability while the old envelope remains supported. Migrate means routing new executions to the new envelope and moving eligible existing ones only through declared boundaries. Contract means retiring an old envelope only after no active execution, recovery path or required audit interpretation depends on it.

The operating consequence: deployment status is not execution status

A deployment dashboard can show green while the organization is unsafe to operate. It may show that a new agent, schema and policy are available, but not whether an in-flight procurement, incident response or customer case is now mixing incompatible interpretations. Conversely, holding all work on old versions forever turns compatibility into operational debt. The runtime needs a deliberate route between those failures.

This also changes incident response. When an execution produces an unexpected effect, investigators should be able to retrieve the envelope that governed it, including its authorized transitions. They should not have to reconstruct the answer from container images, repository history, service logs and informal release notes. Recovery must likewise know whether it is resuming under the same envelope, restoring an older compatible environment, or performing a documented migration.

Build the envelope before enforcing it everywhere

The first practical step is inventory, not a universal migration engine. Identify the contracts that actually shape an execution: workflow logic, agent behavior, tool inputs and outputs, persistent state, knowledge interpretation and policy. Then identify which combinations are supported and where an execution may safely cross between them. Long-running, high-consequence processes are the right place to begin because their mixed-version risk is visible and their checkpoints can be designed deliberately.

Next, make the bundle durable and queryable. A runtime should persist the envelope identifier when work begins, attach it to consequential actions, and write a transition record whenever the bundle changes. Only then should admission controls prevent unsupported combinations or require evidence before a migration proceeds.

Autonomous organizations will not stop changing while work is running. Nor should they attempt an impractical single instant in which every agent, interface, schema and policy changes together. The architectural requirement is narrower and more useful: every business execution must have a coherent compatibility context, and every departure from it must be explicit, authorized and inspectable.