Agenter er altid ansættelser fra dag ét. Det er på tide, vi designer til det.

I 2027 forventes 74% af virksomhederne at bruge agenter i en eller anden grad, ifølge en nylig Deloitte‑undersøgelse. I årevis har vi designet og bygget software for at forbedre den menneskelige oplevelse af at navigere i vores apps, hjemmesider, operativsystemer og dokumenter. Nu er brugeren slet ikke et menneske. Dette har bredere implikationer end blot at skifte fra instrumentbrætter og de kontrollerede arbejdsgange, vi designer til menneskelige opgaver. Vi befinder os i et øjeblik, hvor vi skal designe agenters driftsmiljøer, mens også designer menneskelige arbejdsgange for effektivt at guide agentoplevelsen inden for disse miljøer.  

Vi er stadig tidligt i vores læring om, hvad agenter faktisk har brug for fra os for at kunne levere gentageligt og pålideligt. Instinktet er at behandle agentintegration som et rent prompt‑ eller UI‑problem. At designe et velstyret udførelsesmiljø er nyt terræn for os som kultur. Men de underliggende principper for god design og god ledelse har ikke ændret sig: vi skylder agenter klar kontekst, entydig retning og eksplicit intention.

Kontekst: Hvorfor kodning kom først

Kontekst er uden tvivl den vigtigste input, hvis vi vil have agenter til gentageligt at levere på det niveau, vi ønsker. Softwareudvikling har mere af det registreret end næsten noget andet område: repos, API‑skemaer, relationerne mellem systemer, kodegennemgang og fællesskabsdiskussioner. Så det giver mening, at AI‑frontier‑laboratorier startede med kodning. Det er et af de få domæner, hvor en god del kontekst allerede er skrevet ned. 

Men som enhver nyansat i et softwareteam vil fortælle dig, vil agenter selv med al den data stadig mangle den institutionelle hukommelse, der er indlejret i de uskrevne regler, som ingen nogensinde har dokumenteret. Det hul er udbredt: 43 % af udviklere er bekymrede for, at AI‑værktøjer mangler tilstrækkelig kontekst om deres specifikke projekt eller kodebase. Tavs viden spænder fra daglige konventioner, som foretrukne biblioteker til specifikke opgaver, til højtstående operationelle spøgelser: en sen nat‑hotfix, der hænger ved for evigt, eller en tilsyneladende tom databasekolonne, der i hemmelighed understøtter en specialtilpasset indtægtsrapport. Denne kontekst lever i en senioringeniørs hoved, en nylig Slack‑tråd, eller ingen steder overhovedet. Den findes sjældent i selve kodebasen.  

Hvis dette er sandt i software, et af de bedst dokumenterede felter, er det let at se, hvorfor agenter har svært ved at præstere effektivt fra dag ét i mange andre brancher. I sundhedssektoren og i jura er meget af den institutionelle viden, der former det daglige arbejde, lært og internaliseret. Den lever i folks erfaring snarere end i formel dokumentation. En juridisk agent ved måske ikke en bestemt partners foretrukne struktur, tone eller argumentation for et notat, mens en sundheds‑agent måske ikke forstår de lokale arbejdsgange og eskaleringspraksisser, som en travl klinik bruger til at understøtte kliniker‑ledet triage. Dokumentation alene kan ikke lukke dette hul, fordi udfordringen ikke kun er adgang til information; det er overførslen af kontekst. For at give agenter, hvad de behøver for at lykkes, må vi onboarde dem, som vi ville gøre med en nyansat.

Retning: Hvorfor Osmose ikke virker

Onboarding af en ny holdkammerat kræver mere end blot at levere de rette materialer og adgang. Når vi er investeret i succesen for dem omkring os, giver vi solid retning om, hvad der skal gøres med de nye materialer og den nye adgang: forventninger, klarhed over, hvad vi forsøger at opnå, og feedback undervejs. Jeg anvender den samme tankegang, når jeg designer for agenter. Jeg giver klar, specifik retning (i forhold til den aktuelle opgave). Det gælder for enhver holdkammerat, uanset anciennitet. Alligevel, i et nyansat‑scenario, skal retningen gå længere, fordi de endnu ikke har nogen institutionel kontekst.

Tænk på en agent som en nyansat, der aldrig holder op med at være ny. Den er ivrig og kapabel (og ærligt talt har den ubegrænset energi), men den kan ikke indsamle og fastholde så mange af de uskrevne regler, som et menneske gør over tid. Mennesker lærer gennem osmose og erfaring, mens agenter lærer fra en arkitektur, der er eksplicit bygget ind i deres arbejdsmiljø.

Med en nyansat kan du lukke det hul over tid med spørgsmål, feedback og nye indsigter, de opfanger om organisationens processer og præferencer undervejs. Bogstavelige kaffemaskine‑snakke eller team‑frokoster. Med en agent skal du bygge den hullerensluttende ind i selve designet. Dette kan inkludere: 

