Agenter er alltid nyansatte fra dag én. Det er på tide at vi designer for det.

Innen 2027, 74% av selskaper forventes å bruke agenter i en eller annen kapasitet, ifølge en nylig Deloitte‑studie. I flere år har vi designet og bygget programvare for å forbedre den menneskelige opplevelsen av å navigere i appene, nettstedene, operativsystemene og dokumentene våre. Nå er brukeren ikke et menneske i det hele tatt. Dette har bredere implikasjoner enn å gå fra dashbord til de kontrollerte arbeidsflytene vi designer for menneskelige oppgaver. Vi er i et øyeblikk hvor vi må designe agenters driftsmiljøer, mens også designer menneskelige arbeidsflyter for effektivt å veilede agentopplevelsen i disse miljøene.  

Vi er fortsatt tidlig i vår læring om hva agenter faktisk trenger fra oss for å bli gjentagbart og pålitelig vellykkede. Instinktet er å behandle agentintegrasjon som et rent prompt‑ eller UI‑problem. Å designe et velstyrt utførelsesmiljø er nytt territorium for oss som kultur. Imidlertid har de underliggende prinsippene for god design og god ledelse ikke endret seg: vi skylder agenter klar kontekst, entydig retning og eksplisitt intensjon.

Kontekst: Hvorfor koding kom først

Kontekst er sannsynligvis den viktigste innspillingen dersom vi vil at agenter skal levere gjentagbart på det nivået vi ønsker. Programvareutvikling har mer av dette dokumentert enn nesten noe annet felt: repos, API‑skjemaer, forholdet mellom systemer, kodegjennomganger og fellesskapsdiskusjoner. Så det gir mening at AI‑frontier‑labber begynte med koding. Det er ett av de få domenene hvor en god del av konteksten allerede er skrevet ned. 

Men som enhver nyansatt i et programvareteam vil fortelle deg, selv med all den dataen vil agenter fortsatt mangle den institusjonelle hukommelsen som er innebygd i de uskrevne reglene ingen noen gang har dokumentert. Det gapet er utbredt: 43 % av utviklere er bekymret for at AI‑verktøy mangler tilstrekkelig kontekst om deres spesifikke prosjekt eller kodebase. Tause kunnskaper spenner fra hverdagskonvensjoner, som foretrukne biblioteker for spesifikke oppgaver, til høy‑risiko operasjonelle spøkelser: en sen‑natt‑hotfix som henger rundt for alltid, eller en tilsynelatende tom databasekolonne som i hemmelighet støtter en tilpasset inntektsrapport. Denne konteksten lever i en senioringeniørs hode, en nylig Slack‑tråd, eller ingensteds. Den finnes sjelden i selve kodebasen.  

Hvis dette er sant i programvare, et av de best dokumenterte feltene, er det lett å forstå hvorfor agenter sliter med å prestere effektivt fra dag én i mange andre bransjer. Innen helse og jus er mye av den institusjonelle kunnskapen som former det daglige arbeidet lært og internalisert. Den lever i folks erfaring snarere enn i formell dokumentasjon. En juridisk agent kan mangle kunnskap om en bestemt partners foretrukne struktur, tone eller argumentasjon for et notat, mens en helserelatert agent kanskje ikke forstår de lokale arbeidsflytene og eskaleringspraksisene en travel klinikk bruker for å støtte kliniker‑ledet triage. Dokumentasjon alene kan ikke lukke dette gapet, fordi utfordringen ikke bare er tilgang til informasjon; det er overføring av kontekst. For å gi agenter det de trenger for å lykkes, må vi ombordstille dem på samme måte som vi ville gjort med en nyansatt.

Retning: Hvorfor osmose ikke fungerer

Å ombordstille en ny lagkamerat krever mer enn å tilby riktig materiell og tilgang. Når vi er investert i suksessen til de rundt oss, gir vi klar retning om hva man skal gjøre med det nye materialet og tilgangen: forventninger, tydelighet om hva vi prøver å oppnå, og tilbakemeldinger underveis. Jeg tar dette samme tankesettet til design for agenter. Jeg gir klar, spesifikk retning (i forhold til den aktuelle oppgaven). Det gjelder for enhver lagkamerat, uavhengig av ansettelsestid. Likevel, i et nyansatt‑scenario må retningen gå lenger, fordi de ennå ikke har noen institusjonell kontekst.

Tenk på en agent som en nyansatt som aldri slutter å være ny. Den er ivrig og kapabel (og ærlig talt har den grenseløs energi), men den kan ikke plukke opp og beholde like mange av de uskrevne reglene som et menneske gjør over tid. Mennesker lærer gjennom osmose og erfaring, mens agenter lærer fra arkitektur som er eksplisitt bygget inn i deres arbeidsmiljø.

Med en nyansatt kan du lukke det gapet over tid med spørsmål, tilbakemeldinger og ny innsikt de plukker opp om organisasjonens prosesser og preferanser underveis. Bokstavelige kaffemaskinsamtaler eller teamlunsjer. Med en agent må du bygge den gap‑lukking inn i selve designet. Dette kan inkludere: 

