Nya Copilot Studio: byggblocken, kostnaden och vad som skiljer mot den gamla

Microsoft har lanserat en stor uppgradering av Copilot Studio, sitt low-code-verktyg för att bygga AI-agenter. Det som framför allt har bytts ut är motorn under agenten, alltså det som driver hur den faktiskt arbetar. Den nya motorn heter GitHub Copilot harness.

Microsoft beskriver den som sitt mest kapabla alternativ:

“Det mest kapabla alternativet, byggt för resonemangstunga agenter och arbetsflöden som behöver slutföra komplexa affärsprocesser.”

Källa: Välj en harness

Det största skiftet märks i hur agenten arbetar. Tidigare ritade man upp ämnen, flöden och förgreningslogik som agenten följde. Nu behöver den inte styras lika hårt. Du bygger förutsättningarna, alltså vad agenten vet, vad den får göra och hur den ska bete sig, och sedan tar den ett mål, väljer väg själv och justerar när något inte fungerar.

Att den kan arbeta så beror på hur den är byggd i grunden, alltså på den nya harnessen. Vi har gått igenom den i detalj i motorn inifrån.

Syftet med den här artikeln är helheten: vad du sätter ihop en agent av, vad det kostar, och vad som faktiskt skiljer mot den gamla motorn. Vi börjar med motorn, eftersom resten bygger på den.

Vad är en harness?

En agent kan förenklat beskrivas som modell plus harness. Modellen står för intelligensen och resonemanget. Harnessen är all programvara runt modellen som bestämmer vad den får veta, vad den kan göra, hur handlingar faktiskt utförs och hur agentens arbetsloop styrs. Instruktioner, skills, verktyg, orkestrering, guardrails, uppföljning och exekveringsmiljön är alltså delar av harnessen, inte separata system bredvid den.

Bytet av motor är därför större än det låter. Harnessen avgör hur självständigt agenten får arbeta, vilka förmågor som finns direkt i lådan och hur användningen faktureras.

En terminologisk varning för den som läser dokumentationen på svenska: Microsofts svenska sidor är maskinöversatta och kallar genomgående harnessen för sele.

Tre harnesses, och ett val som kräver eftertanke

Med uppgraderingen finns det tre harnesses att välja mellan, och valet gör du när agenten skapas. I praktiken står valet mellan två av dem. Den tredje, Copilot chat harness, är till för något annat: att ge Microsoft 365 Copilot Chat tillgång till företagets egen kunskap.

Det avgörande står i Microsofts egen dokumentation:

“Agenter skapade med GitHub Copilot-selen kan inte överföras till standardselen, och vice versa.”

Källa: Översikt över agenter

Det finns alltså inget standardiserat sätt att flytta en agent från en harness till en annan. Därför är det första valet viktigt, och längre ned i artikeln finns en kort jämförelse att utgå från.

Det finns dock ett inofficiellt tillvägagångssätt för att migrera agenter. Microsoft har publicerat microsoft/copilot-studio-plugin, ett plugin för AI-kodagenter som arbetar mot agenternas underliggande YAML och har ett /migrate-kommando. Det gör en AI-assisterad ombyggnad utifrån capabilities snarare än en komponentflytt. Förbehållet är tydligt uttalat: det är ett experimentellt forskningsprojekt och inte en officiellt stödd Microsoft-produkt, så generad YAML behöver granskas innan den skickas till en miljö.

Det är varken ett krav eller bråttom att gå över. Det äldre sättet lever kvar vid sidan av det nya, eftersom de fyller olika funktioner, och Microsoft skriver uttryckligen att agenter på standardharnessen fortsätter att stödjas fullt ut.

Byggblocken

Agenten sätts ihop av sju delar, konfigurerade från fliken Bygg (Build). Var och en har sin egen yta i komponentpanelen och sina egna regler.

Runt dem ligger fyra flikar: Bygg (Build) för att konfigurera agenten, Förhandsgranska (Preview) för att testa den interaktivt, Utvärdera (Evaluate) för testuppsättningar som mäter agentkvalitet, och Övervaka (Monitor) för att följa uppgifter, aktivitet och vilka filer agenten kommit åt.

