Kommer Windows fortfarande vara Windows?

Windows har länge varit systemet som startar program, sparar filer och väntar på människans nästa klick. Den klassiska modellen är enkel: människa → program → data → resultat. Nu byggs ett nytt lager ovanpå den. AI-agenter kan tolka uppdrag, använda verktyg och i vissa fall utföra avgränsade handlingar åt användaren.

Det förändrar inte Windows över en natt. Men det förändrar frågan om vad ett operativsystem ska göra när människor, program, molntjänster och flera företags agentplattformar behöver samverka. Den viktiga frågan är därför inte bara vad nästa Copilot-funktion kan göra, utan hur kontroll, säkerhet och ansvar fungerar när datorn också kan använda datorn åt oss.

Windows byggdes för människan

Operativsystemet hanterar processer, filer, användarkonton, rättigheter och hårdvara. Automation är inte ny: skript, makron och batchjobb har funnits länge. Skillnaden med en agent är att den kan få ett mål i naturligt språk, välja verktyg och försöka hantera nästa steg utan att varje detalj har skrivits som regel i förväg.

När en agent får läsa filer, öppna ett program eller föreslå en åtgärd räcker det inte att fråga om svaret är rätt. Vem gav agenten åtkomst? Vilken data användes? Går åtgärden att stoppa eller ångra? Det är dessa frågor som börjar flytta upp från enskilda program till själva plattformen.

Nu får operativsystemet nya användare

Microsofts agentiska riktning består av flera byggstenar med olika mognadsgrad. De ska inte beskrivas som en färdig, allmänt tillgänglig agentdator. Copilot Actions på lokal Windows har dokumenterats som en experimentell Insider-funktion. Microsoft beskriver en Agent Workspace där Copilot kan arbeta med lokala filer i en avskild miljö med eget skrivbord, begränsad åtkomst och möjlighet för användaren att följa eller ta över arbetet.

Den verifierade Insiderutrullningen undantog EEA. Det går därför inte att säga att Copilot Actions eller Agent Workspace är allmänt tillgängligt i Sverige. Microsofts modell med separata agentkonton är ändå viktig: agenten ska inte automatiskt få samma rättigheter som personen vid datorn, utan bara åtkomst som uttryckligen ges och kan återkallas.

Skillnaden kan beskrivas med ett vardagligt arbete. I dag kan en användare själv öppna Excel, läsa en försäljningsfil, sammanställa siffrorna och skicka ett mejl. Om användaren i stället säger ”sammanställ försäljningssiffrorna och skicka rapporten till gruppen” måste en agent identifieras, få rättigheter, öppna rätt filer eller program, använda rätt data, eventuellt kontakta andra system och logga vad den gjort. Då blir identitet, begränsade rättigheter och isolering inte bara funktioner i en app, utan OS-frågor.

I företagsmiljö beskriver Microsoft Agent 365 som ett kontrollplan för inventering, policy, säkerhet och observability. Entra Agent ID kan ge agenter en egen hanterbar identitet med behörigheter, sponsor och spårbarhet. Microsoft Execution Containers, MXC, är samtidigt en tidig preview för policybaserad isolering på Windows och WSL.

Microsoft uppger också att Windows 365 for Agents MCP-servern är generellt tillgänglig för arbete i en Windows 365 Cloud PC. Det betyder inte att varje funktion finns överallt eller att varje Windows-dator har samma förmåga. Det visar däremot att Microsofts strategi handlar om mer än en synlig Copilot-yta: identitet, exekvering, policy och övervakning blir delar av plattformen.

Enligt GeekWires sekundärrapportering sade Windows-chefen Pavan Davuluri i september att Windows fortsatt ska tjäna mänskliga användare samtidigt som plattformen får agentic workloads. Han undvek etiketten ”agentic OS”. Någon primär Microsoft-transkription har inte verifierats, så detta är inte en officiell produktdefinition.

