portfolio-optimiser/docs/research/2026-06-23-prior-art-platform.md

Research-rapport: Generisk porteføljeoptimerer på Microsoft Agent Framework

Dato: 2026-06-23 Fase: Decision-grade research (plan-fase — ingen kode skrevet) Metode: Dynamisk multi-agent research-sweep i Claude Code — 7 grunngitte grener (MAF-plattform · Claude Agent SDK-mønstre å porte · prior art · neuro-symbolsk hybrid · dataintegrasjon · HITL/læring · feilmoduser) → adversariell verifisering av plattform-kritiske påstander mot offisiell dokumentasjon → syntese. 22 agenter, ~1.4M tokens, 228 verktøykall, ~9 min. Kilder: Microsoft Learn (offisiell MAF-dok), web/Tavily, akademiske preprints (arXiv, MDPI). Gemini Deep Research-trianguleringen falt bort (MCP-serveren kjører på et API deaktivert av Google mai 2026). Verifisering: Plattform-kritiske MAF-påstander adversarielt re-sjekket mot offisiell dok — 8 av 14 bekreftet uten forbehold; 6 korrigert (se §11 Verifiseringslogg). Praktiker-tall (hallusinasjons-%, FinOps-besparelser, «16 %»-tallet) er medium/lav confidence og merket. Låste premisser (bruker, 2026-06-23): (B) optimering INNI hvert prosjekt; multi-agent samarbeid à la «dynamic workflows»; hybrid AI + deterministisk verifisering; metode oppgis av bruker (helst som «skill»); bruker oppgir datatilgang, trigger og stoppkriterier; HITL-læringssløyfe = nøkkel-suksesskriterium; modell-backend = Microsoft/Azure AI Foundry med per-agent modellvalg.

Lesehjelp: §1 er sammendraget (hva researchen endrer). §13 er anbefalt arkitektur + neste steg. §14 (Foundry-binding) er lagt til etter syntesen fra egen grunngitt sjekk. §11 (verifiseringslogg) og §12 (åpne spørsmål) er de viktigste for beslutninger.

---

1. Sammendrag — hva researchen ENDRER om designet vårt

Researchen bekrefter at MAF er en levedyktig plattform for dette systemet, men flytter flere antakelser. De viktigste endringene, viktigst først:

1. «Skills» er IKKE et gap — det er en åpen, kryss-vendor standard MAF allerede implementerer. MAF Agent Skills følger samme agentskills.io-spesifikasjon som Claude Agent SDK. Brukerens kjernekrav (brukerleverte, kodifiserbare, gjenbrukbare analysemetoder) løses direkte med SKILL.md-pakker (instruksjoner + scripts/ + references/) — uten egen plugin-arkitektur. Verifisert med én korreksjon: progressiv disclosure er fire stadier (Advertise → Load → Read resources → Run scripts), ikke tre. Kilde: https://learn.microsoft.com/agent-framework/agents/skills

2. Magentic (LLM-orkestrert debatt) skal IKKE være default for kjerneflyten. Microsoft flagger den eksplisitt som eksperimentell og «untested outside the original Magentic-One design». Den anbefalte primærflyten for «agenter som debatterer mot et forslag» er Group Chat med maker-checker-loop og deterministisk termineringskontrakt — ikke Magentic. Magentic reserveres for genuint åpne delsteg med harde rundetak. Kilde: https://learn.microsoft.com/agent-framework/workflows/orchestrations/magentic

3. Læringssløyfen (suksesskriteriet) er ikke en MAF-primitiv og MÅ bygges eksternt. MAF har ingen innebygd mekanisme for å persistere ekspertfeedback til fremtidige kjøringer (verifisert). Den anbefalte tilnærmingen er «experience distillation uten fine-tuning» (ExpeL/ERL-mønster): lagre (forslag, ekspertdom, begrunnelse)-tripler, embed dem, hent topp-K ved kjøretid via en custom ContextProvider. Fine-tuning utsettes til retrieval-taket er nådd og ≥~1000 stabile merkede dommer finnes.

4. Hybrid AI + deterministisk verifisering er et arkitektonisk KRAV, ikke et tillegg. Mønsteret «LLM foreslår, solver/validator avgjør» er verifisert og implementerbart i dag via MAF Function Tools + en obligatorisk valideringsekzekutor. Forslag som ikke passerer deterministisk validering skal strukturelt blokkeres fra å nå eksperten.

5. Start single-agent per prosjekt, eskalér bevisst. Microsofts egen Cloud Adoption Framework råder til å prototype med én agent først; MAF-overview sier «if you can write a function to handle the task, do that instead». Multi-agent-debatt innføres kun der single-agent dokumentert svikter. Dette demper kostnads- og loop-risiko som adversarial-grenen dokumenterer (Uber brente hele 2026-AI-budsjettet på 4 mnd; én ukontrollert loop kostet $47 000 på 11 dager).

6. Språkvalg: Python for første bygg. Python er på stabil 1.8.0, har Functional @workflow-API, McpSkillsSource og intermediate_output_from; C# er fortsatt 1.0.0-rc2 (--prerelease kreves). (Merk: én kilde feilattribuerte HarnessAgent/A2AAgentSession til 1.8.0 — de kom i 1.7.0.)

2. MAF-plattformen i praksis — kapabiliteter og GAP

Verifiserte kapabiliteter vi kan stole på (high confidence, offisielle kilder):

