Ambient agents på Bedrock AgentCore

En chatagent har én indbygget sikkerhedsventil: Brugeren sidder lige dér og læser svaret. En ambient agent har ikke den luksus. Den arbejder i baggrunden, ofte om natten eller midt i en travl driftsperiode, og resultatet kan være en e-mail, en opdateret post eller en ændring i et system.

Derfor flytter spørgsmålet sig. Det handler ikke længere om, hvor god samtalen er, men om tre ting: Hvad udløser arbejdet, hvor bliver arbejdet registreret, og hvem ser det, før det får konsekvenser. Det er netop de tre led, som et eksempel på AWS Machine Learning Blog bygger rundt om på Amazon Bedrock AgentCore.

Pointen er praktisk. Mange virksomheder har flere hændelser, end nogen kan nå at tage stilling til: uploadede bilag, planlagte kontroller, overvågningsalarmer. Det er her, en agent giver mening. Den tager den første gennemgang, og mennesket tager de beslutninger, der kræver dømmekraft.

Mønsteret er enkelt nok til at kunne forklares på et whiteboard. En hændelse bliver lagt som en besked i en SQS-kø. En Lambda-funktion samler beskeden op og opretter et job med en status i DynamoDB. Derefter kalder den agenten, som kører på AgentCore og arbejder med jobbet.

Det lyder som standardinfrastruktur, og det er netop fordelen. Køen sikrer, at en pludselig bølge af hændelser ikke vælter agenten, fordi arbejdet bliver taget i et tempo, systemet kan klare. Lambda holder koblingen tynd, så der ikke ligger forretningslogik gemt i selve udløseren. Og DynamoDB giver hvert job en identitet og en historik, som både agenten og et menneske kan slå op i bagefter.

For drift har jobtabellen en ekstra værdi: Den er det sted, man kigger, når noget gik galt. Man kan se, hvilken hændelse der startede jobbet, hvor langt det nåede, og hvad status er nu. Uden den ender man med at rekonstruere forløbet fra logfiler.

Det er også et mønster, der kan genbruges på tværs af udløsere. S3-uploads, tidsplaner og alarmer ender alle som et job i samme tabel, så de håndteres ens af den samme agent og kan gennemses samme sted.

Det mest interessante designvalg er det mindste. I stedet for at bygge en separat godkendelsesmotor giver eksemplet agenten et værktøj ved navn ask_human. Når agenten når til et punkt, hvor den ikke bør gætte, kalder den værktøjet med et konkret spørgsmål, og jobbet går på pause, indtil et menneske har svaret.

Det har to fordele. For det første bliver menneskelig kontrol en del af agentens egne ræsonnementer og ikke en ekstern spærring, der skal skrues på bagefter. Agenten selv vurderer, hvornår den er i tvivl, og beder om hjælp i stedet for at fortsætte. For det andet er spørgsmålet formuleret i klartekst, så den, der svarer, ikke skal grave i en lang kørselshistorik for at forstå, hvad der skal afgøres.

Det er dog ikke en magisk løsning. En agent, der spørger for ofte, bliver en støjkilde, og en agent, der spørger for sjældent, bliver en risiko. Grænsen skal sættes bevidst: Hvad må agenten gøre alene, og hvad kræver altid et ja? Kritiske beslutninger, som betaling, sletning, ekstern kommunikation og ændringer i produktionsdata, hører typisk til i den sidste kategori. Den grænse bør stå i agentens instruktioner og i de rettigheder, den har, ikke kun i håbet om, at modellen opfører sig fornuftigt.

Sidste led er det, brugeren faktisk ser: en jobside, hvor alle igangværende og afsluttede jobs ligger. Her kan et menneske åbne et job, se hvad agenten har gjort, læse det spørgsmål, agenten har stillet via ask_human, og svare eller godkende.

Det lyder som en detalje, men det er ofte her, ambient agents lykkes eller fejler i praksis. Hvis gennemgangen er besværlig, bliver godkendelser liggende, og så er den automatisering, man ville opnå, væk igen. Hvis den er for nem og uden overblik, bliver der klikket ja til alt. Et godt jobbillede viser derfor det nødvendige og ikke mere: hvad der udløste jobbet, hvad agenten foreslår, og hvad den vil gøre, hvis svaret er ja.

Til gengæld får man noget, chatagenter sjældent giver: et revisionsspor. Hvert job har en status, et svar fra et menneske og et tidspunkt. Det er en forudsætning, hvis nogen senere skal kunne forklare, hvorfor noget blev besluttet, og af hvem.

For danske virksomheder er budskabet ikke, at man skal kopiere netop denne AWS-opskrift. Det er, at arkitekturen svarer på de spørgsmål, som kommer, så snart en agent forlader demofasen: Hvordan starter arbejdet, hvor ligger sporet, og hvornår skal en person ind over?

Tre ting er værd at tage med. Start med hændelser, der er veldefinerede og gentagne, for eksempel ankomne dokumenter eller faste kontroller, frem for åbne opgaver. Beslut på forhånd, hvilke handlinger der altid skal godkendes, og lad det være teknisk umuligt for agenten at springe dem over. Og planlæg gennemgangen som en del af driften: Hvem ser jobsiden, hvor ofte, og hvad sker der, hvis ingen svarer?

Jeg driver selv agenter i produktion, og det er de to sidste punkter, der har taget mest af min tid. Ikke modellen. Det er spørgsmålet om, hvad agenten må røre, og om jeg bagefter kan se, hvad den gjorde. Kan jeg ikke vise diffen, skal den ikke i drift.

Eksemplet fra AWS har både en grænse og et spor. Grænsen er ask_human, sporet er jobtabellen med status, svar og tidspunkt. Mangler en af dem, ville jeg ikke lade agenten køre alene. Jeg har ikke et rent tal for, hvor ofte en agent bør spørge. Det afhænger af, hvad den har lov til at røre.