Agenter är alltid nyanställda från dag ett. Det är dags att vi designar för det.

År 2027, 74% av företagen förväntas använda agenter i någon form, enligt en färsk Deloitte‑undersökning. I flera år har vi designat och byggt mjukvara för att förbättra den mänskliga upplevelsen av att navigera våra appar, webbplatser, operativsystem och dokument. Nu är användaren inte en människa alls. Detta har bredare implikationer än bara att gå från instrumentpaneler till de kontrollerade arbetsflöden vi designar för mänskliga uppgifter. Vi befinner oss i ett skede där vi måste designa agenters driftsmiljöer, samtidigt som vi också designar mänskliga arbetsflöden för att effektivt styra agentupplevelsen inom dessa miljöer.  

Vi är fortfarande i ett tidigt skede i vår förståelse av vad agenter faktiskt behöver från oss för att vara upprepade och pålitligt framgångsrika. Instinkten är att betrakta agentintegration enbart som ett prompt‑ eller UI‑problem. Att designa en välstyrd exekveringsmiljö är nytt territorium för oss som kultur. Men de grundläggande principerna för god design och god ledning har inte förändrats: vi är skyldiga agenter tydlig kontext, entydig riktning och explicit avsikt.

Kontext: Varför kodning kom först

Kontext är sannolikt den viktigaste faktorn om vi vill att agenter ska leverera konsekvent på den nivå vi avser. Mjukvaruutveckling har mer av det dokumenterat än nästan något annat område: kodförråd, API‑scheman, relationerna mellan system, kodgranskning och gemenskapsdiskussioner. Det är därför logiskt att AI‑frontlabbar började med kodning. Det är ett av de få områden där en hel del kontext redan är nedskriven. 

Men som varje nyanställd i ett mjukvaruteam kan bekräfta, så saknar agenter även med all den datan den institutionella minnet som är inbäddat i de oskrivna reglerna som ingen någonsin dokumenterat. Det här gapet är utbrett: 43% av utvecklare är oroade över att AI‑verktyg saknar tillräcklig kontext kring deras specifika projekt eller kodbas. Tyst kunskap omfattar allt från vardagliga konventioner, såsom föredragna bibliotek för specifika uppgifter, till kritiska operativa spöken: en sen natt‑snabbfix som hänger kvar för alltid, eller en till synes tom databas‑kolumn som i hemlighet stödjer en skräddarsydd intäktsrapport. Denna kontext lever i en senioringenjörs huvud, i en nyligen Slack‑tråd, eller ingenstans. Den finns sällan i själva kodbasen.  

Om detta är sant inom mjukvara, ett av de mest dokumenterade områdena, är det lätt att förstå varför agenter har svårt att prestera effektivt från dag ett i många andra branscher. Inom sjukvård och juridik är mycket av den institutionella kunskapen som formar det dagliga arbetet inlärd och internaliserad. Den lever i människors erfarenhet snarare än i formell dokumentation. En juridisk agent kanske inte känner till en viss partners föredragna struktur, ton eller argumentation för ett ärende, medan en sjukvårdsagent kanske inte förstår de lokala arbetsflödena och eskaleringsrutinerna som en upptagen klinik använder för att stödja kliniker‑ledd triage. Endast dokumentation kan inte överbrygga detta gap, eftersom utmaningen inte bara handlar om tillgång till information; det handlar om överföringen av kontext. För att ge agenter det de behöver för att lyckas måste vi introducera dem på samma sätt som vi skulle göra med en nyanställd.

Riktning: Varför osmos inte fungerar

Att introducera en ny lagkamrat kräver mer än att bara tillhandahålla rätt material och åtkomst. När vi är engagerade i våra kollegors framgång ger vi tydlig vägledning om hur man använder det nya materialet och åtkomsten: förväntningar, klarhet i vad vi försöker uppnå och återkoppling längs vägen. Jag använder samma tankesätt när jag designar för agenter. Jag ger klar, specifik riktning (i förhållande till den aktuella uppgiften). Det gäller för varje lagkamrat, oavsett hur länge de har varit med. Ändå, i ett nyanställningsscenario måste riktningen gå längre, eftersom de ännu inte har någon institutionell kontext.

Tänk på en agent som en nyanställd som aldrig slutar vara ny. Den är ivrig och kapabel (och ärligt talat har den gränslös energi), men den kan inte samla in och behålla lika många av de oskrivna reglerna som en människa gör med tiden. Människor lär sig genom osmos och erfarenhet, medan agenter lär sig från en arkitektur som uttryckligen byggts in i deras arbetsmiljö.

Med en nyanställd kan du med tiden överbrygga detta gap genom frågor, återkoppling och ny insikt de får om organisationens processer och preferenser längs vägen. Bokstavliga samtal vid kaffemaskinen eller teamluncher. Med en agent måste du bygga den gap‑överbryggningen i själva designen. Detta kan inkludera: 