Det finns en enda selektionsregel att lära sig: orkestratorn väljer utifrån namn och beskrivning. Den är värd att ta på allvar just för att Microsoft skriver in den på tre olika ställen, ett för varje komponenttyp.

“The tool's name and description are critical. Well-described tools are invoked more accurately.” · Verktyg

“Well-written skill descriptions help the orchestrator invoke the right skill at the right time.” · Skills

“The routing decision is based on: The connected agent's name and description…” · Anslutna agenter

Vill du att något ska användas oftare skriver du en bredare beskrivning. Vill du att det ska användas mer sällan skriver du en smalare.

Instruktioner

Instruktionerna är nu den primära mekanismen för att kontrollera beteendet, till skillnad från standardharnessen där ämnesflöden och triggers gör stora delar av jobbet.

Microsoft listar fem saker att överväga att ta med:

• agentens primära roll och syfte
• den ton och stil agenten bör använda, exempelvis formell, vänlig eller koncis
• ämnen eller uppgifter som agenten bör avböja eller omdirigera
• hur agenten ska hantera otydlig eller tvetydig användarinmatning
• eventuella eskalerings- eller överlämningstriggers

Redigeraren stödjer rich text, alltså fetstil, kursiv, listor, blockcitat, inline-kod och länkar. Instruktionerna behöver inte vara en platt textmassa. Någon tecken- eller tokengräns anges inte i dokumentationen.

En fallgrop är värd att känna till, eftersom den ser harmlös ut när man skriver instruktionerna. Microsoft varnar uttryckligen för att peta i hur källhänvisningar genereras:

"Don't modify, override, or interfere with the system-defined citation format or behavior."

Källa: Write agent instructions

Ber du agenten att låta bli att skriva ut källor, eller att svara i ett fast format, kan källhänvisningarna försvinna. Då kan systemet tro att svaret kommer från modellens allmänna kunskap och kasta det, trots att det var rätt. Microsofts eget råd är annars enkelt: börja med en kort beskrivning av syftet, testa i Förhandsgranska och bygg ut därifrån. Ändringar gäller direkt i nästa svar.

Kunskap

Kunskapskällorna är det agenten grundar sina svar i. Under huven ligger en RAG-pipeline byggd på Azure AI-tjänster, med frågeoptimering, sökleverantörer som Bing, SharePoint, Graph, Dataverse och Azure AI Search, en sammanfattningsmotor som producerar citerade svar, och ett modereringslager.

Att kunskapsvägen är delad är faktiskt poängen. Microsoft skriver det rakt ut:

“Agents powered by the GitHub Copilot harness support the same categories of knowledge sources as the standard harness, including websites, SharePoint, and uploaded files.”

Källa: Add knowledge sources to an agent

Reservationen de själva gör är att gränssnitt och standardvärden kan skilja sig mellan upplevelserna, och att man jämför genom att testa i Förhandsgranska. Kunskap är alltså det byggblock som ändrats minst.

Det är inte en enda semantisk sökning

Här finns en missuppfattning värd att röja ur vägen, för den styr vad man tror sig kunna fråga om. RAG i Copilot Studio är en pipeline, men själva hämtningen är inte en och samma vektorsökning över allt du kopplat in. Varje källtyp har sin egen sökväg, och Microsoft beskriver dem olika:

Semantisk sökning finns alltså, men som en av flera mekanismer och delvis som ett tillval. Det finns nämligen en inställning som heter tenant graph grounding med semantisk sökning. Slår du på den får agenten söka i samma semantiska index som Microsoft 365 Copilot använder, vilket ger bättre träffar framför allt i SharePoint. Den kräver att någon i organisationen har en Microsoft 365 Copilot-licens, och den kostar extra credits.

Två siffror är värda att känna till. Innan sökningen skrivs frågan om, med hjälp av de tio senaste turerna i samtalet. Sedan hämtas de tre bästa träffarna från varje källa. Det agenten får se är alltså korta utdrag, inte hela dokumenten.

Viktigare är dock vad RAG är till för, eftersom förväntningarna ofta hamnar fel.

