# Autonomous Workflow Automation Patterns

**Last updated:** 2026-02
**Status:** GA
**Category:** Agent Orchestration & Automation

---

## Introduksjon

Autonomous Workflow Automation representerer et paradigmeskift i hvordan organisasjoner bygger intelligente arbeidsprosesser. Der tradisjonelle workflows krever eksplisitt programmering av hvert steg, tillater autonome workflows at AI-agenter tar beslutninger, tilpasser seg kontekst, og orkestrerer komplekse oppgaver med minimal menneskelig intervensjon.

Microsoft-stakken tilbyr tre primære tilnærminger til autonomous workflow automation: **Durable Functions** for kode-basert orkestrering med full kontroll, **Power Automate** med AI Builder for low-code intelligens, og **Azure Logic Apps** for deklarativ integrasjon med AI-kapabiliteter. Kombinasjonen av disse verktøyene med Microsoft Agent Framework, Azure OpenAI, og Copilot Studio muliggjør workflows som kan resonnere, lære fra kontekst, og håndtere uventede scenarioer.

Sentrale kjennetegn ved autonomous workflows inkluderer **stateful orchestration** (tilstandshåndtering på tvers av lange prosesser), **durable execution** (automatisk gjenoppretting ved feil), **intelligent decision-making** (AI-drevne valg underveis), og **human-in-the-loop patterns** (sømløs integrasjon av menneskelig godkjenning når nødvendig). Dette muliggjør alt fra selvhelbredende systemer til komplekse multi-agent workflows som kan ta timer, dager eller måneder å fullføre.

## Kjernekomponenter

| Komponent | Teknologi | Formål | Nøkkelegenskaper |
|-----------|-----------|--------|------------------|
| **Orchestrator** | Durable Functions, Logic Apps, Power Automate | Koordinerer workflow-logikk og tilstand | Automatisk checkpointing, replay-safe, versjonering |
| **Activity Functions** | Azure Functions, AI Builder actions | Utfører diskrete arbeidsenheter | Stateless, retriable, parallel-capable |
| **Durable Entities** | Durable Functions Entities | Håndterer tilstand over tid | Concurrency control, addressable state, event aggregation |
| **AI Agents** | Microsoft Agent Framework, Azure OpenAI | Intelligent beslutningstakning | Kontekstforståelse, tool calling, memory |
| **Timers & Events** | Durable Timers, External Events | Tidsstyring og integrasjon | Billige venteperioder, timeout-håndtering, event-driven triggers |
| **Client API** | DurableTaskClient, Connector API | Starter og overvåker workflows | HTTP management APIs, status queries, event raising |

### Teknologivalg per scenario

| Scenario | Anbefalt teknologi | Begrunnelse |
|----------|-------------------|-------------|
| Kompleks forretningslogikk med kode | **Durable Functions** | Full kontroll, type safety, unit testing |
| Multi-agent AI orchestration | **Microsoft Agent Framework + Durable Functions** | Deterministic multi-agent coordination, stateful conversations |
| Business user-driven automation | **Power Automate + AI Builder** | Low-code, 1400+ connectors, Copilot-assistert utvikling |
| Enterprise integration workflows | **Azure Logic Apps** | Built-in connectors, visual designer, managed service |
| Human-in-the-loop approval | **Durable Functions (human interaction pattern)** | Timeout-håndtering, event-driven escalation |
| Long-running batch processing | **Durable Functions (fan-out/fan-in)** | Parallel execution, automatic retry, progress tracking |

## Arkitekturmønstre

### 1. Function Chaining (sekvensiell orkestrering)

**Bruksområde:** Prosesser hvor hvert steg avhenger av output fra forrige.

**Implementering (Durable Functions):**

