# 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
**Type:** reference
**Source:** https://learn.microsoft.com/azure/foundry/agents/concepts/workflow

---

## Innhold

- [Introduksjon](#introduksjon)
- [Visuell Designer](#visuell-designer)
- [Node-typer](#node-typer)
- [Orkestreringsmønstre (Maler)](#orkestreringsmønstre-maler)
- [Feilhåndtering](#feilhåndtering)
- [Power Fx for Betingelser og Datatransformasjon](#power-fx-for-betingelser-og-datatransformasjon)
- [Integrasjon med Foundry Agent Service og MCP](#integrasjon-med-foundry-agent-service-og-mcp)
- [Foundry Workflows vs. Logic Apps vs. Power Automate](#foundry-workflows-vs-logic-apps-vs-power-automate)
- [Deployment: API-endepunkter, Versjonering og A/B-testing](#deployment-api-endepunkter-versjonering-og-ab-testing)
- [Overvåking: Tracing, Tokenbruk og Latensmetrikker](#overvåking-tracing-tokenbruk-og-latensmetrikker)
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
- [For Cosmo: Beslutningsveiledning](#for-cosmo-beslutningsveiledning)
- [Kilder og verifisering](#kilder-og-verifisering)

## Introduksjon

Foundry Workflows er den visuelle orkestreringsdesigneren i Microsoft Foundry (Microsoft 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:

```yaml
# 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:

```yaml
# 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:

```yaml
- 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):
```yaml
- 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)

```yaml
- 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

```yaml
# 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:
```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:

```yaml
# 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:

```bash
# 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 `Foundry User`-rollen (tidligere `Azure AI User` — rolle-ID og kjernepermisjoner uendret) 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

```python
# 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:**
```kusto
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)

```yaml
# 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)