Och det är här den nya harnessen skiljer sig mest praktiskt. I gamla Copilot Studio var kunskapshämtningen i princip enda vägen till företagsdatan, så frågor som inte passade i den formen gick inte att ställa. Den nya agenten kan i stället gå till filerna, öppna ett helt dokument när utdraget inte räcker, öppna flera dokument när frågan spänner över dem, och köra kod när något ska räknas. Microsofts egen jämförelsetabell skriver ut skillnaden i raden om filer:

“Skapar, redigerar och resonerar över Word-, Excel-, PowerPoint- och PDF-filer.”

Källa: Välj en harness

Samma rad för standardharnessen lyder “Inte ett fokus”.

Det gör den betydligt bättre på att arbeta med företagsdata.

Ett exempel: frågan RAG inte kan svara på ensam

Vi laddade upp en produktkatalog som kunskapskälla, en PDF på 36 sidor med HAY:s belysningssortiment, och ställde en fråga som kräver att man går igenom hela underlaget: vilken är den dyraste lampan designad av Naoto Fukasawa, och vad kostar den?

Det är precis en sådan fråga som inte kan besvaras av tre utdrag. Rätt svar kräver att alla Fukasawa-lampor i katalogen hittas och att priserna jämförs. Aktivitetsspårningen visar hur agenten löste det, i fyra steg.

Agenten började inte med att söka, utan med att ladda en skill. search-before-answer är en av de inbyggda skillsen i harnessen, och dess beskrivning inleds med REQUIRED FIRST: den ska köras innan agenten besvarar något som skulle kunna finnas i en ansluten källa.

Sedan söktes kunskapskällan, och sökverktyget säger själv ifrån om sina begränsningar. I dess egen beskrivning står att träffar från dokument är partiella utdrag, och att agenten ska hämta hela dokumentet när svaret kräver fullständiga data, exempelvis vid beräkningar, summeringar, kompletta listningar eller analys över flera dokument.

Därefter händer det som är hela poängen. Sökresultatet innehåller en enda träff, och till den hör raden “File downloaded to sandbox: HAY-Lighting.pdf” med uppmaningen att öppna filen med lämplig skill eller verktyg. Katalogen ligger nu på agentens arbetsyta, inte som utdrag utan som fil.

Till sist laddas ytterligare en inbyggd skill, analyzing-pdf, som förbehandlar dokumentet till sökbara artefakter och går igenom produktsidorna innan agenten svarar.

Två byggblock samarbetade alltså. Kunskapen hittade dokumentet, och skillsen bestämde arbetssättet: sök först, hämta hela filen när utdraget inte räcker, förbehandla, verifiera. Skillsen som gjorde jobbet här är av samma sort som du själv kan skriva, vilket för oss vidare till nästa byggblock.

Skills

En skill är en återanvändbar, uppgiftsspecifik förmåga. Verktyg låter agenten hämta data eller utföra handlingar, både i den egna miljön och i externa tjänster. En skill beskriver i stället ett arbetssätt genom instruktioner, logik och eventuella tillhörande resurser som du kan dela och återanvända mellan agenter.

Det som en skill egentligen fångar är erfarenhet. En språkmodell kan oerhört mycket allmänt, men nästan ingenting om hur just er organisation gör saker, eftersom den kunskapen sällan finns nedskriven. Den sprids muntligt eller genom trial and error, och är därför i praktiken omöjlig att träna in. Den öppna standarden bakom skills säger samma sak om vad en bra skill ska bygga på:

“Effective skills are grounded in real expertise.”

Källa: Best practices for skill creators

Ber du i stället ChatGPT eller en agent att skriva skillen åt dig, utan att mata in ditt eget underlag, blir den sällan bra. Den har bara sin allmänna kunskap att utgå från, och då blir råden vaga: “handle errors appropriately”.

I praktiken betyder det att en erfaren person beskriver sitt tillvägagångssätt: stegen som fungerar, korrigeringarna hen brukar göra, formaten in och ut, och de projektspecifika förutsättningar agenten omöjligt kan känna till. Sedan kopplar man in verktygen som krävs för att faktiskt utföra det. Därför är skills värda att lära sig hantera nu. Det är den mest direkta vägen att få in arbetslivserfarenhet i ett AI-system.

Den bästa beskrivningen av var skills hör hemma bland de andra byggblocken kommer från Microsofts Customer Advisory Team:

“Knowledge gives the agent facts, tools give it reach, and a Skill gives it the situational know-how to use both well. And crucially, a Skill guides the agent, it does not straitjacket it.”

Källa: Roel Schenk, Agents Have Skills Now

Formatet är enkelt med flit: YAML front matter med namn och beskrivning, plus instruktioner i Markdown. Det gör dem portabla, och de kan skrivas i vilken textredigerare som helst och laddas upp.

En skill kan också laddas upp som en zip-fil, och då får den ta med sig filer utöver själva instruktionen. Skript är körbar kod som följer med skillen: instruktionstexten förklarar när och varför något ska göras, och skriptet gör själva jobbet. Agenten läser instruktionen, kör skriptet och fortsätter i skillen, i stället för att skriva samma kod på nytt varje gång. Referensfiler är material som bara laddas när det behövs, exempelvis en schemabeskrivning eller en felkodslista, och assets är mallar och andra statiska resurser. Poängen med uppdelningen är kontext: namn och beskrivning ligger alltid framme, instruktionerna laddas när skillen aktiveras, och resten hämtas först när agenten faktiskt behöver det.

Instruktion eller skill? Regeln är enkel. Gäller det i varje konversation, för varje scenario, hör det hemma i agentens instruktioner. Ton, roll och alltid gällande skyddsräcken är giltiga hundra procent av tiden och bör ligga i kontexten. Gäller det bara specifika scenarier ska det vara en skill.

Ett vanligt läge när man börjar arbeta med skills är alltså att instruktionerna behöver brytas ned. Det ger fyra fördelar, varav de två första gäller nästan alltid:

Skriv inte in sådant modellen redan kan. En skill ska tillföra det agenten inte hade klarat själv, alltså era konventioner, era undantagsfall och de verktyg som ska användas. Den behöver inte förklara vad en PDF är eller hur en for-loop fungerar. Standarden bakom skills föreslår ett enkelt test innan du skriver in något: skulle agenten göra fel utan den här meningen? Är svaret nej ska meningen bort, eftersom varje rad i skillen konkurrerar om utrymmet i kontexten när den laddas. Undantaget är när ni gör den generella saken på ett eget sätt, för då är just avvikelsen värd att skriva ner.

Skill eller ny agent? Instinkten före skills var att bygga en ny specialiserad agent per uppgift. Enklaste tumregeln är att hålla sig inom området: har du en HR-agent bygger du fem HR-skills i den, inte fem små HR-agenter under den. En ekonomiskill hör däremot inte hemma i HR-agenten, utan då bygger du en separat ekonomiagent med sina egna ekonomiskills. Det som avgör är alltså om förmågan skulle stå på egna ben, med en annan målgrupp bakom en annan säkerhetsgräns. Det finns ett skäl till: när en enda agent fått för många verktyg börjar träffsäkerheten degradera, och då hjälper inte fler skills utan då ska arbetet delas upp.

Namnet ska vara specifikt, beskrivningen avgör. HR Leave Eligibility Triage säger något, HR Help gör det inte. Men det är beskrivningen orkestratorn faktiskt matchar mot när den avgör om skillen ska kallas in, så det är där arbetet ligger. En bra beskrivning säger både vad som ingår och vad som inte gör det, exempelvis att den gäller ledighetsregler och underlag men inte löner. Kallas skillen in för ofta är beskrivningen för bred, kallas den aldrig är den för smal eller använder inte de ord användarna faktiskt skriver.

En skill är en trust surface. Eftersom den formar agentens beteende och kan bunta skript ska varje skill du inte skrivit själv behandlas som otillförlitlig kod. Granska den innan du lägger till den, och leta specifikt efter prompt injection, instruktioner att missbruka verktyg, och sådant som inte matchar vad den utger sig för att göra.

Harnessen kommer dessutom med åtta inbyggda skills. De är det bästa konkreta exemplet på hur en välskriven skill ser ut, och de gås igenom i motorn inifrån.

Verktyg

Verktygen är det som låter agenten göra något annat än att svara på frågor, alltså interagera med omvärlden. Microsoft delar in dem i tre typer, och det är värt att notera att workflows räknas som en verktygstyp och inte som något vid sidan av.

