Skip to content
Tilbage til Magazine
automation-aiops 5 min læsning

Microsoft Foundry Local + Scout: når agentarbejdet flyttes ud i periferien

Gælder dette din virksomhed?

Gratis AI-diagnose 30 min →

Nøglepunkter

  • - kontekst fra Microsoft 365
  • - handlinger i arbejdsapps
  • - lokale desktop-ressourcer
  • - modeller og runtimes, der ikke længere altid afhænger af et fjernkald

Beslutning

Skeln pålidelig automatisering fra skrøbelig demo, før den gives autonomi.

Møde

Driftsgennemgang, arkitektur, sikkerhed eller platform.

Risiko

At øge hastigheden uden observerbarhed, rollback, ejerskab eller stopkriterium.

Agent-prompt: identificér beskyttelsesrækværk, kontrolpunkter, sandsynlige fejl og autonomikriterier

Problem

I for lang tid har det enterprise-agentbaserede løfte stået delt i to.

På den ene side kraftfulde agenter i cloud med adgang til modeller, workflows og governance. På den anden side reelt arbejde, der stadig lever i browser, desktop, lokale filer og interne systemer. Resultatet er en fragmenteret operation: agenten ræsonnerer langt fra det sted, hvor arbejdet reelt foregår.

På Build 2026 samlede Microsoft to dele, der normalt analyseres hver for sig: Foundry Local til at køre modeller og AI-kapaciteter lokalt i Windows, og Scout som en persistent personlig agent inden for Microsoft 365. Signalet er ikke, at Microsoft “også har sin egen AI”. Signalet er, at de vil forene cloud, desktop og lokal periferi i én samlet operationel overflade.

Tese

Det relevante fra Microsoft i denne uge er ikke en ny model. Det er et arkitektonisk skifte.

Microsoft prøver at få agenten til at stoppe med at være et chatvindue og i stedet blive et lag, der opererer mellem:

  • kontekst fra Microsoft 365
  • handlinger i arbejdsapps
  • lokale desktop-ressourcer
  • modeller og runtimes, der ikke længere altid afhænger af et fjernkald

Det flytter samtalen fra “hvilken model bruger du” til “hvor kører arbejdet, og under hvilken kontrol”.

Framework

Der er fire lag i Microsofts indsats:

  • Scout: persistent agent forbundet til Teams, Outlook, OneDrive og SharePoint.
  • Work IQ APIs: en overflade hvor agenter kan interagere med data og apps fra Microsoft 365.
  • Foundry Local + Windows AI APIs: lokal eksekvering og on-device-kapaciteter i Windows.
  • Agent 365 / sikkerhed og governance: observerbarhed, tilladelser og kontrol af agenter, selv når de ikke kun lever i cloud.

Mini-case: en analytiker modtager mails, forbereder et møde, slår filer op, tjekker kalender og skal krydsholde beslutninger med lokale projektoptegnelser. Hvis agenten kun lever i cloud, stiger friktionen hver gang den bevæger sig væk fra de centrale apps. Hvis den lever i en blandet periferi, kan den bevæge sig mellem enterprise-viden og lokal kontekst med mindre rundtur.

Målbart signal: andel af agentbaserede opgaver, der kan løses uden at trække brugeren ud af sit workflow mellem desktop, browser og den samarbejdsorienterede suite.

Position: det sande produkt er ikke copiloten. Det er periferien, hvor den copilot kan arbejde sikkert.

Hvorfor det betyder noget nu

Den 2. juni 2026 præsenterede Microsoft Scout som en altid aktiv agent til arbejde og styrkede parallelt det lokale AI-stack i Windows med Foundry Local, Windows AI APIs og mere on-device-kapacitet på CPU, GPU og NPU.

Set under ét peger dette skridt mod en ambitiøs tese: agenter kommer ikke kun til at leve i SaaS eller kun i chat. De kommer til at leve i hele arbejdsfladen.

Det er operationelt vigtigt af tre grunde:

  • Reducerer kontekstlatens: det hele kræver ikke en tur til cloud.
  • Rykker agenten tættere på det reelle arbejde: browser, filer og lokale apps kommer tilbage i spil.
  • Hæver barren for governance: hvis agenten rører desktop og lokale ressourcer, kan kontrollen ikke længere blive i appen.

Anti-eksempel

“Vi har en agent i M365, så vi er dækket ind.”

Nej. At have en agent i en suite løser ikke i sig selv:

  • hvilke lokale ressourcer den kan bruge
  • hvilken model der kører hvor
  • hvilke data der forlader enheden
  • hvordan handlingen logges mellem cloud og desktop
  • hvem der slukker for flowet, hvis noget afsporer

Uden det design skifter du kun grænseflade. Du skifter ikke driftsmodel.

Protokol (3 trin)

  1. Kortlæg hvor arbejdet reelt foregår. Suite, browser, desktop, lokale filer, interne systemer.
  2. Beslut hvilken del der skal køre lokalt. Privatliv, latens, omkostning, offline-kontinuitet eller nærhed til brugeren.
  3. Foren eksekvering og governance. Logs, identitet, tilladelser og kill switch skal krydse cloud og lokal periferi.
LagSpørgsmålRisiko hvis det mangler
agenthvem der handler og til hvadautomatisering uden ejer
konteksthvilke data den brugerfrakoblede svar
lokalt runtimehvad der kører på enhedenlatens og overdreven afhængighed
governancehvem der observerer og stopperautonomi uden kontrol

Relateret

Konsulterede kilder

Næste skridt

Hvis din virksomhed vil have persistente agenter, så stop med kun at tænke i suiten. Lav et kort over den reelle arbejdsperiferi: browser, desktop, filer, lokal kontekst og delt governance.


Oversat fra den spanske original med AI-hjælp og gennemset for nøjagtighed. Læs originalen på spansk.

microsoft foundry-local scout local-ai
Citer artiklen

Berthelius, V. (2026). “Microsoft Foundry Local + Scout: når agentarbejdet flyttes ud i periferien”. BRTHLS Magazine. https://www.brthls.com/magazine/microsoft-foundry-local-scout-agentarbejde-periferi-da

Fractional CAIO · Gratis diagnose

Er din virksomhed klar til at blive drevet med AI?

30 minutter. Ingen pitch. Et ærligt billede af, hvor du står, og hvad du skal flytte først.

Book gratis diagnose