ms-ai-architect/skills/ms-ai-engineering/references/agent-orchestration/foundry-workflows-visual-orchestration.md

Foundry Workflows — Visuell Multi-Agent Orkestrering

Last updated: 2026-06-19 | Verified: MCP 2026-06-19 Status: Public Preview (announced MS Ignite november 2025) Category: Agent Orchestration & Automation

---

Introduksjon

Foundry Workflows er den visuelle orkestreringsdesigneren i Microsoft Foundry (Azure AI Foundry) for å bygge, teste og deploye multi-agent-prosesser uten å skrive orkestreringslogikk for hånd. Annonsert i Public Preview på Microsoft Ignite november 2025, er Workflows bygget på toppen av Microsoft Agent Framework og tilbyr en drag-and-drop-kanvas kombinert med YAML-definisjon for team som vil ha en visuell designopplevelse med pro-code-flukt.

Den kritiske innsikten er at Foundry Workflows løser et annet problem enn enkelt-agenter: der én agent håndterer ett fokusert problem, koordinerer en Workflow flere spesialiserte agenter, branching-logikk, datatransformasjoner og menneskelige godkjenningstrinn i en repeterbar, versjonert og observerbar prosess. Dette er produksjonsnivå-automatisering — ikke prototyping.

Workflows er ett av tre agenttyper i Foundry:

• Prompt-based: Enkelt-agent med instruksjoner og verktøy
• Workflow: Sekvenser og orkestrering av agenter (denne filen)
• Hosted (preview): Containeriserte agenter med egendefinert kode

---

Visuell Designer

Drag-and-Drop Kanvas

Foundry Workflows tilbyr en nettleserbasert visuell designer tilgjengelig direkte i Foundry Portal:

Funksjonalitet	Beskrivelse
Drag-and-drop	Legg til og flytt noder på en kanvas uten kode
Kanter (edges)	Koble noder med piler for å definere dataflyt og sekvens
Livevisualisering	Noder lyser opp i sanntid under kjøring — se hvilken agent som er aktiv nå
Tospannsvisning	Bytt mellom visuell kanvas og YAML-redigering — endringer synkroniseres automatisk
Notater	Legg til forklarende tekst direkte på kanvaset for dokumentasjon og kontekst
Maler	Start fra Sequential, Human-in-the-loop, eller Group chat-mal
Versionslogg	Klikk på versjonsdropdown for å navigere mellom lagrede versjoner

Toveis YAML/Visuell-synkronisering

Et sentralt designprinsipp er at visuell og YAML-representasjon alltid er i sync:

# Eksempel: Sequential workflow (YAML-visning)
kind: Sequential
name: document-review-workflow
agents:
  - name: extractor-agent
    agentId: agent-extractor-001
    outputVariable: Local.extractedData
  - name: reviewer-agent
    agentId: agent-reviewer-002
    input: =Local.extractedData
  - name: approver-agent
    agentId: agent-approver-003
    input: =Local.reviewResult

Endringer i YAML-visning reflekteres umiddelbart i kanvaset — og vice versa. Dette gjør det mulig for forretningsbrukere å jobbe visuelt mens utviklere jobber i YAML eller VS Code.

---

Node-typer

Noder er byggesteinene i en Workflow. Hver node utfører én spesifikk handling.

Oversikt over node-typer

Node-type	Kategori	Formål
Invoke agent	Agent	Kall en Foundry-agent og bruk output videre
If/else	Logic	Branching basert på betingelse (Power Fx)
Go to	Logic	Hopp til en annen node (loop-kontroll)
For each	Logic	Iterer over en liste eller tabell
Set variable	Data transformation	Tilordne verdi til lokal variabel
Parse value	Data transformation	Tolk/transformer data (f.eks. JSON-parsing)
Send message	Basic chat	Send tekst til brukeren
Ask a question	Basic chat / Human-in-the-loop	Spør brukeren og vent på svar

Detaljer: Agent-noden

Agentnode lar deg kalle enhver eksisterende Foundry-agent fra prosjektet ditt, eller opprette en ny agent direkte fra kanvaset:

# Agent-node med strukturert JSON-output
- kind: InvokeAgent
  id: classify_document
  agentId: agent-classifier-001
  input: =Local.uploadedDocument
  outputVariable: Local.classificationResult
  responseFormat:
    type: json_schema
    schema:
      type: object
      properties:
        category: { type: string }
        confidence: { type: number }
        requiresHumanReview: { type: boolean }
      required: [category, confidence, requiresHumanReview]

Detaljer: Human-in-the-loop-noden

Human-in-the-loop er et førsteklasses konsept i Foundry Workflows. Workflowen pauser ved noden og venter på menneskelig input eller godkjenning før den fortsetter:

- kind: AskQuestion
  id: request_approval
  activity:
    text: =Concat("Klassifisering: ", Local.classificationResult.category,
                  ". Confidence: ", Text(Local.classificationResult.confidence, "0%"),
                  ". Godkjenner du dette?")
  outputVariable: Local.humanApproval

- kind: IfElse
  id: check_approval
  condition: =Lower(Local.humanApproval) = "ja"
  truePath: proceed_node
  falsePath: escalation_node

Godkjennings-mønster (approval workflow):

- kind: AskQuestion
  id: manager_approval
  activity:
    text: "Dokument krever godkjenning. Skriv 'godkjenn' eller 'avvis':"
  outputVariable: Local.decision

- kind: IfElse
  id: route_decision
  condition: =Local.decision = "godkjenn"
  truePath: publish_agent
  falsePath: return_for_revision