• At give agenten et struktureret kontekstvindue, der adskiller holdbare regler, opgavespecifikke fakta og relevant historik, i stedet for at smide en bunke dokumenter i dens skød. 
• At definere dens tilladelser og beslutningsgrænser på forhånd: hvad den må gøre selvstændigt, hvad der kræver godkendelse, og hvad den aldrig må tilgå. 
• At indlejre et par konkrete eksempler på stærkt output direkte i oplevelsen, så agenten har en klar model for, hvordan arbejdet skal udføres.
• At dele tidligere blindgyder, du har stødt på.

At designe et velstyret agentmiljø handler ikke om at gøre arbejdet lettere for modellen. Det handler om at beskytte det menneskelige ingeniørteam mod usynlig teknisk gæld. Men selv en velrettet agent kan følge instruktioner perfekt og stadig misforstå pointen. Retning fortæller den, hvad den skal gøre, men den fortæller den ikke, hvordan “godt” ser ud. Det hul er, hvor intentionen kommer ind.

Intention: Hvorfor agenter driver mod midten

Det er vigtigt at huske, at agenter er mønster‑matchende maskiner, trænet på massive mængder viden og naturligt tilbøjelige til at levere det statistiske gennemsnit. Uden klar, eksplicit intention er dette gennemsnitsoutput præcis, hvad en agent vil levere tilbage. Bed en agent om at “tilføje et bruger‑autentificerings‑endpoint”, så vil den generere en lærebogs‑Express‑rute med grundlæggende password‑hashing. Det virker, men den ignorerer fuldstændigt dit teams tilpassede auth‑service, springer over nødvendig telemetri og ødelægger din standardiserede fejlformattering. Det er en acceptabel funktion på papiret, men afhængig af konteksten er det en arkitektonisk fejl i praksis. Hvor let “fejl” som denne kan introduceres, kan ikke overdrives.

For at forhindre dette skal retning kombineres med aktiv verifikation af intention og logning. Guardrails bør ikke kun tjekke, om koden kompilerer, selvom det er vigtigt. Guardrails skal eksplicit håndhæve de opinionerede standarder, kant‑case‑regler og domænekontekst, der løfter generisk output til produktionsklar kode. Logning er vigtigt som en systemstatusindikator for os mennesker. Denne sporbarhed er kritisk for tillid. 

I menneskelige interaktioner er der meget plads til usikkerhed. En kan dele en første version med dig, og sammen kan I tale igennem, hvad der er stærkt, og hvad der skal forbedres. Dette fungerer, fordi vi ikke forventer, at vores menneskelige kolleger er autonome maskiner. For virkelig at indfange kraften og løftet ved agent‑kolleger (som vi har brug for at køre mere autonomt…), kan vi konstruere mange af disse retnings‑tjek. Tilbage‑ og‑frem‑dialogen skal stadig foregå, men den kan ikke falde fuldstændigt på manuelt arbejde. Ved at forudindlægge klare acceptkriterier og verifikationsregler giver du agenten mulighed for at køre sine egne interne feedback‑loops. Design for fejlforebyggelse er et andet solidt UX‑princip, vi kan anvende i denne nye verden: give agenter evnen til at flagge lav selvtillid, før de forpligter sig til en handling, i stedet for tavst at falde tilbage på et bedste gæt.

Hvor metaforen bryder sammen

Den nye‑ansatte‑ramme fungerer, indtil den ikke gør. Med en menneskelig ansættelse fører erfaring til kompetence, som fører til dømmekraft. At se din nyeansatte internalisere “hvorfor” bag kontekst og retning er, hvad der opbygger tillid over tid, og generelt er dette kumulativt. En agent har ingen steder at akkumulere og gemme denne erfaring.

En nyansattes første uge og hundrede‑te uge ser forskellige ud. En agents første opgave og tusinde‑te ser identiske ud, medmindre du designer og bygger noget, der gør dem forskellige. Dette er vores nye designudfordring.

Agentansvar afhænger af design

Hvis ansvar ikke kan leve i agenten, må det leve i stilladset omkring den. Det reduceres til de samme tre spørgsmål, jeg ville stille, før jeg overlader arbejde til en nyansat: Hvilken kontekst har de? Hvilken retning har jeg givet dem? Hvad er min faktiske intention?

Næste gang du overlader en opgave til en agent, så tjek ikke kun outputtet. Tjek dine egne input først. Gav du den den kontekst, en nyansat ville have brug for fra dag ét? Var din retning specifik nok til at overleve en bogstavelig fortolkning? Var din intention klar nok til, at “median‑svaret” ikke var det bedste, den kunne levere?

Med denne klare vejledning i hånden (i byte?), sker der noget interessant: en agent behøver ikke en lang landingsbane for at blive pålidelig. Den kontekst, retning og verifikation, du bygger ind på forhånd, definerer, hvordan den opererer på hver opgave. En nyansat opnår din tillid over tid; en agent skal opnå den hver gang gennem det system, du har designet. Ansvar er ikke noget, den vokser ind i, det er indbygget fra starten. Spørgsmålet er ikke, hvornår din agent vil være klar til mere ansvar. Det er, om du har designet den til at opnå det ansvar på hver eneste opgave.