Valet mellan dem är inte särskilt subtilt. Finns en färdig connector mot tjänsten använder du den. Är det din egen tjänst bygger du en MCP-server. Ska något hända likadant varje gång är det ett workflow.

För MCP gäller att det primära transportprotokollet är Streamable, att det äldre SSE-stödet fasas ut, och att autentisering kan vara ingen alls, API-nyckel eller OAuth 2.0. Eftersom anslutningarna bygger på Power Platform omfattas åtkomsten av organisationens dataprinciper.

MCP är också den väg som blivit vanligast i praktiken, av två skäl. Många organisationer har redan satt upp egna MCP-servrar mot sina interna system, och en sådan server kopplas in i en agent genom att ange URL, autentisering samt ett namn och en beskrivning som agenten ser. Vill du bygga en ny finns Microsofts guide, och anslutningsflödet i nya upplevelsen beskriver stegen för att lägga till en befintlig. Täckningen mot Microsofts egna tjänster är dessutom god: den mest använda servern i sammanhanget är Work IQ, som ligger under samlingsnamnet Microsoft IQ och ger agenten arbetskontext, affärsdata och appsignaler från Microsoft 365. Den har en egen genomgång.

Ett råd som är lätt att hoppa över: kontrollera namn och beskrivning på varje verktyg servern exponerar innan du förlitar dig på den. Saknar ett verktyg tydlig beskrivning blir svaren som involverar det mindre pålitliga, och då är rätt åtgärd att be den som byggt servern skriva om beskrivningen.

En gräns är värd att notera: MCP-servrar räknas mot det totala antalet verktyg agenten kan hosta, och antalet servrar som kan köras samtidigt i en konversation är begränsat. Håll antalet litet och ta bort det du inte använder.

Workflows: den deterministiska verktygstypen

Workflows är den tredje verktygstypen och samtidigt en egen designyta, driven av samma harness. Ett flöde består av en trigger och minst en åtgärd. Triggern kan köras manuellt, enligt schema eller av en händelse, vilket också är svaret på hur en agent kan startas utan att en människa skriver något.

Åtgärderna kommer i fyra typer: AI-funktioner som kan generera text, bearbeta dokument, köra en prompt mot en modell och anropa en agent, mänsklig medverkan för steg som kräver att någon ingriper, inbyggda verktyg för loopar, förgreningar, dataoperationer, datum- och tidsfunktioner samt underordnade flöden, och anslutningsappar mot Microsoft 365, tredjepartstjänster och egna connectors.

Kopplingen tillbaka till agenten går genom en särskild trigger. Ett flöde som använder When an agent calls the flow kan läggas till som verktyg i en agent, vilket gör relationen tvåvägs: agenter kan köra flöden och flöden kan anropa agenter. Mänsklig medverkan är dessutom den enda uttryckliga mekanismen för human-in-the-loop i hela materialet, vilket gör den central om du behöver godkännandesteg.

Kostnadsmässigt beter sig flöden annorlunda än agenter. Varje åtgärd ett flöde kör förbrukar kapacitet, och tar den prepaid-kapaciteten slut blockeras nya flödeskörningar medan pågående får köra klart. Men att testa ett flöde, både i designern och från agentens testchatt, förbrukar ingenting.

Filer agenten skapar

Att agenten skapar filer är inget du slår på eller konfigurerar. Behöver den skriva en fil för att slutföra en uppgift gör den det och bifogar den i svaret.

Användaren får ett filkort under meddelandet med filnamn, förhandsvisning och en nedladdningsknapp, och korten renderas i alla kanaler med respektive kanals eget filgränssnitt. Filen lever kvar i konversationen, så användaren kan säga gör diagrammet högre eller översätt det här till franska och få en uppdaterad version.

Två siffror gäller här. Filerna är begränsade till 10 MB per fil, och en fil som överskrider gränsen returneras inte alls även om agenten arbetar vidare. Be den i så fall dela upp resultatet i flera filer. Och filerna finns kvar i 28 dagar efter senaste aktiviteten i konversationen, samma siffra som för minne.

Minne

Varje användares minne ligger i en dedikerad mapp i Microsoft-hanterad lagring. Agenten fångar signaler under samtalet, sparar dem som filer och tillämpar dem vid senare interaktioner.