Settings Agent visar hur tillgänglighet kan delas upp. Microsoft anger att funktionen geografiskt finns i alla länder utom Kina, så Sverige är inte undantaget. Svenska saknas däremot i språklistan. Funktionen kräver dessutom Windows 11 24H2 med relevant uppdatering, Copilot+ PC och policykonfiguration. Geografi, språkstöd och faktisk åtkomst är tre olika saker.

Windows-världen tillhör inte Microsoft ensam

Google lanserade i september Gemini som desktopapp för Windows 10 och 11. Appen öppnas med Alt + Space och kan enligt Google använda information från Gmail och Drive. Google beskriver detta som början på Geminis native desktop capabilities för Windows. Det är inte samma sak som generell kontroll över Windows, men det gör Google till en tydligare aktör på skrivbordet.

Adobe bygger från ett annat håll. Bolaget har presenterat Creative Agent och AI Assistant som public beta i bland annat Photoshop, Illustrator och Premiere. Användaren beskriver ett resultat medan Adobe-agenten samordnar arbete i program som Adobe själv äger och förstår. Hur mycket måste en universell Windows-agent förstå om Photoshop om Adobe kan ansvara för sin egen specialistagent?

Google driver A2A, Agent-to-Agent, för samarbete mellan agenter. Google beskriver modellen som en avgränsad ”black box”-handoff där specialistagenten behåller sin interna miljö och logik. Microsofts Agent Framework dokumenterar A2A-sessioner med context_id, task_id, task_state och continuation tokens för långa uppgifter.

Det är konkreta protokollbyggstenar, men ingen komplett lösning på handoff. De flyttar inte automatiskt över hela applikationens state, agentminne, versionsinformation, behörigheter eller ansvar för följderna. En uppgift kan fortsätta tekniskt utan att hela kontinuitetsproblemet är löst.

Framtidens fråga blir därmed inte bara ”fungerar programmet i Windows?”. Den blir: fungerar Windows-agenten tillsammans med andra företags agenter, rättigheter, API:er och versionsmodeller? Ett ekosystem där varje leverantör kontrollerar sin egen data och sina egna specialistfunktioner behöver tydliga gränser, även när allt visas på samma skrivbord.

När kompatibilitet blir ett agentproblem

• Computer use eller UI-automation tolkar skärmen och använder virtuell mus och tangentbord.
• API är ett strukturerat sätt att begära en bestämd funktion eller data.
• App Actions är avgränsade programfunktioner som kan exponeras för en agentisk yta.
• MCP kopplar modeller och agenter till verktyg, data och tjänster.
• Agent-to-agent handoff innebär att en agent ber en specialistagent utföra ett eget arbete.

Computer use är flexibelt där stabila API:er saknas, men skörare. Microsofts FAQ för Copilot Studio computer use anger ungefär 80 procents lyckandefrekvens för webbaserade uppgifter och ungefär 35 procent för desktopappar. Det är Microsofts egna produktsiffror för just verktyget, inte ett generellt mått på alla AI-agenter.

En människa kan ofta förstå att en knapp flyttats eller att en ruta laddar långsamt. En visuellt arbetande agent kan fastna på grund av timing, dropdowns, date pickers, specialbyggda kontroller eller en loop där skärmen inte ser ut som väntat. UI-automation kan vara rimlig för enkla, övervakade uppgifter. När en handling är viktig eller återkommer ofta är ett tydligt API, en avgränsad appfunktion eller ett specialist-handoff lättare att testa, logga och uppdatera.

Anta att en agent visuellt letar efter knappen ”Exportera”. En mindre ändring av fönstrets layout, språk, behörighetsruta eller ikon kan bryta arbetsflödet. Om samma app i stället erbjuder en stabil exportfunktion via API, App Action eller annan strukturerad integrationsyta kan gränssnittet ändras utan att själva kontraktet behöver ändras. MCP kan göra verktyg och data åtkomliga för en agent, medan agent-to-agent-handoff kan låta en specialist behålla sin egen arbetsmiljö. Skillnaden spelar roll eftersom varje metod flyttar ansvaret och felrisken till olika ställen.

