Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-101.1 Design logical architecture for multi-agent solutions

Share context through explicit memory ownership

Completed by the knowledge check

Learning objective

Define short-term and long-term memory boundaries and cross-agent context-sharing responsibilities.

Core idea

Memory needs a purpose, an owner, and a lifetime. The conversation needed to finish a request is different from the workflow state needed to coordinate agents, and both differ from knowledge deliberately retained for later sessions. Persisting a value does not decide which agents should read it or whether it should influence another customer’s request.

Specify what each store contains, who supplies its identifiers, who can write or correct records, and when records expire. Share the minimum context needed for delegated work. See 1.2.5 for persistence component selection; this lesson defines the responsibilities those components must enforce.

How it works

Separate three kinds of state

Short-term memory maintains the active conversation’s immediate context. In Microsoft Agent Framework, an AgentSession carries conversation-associated state; Python creates one with agent.create_session() and supplies it through session on agent.run(). Reusing a session supports continuity, but you still need application ownership checks before resuming it.

Service-issued identifiers are not automatically end-user authorization controls. Microsoft’s session guidance warns against accepting raw service_session_id, previous_response_id, or conversation IDs from clients without ownership checks when a hosted application shares one backing project or API key. Map a client-visible session to the service-side identifier in trusted storage, then verify the authenticated user or tenant before resuming it.

Workflow state contains information executors need during coordinated work: selected evidence, a validated intermediate result, or a decision still awaiting review. It is an execution contract rather than a permanent user profile. A workflow checkpoint can persist it for recovery without making it long-term semantic memory.

Long-term memory retains distilled knowledge across sessions. Foundry Memory and the Memory Store API are public preview. Microsoft describes extraction from conversations, consolidation, and retrieval; it distinguishes user profile, chat summary, and procedural memory. These are learned records, not guaranteed authoritative facts or a replacement for a curated organizational knowledge source.

Assign cross-agent sharing deliberately

Choose the orchestration pattern partly by what context crosses between agents. Microsoft Agent Framework handoff gives the receiving agent the conversation context, while agent-as-tools lets the primary agent supply only relevant information to a tool agent. See 1.1.3 for who owns the delegated outcome. If a shipping specialist needs destination and approved delivery constraints but not the billing conversation, agent-as-tools gives the primary agent responsibility for constructing that bounded input.

Handoff participants do not share the same AgentSession instance. Instead, they synchronize user and agent messages across participants. Tool-related content, including handoff tool calls, is not broadcast. Thus, full conversational context does not mean every internal execution artifact or pending approval is copied to another agent.

Python’s handoff synchronization preserves user text, inline data, URIs, hosted files, and hosted vector stores, while non-user messages retain text only. It filters function calls, function results, approval payloads, and other tool-control content before forwarding. Do not assume a receiving agent can reconstruct a tool’s authoritative outcome from synchronized history. Supply required evidence through the chosen input or shared-state contract, and preserve the execution record separately.

Name the context-sharing responsibility alongside the pattern. In agent-as-tools, the primary agent selects and validates the specialist’s input and returned evidence. In handoff, each participant maintains its own session and depends on synchronization for conversational consistency. Neither pattern grants permission to reveal unrelated personal data; choose participants and supplied content according to their task.

For accepted intermediate values, .NET uses QueueStateUpdateAsync and ReadStateAsync with scopeName; Python uses WorkflowContext.set_state() and get_state() (see 1.2.5 for visibility rules). Define consistent keys and one responsible writer per authoritative value. Shared visibility does not decide which specialist’s conflicting claim should win.

Make promotion explicit. A specialist’s tentative estimate can remain in its returned result until the orchestrator validates it. Only then should the designated writer publish the accepted value. The same principle applies to long-term memory: a useful statement in conversation is a candidate for retention, not permission for every agent to store it indefinitely.

Partition long-term memory by the intended subject

Foundry Memory partitions records with scope; the memory_search_preview tool can use {{$userId}} and x-memory-user-id for user resolution, while low-level APIs require explicit scopes (see 1.2.5). Assign the application component that derives these identifiers from trusted user or tenant context, and use the same mapping for writes, searches, and deletion.