• Ge agenten ett strukturerat kontextfönster som separerar beständiga regler, uppgiftsspecifika fakta och relevant historik, snarare än att slänga en hög dokument på den. 
• Definiera dess behörigheter och beslutsgränser i förväg: vad den får göra självständigt, vad som kräver godkännande, och vad den aldrig får komma åt. 
• Inbädda några konkreta exempel på starkt resultat direkt i upplevelsen, så att agenten har en tydlig modell för hur arbetet ska utföras.
• Dela tidigare återvändsgränder som du har stött på.

Att designa en välstyrd agentmiljö handlar inte om att göra arbetet enklare för modellen. Det handlar om att skydda det mänskliga ingenjörsteamet från osynlig teknisk skuld. Men även en välstyrd agent kan följa instruktioner perfekt och ändå missa poängen. Riktning talar om vad den ska göra, men den visar inte hur ”bra” ser ut. Det där gapet är där avsikt kommer in.

Avsikt: Varför agenter driver mot mitten

Det är viktigt att komma ihåg att agenter är mönstermatchande maskiner, tränade på enorma mängder kunskap och naturligt benägna att leverera det statistiska genomsnittet. Utan tydlig, explicit avsikt blir just det genomsnittliga resultatet vad en agent levererar. Be en agent att ”lägga till en användarautentiserings‑endpoint”, så genererar den en klassisk Express‑rutt med grundläggande lösenordshashning. Det fungerar, men det ignorerar helt ditt teams anpassade autentiseringstjänst, hoppar över nödvändig telemetri och förstör er standardiserade felformatering. Det är en tillräcklig funktion på papper, men beroende på kontexten blir det i praktiken en arkitekturell bugg. Hur enkelt sådana ”buggar” kan introduceras kan inte överskattas.

För att förhindra detta måste riktning kombineras med aktiv avsiktsverifiering och loggning. Säkerhetsgrindar bör inte bara kontrollera om koden kompilerar, även om det är viktigt. Säkerhetsgrindar måste uttryckligen upprätthålla de föredragna standarderna, kantfallsreglerna och domänkontexten som lyfter generiskt resultat till produktionsklar kod. Loggning är viktigt som ett systemstatusindikator för oss människor. Denna spårbarhet är avgörande för förtroende. 

I mänskliga interaktioner finns det mycket utrymme för osäkerhet. Någon kan dela en första version med dig, och tillsammans kan ni diskutera vad som är starkt och vad som behöver förbättras. Det fungerar eftersom vi inte förväntar oss att våra mänskliga medarbetare ska vara autonoma maskiner. För att verkligen fånga kraften och löftet med agentbaserade medarbetare (som vi faktiskt behöver köra mer autonomt…) kan vi konstruera många av dessa riktningskontroller. Tillbakagången måste fortfarande ske, men den kan inte helt förlita sig på manuellt arbete. Genom att i förväg lägga in tydliga acceptanskriterier och verifieringsregler gör du det möjligt för agenten att köra sina egna interna återkopplingsslingor. Designa för felprevention är en annan sund UX‑princip vi kan tillämpa i denna nya värld: att ge agenter förmågan att flagga låg förtroendegrad innan de genomför en handling, snarare än att tyst falla tillbaka på en bästa gissning.

Där metaforen bryter

Ramverket med nyanställning fungerar, tills det inte gör det. Med en mänsklig anställning leder erfarenhet till kompetens som i sin tur leder till omdöme. Att se din nyanställda internalisera “varför” bakom kontext och riktning är vad som bygger förtroende över tid, och i allmänhet är detta kumulativt. En agent har ingen plats att samla och lagra denna erfarenhet.

En nyanställds första vecka och hundrade vecka ser olika ut. En agents första uppgift och tusende ser identiska ut, om du inte designar och bygger något som gör dem olika. Detta är vår nya designutmaning.

Agentansvar hänger på design

Om ansvar inte kan finnas i agenten måste det finnas i den stödstruktur som omger den. Det handlar om samma tre frågor jag skulle ställa innan jag ger arbete till någon nyanställd: Vilken kontext har de? Vilken riktning har jag gett dem? Vad är min egentliga avsikt?

Nästa gång du ger en agent en uppgift, kontrollera inte bara resultatet. Kontrollera först dina egna indata. Gav du den den kontext en nyanställd skulle behöva på dag ett? Var din riktning tillräckligt specifik för att klara av att tas bokstavligt? Var din avsikt tydlig nog så att ”det genomsnittliga svaret” inte var det bästa den kunde göra?

Med denna tydliga vägledning i handen (i byte?), händer något intressant: en agent behöver ingen lång inkörningsperiod för att bli pålitlig. Den kontext, riktning och verifiering du bygger in i förväg definierar hur den arbetar med varje uppgift. En nyanställd förtjänar ditt förtroende över tid; en agent måste förtjäna det varje gång genom det system du designat. Ansvar är inte något den utvecklar, utan det är inbyggt från början. Frågan är inte när din agent kommer att vara redo för mer ansvar. Det är om du designade den för att förtjäna det ansvaret på varje enskild uppgift.