Minne är alltså ett reglage längst ned i komponentpanelen, och det är fortfarande märkt som förhandsversion.

Reglerna runt det är ovanligt strikta, på ett sätt som är värt att lyfta i en governance-diskussion:

En fallgrop är värd att citera ordagrant, eftersom den lätt läses baklänges:

“Turning Memory off doesn't delete stored memories. It only prevents the agent from using them.”

Källa: Memory (preview)

Att stänga av minnet hindrar alltså bara agenten från att använda det som redan lagrats. Minne är dessutom en preview-funktion, om än beskriven som production-ready preview.

Modell

Modellen är hjärnan som kopplas in i agenten, alltså det som står för resonemanget. Du byter modell i komponentpanelen på Bygg-fliken.

Modellerna i listan kommer som standard i huvudsak från OpenAI, och det är oftast de senaste tillgängliga, även om de ibland ligger en generation efter det som precis släppts. Vid sidan av dem finns modeller från andra leverantörer, som Microsoft kallar externa modeller: Anthropic, Mistral och xAI. Anthropics modeller är allmänt tillgängliga och dyker därför oftast upp direkt i listan, medan Mistral och xAI ligger som experimentella. Gemensamt för alla tre är att en administratör först måste slå på externa modeller för miljön och sedan godkänna varje leverantör för sig.

Olika modeller är byggda för olika saker. En del svarar snabbt och billigt men klarar inte lika svåra uppgifter, andra resonerar längre och löser mer komplexa problem, till priset av högre latens och högre kostnad. Agenten presterar bättre när modellen matchar vad den ska användas till.

Anslutna agenter

En primär agent kan anropa andra agenter under en konversation, och orkestreringen routar förfrågan när den faller inom en ansluten agents domän. Det ger modulära lösningar där varje agent äger en domän, olika team kan äga olika agenter, och nya förmågor läggs till genom att koppla in en agent i stället för att blåsa upp instruktionerna hos en enda.

Tre förutsättningar gäller. Den primära agenten måste vara byggd med GitHub Copilot-harnessen, den anslutna måste vara det också och ligga i samma miljö, publicerad och markerad som tillgänglig. Och du måste antingen äga den anslutna agenten eller ha fått den delad med dig. Just nu går det bara att koppla ihop agenter byggda i Copilot Studio.

Routningen följer samma regel som resten av artikeln: namn och beskrivning. Microsofts råd är kort och pekar på den vanligaste felkällan när flera agenter är inkopplade.

“Write a clear, specific description for each connected agent so the orchestrator can accurately determine when to route requests to it. Avoid overlapping descriptions between connected agents.”

Källa: Add a connected agent to an agent

Vad det kostar

Båda harnessarna betalar med samma valuta. En Copilot Credit kostar $0,01 vid pay as you go, och formeln är rakt av antal credits gånger en cent. Skillnaden ligger i hur de förbrukas.

Två motvikter finns. Manuell konfiguration i Bygg och Övervaka förbrukar inga credits, och att testa ett flöde i flödesdesignern eller från agentens testchatt förbrukar inte kapacitet. Det ger en asymmetri värd att ha med sig: att testa en agent kostar, att testa ett flöde gör det inte.

För den nya harnessen beräknas förbrukningen utifrån mängden agentiskt arbete, och Learn formulerar det utan omsvep:

“Copilot credits are charged for large language model (LLM) tokens, tools (including knowledge and MCPs), and the harness itself. Any experience that uses one of these consumes credits.”

Källa: Overview of usage-based billing

Kunskap och MCP räknas alltså som verktygsanvändning när de faktiskt används. Många anslutna kunskapskällor och MCP-servrar gör därför inte automatiskt varje tur dyrare. Kostnaden beror på vilka resurser agenten använder och hur mycket arbete uppgiften kräver.

Microsofts planeringsestimat per agentisk uppgift:

Siffrorna är uttryckligen illustrativa, och faktisk förbrukning varierar med uppgiftens komplexitet.

