Give each kind of state an owner

Learning objective

Distinguish workflow state, sessions, conversations, and persistent memory.

Core idea

For an architect choosing what an agent retains, “state” is too broad to be a storage requirement. A workflow needs execution facts, an agent session needs continuity across runs, a conversation records interaction, and persistent memory carries selected knowledge across sessions. These can overlap in content without becoming the same object.

Classify each value by purpose, owner, lifetime, and recovery requirement. A shipping preference can belong in persistent memory; the fact that a shipment has been authorized belongs in authoritative business state. A transcript containing “approved” is not a reliable replacement for a recorded approval decision. See 1.2.5 for choosing persistence components; this lesson explains what those components must preserve.

How it works

Keep workflow state about execution

Workflow state carries facts that executors need while processing a particular task: a validated request, a selected branch, an intermediate result, or the identifiers of work already performed. Microsoft Agent Framework’s Python WorkflowContext.set_state() and WorkflowContext.get_state() let executors write and read values during workflow execution.

Shared state is not the same as an executor’s own mutable fields. The framework’s state guidance warns that reusing workflow and executor instances can share data across unrelated requests. Its Python pattern creates fresh executors and a fresh workflow inside a helper for each task. Keeping a shared executor object outside that helper can undermine the intended isolation even if you build a different workflow object.

Treat an execution-state key as a fact with a producer and consumer. If one executor writes validated_request, another must know its shape and whether validation has completed. A conversation summary is not sufficient evidence that this key exists. Similarly, setting a state value does not by itself establish a durable recovery strategy. Decide separately what survives a process failure; see 1.2.5.

Use a session for agent continuity

In Agent Framework, AgentSession is the conversation-state container used across agent runs. The Python object includes session_id, service_session_id, and a mutable state dictionary shared with context and history providers. agent.create_session() creates a session; passing it as session= to agent.run() keeps turns associated with that session.

The local session identifier and the service identifier have different jobs. service_session_id can refer to remotely managed history, such as a conversation or response ID. The local session can contain additional provider state. Therefore, persisting only the messages you display in a chat interface might not preserve everything needed to resume the framework session.

Python sessions support session.to_dict() and AgentSession.from_dict() for serialization and restoration. Serialization produces data; your application still needs to store and retrieve it durably. Sessions are agent- and service-specific, so restoring one with a different provider or agent configuration can create invalid context. Preserve the owning configuration and authenticated application user alongside the continuation mapping.

The session documentation explicitly warns that a raw service-side ID is not an end-user authorization boundary when several users share one backing project. Resolve client-visible session identifiers through trusted application storage and verify user or tenant ownership before resuming remote history. A valid-looking conversation ID does not authorize another person’s conversation.

Distinguish a conversation from its container

A conversation is the interaction history: user messages, agent responses, and associated exchanged content. A session is the runtime container that connects agent runs and history providers. They are related, but “one session equals one transcript file” is not a safe universal implementation assumption.

Foundry’s memory example uses openai_client.conversations.create() to create a conversation, then passes conversation=conversation.id on response calls. Creating another conversation gives the example a separate interaction history. Continuing an existing conversation and recalling a preference in a different conversation demonstrate two distinct forms of continuity.

A transcript is useful for conversational context and investigation. It does not automatically provide the workflow’s typed intermediate state, establish that an external action committed, or reconstruct provider-specific session state. Keep those records explicitly rather than asking a model to infer them from natural-language turns after a restart.

Reserve persistent memory for cross-session knowledge

Memory in Foundry Agent Service is a managed long-term memory capability in public preview. It extracts meaningful information from conversations, consolidates it, and retrieves relevant memories across sessions. The documentation distinguishes user profile memory, chat summary memory, and procedural memory. These are selected or distilled knowledge, not every previous message replayed verbatim.

For a prompt agent, MemorySearchPreviewTool attaches a memory store using memory_store_name, scope, and update_delay. The scope associates memories with the intended user or context. The delay controls when conversation-derived updates run after inactivity; the documented default is 300 seconds. A completed response therefore does not imply that every extractable preference is already searchable in another conversation.

Do not let a caller choose arbitrary memory scope without an ownership check. Do not treat extracted memory as an authoritative transaction ledger. A learned preference can help personalize an answer, but execution correctness should depend on validated workflow and business records. Foundry’s memory guidance also distinguishes personalization from grounding on curated organizational content; retrieval fundamentals are covered in 0.8.

Key distinctions and trade-offs

Use purpose rather than the word “persistent” to classify retained data:

Durable conversation history can outlive a process without becoming long-term semantic memory. Long-term memory can outlive a conversation without proving that a workflow step completed. More retention improves continuity but increases stale-context and isolation risks. Keep only data whose later use and owner you can explain.

Architecture / decision scenario

A purchasing assistant collects requirements, searches permitted catalogs, and prepares an order. The customer returns tomorrow to discuss a separate order and expects the assistant to remember a delivery preference.

For each order, the application creates fresh workflow and executor instances. Validated requirements and the selected quote flow through set_state() and get_state(). The order system records any committed order independently; the assistant does not use a remembered conversation summary as proof of purchase.

Within one discussion, the application reuses an AgentSession and the service conversation it references. If the process restarts, it restores the serialized session from trusted storage after checking customer ownership. A client-provided service conversation ID alone is insufficient.

For the separate discussion tomorrow, it creates a different conversation. If the deployment accepts Foundry memory’s preview status, a scoped MemorySearchPreviewTool can supply the customer’s distilled delivery preference. The team tests recall after the configured update delay and distinguishes a pending memory update from missing conversation history. A preference helps choose a suggestion; it cannot authorize an order.

Common exam traps

• Calling a persisted transcript a workflow checkpoint without preserving execution state.
• Assuming a local session_id and a remote service_session_id are interchangeable.
• Reusing mutable executors across unrelated workflow requests.
• Treating serialization as a storage service or a complete recovery design.
• Accepting a raw conversation identifier as proof of user ownership.
• Assuming Foundry memory updates synchronously after every response or is generally available.

What to remember

Workflow state tracks execution, sessions connect agent runs, conversations retain interaction history, and memory carries selected knowledge across sessions. Persisting one does not reconstruct the others. Preserve ownership and isolation whenever you create, resume, or retrieve context.

Knowledge check

References

• Microsoft, Workflow state
• Microsoft, Agent session
• Microsoft, What is memory in Foundry Agent Service?
• Microsoft, Create and use memory in Foundry Agent Service