Persistence is easy to enable. Isolation is the harder product decision.
Microsoft's current Agent Framework state guidance is unusually direct about the failure mode. It says teams should not reuse a single workflow instance for multiple tasks or requests because shared mutable state can leak across executions, and it recommends helper methods that build fresh workflow and executor instances per task. The same page adds a second warning that matters even more for enterprise teams rolling out shared agents: agent threads persist across workflow runs when the same workflow instance is reused. OpenAI's current Conversations API makes the same operating shift visible from another angle. Conversations exist specifically to store and retrieve conversation state across Responses API calls, and the platform's data-controls page says `/v1/conversations` and conversation items persist until deleted. The common story says continuity makes agents feel smarter. The operational reality is that continuity changes the state boundary, and every state boundary needs ownership.
Shared executors, history providers, and service-side state create a reset problem
Microsoft's resettable-executors guidance names the exact contract enterprises usually leave vague. If a workflow reuses shared stateful executors across runs, those executors need `IResettableExecutor` so the runtime can clear mutable state between executions; otherwise reuse can fail or leak state into the next run. Its memory-and-persistence guidance adds another subtle failure mode: if more than one history provider loads messages, teams can replay multiple stores into the same invocation and duplicate state unintentionally. OpenAI's data-controls guidance draws the service-side version of the same map. `/v1/responses` can retain application state for at least 30 days when storage is enabled, background mode keeps response data long enough to support polling, and conversation objects persist until deletion. That means a shared-agent rollout is never just one memory feature. It is a combined decision about local history, workflow state, reusable executors, service-side objects, retention windows, and deletion semantics.
Publish one reset contract before a shared agent goes wide
NIST gives the executive standard for why this should not stay informal. GOVERN calls for clear roles, responsibilities, and human oversight policies across the AI lifecycle. MANAGE says post-deployment plans should include monitoring, incident response, recovery, override, decommissioning, and change management. The practical artifact is one state-reset contract per shared workflow. Name the workflow-creation boundary, the executor-sharing rule, the conversation or session object that carries forward, the exact reset trigger, the deletion or TTL owner, the review point for exceptions, and the evidence that proves the reset happened before the next task began. If a team cannot show that contract for one shared research agent, one shared coding workflow, or one shared browser agent today, the rollout is already ahead of its control surface.
Key takeaways
- Treat shared-agent continuity as a state-ownership problem, not as a harmless memory upgrade.
- Name what gets reused, cleared, deleted, and retained across each workflow run.
- Publish one state-reset contract per shared workflow before rollout expands across teams.