Problemet är inte att en modell måste tränas om varje gång en app uppdateras. Problemet är föränderliga integrationskontrakt: ett API fasas ut, ett schema ändras, en behörighet dras in eller en connector uppdateras. Ju fler leverantörer som utvecklas i olika takt, desto fler sådana gränser måste fungera samtidigt.

Ett litet fel kan bli en kedja

NextNet-analys: risken är inte bara ett felaktigt svar. Det är att svaret blir en handling och att handlingen blir indata till nästa system. Det finns begränsad oberoende empirisk evidens om hur ofta sådana felkedjor sprids mellan flera agentplattformar. Detta är därför ett realistiskt riskscenario, inte ett fastställt utfall.

Föreställ dig att en agent tolkar ett kundvärde fel. En annan för in värdet i ett dokument. Dokumentet används i en intern rapport, rapporten sammanfattas i ett mejl och mejlet påverkar ett beslut. Varje steg kan se rimligt ut om ingen granskar hela kedjan.

Ett fel i ett utkast kan ofta rättas. Ett skickat mejl kan kanske kompletteras. En databasändring, betalning, publicering eller kundkommunikation kan vara svårare att återställa, särskilt när nästa människa eller agent redan agerat på resultatet. Organisationer behöver därför skilja mellan reversibla steg, steg som kräver godkännande och handlingar som aldrig bör lämnas till en obevakad kedja.

Frågan är när felet upptäcks. Agent A kan ha hämtat ett kundvärde, Agent B kan ha lagt det i en rapport, Agent C kan ha sammanfattat rapporten i en presentation och Agent D kan ha skickat presentationen till ledningen. Då har felaktig information blivit ett felaktigt dokument, sedan ett möjligt felaktigt beslut och till sist en handling. Vissa steg är lätta att rätta, andra är delvis möjliga att återställa och några är svåra eller omöjliga att återkalla. Poängen är inte katastrofspråk, utan att automatisering kan öka spridningshastigheten om kontroll saknas.

Vem på företaget förstår vad som hände?

När en medarbetare gör fel går det ofta att hitta kontot, dokumentet och tidpunkten. När flera agenter samverkar blir frågan svårare: vilken agent tog initiativet, vilken identitet användes, vilket verktyg anropades och vilka data fanns tillgängliga?

Agentinventering, identitet, minsta möjliga behörighet, loggar, observability och tydliga ägare blir därför grunden för att kunna utreda vad som hänt. Agent 365 pekar mot ett sådant kontrollplan, men fungerar bara där organisationen faktiskt registrerat sina agenter och kopplat dem till policy- och säkerhetssystem.

Efter en incident behöver organisationen kunna svara på mer än att ”vi har loggar”. Vilken agent startade arbetet och på vems uppdrag? Vilken identitet användes? Vilka data lästes, vilka verktyg anropades och vilken version av connectorn eller API:t användes? Vilken annan agent fick resultatet, vad hann skickas vidare och vad går att återställa? Loggar från flera system kan finnas, men ändå vara svåra att koppla till en begriplig händelsekedja.

En kill switch kan stoppa framtida handlingar. Den kan inte automatiskt ta tillbaka ett mejl som redan lästs, ett dokument som laddats ned eller ett beslut som fattats. Säkerhet behöver därför omfatta förebyggande skydd, upptäckt, isolering, incidenthantering och rollback där rollback verkligen är möjlig.

Microsofts säkerhetsforskning illustrerar varför arkitekturen spelar roll. Defender-signaler visade att 15 procent av de remote MCP-servrar Microsoft observerade var allvarligt osäkra och gav oautentiserad åtkomst till känsliga data eller operativa funktioner. Det är inte 15 procent av alla MCP-servrar globalt. Microsoft har också beskrivit patchade Semantic Kernel-sårbarheter där prompt injection kunde kedjas till RCE på värddatorn via agentverktyg.

