ms-ai-architect/skills/ms-ai-engineering/references/agent-orchestration/agent-memory-and-context-management.md
Kjell Tore Guttormsen 3a73eeafdc refactor(ms-ai-architect): R13 del 1 — nøytraliser Cosmo-personaen i ref-korpusets headinger, etter å ha rettet en gate som var målt usann to ganger
Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:

1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
   produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
   substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
   `Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
   tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
   kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
   formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
   132 bokføres til R13b/R14.

Tre korreksjoner av premisser som sto i ordren og STATE:
  «ca 320 produkt»   -> 451 (case-sensitivt nett manglet 327 lowercase
                        TOC-ankre + 99 identifikatorer; sann nevner 1 638)
  «169 headinger»    -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
                        internt inkonsistent med sin egen topp-variant (204)
  «417 matcher ingen
   populasjon»       -> 417 er cosmo-headinger utenfor kodefences; briefens
                        nevner var reell hele tiden

Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.

TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.

Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.

Verifisering (alle 7 kriterier fra ordren):
  G1 persona på heading-linjer   401 -> 0
  G2 døde fragmentlenker         1 -> 1 (pre-eksisterende, unntatt)
  G3 produkt-forekomster         451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
  de 3 kun-produkt-filene        byte-identiske
  nettet validert begge veier    injisert persona feller G1; genitiv feller G1;
                                 produkt-heading og de 3 filene passerer
  hele diffen                    802 heading-linjer + 654 TOC-linjer, ANNET = 0
  linjeantall                    728 lagt til = 728 slettet
  suite                          1120/1120 (1097 + 23 nye)
  validate-plugin                250 PASS / 0 FAIL
  stikkprøve                     10 filer, alle 5 skills, inkl. de 3 mest
                                 produkt-tunge (26/20/19) — kun heading+TOC

Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 22:12:28 +02:00

23 KiB

Agent Memory and Context Management Strategies

Last updated: 2026-06-24 Status: GA (Managed Memory in Foundry Agent Service: Preview) Category: Agent Orchestration & Automation Type: reference Source: https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory


Innhold

Introduksjon

Agent memory og context management er grunnleggende for å bygge AI-agenter som leverer personaliserte, kontekstbevisste opplevelser over tid. Uten minnehåndtering er alle Large Language Models (LLMs) stateless — hver interaksjon starter fra blanke ark, uten kjennskap til tidligere samtaler eller brukerpreferanser.

Microsoft tilbyr et hierarkisk minnesystem for agenter i sin AI-stack, som spenner fra kortvarig session context til persistent long-term memory. Strategiene varierer fra ephemeral in-memory storage (Semantic Kernel) til managed, cloud-baserte memory stores (Foundry Agent Service). Riktig minnearkitektur er kritisk for å balansere brukerpersonalisering, ytelse, kostnad, og compliance-krav som GDPR og datasuverenitet.

Hovedutfordringen er å håndtere to typer minne: short-term memory (session context, chat history) og long-term memory (brukerpreferanser, facts på tvers av sesjoner). Microsoft-stakken tilbyr tre hovedtilnærminger: chat history management (alle agenttyper), vector-basert semantic memory (Semantic Kernel), og managed memory extraction (Foundry Agent Service preview).


Kjernekomponenter

Memory-typer i Microsoft AI-stakken

Memory-type Varighet Bruksområde Implementering Documented
Short-term (Session) Inneværende samtale Opprettholde immediate context ChatHistory, AgentThread ✅
Working Memory Inneværende session Kritiske beslutninger/krav WhiteboardProvider (SK) ✅
Long-term (User Profile) På tvers av sesjoner Brukerpreferanser, facts Mem0Provider (SK), Foundry Memory Store ✅
Long-term (Chat Summary) På tvers av sesjoner Tråd-kontinuitet Foundry Memory Store (preview) ✅
Semantic Memory (Vector) Persistent, søkbar RAG-basert knowledge retrieval Vector Store connectors ✅

Minnearkitekturer per plattform

Plattform Kortvarig minne Langvarig minne Persistence-layer Documented
Semantic Kernel Agents ChatHistoryAgentThread Mem0Provider, Vector Stores Egen/ekstern (Cosmos DB, Redis, etc.) ✅
Foundry Agent Service Session context (managed) Managed Memory Store (preview) Azure-managed (AI Search, embeddings) ✅
Microsoft Agent Framework ChatHistoryProvider (in-memory/Cosmos) ChatHistoryMemoryProvider, Mem0Provider, Redis Cosmos DB, Redis, external ✅
Copilot Studio Built-in session variables Conversation history (opt-in Cosmos DB) Managed eller BYOS (Cosmos DB) ✅
M365 Copilot Microsoft-managed Microsoft-managed Microsoft-controlled ✅

Semantic Kernel Memory Providers

Legacy Memory Stores (deprecated — bruk Vector Store abstractions):

Provider Type Documented
InMemoryMemoryStore Prototyping, testing ✅
Azure AI Search Production vector storage ✅
Cosmos DB (NoSQL/MongoDB) Multi-region, low-latency ✅
PostgreSQL, SQL Server Relational database-backed ✅

Modern Vector Store Abstractions (anbefalt):

  • Støtter custom schemas, multiple vectors per record, pre-filtering
  • Mer fleksibel enn IMemoryStore (f.eks. valg av distance function, index types)
  • Se rag-architecture/vector-databases-and-indexing.md for detaljer

Baseline: Microsoft migrerer bort fra IMemoryStore til Vector Store abstractions. Bruk sistnevnte for nye prosjekter.


Arkitekturmønstre

Mønster 1: Stateless Agent med manuell history management

Bruksområde: Enkel chatbot, transactional agents, prototyping.

// Semantic Kernel ChatCompletionAgent
ChatHistoryAgentThread agentThread = new();
ChatMessageContent response = await agent.InvokeAsync("Hva er været i dag?", agentThread).FirstAsync();

// Session context lagres i agentThread, som lever i appens minne
// Langvarig persistence krever eksplisitt lagring (Cosmos DB, Redis, etc.)

Fordeler:

  • Enkel implementering
  • Lav overhead for korte sesjoner
  • Full kontroll over data lifecycle

Ulemper:

  • Ingen automatisk persistence
  • Session state går tapt ved restart
  • Krever manuell implementering av long-term memory

Baseline: Standard for Semantic Kernel. Egnet for low-stakes apps eller prototyper.


Mønster 2: Managed Long-Term Memory (Foundry Agent Service)

Bruksområde: Personaliserte agenter med cross-session continuity.

Foundry Agent Service tilbyr managed memory (preview) som automatisk:

  1. Ekstraherer key information fra samtaler (preferanser, facts)
  2. Konsoliderer duplikater og løser konflikter
  3. Henter relevant context ved nye sesjoner

Memory-typer (Foundry Agent Service ekstraherer tre typer long-term memory):

  • User profile memory: Statisk info (allergi, språkpreferanse, navn)
  • Chat summary memory: Distillert sammendrag av tidligere tråder
  • Procedural memory: Gjenbrukbare how-to-rutiner og operating patterns utledet fra tidligere interaksjoner (aktivert by default)

Retensjon/forvaltning (siste preview): item-level memory CRUD (create/read/update/list/delete), store-nivå default TTL (default_ttl_seconds, 0 = ingen utløp) og direkte remember/forget-kommandoer. Styr hva som lagres via user_profile_details (også for å ekskludere sensitive data → styrker GDPR/«retten til å bli glemt»).

# Foundry Agent Service (Python SDK)
memory_store = client.memory.create_memory_store(
    memory_store_id="user-profile-store",
    chat_summary_enabled=True,
    user_profile_details=["dietary restrictions", "preferred name", "language"]
)

# Attach memory search tool til agent
agent_with_memory = client.agents.create_agent(
    model="gpt-4o",
    instructions="You are a recipe assistant. Use memory to personalize suggestions.",
    tools=[{"type": "memory_search"}]
)

Fordeler:

  • Automatisk extraction og consolidation (LLM-powered)
  • Managed persistence (ingen egen database-oppsett)
  • Konsistent cross-session experience

Ulemper:

  • Preview-funksjonalitet (kan endre)
  • Krever Azure OpenAI chat + embedding models
  • Quotas: 100 scopes, 10 000 memories per scope

Verified: Microsoft Product Terms for Previews gjelder. Data lagres i Azure (se offentlig sektor-seksjon for compliance).


Mønster 3: Hybrid Memory (Semantic Kernel Mem0 + Whiteboard)

Bruksområde: Agenter som trenger både long-term user memory og short-term working context.

Mem0Provider: Ekstern memory service for user-specific facts (cross-thread persistence).

var mem0Provider = new Mem0Provider(httpClient, options: new()
{
    UserId = "U1",
    ScopeToPerOperationThreadId = true  // Thread-spesifikke minner
});

WhiteboardProvider: Extracts requirements, proposals, decisions, actions fra samtalen. Beholder kritisk context selv når chat history truncates.

var whiteboardProvider = new WhiteboardProvider(chatClient);

// Kombiner begge i samme thread
agentThread.AIContextProviders.Add(mem0Provider);
agentThread.AIContextProviders.Add(whiteboardProvider);

Fordeler:

  • Best of both worlds: personalisering + session focus
  • Whiteboard forhindrer kontekst-tap ved truncation
  • Mem0 gir cross-session continuity

Ulemper:

  • Ekstern avhengighet (Mem0 service)
  • Mer kompleks konfigurasjon
  • Kostnad for Mem0 API-kall

Verified: Experimental Semantic Kernel-funksjonalitet. WhiteboardProvider og Mem0Provider er subject to change.


Mønster 4: Enterprise-grade Persistence (Cosmos DB Chat History)

Bruksområde: Multi-tenant SaaS, compliance-krevende miljøer, high-scale apps.

Microsoft Agent Framework tilbyr CosmosChatHistoryProvider for durable storage:

// Agent Framework med Cosmos DB persistence
var cosmosProvider = new CosmosChatHistoryProvider(
    cosmosClient: cosmosClient,
    databaseName: "agent-db",
    containerName: "chat-sessions"
);

var agent = new ChatClientAgent(
    chatClient: azureOpenAIClient,
    chatHistoryProvider: cosmosProvider
);

Azure Copilot BYOS (Bring Your Own Storage):

  • Organisasjonen velger og administrerer sin egen Azure Cosmos DB-instans
  • Full audit trail av alle Azure Copilot-samtaler (user prompts + Copilot responses) for alle tenant-brukere
  • System-assigned managed identity med Cosmos DB Built-in Data Contributor-rollen for sikker lese-/skrivetilgang
  • Aktiveres via Azure Copilot admin center → Conversation storage
  • OBS: Hvis BYOS aktiveres, mister brukere tilgang til samtaler lagret av Microsoft foer aktivering. Bytte av Cosmos DB-instans gir tilsvarende tap av tilgang til tidligere instans.
  • OBS: BYOS deaktiverer for oeyeblikket migration agent-kapabiliteter i Azure Copilot

Fordeler:

  • Full data control og compliance
  • Multi-region replication (global low-latency)
  • Integration med existing Cosmos DB infrastruktur

Ulemper:

  • Cosmos DB-kostnader (RU/s)
  • Krever tenant isolation-strategi (partitioning)
  • Mer kompleks ops (backup, scaling, monitoring)

Verified: GA for Cosmos DB Chat History. BYOS for Azure Copilot er GA.


Beslutningsveiledning

Når bruke hvilken memory-strategi?

Scenario Anbefalt løsning Hvorfor
Prototyping, demo InMemory (Semantic Kernel) Rask setup, ingen persistence nødvendig
Transactional agent (single-turn) Stateless (ingen memory) Minimere data retention-risiko
Personalisert support agent Foundry Managed Memory Automatisk extraction, cross-session
Enterprise SaaS (multi-tenant) Cosmos DB + Vector Store Tenant isolation, compliance, scale
Offentlig sektor (Norge) Cosmos DB i Norway East/West Datasuverenitet, GDPR-compliance
RAG-basert agent Vector Store (AI Search, Cosmos DB) Semantic search over knowledge base
Complex reasoning agent Whiteboard + Mem0/Cosmos Bevare kritisk context + long-term facts

Vanlige feil

Feil Konsekvens Løsning
Deler samme ChatPrompt-instans på tvers av samtaler Cross-contamination av chat history Opprett ny ChatPrompt per conversation eller bruk persistent store
Ingen truncation-strategi Token-overflow, dyre API-kall Implementer ChatHistoryTruncationReducer eller max message limits
Lagrer secrets i chat history Sikkerhetshull (PII, credentials i logs) Implementer content safety (Azure AI Content Safety)
Ingen tenant isolation (multi-tenant) Data leakage mellom kunder Bruk per-tenant indexes eller partition keys
Automatisk memory extraction uten review Prompt injection → memory corruption Adversarial testing, content safety filters

Røde flagg

🚩 Agent husker feil data eller motsetninger: Memory consolidation-logikk må håndtere conflicts. Foundry Memory gjør dette automatisk (preview), men vær oppmerksom på edge cases.

🚩 Memory-quotas nås raskt: 10 000 memories per scope (Foundry). Design data retention-policy.

🚩 Session state går tapt ved restart: In-memory providers overlever ikke restarts. Bruk persistent store for critical apps.

🚩 Ingen audit trail: Offentlig sektor og regulerte bransjer krever logging. BYOS Cosmos DB gir full audit.


Integrasjon med Microsoft-stakken

Semantic Kernel ↔ Vector Stores

// Bruk Azure AI Search for semantic memory
var vectorStore = new AzureAISearchVectorStore(
    searchClient: searchClient,
    embeddingGenerator: embeddingGenerator
);

var textSearchStore = new TextSearchStore<string>(
    vectorStore,
    collectionName: "KnowledgeBase",
    vectorDimensions: 1536  // text-embedding-ada-002
);

// Attach til agent som RAG-provider
var textSearchProvider = new TextSearchProvider(textSearchStore);
agentThread.AIContextProviders.Add(textSearchProvider);

Foundry Agent Service ↔ Foundry IQ

Når bruke Memory vs. Foundry IQ:

Feature Memory Foundry IQ
User-specific context ✅ Memory ❌
Organizational knowledge base ❌ ✅ Foundry IQ
User-uploaded documents (session) ❌ ✅ File search tool

Baseline: Memory for personalisering, Foundry IQ for curated enterprise content, File search for ad-hoc docs.

Agent Framework ↔ Purview Context Provider

For compliance-tungt miljøer:

# Agent Framework med Purview integration
from agent_framework_purview import PurviewContextProvider

purview_provider = PurviewContextProvider(
    purview_endpoint="https://<account>.purview.azure.com"
)
agent.plugins.append(purview_provider)

Gir data lineage tracking og governance-enforcement.


Offentlig sektor (Norge)

GDPR og datasuverenitet

Krav:

  • Data residency: Samtalehistorikk må lagres i Norge (Norway East/Norway West regions)
  • Right to be forgotten: Implementer deletion APIs for memory/chat history
  • Data minimization: Ikke lagre mer enn nødvendig (ephemeral memory for transactional agents)

Løsning:

  • Cosmos DB: Deploy i Norway regions med geo-replication kun til EU
  • Foundry Memory Store: Sjekk data residency-dokumentasjon (preview-funksjon, kan ha begrensninger)
  • BYOS (Bring Your Own Storage): Anbefalt for full kontroll (Azure Copilot, custom Cosmos DB)

AI Act-implikasjoner

Artikkel 13 (Transparency): High-risk AI må logge all aktivitet. Memory/chat history må være auditable.

Artikkel 10 (Data Governance): Training data ≠ operational data, men memory extraction bruker LLMs. Vurder om memory consolidation trigger data governance-krav.

Løsning:

  • Bruk Cosmos DB BYOS for full audit trail
  • Implementer Azure Monitor + Application Insights for memory/context operations
  • Document memory extraction logic i AI-dokumentasjon (jf. Utredningsinstruksen)

Schrems II og dataoverføringer

Status (juni 2026): Foundry Memory (preview) har nå en eksplisitt region-liste som inkluderer Norway East (+ Sweden Central, France Central m.fl.), så memory kan holdes i Norge for norske deployments. Kjent begrensning: VNet-integrasjon støttes ikke for memory stores.

Løsning:

  • Anbefalt: Deploy memory store i Norway East (region bekreftet tilgjengelig i preview)
  • Alternativ: Semantic Kernel + Cosmos DB i Norway regions, eller BYOS-pattern
  • NB: Tjenesten er fortsatt preview — bekreft region-garantier mot Product Terms for Previews før produksjon med persondata

Forvaltningsloven § 11 (internkontroll)

Krav: Beslutninger tatt av AI må være etterprøvbare.

Memory/context-implikasjon: Hvis agent bruker long-term memory til å påvirke saksbehandling, må memory-innholdet logges sammen med beslutningen.

Løsning:

  • Export memory snapshot ved kritiske beslutninger
  • Lagre memory version ID i sakssystem
  • Implementer memory provenance (hvem/når/hvordan ble minnet opprettet)

Kostnad og lisensiering

Prismodeller

Foundry Managed Memory (preview):

  • Underlying model costs (chat + embedding)
  • Ingen separat memory-storage fee (preview — kan endre ved GA)
  • Quotas: 1000 requests/min (search + update)

Semantic Kernel Mem0:

  • Mem0 service subscription (external — se mem0.ai)
  • API call costs per memory operation

Cosmos DB Chat History:

  • Request Units (RU/s): ~400 RU per read, ~1000 RU per write (avhenger av størrelse)
  • Storage: ~NOK 2.5/GB/måned (Norway regions)
  • Global distribution: +50% for multi-region

Azure AI Search (Vector Store):

  • Basic tier: ~NOK 600/måned (prototyping)
  • Standard S1: ~NOK 2000/månd (production — 50M vectors)
  • Se cost-optimization/cost-estimation-frameworks.md for kalkulator

Optimaliseringstips

Strategi Besparelse Trade-off
Truncate chat history (keep last 10 msgs) 50-70% token cost Tap av long-term context
Use WhiteboardProvider 30-40% (bevarer kritisk context, mindre full history) Complexity
Ephemeral memory for transactional agents 100% memory storage cost Ingen personalisering
Batch memory consolidation (off-peak) 20-30% RU/s (Cosmos DB) Eventual consistency
Use Foundry Memory (preview) over custom Save ops cost (managed service) Less control, preview risks

Baseline: For cost-sensitive apps, prioritér chat history truncation + WhiteboardProvider over full conversation storage.


For arkitekten

Spørsmål å stille klienten

  1. "Skal agenten huske brukerpreferanser på tvers av sesjoner, eller kun innenfor én samtale?"

    • Nei → Stateless eller in-memory
    • Ja → Foundry Memory, Mem0, eller Cosmos DB
  2. "Hvor lenge skal samtalehistorikk bevares? (compliance-krav)"

    • < 24 timer → In-memory
    • 30-90 dager → Cosmos DB med TTL
    • Permanent → Cosmos DB + backup-strategi
  3. "Er det multi-tenant? Trenger vi tenant isolation?"

    • Ja → Cosmos DB med partition keys per tenant, eller per-tenant indexes i AI Search
  4. "Hvilke compliance-krav gjelder? (GDPR, AI Act, Forvaltningsloven)"

    • GDPR → BYOS (Cosmos DB i Norway), deletion APIs
    • AI Act high-risk → Full audit trail, memory provenance
    • Forvaltningsloven → Etterprøvbarhet av memory-påvirkning
  5. "Hva er token-budsjettet per sesjon? (context window limits)"

    • GPT-4o: 128K context → kan holde ~300 messages in-memory
    • GPT-4o-mini: 128K context → samme
    • Hvis > 300 msgs → Truncation eller WhiteboardProvider
  6. "Bruker agenten RAG (Retrieval-Augmented Generation)?"

    • Ja → Kombiner Vector Store (knowledge) + Memory (user context)
    • Nei → Kun chat history + memory
  7. "Hvor mye kontroll trenger vi over memory consolidation logic?"

    • Full kontroll → Custom logic med Semantic Kernel + Cosmos DB
    • Managed OK → Foundry Memory (preview, LLM-powered consolidation)
  8. "Hva er acceptable memory-quotas?"

    • Foundry Memory: 10 000 memories per scope
    • Custom Cosmos DB: Unlimited (cost-driven limit)

Fallgruver å unngå

❌ Anta at Foundry Memory er GA: Det er preview. For production, ha fallback til Cosmos DB.

❌ Ignorer prompt injection-risiko i memory: Malicious user → corrupt memory → påvirke andre sesjoner. Bruk Azure AI Content Safety.

❌ Lagre secrets i chat history: API keys, passwords, PII → bruk content filters.

❌ Glem tenant isolation: Multi-tenant uten partitioning → data leakage.

❌ Overstole på automatic consolidation: LLM-basert memory merging kan feile ved edge cases. Implementer conflict resolution-logging.

Anbefalinger per modenhetsnivå

Beginner (pilot/POC):

  • Semantic Kernel InMemory + ChatHistoryAgentThread
  • Ingen persistence (eller manuell JSON-fil export for testing)
  • Fokus: Funksjonalitet, ikke scale

Intermediate (intern produksjon):

  • Semantic Kernel + Cosmos DB Chat History Provider
  • Azure AI Search for RAG (hvis nødvendig)
  • Monitoring: Application Insights for token usage

Advanced (ekstern SaaS, offentlig sektor):

  • Foundry Agent Service + Managed Memory (preview) eller Cosmos DB BYOS
  • Multi-tenant isolation (partition keys, per-tenant indexes)
  • Full audit trail (Cosmos DB change feed → Azure Monitor)
  • Content safety (prompt injection detection, PII filtering)
  • Data residency enforcement (Norway regions, geo-replication policies)

Kilder og verifisering

Microsoft Learn-kilder (MCP-verified)

  1. Semantic Kernel Agent Memory https://learn.microsoft.com/en-us/semantic-kernel/frameworks/agent/agent-memory Confidence: ✅ Documented (Mem0Provider, WhiteboardProvider documentation)

  2. Foundry Agent Service Memory (preview) https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-memory?view=foundry Confidence: ✅ Documented (Managed Memory Store, extraction/consolidation/retrieval phases)

  3. Agent Framework Chat History Providers https://learn.microsoft.com/en-us/agent-framework/integrations/overview Confidence: ✅ Documented (CosmosChatHistoryProvider, Memory AI Context Providers)

  4. Azure Copilot BYOS (Bring Your Own Storage) https://learn.microsoft.com/en-us/azure/copilot/bring-your-own-storage Confidence: ✅ Documented (Cosmos DB conversation history, managed identity)

  5. Semantic Kernel Vector Stores https://learn.microsoft.com/en-us/semantic-kernel/concepts/vector-store-connectors/memory-stores Confidence: ✅ Documented (Legacy IMemoryStore deprecated, Vector Store abstractions GA)

  6. Multi-turn Conversations with Agents https://learn.microsoft.com/en-us/agent-framework/tutorials/agents/multi-turn-conversation Confidence: ✅ Documented (AgentSession for state management)

  7. Foundry Agent Service Context Layer https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/build-secure-process Confidence: ✅ Documented (Hierarchical memory: knowledge, long-term, short-term)

  8. Azure OpenAI Web App Chat History (Cosmos DB) https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/use-web-app Confidence: ✅ Documented (Cosmos DB enablement for chat history)

Konfidensnivå per seksjon

Seksjon Konfidens Kilde
Memory-typer ✅ Documented Microsoft Learn docs (Foundry, SK, Agent Framework)
Arkitekturmønstre ✅ Documented Code samples fra microsoft-learn MCP
Foundry Managed Memory ✅ Documented Microsoft Foundry Memory docs (preview disclaimer inkludert)
Cosmos DB Chat History ✅ Documented Agent Framework integrations, Azure Copilot BYOS
Vector Store deprecation ✅ Documented Semantic Kernel Memory Stores migration guide
Offentlig sektor compliance 🟡 Baseline GDPR/AI Act krav (established), Foundry Memory region-support TBD
Pricing 🟡 Baseline General Azure pricing (Cosmos DB, AI Search verified), Foundry Memory preview (TBD)

Overall confidence: ✅ Verified (90% MCP-sourced, 10% baseline for compliance interpretation)

Unique Microsoft Learn URLs accessed

  1. /semantic-kernel/frameworks/agent/agent-memory
  2. /azure/foundry/agents/concepts/what-is-memory
  3. /agent-framework/integrations/overview
  4. /azure/copilot/bring-your-own-storage
  5. /semantic-kernel/concepts/vector-store-connectors/memory-stores
  6. /agent-framework/tutorials/agents/multi-turn-conversation
  7. /azure/cloud-adoption-framework/ai-agents/build-secure-process
  8. /azure/foundry-classic/openai/how-to/use-web-app

Total unique sources: 8 Microsoft Learn URLs