Kapabilitet	Status	Kilde
Fem orkestreringsmønstre (Sequential, Concurrent, Handoff, Group Chat, Magentic)	Verifisert	learn.microsoft.com/agent-framework/workflows/orchestrations/
Graf-workflow (fan-out/fan-in, conditional/switch-case-edges, superstep-eksekvering, typesikkerhet)	Verifisert	.../workflows/edges
Checkpointing (InMemory/File/Cosmos), pending HITL re-emitteres ved resume	Verifisert	.../workflows/checkpoints
HITL: tool approval + RequestPort/request_info() + Magentic plan review	Verifisert (se korreksjon under)	.../workflows/human-in-the-loop
Magentic stoppkriterier: max_round_count, max_stall_count, max_reset_count + progress ledger	Verifisert	.../orchestrations/magentic
MCP-integrasjon native (stdio/HTTP/WebSocket); agent kan eksponeres som MCP-server	Verifisert	.../agents/tools/local-mcp-tools
Function Tools på alle store providere (inkl. Anthropic)	Verifisert	.../agents/tools/
Middleware-pipeline (intercept input/output per tool/run)	Verifisert	.../agents/middleware/
Agent-as-tool (AsAIFunction() / as_tool())	Verifisert (se korreksjon)	.../agents/tools/
ContextProvider/HistoryProvider; vector-store-abstraksjoner (Azure AI Search, Cosmos, Qdrant, Redis, Postgres m.fl.)	Verifisert	.../integrations/
OpenTelemetry-observabilitet (GenAI-konvensjoner)	Verifisert	.../agents/observability
Innebygd evaluering (LocalEvaluator, evaluate_workflow())	Verifisert	.../agents/evaluation
Durable Task-extension (kræsj-overlevende sesjoner, langvarig HITL)	Verifisert	learn.microsoft.com/azure/durable-task/...

GAP-er (verifisert):

• Ingen innebygd feedback-til-fremtidige-kjøringer. Må bygges på ContextProvider + ekstern verdict-store (Cosmos/Neo4j/vektorstore). (high)
• Ingen Claude-style «Stop hook» (rejiser respons + tving fortsettelse) i MAF-kjernen. Nærmeste er Magentic stall-detection eller eksplisitt while-loop i Functional API. (Merk: Azure SRE Agent — eget produkt — har en slik hook, men det er ikke MAF-SDK.)
• Ingen modell-generert orkestrering ved kjøretid (Claudes «dynamic workflows»). MAF-workflows er utviklerdefinert ved design-tid. (Verifisert)
• Ingen MAF-native provenance-standard. Må bygges på melding-source-stamping + egen logg.
• Functional @workflow og Magentic er eksperimentelle; Functional er Python-only.
• State-isolasjon er en footgun: gjenbruk av én WorkflowBuilder-instans på tvers av kjøringer korrumperer state — krever helper-method-mønster og IResettableExecutor. Kritisk i fan-out.

Korreksjoner fra verifiseringen (eksplisitt):

• Påstanden «limit group chat to three or fewer agents» finnes IKKE i offisiell MAF-dok — behandle som ikke-verifisert/sannsynlig hallusinasjon. Det finnes ingen tallfestet agent-grense i Group Chat-doken.
• «All HITL resume via SendResponseAsync» er feil: SendResponseAsync er C#-workflow-resume; Python bruker responses={request_id: ...} til workflow.run(...); standalone-agenter svarer via ny melding.
• Magentic er «based on / inspired by» Magentic-One, ikke en «direct port».

3. Støtter MAF «skills» / kodifiserte metoder?

Ja — direkte og uten gap. Dette var brukerens eksplisitte spørsmål, og svaret er positivt med høy konfidens.

MAF har et førsteklasses Agent Skills-konsept som følger den åpne agentskills.io-spesifikasjonen — samme spec som Claude Agent SDK. Struktur: skills/<navn>/SKILL.md (frontmatter med navn+beskrivelse, ~100 tokens, injiseres ved oppstart) + body (lastes ved trigger) + references/ + scripts/ + assets/. Innebygde providere finnes for både Python (SkillsProvider) og C# (AgentSkillsProvider). Kilde: https://learn.microsoft.com/agent-framework/agents/skills

Korreksjon (verifisert): Progressiv disclosure er fire stadier, ikke tre: (1) Advertise (~100 tokens), (2) Load (full SKILL.md-body), (3) Read resources (references/assets on demand), (4) Run scripts (on demand).

Konsekvens for designet: Hver brukerlevert analysemetode kodifiseres som én skill. SKILL.md beskriver når metoden gjelder; scripts/ holder de deterministiske validatorene (Python som regner tallene); references/ holder metodikk. Dette er den direkte implementasjonen av «kodifiserbar gjenbrukbar modul»-kravet. To uavklarte punkter (åpne spørsmål): (a) agentskills.io-spec'ens versjonerings-/governance-modell, og (b) riktig granularitet — én skill per metode vs. per delsteg. Sandboxing av brukerleverte scripts er IKKE løst av rammeverket: SubprocessScriptRunner er eksplisitt «demonstration only» — produksjonssandboxing er utviklerens ansvar.

4. Orkestreringsmønster for «agenter som debatterer mot et forslag» + stoppkriterier

Anbefalt primærmønster: Group Chat som maker-checker-loop. Offisiell dok beskriver Group Chat som ideell for «Iterative Refinement, Collaborative Problem-Solving, Multi-Perspective Analysis», og anbefaler eksplisitt maker-checker-loops (generator-verifier) som en Group Chat-variant. Én agent foreslår (maker), én validerer mot definerte kriterier (checker); loopen fortsetter til checker godkjenner eller hard grense nås. Kilde: https://learn.microsoft.com/agent-framework/workflows/orchestrations/group-chat

Hvorfor ikke Magentic som default: Magentic er kraftigere for åpne oppgaver (dynamisk manager + replanlegging), men flagget eksperimentell og utestet utenfor original-designet, og doken sier selv «if your scenario requires simpler coordination without complex planning, consider Group Chat instead». Reserver Magentic for genuint åpne delsteg, med harde rundetak satt.

Stoppkriterier — uttrykk dem på to nivåer (deterministisk, ikke LLM-styrt):

