Agentisk AI: när hjälper en agent på riktigt?

Vad menas med agentisk AI?

En agent kan själv välja nästa steg inom de gränser vi sätter: söka, använda ett verktyg, kontrollera sitt arbete eller lämna över till en människa. Det är skillnaden mot ett vanligt modellanrop med fasta steg. Varje nytt val agenten får göra ger oss också ett nytt fel att kunna upptäcka.

När är det rätt verktyg?

Jag skulle börja med en agent om uppgiften kräver flera beslut, underlaget varierar och resultatet går att granska. Om en sökning eller ett vanligt program redan löser uppgiften finns ingen anledning att lägga en agent ovanpå. En demo räcker inte som bevis; jämför med det ni gör i dag.

• Finns ett konkret resultat som går att bedöma?
• Kan verktygsåtkomst begränsas till det som uppgiften kräver?
• Går fel att upptäcka, stoppa och återställa?

När behövs subagenter?

Starkare modeller kan ofta planera, använda verktyg och ompröva sitt arbete i en och samma arbetsgång. Anthropic pekar särskilt på utvecklingen sedan Opus 4.5. I flera tillämpningar har deras team fått bättre resultat när huvudagenten behåller sammanhanget och hämtar instruktioner och verktyg först när de behövs. Överlämningar till subagenter kan ta tid och tappa detaljer. Rådet bygger på deras mätningar och behöver prövas i varje nytt system.

I den arkitektur Anthropic föreslår kan huvudagenten själv lägga upp arbetet och ändra planen när den får nya resultat. En tidigare subagent kan bli en instruktion för hur arbetet ska göras eller ett verktyg för att hämta data och utföra en åtgärd. Instruktionerna behöver inte ligga i agentens kontext hela tiden. Däremot ska gränser för kostnad, antal steg och skrivåtkomst ligga kvar i harness och verktyg, där modellen inte kan kringgå dem.

Jag skulle behålla en subagent när en avgränsad uppgift kan göras parallellt eller granskas fristående, när huvudagentens växande kontext faktiskt försämrar resultatet eller när motstridiga instruktioner och verktyg är svåra att hantera tillsammans. I andra fall kan tydliga instruktioner och verktyg i huvudagenten vara enklare. Avgörandet kräver samma uppgifter, samma kvalitetskrav och en jämförelse av resultat, tid och kostnad.

Ge agenten rätt sammanhang

I juli 2026 berättade Anthropic att de tog bort över 80 % av Claude Codes systemprompt för sina Claude 5-modeller utan mätbar försämring i sina kodtester. Regler och exempel som hjälpte äldre modeller kunde begränsa de nyare. Det betyder inte att en kort prompt alltid är bäst. Det betyder att varje instruktion bör ha ett syfte, och att modellbyten kräver nya tester av hela arbetsgången.

Jag skulle hålla grundinstruktionerna korta, lägga projektspecifika fallgropar där agenten kan hitta dem och låta verktygen visa relevant information när den behövs. Det är också en rimlig riktning för ctx: ge agenten just de kodsamband uppgiften kräver, i stället för att lägga en stor graf i kontexten från början.

Mät och förbättra med MLOps

Välj en återkommande uppgift och mät hur den löses utan agent. Ge sedan agenten de verktyg den behöver och pröva den på samma fall. I mina tester av ctx på 36 koduppgifter löste samma modell 28 % med min första harness och 51 % med pi utan tillägg. Hur agenten får arbeta kan alltså spela större roll än vilket extra verktyg vi ger den.

Här hjälper MLOps som arbetssätt. Versionshantera modell, prompt, verktyg och harness tillsammans. Spara körningarnas indata, verktygsanrop, resultat, tidsåtgång och kostnad. Bygg en liten testmängd med kända fall och kör om den när något ändras. Följ sedan upp verkliga körningar: vilka uppgifter misslyckas, vad behöver människor rätta och vilka nya fel ska bli tester? Då går det att se om en ny modell, en subagent eller en ändrad instruktion faktiskt förbättrar helheten.

Låt tester stoppa en ändring som försämrar resultatet och låt en människa godkänna åtgärder som är svåra att ångra. Då blir återkopplingen en del av systemet och fångar problemen tidigare.

Anthropic betonar också att testfallen måste likna verkliga uppgifter. Behåll en del fall som ni inte använder när ni justerar promptar och verktyg. Om resultatet stiger på fallen ni justerar mot men står stilla på de undanhållna fallen har ni troligen anpassat systemet till testet, inte till arbetet. Kontrollera även att den som bedömer svaren själv bedömer rätt; annars optimerar ni mot fel mått.

Exempel: en agent i en kodbas

En kodagent måste hitta rätt filer, förstå vad som redan finns, göra ändringen och visa att den håller. Jag byggde ctx för att ge agenten en sökbar modell av kodbasen när den inte själv hittar sambanden. Tanken var särskilt att hjälpa mindre kapabla agenter med orienteringen, så att de inte behöver läsa stora mängder kod eller skriva om något som redan finns.

Opus 4.6 är ett exempel på en tidigare modellgeneration där jag skulle vilja pröva om sådan hjälp behövs. Jag har däremot inte testat ctx med just Opus 4.6. Mina redovisade agentkörningar använde främst gpt-oss-20b. I dem räckte ett filnamn ibland lika långt som en graf, och pi utan ctx hittade rätt fil nästan lika snabbt. Det visar inte att grafen saknar värde, men det visar att ctx inte gav någon säkerställd förbättring på de uppgifterna.

Med nyare modeller är frågan mer specifik: kan ctx hjälpa när filnamn inte avslöjar var ändringen hör hemma, när en ändring berör flera delar av ett stort repo eller när agenten riskerar att missa befintlig kod som borde återanvändas? En tydlig karta över anrop och beroenden kan då vara värdefull, men det återstår att visa. Jag vill jämföra samma uppgifter med och utan ctx och mäta lösta uppgifter, tidsåtgång, kostnad och hur mycket arbete som blir kvar för granskaren. Mer kontext är bara användbar om den förbättrar något av det.

Läs hur jag testade ctx och vad som inte fungerade.

När agenten får ändra kod

Anthropics Claude Code-team beskrev i oktober 2026 hur de granskar kod när agenter gör fler ändringar än människor hinner läsa rad för rad. Agenten får först köra tester och visa resultatet. Sedan följer automatisk kod- och säkerhetsgranskning, vanliga kontroller i CI och mänskligt godkännande där ändringens risk kräver det. Att agenten säger att arbetet är klart räcker inte som kontroll.

Deras mått är inte bara hur fort en ändring blir godkänd. De följer också återställningar och incidenter, så att mindre tid i granskning inte bara flyttar arbetet till den som måste laga felet senare. För ett eget team skulle jag börja i mindre skala: låt agenten visa testresultat och ändringens risk, kräv granskning för känsliga delar och följ upp fel efter driftsättning.