Agent Framework HITL (pro-code): Bruk RequestPort (C#) eller ctx.request_info() (Python) for HITL i egendefinerte workflows. For agent orchestrations (sequential, concurrent, group chat): bruk ToolApprovalRequestContent — agenten kan markere tools som approval-required, workflow pauser og emitter RequestInfoEvent. Checkpoints bevarer pending requests ved gjenopptak.

Detaljer: Loop-noden (For each)

- kind: ForEach
  id: process_each_document
  collection: =Local.documentList
  itemVariable: Local.currentDoc
  body:
    - kind: InvokeAgent
      id: process_doc
      agentId: agent-processor-001
      input: =Local.currentDoc
      outputVariable: Local.processedDoc
    - kind: SetVariable
      id: append_result
      variable: Local.results
      value: =Concat(Local.results, Local.processedDoc, "\n")

---

Orkestreringsmønstre (Maler)

Foundry tilbyr tre startmaler inspirert av Microsoft Agent Framework:

Mønster	Beskrivelse	Typisk brukstilfelle
Sequential	Resultat fra én agent sendes direkte til neste i fast rekkefølge	Dokumentprosessering, flertrinns-analyse, innholdspipelines
Human-in-the-loop	Workflowen pauser og venter på brukerinput eller godkjenning	Godkjenningsprosesser, compliance-sjekk, vedtak som krever menneskelig oversikt
Group chat	Kontroll sendes dynamisk mellom agenter basert på kontekst og regler	Eskalering, eksperthandoff, dynamiske arbeidsflyter

---

Feilhåndtering

Foundry Workflows har innebygd feilhåndteringsmekanikk, primært via Power Fx betingelseslogikk og workflow-strukturering. Full retry-policy konfigurasjon er foreløpig mer moden i pro-code/YAML-tilnærminger.

Praktisk feilhåndtering med Power Fx

# Sjekk om agent-output er gyldig før neste steg
- kind: IfElse
  id: validate_output
  condition: =IsBlank(Local.agentResult) Or IsError(Local.agentResult)
  truePath: error_handler_node
  falsePath: next_step_node

# Feilhåndterings-node
- kind: SendActivity
  id: error_handler_node
  activity:
    text: =Concat("Feil i prosessering. Melding: ", Local.lastError,
                  ". Sak eskalert til manuell behandling.")

Timeout-håndtering

Fra offisiell dokumentasjon (troubleshooting): komplekse workflows kan timeout dersom eksterne tjenester ikke svarer innenfor forventet tid. Anbefalt mønster:

Problem	Mitigering
Workflow timer ut	Bryt komplekse workflows i mindre segmenter
Agent svarer ikke	Sjekk at agentens modell og verktøy er konfigurert korrekt
Uventet output	Valider JSON-schema på agent-noder; bruk IfError() i Power Fx

Retry (via Microsoft Agent Framework / YAML)

For pro-code-tilnærming med Agent Framework YAML:

- kind: InvokeAgent
  id: resilient_agent_call
  agentId: agent-001
  retryPolicy:
    maxRetries: 3
    retryDelay: PT5S   # ISO 8601 duration: 5 sekunder
    retryOn: [Timeout, ServiceUnavailable]

---

Power Fx for Betingelser og Datatransformasjon

Power Fx er Microsofts lavkodespråk (Excel-lignende formler) brukt i Foundry Workflows for å drive logikk og datamanipulasjon.

Variabelscoping

Prefiks	Scope	Eksempel
Local.	Lokal til workflowen	Local.documentCategory
System.	Systemvariabler (bruker, samtale, tid)	System.User.Language

Nyttige formler

# Strengmanipulasjon
Upper(Local.Var01)               -- Konverter til store bokstaver
Concat("Hei, ", Local.userName)  -- Strengkonkatenering
Len(Local.responseText)          -- Lengde

# Betingelser
If(Local.score > 0.8, "godkjent", "avvist")
IsBlank(Local.agentResult)       -- Sjekk om variabel er tom
IsError(Local.result)            -- Sjekk om forrige steg feilet

# Dato/tid
Text(Now(), "yyyy-MM-dd")        -- Formater dato
DateDiff(Local.startDate, Now(), Days)  -- Beregn antall dager

---

Integrasjon med Foundry Agent Service og MCP

Foundry Agent Service

Foundry Workflows er bygget direkte inn i Foundry Agent Service — ikke et separat produkt. Workflows er et agenttype på linje med prompt-based og hosted agenter, og deler:

• Identitets- og RBAC-modell: Workflows bruker prosjektidentitet under utvikling og egen Agent Identity etter publisering
• Verktøykatalog: Alle verktøy som er tilgjengelige for enkelt-agenter (Code Interpreter, Bing Search, Azure AI Search, Key Vault, MCP-servere) er tilgjengelige i agent-noder inni workflows
• Livssyklus: Workflows følger samme Develop → Test → Evaluate → Publish → Monitor-livssyklus som enkelt-agenter

MCP-verktøy i Workflows

Agent-noder i Workflows støtter MCP-tilkoblinger på linje med enkelt-agenter:

# Agent-node med MCP-verktøy (konfigurert på selve agenten)
- kind: InvokeAgent
  id: research_step
  agentId: agent-researcher-mcp
  # Agenten er konfigurert med MCP-server (f.eks. microsoft-learn, sharepoint)
  input: =Local.researchQuery
  outputVariable: Local.researchFindings

Foundry MCP Server (preview) eksponerer Foundry selv som et MCP-endepunkt — agenter og workflows kan dermed orkestreres fra MCP-kompatible klienter uten å skrive backend-kode.

---

Foundry Workflows vs. Logic Apps vs. Power Automate

Dette er den mest stilte arkitekturspørsmålet. Velg basert på hvem som eier prosessen og hva slags intelligens som kreves.

Sammenligningstabellen

Dimensjon	Foundry Workflows	Azure Logic Apps	Power Automate
Primær målgruppe	AI-ingeniører, løsningsarkitekter, operasjonsteam	IT-profesjonelle, enterprise-integrasjonsteam	Forretningsbrukere, Microsoft 365-brukere
Kjernekonsept	Orkestrering av AI-agenter	Enterprise-integrasjon (iPaaS)	Menneskesentrisk automatisering
Intelligens	Innebygd — agent-noder tar egne beslutninger	Ingen innebygd LLM — kaller Azure AI som ekstern connector	AI Builder for enkle scenarier
Triggers	Chat-basert (brukerinput), API-kall	1400+ triggere (HTTP, Events, Schedule, Queues, SaaS)	Microsoft 365-hendelser, skjemainnsending, godkjenning
Tilkoblinger	Foundry-agenter, MCP-verktøy, Azure-tjenester	400+ enterprise-koblinger (SAP, Salesforce, AS2, EDI)	Microsoft 365, SharePoint, Teams, Dynamics
Variabelmodell	Power Fx, JSON-schema	Expressions (JSON-paths, ARM-funksjoner)	Power Fx
Feilhåndtering	Betingelseslogikk, agent-resiliens	Retry-policies, error scopes, dead-letter	Kjøre mislykket gren, parallell gren
Overvåking	Agent Monitoring Dashboard, OpenTelemetry traces	Azure Monitor, Logic App Run History	Power Platform Admin Center
Prising	Inkludert i Foundry Agent Service (token-basert)	Consumption (per execution) eller Standard (fast)	Per-bruker-lisens (Microsoft 365 inkl.)
Datasuverenitet	Azure-regioner (Norway East støttet)	Azure-regioner, on-premises gateway	Power Platform-regioner

Beslutningsguide: Velg riktig orkestrator

Trenger prosessen AI-agenter som tar beslutninger?
├─ Nei → Vurder Logic Apps eller Power Automate
│   └─ Er det forretningsbrukere som skal eie og kjøre prosessen?
│       ├─ Ja → Power Automate (Microsoft 365-kontekst)
│       └─ Nei → Logic Apps (enterprise-integrasjon, høy volum)
└─ Ja → Foundry Workflows
    └─ Er det enkelt scenarier med én agent?
        ├─ Ja → Vurder Foundry single agent (enklere)
        └─ Nei → Foundry Workflows (multi-agent, branching, HITL)

Hybridmønster (anbefalt for enterprise)

For norsk offentlig sektor er hybridmønsteret vanligst:

• Logic Apps: Trigger fra eksisterende systemer (sak-system, e-post, skjema), integrasjoner mot fagsystemer (SAP, Dynamics), scheduling
• Foundry Workflows: AI-analyse, klassifisering, sammendrag, beslutningsstøtte
• Power Automate: Menneskelige godkjenningstrinn, Teams-varsler, Microsoft 365-oppgaver

Fagsystem → Logic Apps (trigger + datafetch) → Foundry Workflow (AI-analyse)
         → Logic Apps (skriv resultat tilbake) → Power Automate (varsle saksbehandler)

---

Deployment: API-endepunkter, Versjonering og A/B-testing

Publisering som API-endepunkt

Workflows publiseres som Agent Applications — selvstendige Azure-ressurser med stabile API-endepunkter:

# Verifiser at workflow er publisert
curl -X POST \
  "https://<foundry-resource>.services.ai.azure.com/api/projects/<project>/applications/<app>/protocols/openai/responses?api-version=2025-11-15-preview" \
  -H "Authorization: Bearer <access-token>" \
  -H "Content-Type: application/json" \
  -d '{"input": "Start dokumentgjennomgang for saksnummer 2025-1234"}'

RBAC for publiserte endepunkter: Klienter som kaller endepunktet må ha Azure AI User-rollen på Agent Application-ressursen.

Versjonering

Foundry Workflows har et immutabelt versjonssystem:

Versjonsprinsipp	Detalj
Immutable versions	Hvert lagring oppretter en ny versjon. Eksisterende versjoner kan ikke endres
Draft state	Usavede endringer kan testes i playground, men mistes ved navigering
Version history	Alle versjoner er listet i versjonsdropdown; naviger til hvilken som helst
Rollback	Deploy en tidligere versjon ved å publisere den på nytt
Version comparison	Sammenlign konfigurasjoner, chat-output og YAML mellom versjoner
Code reference	Referanse til agent i kode: <agent_name>:<version>

A/B-testing (begrenset)

Per februar 2026 er A/B-testing av workflows begrenset: all trafikk rutes til én aktiv deployment. For å eksperimentere:

1. Opprett en parallell Agent Application for B-varianten
2. Split trafikk manuelt i lag foran (API Management, Logic Apps, eller custom router)
3. Sammenlign metrics i Agent Monitoring Dashboard

Microsofts roadmap indikerer at trafikkdeling mellom deployments planlegges som funksjon.

---

Overvåking: Tracing, Tokenbruk og Latensmetrikker

Agent Monitoring Dashboard

Foundry tilbyr et dedikert Agent Monitoring Dashboard tilgjengelig fra Monitor-fanen på enhver agent eller workflow:

Metrikk	Beskrivelse	Terskelverdi å kjenne til
Token usage	Prompt + completion tokens per agent-kall i tidsvindu	Høy tokenbruk kan indikere verbose prompts
Latency	End-to-end responstid per workflow-kjøring	>10 sekunder kan indikere modell-throttling
Run success rate	Andel kjøringer som fullføres uten feil	<95% bør undersøkes
Error rate	Antall mislykkede node-kjøringer	Bør nærme seg 0 i produksjon
Evaluation metrics	Scores fra evaluators (korrekthet, sikkerhet, relevans)	Varierer per evaluator

Tracing (OpenTelemetry)

Foundry bruker OpenTelemetry med egne semantiske konvensjoner for multi-agent observability:

Span-type	Formål
execute_task	Overordnet task-planlegging og event-propagering
agent_to_agent_interaction	Sporing av kommunikasjon mellom agenter
agent.state.management	Context og minnehåndtering
agent_planning	Agentens interne planleggingssteg
execute_tool	Verktøy-kall med input/output

Granular tracing av en Workflow-kjøring viser:

• Hvert agent-kall med input og output
• Variabeltilordninger og verdier
• Hvilken branch som ble tatt i if/else-noder
• Latens per node
• Token-forbruk per LLM-kall

Continuous Evaluation

# Sett opp kontinuerlig evaluering av workflow
from azure.ai.projects import AIProjectClient

client = AIProjectClient(endpoint=project_endpoint, credential=credential)

# Konfigurer evaluator på workflow-kjøringer
evaluation_config = {
    "evaluators": {
        "relevance": {"type": "relevance"},
        "groundedness": {"type": "groundedness"},
        "safety": {"type": "safety"}
    },
    "samplingRate": 0.1  # Evaluer 10% av produksjonskjøringer
}

Integration med Azure Monitor og Application Insights

Foundry Workflows → OpenTelemetry traces → Application Insights
                                         → Azure Monitor (platform metrics)
                                         → Log Analytics Workspace
                                         → KQL-spørringer og alerter

KQL-eksempel — oppdag workflows med høy feilrate:

traces
| where customDimensions["workflow_name"] == "dokumentgodkjenning-workflow"
| where timestamp > ago(24h)
| summarize SuccessCount = countif(resultCode == "200"),
            FailureCount = countif(resultCode != "200")
          by bin(timestamp, 1h)
| extend SuccessRate = round(100.0 * SuccessCount / (SuccessCount + FailureCount), 1)
| where SuccessRate < 95

---

Norsk offentlig sektor

Visuell styring og revisjonsspor

Foundry Workflows' visuelle designer gir offentlig sektor-organisasjoner en unik fordel: prosessen er synlig og forklarbar — ikke skjult i kode. Dette adresserer flere krav:

Krav	Hvordan Foundry Workflows møter det
Innsyn i automatiserte prosesser	Visuell kanvas kan vises for revisorer og tilsynsmyndigheter
Dokumentasjon	YAML-definisjon er versionskontrollert og lesbar — fungerer som prosessdokumentasjon
Forvaltningsloven § 11a	Human-in-the-loop-noder sikrer at saksbehandler godkjenner vedtak
AI Act transparenskrav	Hvert steg er sporbart via OpenTelemetry; agent-identitet er deklarert
GDPR — sporbarhet	Conversation.Id og trace-IDer kobler brukeraktivitet til loggoppføringer
Schrems II	Deploy til norwayeast region; persondata forlater ikke EØS

Automatiserte vedtak og forvaltningsloven

Kritisk: Workflows som bidrar til vedtaksprosesser i norsk forvaltning må:

1. Ha human-in-the-loop for alle vedtak som påvirker rettighetsstatus (§ 11a)
2. Logge beslutningsgrunnlaget — bruk variabellagring og tracing til å bevare agentens resonnement
3. Versjonere prosessen — Foundry Workflows' immutable versioning gir sporbarhet over tid
4. DPIA — Workflows som behandler personopplysninger krever PVK (personvernkonsekvensvurdering)

# Obligatorisk HITL-mønster for offentlig sektor-vedtak
- kind: InvokeAgent
  id: analyse_soknad
  agentId: agent-soknad-analyser
  outputVariable: Local.analyseResultat

- kind: AskQuestion
  id: saksbehandler_godkjenning
  activity:
    text: =Concat("AI-analyse: ", Local.analyseResultat.anbefaling,
                  " (confidence: ", Text(Local.analyseResultat.confidence, "0%"), ")",
                  "\nGrunnlag: ", Local.analyseResultat.begrunnelse,
                  "\n\nGodkjenner du denne anbefalingen? (ja/nei/endre)")
  outputVariable: Local.saksbehandlerBeslutning

- kind: SetVariable
  id: log_beslutning
  variable: Local.revisionslogg
  value: =Concat("Vedtak: ", Local.saksbehandlerBeslutning,
                 " | Tid: ", Text(Now(), "yyyy-MM-dd HH:mm"),
                 " | Saksbehandler: ", System.User.DisplayName,
                 " | AI-anbefaling: ", Local.analyseResultat.anbefaling)

NSM og dataminimering

• Bruk IsBlank() og ParseJSON() til å filtrere bort unødvendige persondata mellom noder
• Ikke mellomlagre sensitive data som workflow-variabler utover det som trengs for neste steg
• Konfigurer Azure Monitor-oppbevaring i henhold til virksomhetens sletteplan

---

For Cosmo: Beslutningsveiledning

Spørsmål å stille kunden

1. Trenger prosessen mer enn én agent?

   • Nei → Foundry enkelt-agent (enklere, billigere)
   • Ja → Foundry Workflows

2. Er det saksbehandlere som skal godkjenne underveis?

   • Ja → Human-in-the-loop-mønster i Foundry Workflows
   • Nei → Vurder fullt automatisert workflow eller Logic Apps

3. Er prosessen godt definert (sekvens av steg)?

   • Ja → Sequential workflow (mal)
   • Nei, dynamisk → Group chat-mønster eller enkelt-agent med verktøy

4. Hvem skal vedlikeholde prosessen?

   • Forretningsteam (lav teknisk kompetanse) → Visuell designer i Foundry Workflows
   • Utviklerteam → YAML + VS Code + CI/CD-integrasjon
   • Blandet → Foundry Workflows (begge tilnærminger i ett verktøy)

5. Trenger prosessen triggers fra eksisterende systemer?

   • Sak-system, e-post, filopprettelse → Logic Apps trigger → Foundry Workflow (hybrid)
   • Chat/Teams → Copilot Studio → Foundry Workflow

6. Hva er compliance-kravene?

   • Forvaltningsloven → HITL obligatorisk, logging av beslutningsgrunnlag
   • GDPR → Databehandleravtale med Microsoft, Norway East-region, DPIA
   • NSM grunnprinsipper → Minste privilegium, audit logging, MFA

7. Er det behov for A/B-testing av ulike prosessdefinisjoner?

   • Ja, kritisk → Vurder Logic Apps eller custom routing (mer fleksibelt nå)
   • Ja, enkelt → Manuell splitt via to Agent Applications

Kompetansekrav

Rolle	Foundry Workflows-kompetanse	Tid til produktivitet
Forretningsanalytiker	Visuell designer, Human-in-the-loop, Power Fx grunnleggende	1-2 dager
Løsningsarkitekt	Node-typer, orkestreringsmønstre, deployment, integrasjon	3-5 dager
AI-ingeniør	YAML-editing, VS Code-integrasjon, Agent Framework, CI/CD	1 uke
DevOps	Publisering, RBAC, monitoring, alerting	2-3 dager

Fallgruver

Fallgruve	Konsekvens	Mitigering
Bruke Workflow for enkelt scenarier	Unødvendig kompleksitet og overhead	En agent med verktøy er tilstrekkelig for de fleste enkelt-oppgaver
Ingen HITL der det kreves	Compliance-brudd (Forvaltningsloven)	Design HITL inn fra dag én for vedtaksprosesser
For lange workflow-kjøringer	Timeout, dårlig UX	Del opp i delprosesser; bruk asynkron orkestrering for lang-levende tasks
Ukontrollerte persondata i variabler	GDPR-risiko	Filtrer og minimer data mellom noder; bruk Key Vault for sensitiv info
Ingen versjonskontroll av YAML	Kan ikke rollbacke ved feil	Eksporter YAML til Git-repo som del av CI/CD-pipeline
Avhengighet av visuell designer uten backup	Vendor lock-in i UI	Alltid vedlikehold YAML som autoritativ kilde; bruk VS Code

Modenhetsnivåer

Nivå 1: Utforsking (0-1 måned)

• Bygg en 2-3 agent Sequential workflow via visuell designer
• Test Human-in-the-loop-malen
• Evaluer tracing i Agent Monitoring Dashboard

Success metric: Første Workflow publisert og testet med reell brukerinput

Nivå 2: Pilot (1-3 måneder)

• Én faktisk forretningsprosess i Foundry Workflows
• YAML eksportert til Git for versjonskontroll
• Continuous evaluation konfigurert (10% sampling)
• Logging til Azure Monitor konfigurert

Success metric: Workflow kjører i produksjon, <5% feilrate, audit trail komplett

Nivå 3: Skalering (3-12 måneder)

• Multiple workflows per team/domene
• CI/CD-pipeline for YAML-deploy
• Hybrid med Logic Apps for triggere fra fagsystemer
• Custom evaluators for domene-spesifikke kvalitetsmetrikker
• DPIA gjennomført og oppdatert

Success metric: Driftsavhengig prosess automatisert, sporbar, og godkjent av revisjon

---

Kilder og verifisering

Microsoft Learn (Verified)

1. Build a workflow in Microsoft Foundry

   • https://learn.microsoft.com/azure/foundry/agents/concepts/workflow?view=foundry
   • Confidence: Verified (offisiell workflow-guide, Foundry new portal)

2. Agent development lifecycle

   • https://learn.microsoft.com/azure/foundry/agents/concepts/development-lifecycle?view=foundry
   • Confidence: Verified (versjonering, publisering, livssyklus, januar 2025)

3. Publish and share agents in Microsoft Foundry

   • https://learn.microsoft.com/azure/foundry/agents/how-to/agent-applications?view=foundry
   • Confidence: Verified (Agent Application deployment, API-kall, RBAC)

4. Monitor agents with the Agent Monitoring Dashboard

   • https://learn.microsoft.com/azure/foundry/observability/how-to/how-to-monitor-agents-dashboard?view=foundry
   • Confidence: Verified (token usage, latency, success rate, evaluators)

5. Declarative Workflows — Overview (Agent Framework)

   • https://learn.microsoft.com/agent-framework/workflows/declarative
   • Confidence: Verified (YAML action types-tabell: Variable, Control Flow, Output, Agent/Tool Invocation (InvokeAzureAgent, InvokeFunctionTool, InvokeMcpTool), HTTP, HITL (Question, RequestExternalInput), Conversation — C# og Python; Conversation-actions er C#-only; verifisert MCP 2026-06-19)

6. Human-in-the-Loop Workflows

   • https://learn.microsoft.com/agent-framework/workflows/human-in-the-loop
   • Confidence: Verified (HITL-mønster, pause og resume, compliance)

7. Transparency Note for Azure Agent Service

   • https://learn.microsoft.com/azure/foundry/responsible-ai/agents/transparency-note?view=foundry-classic
   • Confidence: Verified (Foundry Workflows capabilities, visioning, governance)

Microsoft Dev Blog (Verified)

8. Introducing Multi-Agent Workflows in Foundry Agent Service
   • https://devblogs.microsoft.com/foundry/introducing-multi-agent-workflows-in-foundry-agent-service/
   • Confidence: Verified (MS Ignite november 2025 announcement, feature liste, customer quotes)

Confidence per seksjon

Seksjon	Confidence	Kilde
Visuell designer og node-typer	Verified	MS Learn workflow-guide
Orkestreringsmønstre	Verified	MS Learn + Agent Framework docs
Feilhåndtering	Baseline	MS Learn troubleshooting + Agent Framework YAML
Foundry vs Logic Apps vs Power Automate	Baseline	MS Learn + community analysis
Deployment og versjonering	Verified	MS Learn publish-agent guide
Monitoring og tracing	Verified	MS Learn monitoring dashboard + OpenTelemetry docs
Norsk offentlig sektor	Baseline	LLM-kunnskap + NO compliance praksis
Kostnadsestimater	Ikke inkludert	Se cost-estimation KB for priser

Total sources cited: 8 unike URL-er fra MCP-research og Tavily MCP calls: 4 (2x docs_search, 2x docs_fetch)