```csharp
[Function("OrderProcessing")]
public static async Task<string> Run(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var orderId = context.GetInput<string>();

    await context.CallActivityAsync("ValidateOrder", orderId);
    var paymentResult = await context.CallActivityAsync<string>("ProcessPayment", orderId);
    var inventoryUpdate = await context.CallActivityAsync("UpdateInventory", orderId);
    var shipmentId = await context.CallActivityAsync<string>("ShipOrder", orderId);

    return $"Order {orderId} shipped as {shipmentId}";
}
```

**Fordeler:**
- Enkel feilhåndtering med try-catch
- Automatisk checkpointing ved hver await
- Replay-safe: kan gjenopprettes fra hvilken som helst steg

**Ulemper:**
- Sekvensiell utførelse kan være treg
- Alle steg må vente på hverandre

**Anti-patterns:**
- ❌ Hardkode tidsavhengige beslutninger (bruk `context.CurrentUtcDateTime`)
- ❌ Kalle eksterne API-er direkte fra orchestrator (bruk activity functions)

---

### 2. Fan-out/Fan-in (parallell prosessering)

**Bruksområde:** Batch-prosessering, ETL-pipelines, parallelle AI-agent tasks.

**Implementering (Python + Agent Framework):**

```python
@app.orchestration_trigger(context_name="context")
def agent_orchestration_workflow(context: df.DurableOrchestrationContext):
    input_text = context.get_input()

    # Get main agent response
    main_agent = context.get_agent("MainAgent")
    main_response = yield main_agent.run(messages=input_text)

    # Fan-out: Run translation agents in parallel
    french_agent = context.get_agent("FrenchTranslator")
    spanish_agent = context.get_agent("SpanishTranslator")
    german_agent = context.get_agent("GermanTranslator")

    parallel_tasks = [
        french_agent.run(main_response.result.text),
        spanish_agent.run(main_response.result.text),
        german_agent.run(main_response.result.text)
    ]

    # Fan-in: Wait for all translations
    results = yield context.task_all(parallel_tasks)

    return {
        "original": main_response.result.text,
        "french": results[0].result.text,
        "spanish": results[1].result.text,
        "german": results[2].result.text
    }
```

**Fordeler:**
- Dramatisk redusert totaltid (N steg i parallell vs sekvensiell)
- Automatisk feilhåndtering per task
- Skalerer horisontalt (Azure Functions autoscaling)

**Ulemper:**
- Kan være dyrt hvis mange parallelle tasks
- Race conditions hvis tasks deler tilstand (bruk Durable Entities)