AutoJack visade på liknande sätt hur en browsing agent och en lokal MCP-kontrollplan kunde skapa en farlig kedja. Fallet åtgärdades under utveckling och den berörda WebSocket-ytan fanns aldrig i en PyPI-release. Exemplen är inte pågående massincidenter, utan visar varför verktygsbehörigheter, isolering och autentisering av kontrollplan är avgörande.

Kan Windows hinna med sin egen utveckling?

Microsoft, Google, Adobe, API-leverantörer, connectorer och säkerhetsteam uppdaterar sina delar oberoende av varandra. En agent kan få en ny förmåga samtidigt som ett program ändrar sin behörighetsdialog eller en säkerhetspolicy blockerar ett anrop. Det är inte ett argument för att stoppa utvecklingen, utan för att behandla agentintegrationer som levande system med versionshantering, tester, loggar och tydliga sätt att begränsa eller stänga av en integration.

Microsoft uppdaterar Windows och agentlagret. Google uppdaterar Gemini, Chrome, A2A och Workspace. Adobe uppdaterar Creative Cloud, API:er och egna agenter. Företaget ändrar samtidigt egna regler för data, identiteter och godkännanden. Varje del kan fungera för sig och ändå skapa problem i kombination. Det är versioner, integrationer, behörigheter, scheman, verktyg och policyer som måste fungera tillsammans.

Molnet kan ge konsekventa policyer, separata identiteter och bättre observability, men skapar också beroenden av leverantörens tillgänglighet, datahantering, pris och kontrollplan. Vem som äger integrationen blir därmed minst lika viktigt som vem som äger datorn.

Microsoft som trafikpolis – och gatekeeper

Om Windows blir platsen där människans önskemål, agenternas behörigheter, programmens data och företagets policyer möts, får Microsoft en strategisk roll. Det betyder inte att Microsoft missgynnar konkurrenter. Men det gör frågan relevant: får Google, Adobe och andra agentplattformar samma praktiska möjlighet att integrera som Microsofts egna tjänster?

Dubbelrollen är begriplig. Windows kan behöva skydda användaren från osäkra eller överprivilegierade agenter, särskilt när de får åtkomst till filer, konton och verktyg. Men den som sätter säkerhetskraven, godkänner integrationsytorna och styr vilka funktioner som exponeras får också stort inflytande över tredjepartsagenters praktiska möjligheter. Det är ett legitimt säkerhetsbehov och samtidigt en konkurrens- och interoperabilitetsfråga.

Den brittiska konkurrensmyndigheten CMA granskar i en pågående SMS-utredning paketering, interoperabilitet, förval och hur AI-konkurrenter kan integrera med Microsofts business software. CMA har inte i dessa källor funnit att Microsoft agerat konkurrensstridigt. EU-kommissionen har samtidigt identifierat lika tillgång för AI-baserade tjänster till operativsystem som en DMA-fråga. Det är inte ett särskilt beslut om Windows-agentfunktioner, men förklarar varför frågan redan är regulatoriskt relevant.

En annan möjlig modell: specialiserade agentplattformar

NextNet-analys / framtidsscenario: den mest hållbara modellen kanske inte är att en universell Windows-agent ska styra varje program direkt. Microsoft kan ansvara för Microsoft-miljön, Google för Google-miljön och Adobe för Adobe-miljön. Varje leverantör håller då sina interna program och agentfunktioner kompatibla, medan systemen samarbetar genom kontrollerade gränser.

En Microsoft-agent kan exempelvis hämta aktuell rapportversion och begära bildbearbetning. Adobe-agenten utför då det kreativa arbetet i Adobe-miljön och returnerar ett resultat med verifierbar information om vad som gjorts. Windows-agenten behöver då inte förstå varje detalj i Photoshop, Gmail eller ett specialbyggt affärssystem. Modellen kan ge mindre intern korsstyrning, tydligare ansvar, enklare versionshantering och mindre behov av UI-automation. Samtidigt skapar gränserna nya makt- och säkerhetspunkter: fler tillitgränser (trust boundaries), risk för vendor lock-in, svårare datastyrning och beroende av gemensamma standarder. Vem bestämmer vilka uppgifter som får lämnas över, vilken data som följer med och vad som händer när en leverantör ändrar policy?