A backend calling Foundry for many customers must preserve the intended end-user subject rather than letting every memory follow the backend credential. Reject unchecked client-selected identities. A partition identifier selects a collection; it does not independently prove authorization to read it. Keep the identity mapping testable and make its owner responsible for preventing cross-user retrieval.

Microsoft recommends a dedicated memory store for each agent to establish clear access and optimization responsibilities. If several agents require common context, designate which component retrieves approved memories and supplies a bounded subset. A shared business fact should have an authoritative business source and owner; do not let competing personal memory extracts become the system of record.

Define admission, correction, and retention

MemoryStoreDefaultOptions configures extraction and retention (see 1.2.5 for category fields). Assign a memory admission policy: which preferences can be retained, which evidence supports them, and which content must stay out. Use user_profile_details to exclude inappropriate personal details or credentials, then validate retained content according to application policy. Extraction instructions alone are not a complete security control against memory poisoning.

default_ttl_seconds sets the store’s default retention for newly created entries; 0 means no expiration. Choose a lifetime from the record’s purpose instead of treating persistence as a reason for indefinite retention. Some store options are configured at creation, so verify post-create update support for the API version rather than promising that every setting can be changed later.

Assign correction and deletion to an owner. The Python Memory Store API exposes project_client.beta.memory_stores.create_memory for explicit records and delete_memory for an identified item, with delete_scope available for scope-level deletion. A request to forget information must reach the retained record, not merely remove a visible conversation message. Define how the application locates affected records and confirms the operation.

Check Memory’s scope capacity, region and model compatibility, and VNet constraint before accepting the managed preview; see 1.2.5 for the limits. Give one component responsibility for this capacity and isolation decision. If the selected store cannot satisfy it, change the persistence design rather than weakening the user mapping or sharing a scope across unrelated customers.

Key distinctions and trade-offs

Persistence versus meaning: Durable session or checkpoint state is still execution state. Long-term memory deliberately carries knowledge into future interactions.

Visibility versus ownership: Shared workflow scope makes a value readable. It does not authorize a specialist to overwrite another component’s accepted decision.

Partition key versus authorization: scope selects a memory collection. Trusted application identity and permission checks determine who may select it.

Sharing more context can improve continuity but increases disclosure and contamination risk. Distilling context reduces tokens and exposure but can remove qualifications. Preserve provenance and give the recipient enough evidence to interpret uncertainty rather than treating a summary as an unquestionable fact.

Architecture / decision scenario

A travel orchestrator coordinates itinerary and payment specialists. Each request receives a user-owned session mapping; the application checks ownership before reusing the underlying service identifier. The itinerary specialist receives destination and approved preferences, while payment receives the validated purchase proposal. Neither receives the other’s full conversation.

The design uses agent-as-tools for specialist work so the orchestrator selects the minimum input rather than broadcasting conversation history through handoff. It publishes the accepted itinerary through shared workflow state using the visibility rules in 1.2.5. Only the orchestrator writes that authoritative value; a specialist returns a candidate result instead of overwriting it.

A separate preview Memory store retains permitted user preferences with a defined TTL. The backend derives x-memory-user-id from the authenticated user for {{$userId}} resolution. Payment details remain outside that store. A corrected preference reaches the responsible memory component, and a forget request invokes the appropriate deletion operation. The team checks scope quotas, region support, and the lack of VNet integration before accepting this component for the deployment.

Common exam traps

  • Calling every persisted transcript long-term memory.
  • Treating raw conversation IDs or client-supplied scopes as authorization.
  • Assuming handoff participants share one session or receive tool and approval payloads through history synchronization.
  • Choosing handoff while assuming the primary agent alone controls each specialist’s context.
  • Forgetting preview status, scope quotas, or Memory’s VNet limitation.

What to remember

Give session context, workflow state, and long-term memory different owners and lifetimes. Share validated context through explicit contracts and scoped state. Derive memory identifiers from trusted identity, limit retention, and assign correction and deletion responsibility before any agent learns across sessions.

Knowledge check

References