1. Hard loop-guard (rammeverk): Group Chat MaximumIterationCount (C#) eller termination_condition-lambda (Python, verifisert: lambda conversation: len(conversation) >= 4); eller for Magentic: max_round_count, max_stall_count (utløser replan), max_reset_count (hard stopp). Progress ledger sporer IsRequestSatisfied, IsInLoop, IsProgressBeingMade.
2. Domene-konvergens (eksekutor): en Checker-ekzekutor hvis output (APPROVED/REVISE) trigger en conditional edge til «done» vs «iterate». LLM-en skal aldri selv avslutte loopen.

Designkrav (fra adversarial-grenen): Magentic-parametrene defaulter til None (ubegrenset) i Python-API-et. Systemet må kreve eksplisitte tallverdier ved oppstart — manglende verdi skal feile ved start, ikke ved $10 000 i tokenforbruk. Legg til cost_budget_tokens og wall-clock-timeout som ekstra stoppkriterier. Alle stoppkriterie-brudd skal emittere et strukturert event (ikke stille stopp).

5. Hybrid AI + deterministisk verifisering — anbefalt mønster

Kjernemønster: «LLM-as-modeler → solver/validator disposes», med en mellomliggende typed representasjon (IR). LLM-en produserer aldri validerte tall eller solver-kode direkte; den produserer en strukturert, typet forslagsrepresentasjon (vår ekvivalent av ORPilots IR — solver-agnostisk JSON: sets, parameters, variables, objective, constraints), der hver tallstørrelse har deklarert kilde. En deterministisk modul kompilerer/validerer/eksekverer. Kilder: https://arxiv.org/html/2503.10009v1 (OR-LLM-Agent, 85 % løsningsnøyaktighet); https://towardsdatascience.com/the-secret-to-reproducible-and-portable-optimization-orpilots-intermediate-representation-ir

Konkret pipeline (per forslag):

1. Generér kandidat (Group Chat maker) → strukturert forslag.
2. Skjema-validér med Pydantic field-validators (ge/le, kryss-felt @model_validator for f.eks. savings <= total_cost) — billigste førstelinje, fanger out-of-range før downstream.
3. Solver/validér der relevant: registrer OR-Tools/PuLP/Z3 eller mcp-solver (MIT, MiniZinc/Z3/PySAT via MCP) som Function Tool / Local MCP Tool. Solver returnerer verifisert feasible løsning eller infeasibility-grunn. La aldri LLM gjette feasibility. Kilde: https://github.com/szeider/mcp-solver
4. Monte Carlo som obligatorisk steg for kostnadsanslag: wrap numpy-MC som Function Tool, returnér P10/P50/P90 — aldri punktanslag. Kilde: https://riskonnect.com/reporting-analytics/monte-carlo-analysis-a-powerful-tool-for-risk-management
5. Self-repair-loop: ved solver-feil/infeasibility, mat feilmelding tilbake til LLM (maks N forsøk, så eskalér), à la OR-LLM-Agent.

Plassering i MAF: valideringen legges som FunctionMiddleware (intercepts hver tool-call) og/eller en dedikert Verifier-agent kalt via agent-as-tool. Arkitektonisk regel: forslag som ikke passerer validatoren skal strukturelt blokkeres fra å nå eksperten. Stoppkriteriene for loopen skal være deterministiske (max_iterations, solver OPTIMAL, validator-pass, MC P50 under terskel) — sjekket ved superstep-grense.

6. Heterogen dataintegrasjon — anbefalt tilnærming + skisse til konfig

Anbefalt tilnærming: MCP som universelt data-source-abstraksjonslag + AIContextProvider som RAG-injeksjonspunkt. Hver datakilde (lokal mappe, SQL, REST, RAG-plattform) pakkes som en MCP-server; agenten auto-oppdager tools via tools/list. Dette gjør N×M-integrasjonsproblemet til N+M. Citation-aware RAG injiseres via TextSearchProvider (C#, SourceName/SourceLink) eller Azure AI Search-provider. Kilder: https://learn.microsoft.com/agent-framework/agents/tools/local-mcp-tools ; https://learn.microsoft.com/en-us/agent-framework/agents/rag

Konkrete valg:

• Lokale filer (vanligste prosjektdata): wrap filsystemet med en lokal MCP-server (modelcontextprotocol/server-filesystem finnes), pluss en ingestion-pipeline (recursive chunking ~400–512 tokens, 10–20 % overlap som praktisk default; semantisk/seksjonsbevisst chunking ved behov) til lokal vektorstore (SQLite/Chroma). RAG-grensesnittet blir uniformt uavhengig av lokal/remote.
• Enterprise-korpus i Azure: Azure AI Search agentic retrieval (GA 2026-04-01) — query-dekomponering, semantisk reranking, per-chunk source-referanser + activity log.
• Per-prosjekt data-access som custom AIContextProvider: leser prosjektets data-source-config, henter chunks fra rett backend, injiserer med kilde-metadata (source-stamping via AgentRequestMessageSourceType for audit).

Skisse til generisk data-source-konfig (gjenbruk MCP Claude-Desktop-formatet, utvid med RAG-felt; valider med JSON Schema, fail fast):

project:
  id: "prosjekt-A"
  data_sources:
    - type: local_folder        # diskriminator
      path: "./docs"
      glob: "**/*.{pdf,xlsx,md}"
      chunking: { size: 512, overlap: 64, embedding_model: "..." }
    - type: mcp_server
      command: "uvx"
      args: ["my-connector"]
      env: { API_KEY: "${SECRET}" }
    - type: azure_ai_search
      endpoint: "https://..."
      index: "prosjekt-A-idx"
      semantic_config: "default"
    - type: rag_api
      url: "https://..."
      auth_type: "oauth"
      query_template: "..."

Diskriminert union på type; type-spesifikk connection-blokk + valgfri ingestion-seksjon. Åpent: eierskap til dette skjemaet (definere selv vs. vente på MAF-native format), og inkrementell re-ingestion av lokale mapper (ikke støttet out-of-the-box).

7. HITL læringssløyfe — anbefaling (suksesskriteriet)

Anbefaling: «experience distillation uten fine-tuning» (ExpeL/ERL-mønster) over en custom VerdictStore-ContextProvider. Dette lærer av ekspertdommer uten full re-trening og er state-of-the-art-validert. Kilder: https://arxiv.org/html/2308.10144v2 (ExpeL, AAAI 2024); https://www.langchain.com/resources/llm-as-a-judge (data-flywheel).

Mekanikk:

1. To-lags HITL i flyten: (a) pre-eksekusjon plan-godkjenning via MagenticPlanReviewRequest (eksperten godkjenner/reviderer analyseplanen før dyre analyser kjøres); (b) post-eksekusjon forslagsgodkjenning via request_info()-gate (suspenderer hele workflow ved definert checkpoint) eller tool approval på emit_savings_proposal. Eksperten bryter aldri flyten — den gater progresjonen.
2. Persistér hver dom (approve/reject/revise + begrunnelse + forslags-embedding + prosjekttype + domene) til ekstern store (Cosmos med vektorindeks, eller Neo4j memory provider — sistnevnte Python-only, «preference learning»).
3. Distillér + retrieve: LLM ekstraherer NL-heuristikker fra (dom, forslag)-par; ved start av hver per-prosjekt-kjøring hentes topp-5 mest like historiske dommer og injiseres som few-shot via VerdictStore-ContextProvider. Ingen parameter-oppdatering.
4. Kalibrér LLM-as-judge mot menneskedommer (LangSmith-flywheel): menneskelige korreksjoner forbedrer evaluatoren, ikke modellvektene. Spotify-produksjon (>1500 PR-er) validerte hybrid deterministisk + LLM-judge: judge fanget ~25 % problematiske, hvorav ~50 % korrigerbare. Kilde: https://www.zenml.io/llmops-database/...

Persistens: all HITL-state til CosmosCheckpointStorage for fler-dagers review-sykluser uten compute-kost (pending requests re-emitteres ved resume). Fine-tuning-trigger-policy: ikke fine-tune før (a) ≥~1000 stabile merkede dommer, (b) retrieval+few-shot har platået i A/B-test, (c) shadow-mode-datasett er akkumulert. Kilde: https://www.truefoundry.com/blog/prompting-fine-tuning-or-rag

Åpne risikoer (verifisert/flagget): Foundry-memory er preview (ikke primær verdict-store for produksjon, sjekk GDPR/dataresidens for norsk offentlig sektor); konfliktende ekspertdommer trenger en konfliktløsningsregel før de entrer storen; små-N-feedback kan forsterke ekspertbias.

8. Claude Agent SDK-mønstre å porte → MAF

Claude-mønster	MAF-ekvivalent	Status / korreksjon
Skills (folder, progressiv disclosure)	Agent Skills (agentskills.io)	Direkte. Men fire stadier, ikke tre
Subagents (Task/Agent)	Agent-as-tool (AsAIFunction()/as_tool()) eller Concurrent	Mønster OK. Korreksjon: AIFunctionFactory.Create() er for vanlige funksjoner, IKKE agent-registrering
Hooks (PreToolUse/PostToolUse)	Middleware (.Use()) + ContextProvider (InvokingAsync/InvokedAsync)	Verifisert. Ingen filsystem-hooks i MAF
Stop hook (tving fortsettelse)	Gap — Magentic stall-detection / while-loop i Functional API	Delvis gap. «BUILD 2026 HarnessAgent»-attribusjonen er delvis uverifisert
Dynamic workflows (modell skriver orkestrering)	Graf-WorkflowBuilder (fan-out/fan-in) + Durable Task	Fixed-topologi dekket; runtime-modellgenerert orkestrering: ingen ekvivalent
Adversarial verify	Group Chat / sequential handoff	Achievable, må kodes eksplisitt
MCP-integrasjon	MCPStdioTool/MCPStreamableHTTPTool/MCPWebsocketTool + as_mcp_server()	Verifisert
Context compaction	CompactionProvider (SlidingWindow/Truncation/summarization)	Verifisert
Agent harness loop	Agent Harness (ShellExecutor, FileMemoryStore, ToolApprovalAgent)	Verifisert (BUILD 2026, 3. juni); HITL-komponenten heter ToolApprovalAgent
Magentic-style manager	Magentic (MagenticBuilder, StandardMagenticManager)	Verifisert. «based on», ikke «direct port». Eksperimentell
A2A interop	A2AAgent / A2AExecutor	Verifisert; pakke pre-release. Hver A2A-kall = HTTP-latency + distribuert feilhåndtering
Session-management	AgentSession + ContextProvider	Verifisert

9. Prior art — gjenbruk vs. unngå

Gjenbruk:

• FinOps-mønsteret (Azure Cost Management + Copilot, Anodot, CloudZero): modnest hybrid AI + deterministisk anomalideteksjon; MCP mot billing-API-er. Gjenbruk hybrid-separasjonen. (Merk: tunet for strukturert, uniform billing-data — ikke direkte overførbart til heterogen prosjektdata uten redesign.) Kilde: https://wjaets.com/sites/default/files/fulltext_pdf/WJAETS-2025-0218.pdf
• Multi-agent debatt-forskning (Du et al. 2024 ICML; Yin 2025 bygg/kost): trust-vektet konsensus med terskel θ∈[0.6, 0.7], trust-vekter som evolverer på historisk pålitelighet. Gjenbruk som aggregeringsmekanisme for checker-konvergens. Kilde: https://www.sciexplor.com/jbde/articles/jbde.2025.0018
• OR-LLM-Agent / ORPilot IR / mcp-solver / ProofOfThought (Z3): gjenbruk LLM→IR→deterministisk-kompilering direkte.
• ExpeL/ERL + LangSmith-flywheel + Spotify hybrid-verify: gjenbruk for læringssløyfen.

Unngå:

• Lukkede PPM/PMO-verktøy (Epicflow, Planview, Celoxis): ingen agent-API, ingen brukerleverte metoder, behandler porteføljen som ett system. Unngå arkitektur-modellen; vårt premiss er uavhengige prosjekter med brukerleverte metoder.
• Akademisk RL-portefølje-optimering (MDPI 2025): «tacit knowledge»-state-vektor er ikke praktisk operasjonaliserbar i software i dag. Unngå for MVP.
• Tunge abstraksjonslag (LangChain-stil): hvert ekstra «pluggbart modul-lag» obskurerer debugging. Hold abstraksjonene tynne.

10. Feilmoduser & hva vi BEVISST IKKE skal bygge (anti-scope)

Dokumenterte feilmoduser (baseline å slå): 88 % av enterprise-AI-agenter når aldri produksjon; Gartner: >40 % av agentiske prosjekter kanselleres innen utgangen av 2027 (årsaker: infrastruktur/observabilitet, governance, uklar ROI — ikke modellkvalitet). Token-blow-up er strukturelt undervurdert. Multi-agent kontekstvinduer vokser multiplikativt per handoff. Hallusinasjon på finans/numerikk er strukturelt uunngåelig (9–88 % avhengig av domene). Kilde: https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

BEVISST IKKE bygge (anti-scope):

• Ikke en generisk «analysemodul-markedsplass» der brukere komponerer fritt uten å oppgi termineringskontrakt, feedback-skjema og data-access på forhånd. Onboarding skal være et konfigurasjons-intervju som tvinger frem disse FØR noen agent kjører.
• Ikke Magentic som default multi-agent-mønster (eksperimentell, ingen hard terminering by default).
• Ikke A2A som default for kryss-prosjekt-orkestrering med mindre prosjektene trenger sikkerhets-/compliance-grense (HTTP-latency, state-tap ved restart). Bruk in-process agent-as-tool først.
• Ikke budsjett-circuit-breakers som valgfri brukerkonfig — rammeverket skal nekte å starte uten eksplisitte token/kost-tak.
• Ikke la deterministisk validering være en anbefalt plugin — den skal være arkitektonisk obligatorisk og blokkerende.
• Ikke et generisk «plug in your HITL»-hook — feedback-skjemaet er den mest domenespesifikke delen og MÅ være brukerlevert og strukturert.
• Ikke fine-tuning før retrieval-taket er nådd.

11. Verifiseringslogg — nøkkelpåstander med verdikt

#	Påstand	Verdikt
1	Fem orkestreringsmønstre; Group Chat/Magentic for debatt; maker-checker-loops anbefalt	Verifisert
2	Group Chat-mekanikk (delt historikk, ShouldTerminateAsync/MaximumIterationCount, Python-lambda)	Verifisert — MEN «limit to ≤3 agents» er IKKE verifisert / sannsynlig hallusinasjon
3	Magentic eksperimentell/utestet utenfor Magentic-One	Verifisert
4	Magentic stoppkriterier (max_round/stall/reset_count) + progress ledger	Verifisert
5	HITL-mekanikk (tool approval, RequestPort, plan review)	Delvis — «all resume via SendResponseAsync» er feil (C#-only; Python bruker responses={...})
6	MAF har INGEN innebygd feedback-persistering til fremtidige kjøringer	Verifisert
7	Python 1.8.0 stabil / C# rc2; Python foran på Functional API m.m.	Delvis — HarnessAgent/A2AAgentSession kom i 1.7.0, ikke 1.8.0 (feilattribusjon)
8	Skills: identisk progressiv disclosure med Claude	Delvis — er fire stadier, ikke tre; «GitHub Copilot Cowork» som produktnavn uverifisert (heter «GitHub Copilot»)
9	Subagents → agent-as-tool	Delvis — AIFunctionFactory.Create()-detaljen er feil (bruk AsAIFunction()/as_tool())
10	Hooks → middleware + context providers	Verifisert (nyanse: ApprovalRequiredAIFunction er kooperativ markør, ikke hard enforcement)
11	Stop hook → ingen direkte MAF-ekvivalent	Delvis — gapet er reelt; «BUILD 2026»-kilde-URL og -attribusjon uverifisert; SRE Agent har slik hook (ikke MAF-SDK)
12	Dynamic workflows → fan-out/fan-in + Durable Task; ingen runtime-modellgenerering	Verifisert
13	Agent Harness (ShellExecutor, FileMemoryStore, ToolApprovalAgent)	Verifisert
14	Magentic = MAF-port av Magentic-One	Verifisert med korreksjon — «based on / inspired by», IKKE «direct port»

Uverifiserte påstander brukt i kontekst som bør kildes før de går i arkitekturdokument: «kun ~16 % av enterprise-deployeringer er ekte agenter» (ikke funnet i primærkilde; nær-data finnes: Gartner <5 % apps med innebygde agenter i 2025). Praktiker-tall (chunking-nøyaktighet, hallusinasjons-prosenter, FinOps-besparelser) er medium confidence (ikke Microsoft-primærkilder).

12. Åpne spørsmål til bruker

1. Språkstack: Python-først (anbefalt) godtatt, eller kreves .NET (f.eks. enterprise-interop)? Påvirker tilgang til Functional API, Neo4j-memory (Python-only) og intermediate_output_from.
2. Deploy-mål: Selvhostet/open-source-only, eller er Azure (Cosmos, AI Search, Durable Task, Foundry) tilgjengelig? Mye av produksjons-persistens og agentic retrieval er Azure-sentrisk. Påvirker også om YAML-deklarative workflows kan kjøres uten Foundry.
3. Review-latensbudsjett: Svarer eksperten innen minutter (synkron HITL) eller timer/dager (checkpoint-basert async + varsling via e-post/Teams/webhook — som MAF ikke gir nativt)?
4. Antall/variabilitet av prosjekter: Kjent og fast ved design-tid (fast Group Chat/Concurrent-topologi holder), eller ukjent/sterkt varierende (kan kreve dynamisk orkestrering — et reelt gap)?
5. Datasensitivitet: Norsk offentlig-sektor-data — kreves minimum-eksponering (lokal-only stdio-MCP, lokale embeddings)? Påvirker hele dataintegrasjonslaget.
6. Skjema-eierskap: Skal vi definere og eie data-source- og feedback-skjemaet selv nå, eller vente på et MAF-native prosjekt-config-format?
7. Feedback-skjema: Hvem (rolle/antall eksperter per domene) leverer dommer, og finnes en omforent rejection-taksonomi (wrong_assumption, overestimated_savings, constraint_violation, out_of_scope)?

13. Anbefalt høynivå-arkitektur + neste steg

Arkitektur (ett avsnitt): En MAF-orkestrator fan-out-er per uavhengig prosjekt via ConcurrentBuilder (eller Durable Task fan-out), med streng state-isolasjon (fersk WorkflowBuilder-instans per kjøring via helper-method). Hvert prosjekt kjører en per-prosjekt-workflow som starter single-agent-baseline og eskalerer til en Group Chat maker-checker-debatt kun ved dokumentert behov. Brukerleverte analysemetoder lastes som Agent Skills (SKILL.md + deterministiske scripts/). Data nås via MCP-servere og injiseres som citation-aware RAG via en custom AIContextProvider. AI genererer kandidater som en typet IR; en obligatorisk, blokkerende deterministisk valideringsekzekutor (Pydantic + OR-Tools/mcp-solver/Z3 + Monte Carlo P10/P50/P90) avgjør tallene. Validerte forslag gates av en to-lags HITL (plan review + forslagsgodkjenning); ekspertdommer persisteres til en ekstern VerdictStore og hentes som few-shot ved neste kjøring (ExpeL-læring uten fine-tuning). Harde, deterministiske stoppkriterier og budsjett-circuit-breakers er obligatoriske ved oppstart; alt instrumenteres med OpenTelemetry og checkpointing (Cosmos) for fler-dagers HITL.

Komponenter:

• Orchestrator: ConcurrentBuilder fan-out per prosjekt + FanIn-aggregering; state-isolasjon enforced.
• Per-prosjekt-workflow: single-agent-baseline → (ved behov) Group Chat maker-checker; deterministisk termineringskontrakt.
• Skill-loader: Agent Skills-provider; brukerleverte SKILL.md + sandboxet script-runner (IKKE SubprocessScriptRunner i prod).
• Data-access-lag: MCP-servere per kilde + custom AIContextProvider (citation-aware) + JSON-Schema-validert data-source-config.
• Hybrid-validator: Pydantic-skjema → solver/Z3/MC som Function Tools → blokkerende valideringsekzekutor + self-repair-loop.
• HITL-gate: plan review + request_info()/tool approval; Cosmos-checkpointing; ekstern varsling.
• VerdictStore + ContextProvider: vektor-embeddede dommer; topp-K-retrieval; LLM-as-judge kalibrert mot menneskedommer.
• Guardrails: budsjett-circuit-breaker, stoppkriterie-event-emittering, OpenTelemetry-tracing som deploy-gate, provenance-logg (source-stamping).

Anbefalt NESTE steg (i rekkefølge):

1. Prototype-test (ukritisk for hele designet): bygg en 3-agent Group Chat maker-checker (proposer, critic, validator) i Python på ett syntetisk prosjekt; mål konvergensrate, stall-frekvens og tokenforbruk mot single-agent-baseline. Dette validerer kjernevalget Group Chat-over-Magentic empirisk.
2. Kode-test av footguns: verifiser (a) Magentic-terminering når alle limits er None, og (b) state-isolasjon i ConcurrentBuilder fan-out fra delt builder.
3. Spike VerdictStore-ContextProvider med ExpeL-retrieval på 10–20 syntetiske dommer.
4. Definer data-source- og feedback-skjema (JSON Schema) + onboarding-intervjuet som tvinger frem termineringskontrakt, feedback-skjema og data-access.
5. Avklar de syv åpne spørsmålene (særlig språkstack, deploy-mål og datasensitivitet) før arkitekturen låses.

---

14. Modell-backend: Foundry-binding og per-agent modellvalg

(Lagt til etter syntesen, fra egen grunngitt sjekk mot offisiell MAF-dok — dekker brukerkravet om Microsoft Foundry + modellvalg, som ikke var en egen research-gren.)

Kjernefunn (high confidence): En MAF-agent er ikke en modell — den bindes til en chat-client, og modellen er en parameter på klienten. Det gjør modellvalg førsteklasses og per-agent.

• Python: FoundryChatClient(project_endpoint=..., model="gpt-4o-mini", credential=...) kobler mot en deployert modell i et Foundry-prosjekt (Responses-endpoint). Støtter tools, structured outputs, streaming. Kilde: https://learn.microsoft.com/agent-framework/agents/providers/microsoft-foundry
• To Foundry-mønstre (reelt arkitekturvalg):
  • Responses Agent (ChatClientAgent via AsAIAgent(...)): appen eier modell + instruksjoner + tools på runtime; ingen server-side agent-ressurs. Brukt i de fleste eksempler — fleksibelt.
  • Foundry Agent (FoundryAgent, versjonert): server-styrt; agentdefinisjoner opprettes/versjoneres i Foundry-portalen eller via AgentAdministrationClient. For streng, versjonert governance.
• Modellkatalog: Modeller deployes/velges fra Foundry-modellkatalogen (ai.azure.com/catalog/models): Azure-OpenAI (GPT-4.x/5.x), partner/community, Hugging Face managed compute, og BYOM-endpoints. azd ai agent init spør eksplisitt om hvilken modell.
• Provider-bredde: MAF-oversikten lister Foundry, Azure OpenAI, OpenAI, Ollama og Anthropic. Forbehold (ikke fullt verifisert): AutoGen-migreringstabellen merker Anthropic/Ollama som «🚧 Planned» — Foundry/Azure OpenAI/OpenAI er solide; Anthropic/Ollama-direkte må sjekkes mot gjeldende versjon før det loves. (Function tools fungerer på Anthropic per §11.)

Konsekvens for designet: Siden modellen settes per chat-client, kan hver agent i samarbeidet bruke sin egen modell — billig modell til ruting/henting, sterk modell til den tunge resonneringen, evt. en egen til den deterministiske validatoren. Dette blir en eksplisitt, brukerkonfigurerbar del av onboardingen: en «modell-map» (rolle → Foundry-deployment) ved siden av data-source-konfigen (§6). Det gjør kost/kvalitet til en knapp brukeren kan vri på uten kodeendring, og speiler prinsippet om å matche modell til oppgavekompleksitet.

Åpent (kobler til §12): Responses Agent vs Foundry Agent (governance-behov), og om deploy-målet overhodet har Foundry tilgjengelig (selvhostet open-source vs Azure).

---

15. Implementeringsregister — alt vi må BRUKE, BYGGE, VOKTE, GJENBRUKE eller UNNGÅ

Sporbar sjekkliste. Status: USE = MAF-konstrukt vi bygger på · BUILD = gap vi må implementere selv · GUARD = footgun/risiko å sikre · REUSE = ekstern lib/spec · AVOID = anti-scope · FIX = korreksjon fra verifisering (ikke kod feil variant). Verifisert = bekreftet mot offisiell primærkilde i §11.

15.1 MAF-kapabiliteter vi SKAL BRUKE (USE — verifisert)

ID	Kapabilitet	MAF-konstrukt / API	Kilde	Verifisert
U1	Orkestrator fan-out per prosjekt	ConcurrentBuilder / AgentWorkflowBuilder.BuildConcurrent() + FanIn-aggregering	…/workflows/orchestrations/concurrent	✅
U2	Per-prosjekt graf-workflow	WorkflowBuilder (fan-out/fan-in, conditional/switch-case-edges, superstep, typesikkerhet)	…/workflows/edges	✅
U3	Debatt-mønster (maker-checker)	GroupChatBuilder; C# RoundRobinGroupChatManager.ShouldTerminateAsync + MaximumIterationCount; Python termination_condition-lambda	…/orchestrations/group-chat	✅
U4	Åpne delsteg (kun ved behov)	Magentic: MagenticBuilder/StandardMagenticManager; max_round_count/max_stall_count/max_reset_count; progress ledger	…/orchestrations/magentic	✅
U5	Brukerleverte metoder	Agent Skills: skills/<navn>/SKILL.md + scripts/ + references/ + assets/; SkillsProvider (Py) / AgentSkillsProvider (C#); McpSkillsSource (Py 1.8.0)	…/agents/skills	✅ (4 stadier, se F1)
U6	Datatilgang	MCP-tools: MCPStdioTool / MCPStreamableHTTPTool / MCPWebsocketTool; eksponer agent som server via as_mcp_server()	…/agents/tools/local-mcp-tools	✅
U7	Solver/validator/Monte Carlo som verktøy	Function Tools (alle store providere, inkl. Anthropic)	…/agents/tools/	✅
U8	Intercept av tool-calls (blokkerende validator)	Middleware-pipeline .Use(); FunctionMiddleware (InvokingAsync/InvokedAsync)	…/agents/agent-pipeline	✅
U9	Læringssløyfe-injeksjon	Custom ContextProvider / HistoryProvider	…/agents/conversations/context-providers	✅
U10	Vektorlagre	Azure AI Search, Cosmos, Qdrant, Redis, Postgres (innebygde abstraksjoner)	…/integrations/	✅
U11	Citation-aware RAG-injeksjon	Custom AIContextProvider; TextSearchProvider (C#, SourceName/SourceLink); Azure AI Search agentic retrieval (GA 2026-04-01)	…/agents/rag	✅
U12	Persistens / kræsj-overlevelse	Checkpointing (InMemory/File/Cosmos), pending HITL re-emitteres ved resume; Durable Task-extension for langvarig HITL	…/workflows/checkpoints	✅
U13	HITL-gates	Tool approval (@tool(approval_mode='always_require') Py / ApprovalRequiredAIFunction C#); RequestPort/request_info(); MagenticPlanReviewRequest/.approve()/.revise()	…/workflows/human-in-the-loop	✅ (se F2)
U14	Observabilitet (deploy-gate)	OpenTelemetry (GenAI-konvensjoner)	…/agents/observability	✅
U15	Evaluering	LocalEvaluator, evaluate_workflow(), Foundry Adaptive Evals	…/agents/evaluation	✅
U16	Kontekst-kompaktering	CompactionProvider (SlidingWindow/Truncation/summarization)	…/integrations/	✅
U17	Agent-som-verktøy	AsAIFunction() (C#) / as_tool() (Py) — IKKE AIFunctionFactory.Create()	…/agents/tools/	✅ (se F3)
U18	Modell-backend + per-agent modellvalg	FoundryChatClient(project_endpoint, model, credential); Responses Agent vs Foundry Agent	…/agents/providers/microsoft-foundry	✅ (§14)
U19	Harness-mønstre (bakgrunn/loop)	Agent Harness: ShellExecutor, FileMemoryStore, ToolApprovalAgent (Py 1.7.0)	python-2026-significant-changes	✅

15.2 Mønstre vi MÅ BYGGE SELV (BUILD — gap, ikke i rammeverket)

ID	Hva	Hvorfor (gap)	Skisse
B1	Blokkerende hybrid-validator	Deterministisk verdikontroll er ikke en MAF-primitiv	LLM → typet IR (Pydantic) → skjema-validering (field + kryss-felt @model_validator) → solver (OR-Tools/PuLP/Z3 / mcp-solver) → Monte Carlo P10/P50/P90 → self-repair (maks N forsøk). Forslag som feiler blokkeres strukturelt fra eksperten.
B2	VerdictStore + ExpeL-læringssløyfe	MAF har INGEN feedback-til-fremtidige-kjøringer (verifisert)	Persistér (forslag, dom, begrunnelse, embedding, prosjekttype, domene) → topp-K-retrieval via custom ContextProvider → few-shot-injeksjon. LLM-as-judge kalibrert mot menneskedommer. Ingen fine-tuning før ≥~1000 stabile dommer + retrieval-platå.
B3	To-lags HITL	Sammenstilling av plan-review + forslagsgate er vår logikk	(a) pre-eksekusjon plan-godkjenning; (b) post-eksekusjon forslagsgate (request_info() / tool approval på emit_savings_proposal).
B4	Termineringskontrakt + budsjett-circuit-breakers	Magentic-limits defaulter til None (ubegrenset); ingen kost-tak by default	Krev eksplisitte verdier ved oppstart (fail-fast hvis mangler): max_iterations, max_stall, cost_budget_tokens, wall-clock-timeout. Alle brudd → strukturert event (aldri stille stopp).
B5	Generisk data-source-konfig	Ingen MAF-native prosjekt-config	JSON Schema, diskriminert union på type (local_folder/mcp_server/azure_ai_search/rag_api) + ingestion-blokk (chunking ~400–512 tokens, 10–20 % overlap). Valider, fail fast.
B6	Provenance / sporbarhet	Ingen MAF-native provenance-standard	Melding-source-stamping (AgentRequestMessageSourceType) + egen logg; hvert forslag sporer til kildedata.
B7	State-isolasjon i fan-out	Delt WorkflowBuilder korrumperer state	Fersk builder-instans per kjøring via helper-method + IResettableExecutor.
B8	Sandboxing av brukerleverte skill-scripts	SubprocessScriptRunner er «demonstration only»	Egen produksjons-sandbox (container/jail) for scripts/ i brukerleverte skills.
B9	Onboarding-intervju	Tvinger frem kontrakter FØR noen agent kjører	Samle: termineringskontrakt, feedback-skjema, data-access, modell-map.
B10	Feedback-skjema + rejection-taksonomi + konfliktregel	Mest domenespesifikke delen; må være brukerlevert og strukturert	Taksonomi (wrong_assumption/overestimated_savings/constraint_violation/out_of_scope) + regel for konfliktende ekspertdommer før de entrer storen.
B11	Ekstern varsling for async HITL	MAF gir ikke varsling nativt	E-post/Teams/webhook ved pending review (fler-dagers sykluser).
B12	Modell-map (rolle → Foundry-deployment)	Per-agent modellvalg som brukerknapp	Konfig ved siden av data-source-config; billig modell til ruting, sterk til resonnering.

15.3 Footguns / risikoer å VOKTE (GUARD — verifisert)

ID	Risiko	Tiltak
G1	Magentic-limits = None (ubegrenset)	B4: krev eksplisitte verdier, fail-fast
G2	Delt WorkflowBuilder → state-korrupsjon i fan-out	B7: fersk instans + IResettableExecutor
G3	SubprocessScriptRunner = demo-only	B8: ekte sandbox
G4	ApprovalRequiredAIFunction er kooperativ markør, ikke hard enforcement	Håndhev godkjenning i invoker-koden, ikke stol på markøren
G5	Foundry-memory er Preview	Ikke primær verdict-store i prod; sjekk GDPR/dataresidens for norsk offentlig sektor
G6	Små-N-feedback forsterker ekspertbias	Konfliktregel (B10) + terskel før heuristikk-distillering
G7	Token-blow-up vokser multiplikativt per handoff	Single-agent-baseline først; budsjett-breakers (B4); kontekst-kompaktering (U16)
G8	Functional @workflow og Magentic er eksperimentelle; Functional er Python-only	Ikke bygg kjerneflyt på eksperimentelle API uten fallback

15.4 Eksterne biblioteker / spec å GJENBRUKE (REUSE)

ID	Ressurs	Bruk	Kilde
R1	mcp-solver (MIT)	MiniZinc/Z3/PySAT som MCP-verktøy — solver-i-loopen	github.com/szeider/mcp-solver
R2	OR-Tools / PuLP / Z3	Optimering/feasibility som Function Tool	—
R3	OR-LLM-Agent + ORPilot IR	LLM→typet IR→deterministisk kompilering (85 % løsningsnøyaktighet)	arxiv.org/html/2503.10009v1
R4	ExpeL (AAAI 2024)	Erfarings-distillering uten fine-tuning	arxiv.org/html/2308.10144v2
R5	agentskills.io-spec	Kryss-vendor skill-format (samme som Claude Code)	learn.microsoft.com/agent-framework/agents/skills
R6	modelcontextprotocol/server-filesystem	Lokale filer som MCP-kilde	—
R7	LangSmith LLM-as-judge-flywheel	Kalibrere judge mot menneskedommer	langchain.com/resources/llm-as-a-judge
R8	Multi-agent debatt-konsensus (Du et al. 2024; Yin 2025)	Trust-vektet konsensus (θ≈0.6–0.7) for checker-konvergens	sciexplor.com/jbde/articles/jbde.2025.0018

15.5 Anti-scope — BEVISST IKKE bygge (AVOID)

ID	Ikke bygg	Hvorfor
A1	Fri «analysemodul-markedsplass» uten påkrevd kontrakt	Onboarding må tvinge termineringskontrakt + feedback-skjema + data-access FØR kjøring
A2	Magentic som default multi-agent-mønster	Eksperimentell; ingen hard terminering by default
A3	A2A som default for kryss-prosjekt	HTTP-latency + state-tap; bruk in-process agent-as-tool først (kun A2A ved sikkerhets-/compliance-grense)
A4	Budsjett-breakers som valgfri konfig	Rammeverket skal NEKTE å starte uten token/kost-tak
A5	Deterministisk validering som «anbefalt plugin»	Skal være arkitektonisk obligatorisk og blokkerende
A6	Generisk «plug in your HITL»-hook	Feedback-skjemaet er domenespesifikt og MÅ være brukerlevert
A7	Fine-tuning før retrieval-taket er nådd	Premaur kostnad; ExpeL-retrieval først
A8	Lukket-PPM-arkitektur (Epicflow/Planview-modell)	Behandler porteføljen som ett system; vårt premiss er uavhengige prosjekter

15.6 Korreksjoner fra verifisering — ikke implementér feil variant (FIX)

ID	Feil påstand (forkast)	Riktig (implementér dette)
F1	Skills = 3 stadier progressiv disclosure	4 stadier: Advertise → Load → Read resources → Run scripts
F2	All HITL-resume via SendResponseAsync	C# workflow: SendResponseAsync; Python: responses={request_id: ...} til workflow.run(...); standalone-agent: ny melding
F3	Agent-som-verktøy via AIFunctionFactory.Create()	AsAIFunction() (C#) / as_tool() (Py); AIFunctionFactory.Create() er for vanlige funksjoner
F4	«Begrens Group Chat til ≤3 agenter» (offisiell warning)	Finnes ikke i dok — sannsynlig hallusinasjon; ingen tallfestet agent-grense
F5	HarnessAgent/A2AAgentSession kom i Python 1.8.0	Kom i 1.7.0; 1.8.0 = McpSkillsSource, Foundry Adaptive Evals m.m.
F6	Magentic = «direct port» av Magentic-One	«based on / inspired by»; eksperimentell, utestet utenfor original-design
F7	«BUILD 2026 HarnessAgent»-devblog som kilde	Kilde-URL ikke verifiserbar; Azure SRE Agent (eget produkt, ikke MAF-SDK) har Stop-hook-ekvivalent
F8	«~16 % av enterprise-deployeringer er ekte agenter»	Ikke funnet i primærkilde (medium/lav confidence); nær-tall: Gartner <5 % apps med innebygde agenter 2025