När agentöverlämningen blir mer som en transaktion

System A kan begära en tydligt avgränsad operation från System B. System B utför arbetet i sin egen miljö. System A behöver inte förstå varje intern knapp och fil, men måste kunna kontrollera vem som gjorde arbetet, på vilket underlag, med vilken rättighet och vilket resultat som kom tillbaka.

En framtida handoff skulle i princip kunna bära identitet, authority, syfte, state eller version, provenance, giltighetstid, kvitto, resultat och audit trail. A2A, MCP, App Actions och identitetssystem visar delar av riktningen. De utgör inte tillsammans en färdig universell transaktionsmodell.

En agentöverlämning kanske behöver behandlas mer som en säker transaktion än som en konversation. System A behöver kunna skicka vem det är, vilket uppdrag som gäller, vilken data och version som gäller, vilken rättighet som finns och vad mottagaren får göra. System B behöver kunna returnera ett kvitto, resultatet, vilken operation som genomfördes, vilket underlag som användes och eventuell ändrad state eller version. System A behöver inte förstå hur System B:s interna program fungerar. Det behöver kunna verifiera vem som gjorde arbetet, på vilket underlag, med vilken rättighet, mot vilken version och vilket resultat som kom tillbaka.

Är dagens operativsystem byggda för AI-eran?

Under de kommande fem till tio åren kan modellen människa → program få sällskap av människa → intention → agent → verktyg → annan agent → tjänst → handling. Då blir operativsystemets uppgift inte bara att starta program och hålla filer i ordning, utan också att bidra till att avgöra vem som får göra vad, i vilken miljö och med vilket spårbart ansvar.

NextNet-reflektion: ett nytt operativsystem håller kanske på att växa fram inuti det gamla. Inte som ett färdigt Microsoft-mål, utan som ett lager av identitet, policy, verktyg, agentkommunikation och kontroll ovanpå system vi redan använder.

Windows kan därför fortfarande ha skrivbord, fönster, aktivitetsfält och vanliga program, samtidigt som rollen under ytan förändras. Ett framtida OS kan behöva fungera som lager för identitet, delegation, authority, policy, provenance, handoff, audit och containment. Det är inte en prognos om att det klassiska gränssnittet försvinner, utan en reflektion om vilka nya uppgifter plattformen kan behöva bära.

NextNet-analys: ju mer löpande arbete agenter utför, desto viktigare kan det bli att människor fortfarande förstår processerna när automationen går fel. Frågan är inte bara om organisationen har loggar, utan om någon kan tolka dem och rekonstruera varför ett beslut, en överlämning eller en handling blev som den blev.

Kommer Windows fortfarande vara Windows?

Windows kommer sannolikt att se välbekant ut länge. Människor kommer fortsatt att öppna program och fatta beslut. Men dess underliggande roll kan förskjutas från systemet som kör program mot något närmare systemet som kontrollerar hur människor, program och intelligenta agenter får arbeta tillsammans.

Frågan är därför inte bara om Microsoft kan göra Copilot mer kapabel. Frågan är om alla aktörer kan bygga en miljö där agenters möjligheter växer utan att kontroll, säkerhet, konkurrens och ansvar faller mellan systemen.

Om fem eller tio år kan Windows alltså fortfarande se ut som Windows: samma skrivbord, fönster, aktivitetsfält och välkända program. Men den viktigaste uppgiften under ytan kan ha flyttats från att bara köra program till att hantera identitet, delegation, authority, policy, provenance, agentöverlämning, audit och containment. Det är inte säkert att utvecklingen tar just den formen. Men det räcker att möjligheten finns för att rubrikfrågan ska bli relevant.

💬 Vad tycker du?

Hur mycket kontroll skulle du vara beredd att lämna över till en AI-agent i din egen dator?

Dela gärna dina tankar i kommentarerna.

📚 Relaterade artiklar