• Gi agenten et strukturert kontekstvindu som skiller varige regler, oppgavespesifikke fakta og relevant historikk, i stedet for å kaste en haug med dokumenter i fanget dens. 
• Definere dens tillatelser og beslutningsgrenser på forhånd: hva den kan gjøre selvstendig, hva som krever godkjenning, og hva den aldri får få tilgang til. 
• Innføre noen konkrete eksempler på solid output direkte i opplevelsen, slik at agenten har en klar modell for hvordan arbeidet skal utføres.
• Dele tidligere blindveier du har støtt på.

Å designe et velstyrt agentmiljø handler ikke om å gjøre arbeidet enklere for modellen. Det handler om å beskytte det menneskelige ingeniørteamet mot usynlig teknisk gjeld. Men selv en velrettet agent kan følge instruksjoner perfekt og fortsatt misforstå poenget. Retning forteller den hva den skal gjøre, men den forteller den ikke hvordan «godt» ser ut. Det gapet er hvor intensjon kommer inn.

Intensjon: Hvorfor agenter driver mot midten

Det er viktig å huske at agenter er mønstergjenkjenningsmaskiner, trent på enorme mengder kunnskap og naturlig tilbøyelige til å levere det statistiske gjennomsnittet. Uten klar, eksplisitt intensjon blir dette gjennomsnittlige resultatet akkurat det agenten vil returnere. Be en agent om å «legge til et brukerautentiseringsendepunkt», så vil den generere en lærebok‑Express‑rute med grunnleggende passord‑hashing. Det fungerer, men den ignorerer fullstendig teamets tilpassede autentiseringstjeneste, hopper over nødvendig telemetri, og ødelegger den standardiserte feilformaten. Det er en tilstrekkelig funksjon på papiret, men avhengig av konteksten er det en arkitektonisk feil i praksis. Hvor lett slike «feil» kan introduseres kan ikke overdrives.

For å forhindre dette må retning kombineres med aktiv intensjonsverifisering og logging. Sikkerhetsrekkverk bør ikke bare sjekke om koden kompilerer, selv om det er viktig. Sikkerhetsrekkverk må eksplisitt håndheve de meningsfulle standardene, kanttilfelle‑reglene og domenekonteksten som løfter generisk output til produksjonsklar arbeid. Logging er viktig som en systemstatusindikator for oss mennesker. Denne sporbarheten er kritisk for tillit. 

I menneskelige interaksjoner er det mye rom for usikkerhet. Noen kan dele en første versjon med deg, og sammen kan dere diskutere hva som er sterkt og hva som trenger forbedring. Dette fungerer fordi vi ikke forventer at våre menneskelige kolleger skal være autonome maskiner. For virkelig å fange kraften og løftet fra agentbaserte kolleger (som vi faktisk trenger å la fungere mer autonomt…), kan vi konstruere mange av disse retningssjekkene. Tilbake‑og‑frem‑prosessen må fortsatt foregå, men den kan ikke hvile helt på manuelt arbeid. Ved å forhåndslaste klare akseptkriterier og verifiseringsregler, gjør du det mulig for agenten å kjøre sine egne interne tilbakemeldingssløyfer. Design for feilforebygging er et annet solid UX‑prinsipp vi kan anvende i denne nye verden: å gi agenter muligheten til å flagge lav tillit før de forplikter seg til en handling, i stedet for stille å falle tilbake på et beste gjetning.

Hvor metaforen bryter

Rammen med nyansatt fungerer, helt til den ikke gjør det. Med en menneskelig ansettelse gir erfaring kompetanse som gir dømmekraft. Å se din nyansatte internalisere «hvorfor» bak kontekst og retning er det som bygger tillit over tid, og generelt er dette kumulativt. En agent har ingen plass å samle og lagre denne erfaringen.
En nyansatts første uke og hundrede uke ser forskjellig ut. En agents første oppgave og tusende oppgave ser identisk ut, med mindre du designer og bygger noe som gjør dem forskjellige. Dette er vår nye designutfordring.

Agentansvar hviler på design

Hvis ansvar ikke kan leve i agenten, må det leve i rammen rundt den. Det koker ned til de samme tre spørsmålene jeg ville stille før jeg gir arbeid til en nyansatt: Hvilken kontekst har de? Hvilken retning har jeg gitt dem? Hva er min egentlige intensjon?

Neste gang du gir en oppgave til en agent, sjekk ikke bare resultatet. Sjekk først dine egne innspill. Har du gitt den konteksten en nyansatt ville trenge på dag én? Var retningen din spesifikk nok til å overleve en bokstavelig tolkning? Var intensjonen din klar nok til at «det mediane svaret» ikke var det beste den kunne gjøre?

Med denne klare veiledningen i hånden (i byte?), skjer noe interessant: en agent trenger ikke en lang oppstartstid for å bli pålitelig. Konteksten, retningen og verifiseringen du bygger inn på forhånd definerer hvordan den opererer på hver oppgave. En nyansatt tjener din tillit over tid; en agent må tjene den hver gang gjennom systemet du har designet. Ansvar er ikke noe den vokser inn i, det er innebygd fra starten. Spørsmålet er ikke når agenten din vil være klar for mer ansvar. Det er om du har designet den til å tjene det ansvaret på hver eneste oppgave.