**Optimalisering:**
- Bruk `Task.WhenAll` (C#) / `context.task_all` (Python) for best performance
- Vurder batching hvis over 100 parallelle tasks

---

### 3. Human-in-the-Loop (approval workflows)

**Bruksområde:** AI-generert innhold som trenger godkjenning, expense reports, sensitive operasjoner.

**Implementering (C# + Agent Framework):**

```csharp
[Function("ContentApprovalWorkflow")]
public static async Task<string> ContentApprovalWorkflow(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    string topic = context.GetInput<string>();

    // AI agent generates content
    DurableAIAgent contentAgent = context.GetAgent("ContentGenerationAgent");
    var contentResponse = await contentAgent.RunAsync<GeneratedContent>(
        $"Write an article about {topic}"
    );
    GeneratedContent draftContent = contentResponse.Result;

    // Send for human review
    await context.CallActivityAsync("NotifyReviewer", draftContent);

    // Wait for approval with 24-hour timeout
    HumanApprovalResponse approvalResponse;
    try
    {
        approvalResponse = await context.WaitForExternalEvent<HumanApprovalResponse>(
            eventName: "ApprovalDecision",
            timeout: TimeSpan.FromHours(24)
        );
    }
    catch (TaskCanceledException)
    {
        // Timeout - escalate
        return await context.CallActivityAsync<string>("EscalateForReview", draftContent);
    }

    if (approvalResponse.Approved)
    {
        return await context.CallActivityAsync<string>("PublishContent", draftContent);
    }

    return "Content rejected";
}
```

**Fordeler:**
- Ingen kostnad for ventetid (kun lagring)
- Timeout-håndtering innebygd
- Kan vente dager/uker uten ressursbruk

**Ulemper:**
- Krever ekstern mekanisme for å raise events (HTTP API, webhook, etc.)

**Best practices:**
- Alltid ha timeout for å unngå evig ventende workflows
- Send påminnelser før timeout (bruk nested timers)

---

### 4. Monitor Pattern (polling & adaptive intervals)

**Bruksområde:** Overvåking av eksterne systemer, ML-modelltrening, long-running jobs.

**Implementering (JavaScript):**

```javascript
df.app.orchestration("jobMonitor", function* (context) {
    const jobId = context.df.getInput();
    const pollingInterval = 60; // Start with 60 seconds
    const expiryTime = DateTime.fromJSDate(context.df.currentUtcDateTime)
                               .plus({ hours: 24 });

    let attempts = 0;
    while (DateTime.fromJSDate(context.df.currentUtcDateTime) < expiryTime) {
        const jobStatus = yield context.df.callActivity("GetJobStatus", jobId);

        if (jobStatus === "Completed") {
            yield context.df.callActivity("SendAlert", jobId);
            return "Job completed successfully";
        } else if (jobStatus === "Failed") {
            yield context.df.callActivity("SendErrorAlert", jobId);
            return "Job failed";
        }

        // Adaptive polling: exponential backoff
        attempts++;
        const waitTime = Math.min(pollingInterval * Math.pow(2, attempts), 3600);
        const nextCheck = DateTime.fromJSDate(context.df.currentUtcDateTime)
                                  .plus({ seconds: waitTime });
        yield context.df.createTimer(nextCheck.toJSDate());
    }

    return "Job monitoring timed out";
});
```

**Fordeler:**
- Fleksibel polling-intervall (statisk eller adaptivt)
- Håndterer flere monitor-instances fra én orchestration
- Billig (ingen compute cost under venting)

**Ulemper:**
- Ikke real-time (bruk Event Grid hvis det kreves)

**Optimalisering:**
- Bruk exponential backoff for å redusere API-kall
- Kombiner med Event Grid for hybrid push/pull

---

### 5. Aggregator (Stateful Entities)

**Bruksområde:** Event sourcing, real-time analytics, stateful counter/accumulator.

**Implementering (C#):**

```csharp
public class Counter
{
    public int CurrentValue { get; set; }

    public void Add(int amount) => this.CurrentValue += amount;
    public void Reset() => this.CurrentValue = 0;
    public int Get() => this.CurrentValue;

    [Function(nameof(Counter))]
    public static Task RunEntityAsync([EntityTrigger] TaskEntityDispatcher dispatcher)
    {
        return dispatcher.DispatchAsync<Counter>();
    }
}

// Client signaling entity
[Function("EventHubTrigger")]
public static async Task Run(
    [EventHubTrigger("device-sensor-events")] EventData input,
    [DurableClient] DurableTaskClient client)
{
    var metricType = (string)input.Properties["metric"];
    var delta = Convert.ToInt32(input.Data);

    var entityId = new EntityInstanceId("Counter", metricType);
    await client.Entities.SignalEntityAsync(entityId, "add", delta);
}
```

**Fordeler:**
- Innebygd concurrency control (single-threaded per entity)
- Addressable state (kan query via entity ID)
- Automatisk persistence

**Ulemper:**
- Throughput-begrensninger (1 entity = 1 virtual actor)
- Ikke egnet for high-frequency updates (bruk Azure Cosmos DB for det)

**Best practices:**
- Bruk entities for logisk "singleton" state (f.eks. én counter per customer)
- Kombiner med orchestrators for kompleks logikk

## Beslutningsveiledning

| Kriterium | Durable Functions | Power Automate | Azure Logic Apps |
|-----------|------------------|----------------|------------------|
| **Utviklererfaring** | Kode-først (C#, Python, JS, Java, PS) | Low-code (visual designer) | Low-code (visual designer) |
| **AI-integrasjon** | Microsoft Agent Framework, Azure OpenAI SDK | AI Builder (prebuilt + custom models) | Azure OpenAI connector |
| **Kompleksitet** | Ubegrenset (full programmeringsspråk) | Moderat (begrenset til actions/expressions) | Moderat (begrenset til connectors) |
| **Stateful orchestration** | ✅ Innebygd (checkpointing, replay) | ✅ Via flow runs | ✅ Via workflow runs |
| **Human-in-the-loop** | ✅ External events + timers | ✅ Approval actions | ✅ Approval actions |
| **Parallellisering** | ✅ Fan-out/fan-in pattern | ✅ Apply to each (parallel mode) | ✅ Parallel branches |
| **Lang kjøretid** | ✅ Dager/uker/måneder | ✅ 30 dager (cloud flows) | ✅ 90 dager (Standard tier) |
| **Kostnad** | Consumption/Premium (per execution) | Per flow run + API calls | Consumption/Standard (per action) |
| **Testing** | ✅ Unit testing, mocking | ⚠️ Manual testing i portal | ⚠️ Manual testing i portal |
| **CI/CD** | ✅ Full DevOps-støtte | ⚠️ ALM via solutions | ✅ Infrastructure as Code |
| **Debugging** | ✅ Local debugging, Application Insights | ⚠️ Flow run history | ⚠️ Workflow run history |

### Vanlige feil å unngå

| Anti-pattern | Problem | Løsning |
|--------------|---------|---------|
| **Orchestrator gjør I/O direkte** | Replay-safety brytes, duplikate calls | Bruk activity functions for all I/O |
| **Ingen timeout på external events** | Workflow henger evig | Alltid bruk `Task.WhenAny` med timer |
| **Hardkodet DateTime.Now** | Non-deterministic replay | Bruk `context.CurrentUtcDateTime` |
| **For mange parallelle tasks** | Throttling, minneproblemer | Batch til max 100-200 parallelle tasks |
| **Manglende idempotency** | Duplikate side-effekter ved retry | Design activity functions som idempotente |
| **Ignoring versioning** | Breaking changes dreper in-flight workflows | Bruk versjonering (pattern #6) |

### Røde flagg (når IKKE bruke Durable Functions)

- ❌ **High-frequency events** (>1000 req/sec) → Bruk Event Grid + Functions
- ❌ **Simpel HTTP request-response** → Bruk vanlig Azure Function
- ❌ **Real-time streaming** → Bruk Azure Stream Analytics
- ❌ **Pure data transformation** → Bruk Azure Data Factory

## Integrasjon med Microsoft-stakken

### Power Platform-integrasjon

```mermaid
Power Automate Cloud Flow
  ↓ (triggers)
Durable Functions Orchestration
  ↓ (calls)
AI Builder Models + Custom Activities
  ↓ (stores results in)
Dataverse / SharePoint
  ↓ (triggers)
Power Apps (for human review)
```

**Konkret eksempel:**
- Power Automate flow trigges av SharePoint-dokumentopplasting
- Flow starter Durable Functions orchestration for dokumentbehandling
- Orchestration bruker AI Builder Document Intelligence for ekstraksjon
- Parallelle tasks prosesserer forskjellige seksjoner
- Resultater lagres i Dataverse
- Power App viser resultater til bruker for godkjenning

### Microsoft Agent Framework-integrasjon

**Multi-agent orchestration pattern:**

```python
# Deterministic multi-agent workflow
@app.orchestration_trigger(context_name="context")
def research_workflow(context: df.DurableOrchestrationContext):
    topic = context.get_input()

    # Step 1: Research agent gathers information
    research_agent = context.get_agent("ResearchAgent")
    research_result = yield research_agent.run(
        messages=f"Research {topic} thoroughly"
    )

    # Step 2: Analyst agent analyzes findings
    analyst_agent = context.get_agent("AnalystAgent")
    analysis = yield analyst_agent.run(
        messages=f"Analyze this research: {research_result.result.text}"
    )

    # Step 3: Writer agent creates report
    writer_agent = context.get_agent("WriterAgent")
    report = yield writer_agent.run(
        messages=f"Write executive summary: {analysis.result.text}"
    )

    return report.result.text
```

**Fordeler:**
- Deterministisk agent-sekvens (kan reproduseres)
- Fault-tolerant (agenter kan feile og retryes)
- Observerbar (full history i Durable Functions)

### Microsoft Foundry-integrasjon

Durable Functions kan orkestrere Microsoft Foundry-tjenester:
- **Prompt Flow deployments** (via REST API fra activity functions)
- **Model endpoints** (Azure OpenAI, custom models)
- **Vector stores** (Azure AI Search for RAG-workflows)
- **Evaluation pipelines** (parallel fan-out av test cases)

## Offentlig sektor (Norge)

### GDPR & Schrems II-compliance

| Komponent | Data residency | Personopplysninger | Tiltak |
|-----------|----------------|-------------------|--------|
| **Durable Functions storage** | Azure Storage i Norway-regioner | ⚠️ Kan inneholde workflow-state | Krypter sensitiv state, bruk Azure Private Endpoints |
| **Activity function logs** | Application Insights | ⚠️ Kan logge personopplysninger | Masker PII i logs, bruk customer-managed keys |
| **AI Builder / Azure OpenAI** | EU/Norge (avhengig av modell) | ⚠️ Prompt innhold kan inneholde PII | Anonymiser data før sending til AI, bruk Azure OpenAI i Norge |

**Anbefaling:** Gjennomfør DPIA (Data Protection Impact Assessment) før produksjonssetting av autonomous workflows som prosesserer personopplysninger.

### AI Act-vurdering

Autonomous workflows kan klassifiseres som **Limited Risk** eller **High Risk** avhengig av bruksområde:

- **Limited Risk:** Chatbots, innholdsklassifisering, dokumentoppsummering → Transparenskrav
- **High Risk:** Automatisert saksbehandling, kredittvurdering, HR-beslutninger → Full conformity assessment

**Tiltak:**
- Implementer human-in-the-loop for High Risk-beslutninger
- Logg alle AI-beslutninger (via Application Insights Custom Events)
- Dokumenter treningsdata og modell-versjon for auditerbarhet

### Forvaltningsloven §11b (automatiserte vedtak)

Krav: *"Den som er part i en sak som er til behandling i et forvaltningsorgan, kan kreve at et enkeltvedtak som er truffet ved hjelp av et helautomatisert system [...] overprøves av en fysisk person."*

**Implementering:**

```csharp
[Function("AutomatedDecision")]
public static async Task<Decision> Run(
    [OrchestrationTrigger] TaskOrchestrationContext context)
{
    var caseData = context.GetInput<CaseData>();

    // AI-basert beslutning
    var aiDecision = await context.CallActivityAsync<Decision>("AIDecisionEngine", caseData);

    // Sjekk om human review er påkrevd (lovkrav eller usikkerhet)
    if (aiDecision.ConfidenceScore < 0.85 || caseData.RequiresHumanReview)
    {
        await context.CallActivityAsync("NotifyCaseWorker", caseData);

        var humanReview = await context.WaitForExternalEvent<HumanDecision>(
            "HumanReviewComplete",
            timeout: TimeSpan.FromDays(5)
        );

        return humanReview.Decision;
    }

    // Log automatisert vedtak for auditerbarhet
    await context.CallActivityAsync("LogAutomatedDecision", aiDecision);
    return aiDecision;
}
```

### Digdir Referansearkitektur

Autonomous workflows bør følge **Digdir Referansearkitektur for datautveksling**:
- **Datakatalog:** Dokumenter hvilke data workflows prosesserer
- **API-sikkerhet:** Bruk Maskinporten for maskin-til-maskin autentisering
- **Hendelsesbasert arkitektur:** Integrer med Altinn Events for varslinger

## Kostnad og lisensiering

### Azure Functions Durable Functions

| Plan | Pris (estimat Norge Øst, feb 2026) | Bruksområde |
|------|-------------------------------------|-------------|
| **Consumption** | ~0.20 NOK per 1M executions + 0.0002 NOK per GB-s | Dev/test, variable workloads |
| **Premium** | Fra ~1500 NOK/mnd (1 instans) | Production, VNet, unlimited execution time |
| **Dedicated (App Service)** | Fra ~900 NOK/mnd (B1) | Forutsigbar kostnad, existing App Service Plan |

**Tilleggskostnader:**
- **Storage:** ~0.20 NOK per GB/mnd (orchestration state)
- **Application Insights:** ~5 NOK per GB ingested (logging)
- **Outbound data transfer:** ~0.90 NOK per GB

**Kostnadsoptimalisering:**
- Bruk `Task.WhenAll` for parallellisering (færre orchestrator executions)
- Slå sammen små activity functions (reduserer antall function calls)
- Bruk Durable Timers i stedet for polling (gratis venting)

### Power Automate

| Lisens | Pris (feb 2026) | Inkluderer |
|--------|-----------------|------------|
| **Per user** | ~150 NOK/bruker/mnd | Unlimited flows, 40 000 AI Builder credits/mnd |
| **Per flow** | ~1 000 NOK/flow/mnd | 15 000 cloud flow runs/mnd, 250 000 API requests |
| **Process** | ~1 500 NOK/bot/mnd | RPA desktop flows, unattended automation |

**AI Builder-tillegg:**
- ~4 000 NOK for 1M credits (~500 document processing)

**Kostnadsoptimalisering:**
- Bruk conditions tidlig i flow for å unngå unødvendige actions
- Batch-prosesser data (Apply to each) i stedet for individuelle flows
- Bruk child flows for gjenbruk (teller som én action)

### Azure Logic Apps

| Tier | Pris | Bruksområde |
|------|------|-------------|
| **Consumption** | ~0.0003 NOK per action | Variable workloads |
| **Standard** | Fra ~2 500 NOK/mnd | VNet, longer execution time (90 dager) |

## For arkitekten (Cosmo)

### Spørsmål å stille kunden

1. **Kompleksitet:** "Hvor mange steg har workflowen, og hvor mange av dem avhenger av AI-beslutninger?"
   - <5 steg, ingen AI → Vanlig Azure Function
   - 5-20 steg, noe AI → Durable Functions
   - >20 steg, mye AI, business users → Power Automate

2. **Kjøretid:** "Hvor lenge skal workflowen kunne kjøre?"
   - Sekunder/minutter → Consumption plan
   - Timer/dager → Durable Functions Premium eller Standard Logic Apps
   - Uker/måneder → Durable Functions (med checkpointing)

3. **Human-in-the-loop:** "Trenger noen godkjenne AI-beslutninger? Hvor raskt må det skje?"
   - Umiddelbart → Power Automate approval actions
   - Timer/dager → Durable Functions external events
   - Kritisk juridisk krav → Implementer Forvaltningsloven §11b-pattern

4. **Datakvalitet:** "Hvor sensitive er dataene workflowen prosesserer?"
   - Personopplysninger → DPIA, GDPR-vurdering, Norway-regioner
   - Offentlig informasjon → Standard sikkerhet
   - Kritisk forretningsinformasjon → Private Endpoints, customer-managed keys

5. **Feiltoleranse:** "Hva skjer hvis ett steg feiler midt i workflowen?"
   - Kan starte på nytt → Vanlig retry-logikk
   - Må fortsette fra der den stoppet → Durable Functions checkpointing
   - Må kompensere tidligere steg → Saga pattern (Durable Functions)

6. **Observerbarhet:** "Hvordan skal vi overvåke og debugge workflowen?"
   - Basic logging → Application Insights
   - Detaljert audit trail → Custom events + workbook dashboards
   - Compliance-krav → Integrer med SIEM (Azure Sentinel)

7. **Kostnadsbudsjett:** "Hvor mange kjøringer per måned forventes?"
   - <10 000/mnd → Consumption plan
   - 10 000 - 100 000/mnd → Vurder Premium (forutsigbar kostnad)
   - >100 000/mnd → Dedicated App Service eller kostnad-benefit analyse

8. **Modenhetsnivå:** "Har teamet erfaring med serverless-utvikling?"
   - Ja, sterkt dev-team → Durable Functions (best-in-class developer experience)
   - Nei, business-user drevet → Power Automate
   - Blandet → Hybrid (Power Automate trigger → Durable Functions for kompleksitet)

### Fallgruver per modenhetsnivå

**Begynner (→ Power Automate):**
- ❌ Prøver å bygge kompleks AI-logikk i expressions → Bruk AI Builder eller kall Azure Function
- ❌ Ignorer error handling → Alltid konfigurer run-after på kritiske actions
- ❌ Lager én gigantisk flow → Del opp i child flows for gjenbruk

**Middels (→ Durable Functions Consumption):**
- ❌ Gjør I/O direkte i orchestrator → Bruk activity functions
- ❌ Ingen versjonsstrategi → Plan for breaking changes fra dag 1
- ❌ Under-estimerer logging-kostnad → Filtrer noise, bruk sampling i Application Insights

**Avansert (→ Durable Functions Premium + Agent Framework):**
- ❌ Over-engineering (bruker Durable Functions til alt) → Vurder enkelhet
- ❌ Ignorerer Consumption-alternativet → Premium koster 20x mer, velg riktig
- ❌ Manglende chaos engineering → Test failure scenarios (replay, timeout, concurrency)

### Anbefalinger per modenhetsnivå

| Nivå | Anbefaling | Starter-arkitektur |
|------|------------|-------------------|
| **Begynner** | Start med Power Automate cloud flows + AI Builder prebuilt models | SharePoint trigger → Document processing → Approval → Dataverse |
| **Middels** | Durable Functions (Consumption) + Azure OpenAI for custom AI | HTTP trigger → Orchestrator → 3-5 activity functions → Cosmos DB |
| **Avansert** | Durable Functions (Premium) + Microsoft Agent Framework + Durable Entities | Event Grid → Multi-agent orchestration → Stateful entities → Event sourcing |

## Kilder og verifisering

### Verified (MCP microsoft-learn)

| Seksjon | Kilde | Dato |
|---------|-------|------|
| Durable Functions patterns | https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview | 2026-02 |
| Multi-agent orchestration | https://learn.microsoft.com/en-us/agent-framework/user-guide/agents/agent-types/durable-agent/features | 2026-02 |
| Power Automate cloud flows | https://learn.microsoft.com/en-us/power-platform/release-plan/2025wave1/power-automate/cloud-flows | 2026-02 |
| Code samples (Python, C#, JS) | https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview#application-patterns | 2026-02 |

### Baseline (modellkunnskap)

| Seksjon | Konfidens | Begrunnelse |
|---------|-----------|-------------|
| GDPR & Schrems II | Høy | Generelle prinsipper, må verifiseres mot juridisk rådgiver |
| Forvaltningsloven §11b | Høy | Norsk lov, konseptet er korrekt, eksempel er illustrativt |
| Kostnadsestimater | Moderat | Priser endres hyppig, bruk Azure Calculator for eksakt kalkyle |
| AI Act-klassifisering | Moderat | Regelverket er i endring, må oppdateres kontinuerlig |

**Sist verifisert:** 2026-02-05
**Neste review anbefalt:** 2026-05 (kvartalsvurdering av priser og AI Act)