Tre sätt att betala. Pay as you go kopplas till en Azure-prenumeration och betalas i efterhand utan åtagande, till $0,01 per credit. Copilot Studio Capacity Pack ger 25 000 credits per månad för $200 i månaden, betalt årsvis. Det motsvarar $0,008 per credit, alltså 20 procent under pay as you go-priset, men outnyttjad kapacitet förs inte över till nästa månad.

För större volymer finns Copilot Credit Pre-Purchase Plan, en ettårig förköpsplan där rabatten växer med volymen:

Två saker är värda att notera i tabellen. Rabatten börjar först vid 300 000 credits, alltså $3 000 i förbrukning, och den blir meningsfull först en bra bit däröver. Och eftersom oanvända credits förfaller vid periodens slut är förköp en fråga om hur säker prognosen är, inte bara om hur stor volymen är.

Den viktigaste licensskillnaden. För standardharnessen ingår kvalificerad användning för interna, autentiserade användare i Microsoft 365 Copilot-licensen, under fair usage. Den nya harnessen får inte samma inkluderade användning. Den kräver Copilot Credits, punkt.

Förbrukningen följs upp per agent på dess Övervaka-sida, och per miljö och tenant i Power Platform admin center. Där allokerar administratörer också credits till miljöer, vilket binder ihop kostnadsstyrning med miljöstrukturen.

Vad som faktiskt skiljer mot den gamla

Microsoft själva sammanfattar skillnaderna så här:

Vad betyder det då? Kort sagt att de är byggda för olika saker.

Standardharnessen ger förutsägbarhet. Du definierar ämnen och banor, orkestreringen går att konfigurera, och du vet ganska exakt vad agenten kommer att göra.

GitHub Copilot harness ger handlingskraft. Agenten tar ett mål och arbetar sig fram till det genom att själv avgöra vilka steg som behövs och hur de ska utföras, inom de ramar du satt upp.

Lyfter man blicken från listan och tittar på några viktiga praktiska skillnader landar det i fyra saker.

Det är enklare att bygga agenter. Tidigare behövde du kunna topics, flöden och en hel del Power Automate för att styra agenten rätt. Nu handlar arbetet mer om att förstå vad agenten ska uppnå, vilken information den behöver för att klara det, och hur den bör gå till väga.

Agenten arbetar bättre med företagets data. Exemplet med produktkatalogen ovan visar varför: den kan gå till dokumentet och läsa hela innehållet i stället för att vara hänvisad till korta utdrag. Den gamla motorn kunde också köra kod och bearbeta filer, men en fil i taget och utan att kunna följa upp på samma fil över flera turer.

Verklig erfarenhet går att bygga in. Med skills kan arbetssätt som i dag bara finns i huvudet på erfarna medarbetare paketeras och återanvändas, och det utan att någon behöver skriva kod.

Kostnaden blir generellt högre. Användningen debiteras som arbete, och notan börjar redan när du bygger.

Sammanfattning

Nya Copilot Studio flyttar arbetet från att rita vägar till att beskriva förutsättningar. Det gör utvecklingen snabbare och agenterna mer kapabla, men det flyttar också kostnaden tidigare och gör harnessvalet svårt att ändra i efterhand.

Tre saker att ta med sig:

• harnessvalet görs när agenten skapas och saknar en officiellt stödd direktmigrering, så ett byte kräver normalt ombyggnad
• skills är rätt enhet när något gäller specifika scenarier, instruktioner när det gäller alla
• faktureringen börjar när du börjar bygga, och kunskap och MCP räknas som verktyg och kostar

Vill du gå djupare finns motorn inifrån om harnessen, sandlådan och de inbyggda verktygen, och Work IQ MCP om den vanligaste anslutningen mot Microsoft 365. För grunderna finns AI-agenter och agentiska system och AI-automation och workflows.

---

Om underlaget. Uppgifterna kommer från Microsoft Learn, Copilot Credits Guide från augusti 2026 och Copilot Studio Licensing Guide från samma månad. Avsnittet om skills bygger dessutom på Agents Have Skills Now av Roel Schenk på Microsofts Customer Advisory Team, som är den utförligaste genomgången av när något bör vara en skill och när det inte bör det. Nya Copilot Studio utvecklas snabbt och flera av funktionerna ovan är förhandsversioner, så kontrollera siffror och gränser mot aktuell dokumentation innan de används som beslutsunderlag.