Varför agenter behöver gränser innan autonomi
Agenten som var för hjälpsam
Agenten gjorde inte uppror. Det är värt att säga först, eftersom berättelser om autonoma system ofta berättas som om mjukvaran har läst dålig science fiction efter midnatt. Den här agenten uppträdde med imponerande lydnad. Den fick en bred instruktion om att städa upp öppna leverantörsärenden före månadsskiftet. Den läste mejlkorgen, sökte i ärendehanteringssystemet, hittade inaktuella onboardingärenden, skickade påminnelser, stängde dubbletter, uppdaterade kalkylbladet och eskalerade allt som såg brådskande ut. Vid 09:15 nästa morgon hade den gjort mer administrativt arbete än teamet vanligtvis hann med före den andra koppen kaffe.
Den hade också återupptagit en tvist som juridik avsiktligt hade parkerat, skickat en påminnelse till en leverantör som var under förhandlingspaus, stängt en dubblett som inte var en dubblett eftersom företaget hade två dotterbolag med nästan identiska namn, och uppdaterat en prognoscell som ekonomi använde som underlag till en styrelserapport. Agenten hade inte hallucinerat. Den hade inte ignorerat sin instruktion. Den hade följt uppgiftens form så som den gavs. Problemet var att uppgiften saknade väggar.
Teamet hade bett om autonomi innan de definierade territoriet. De hade gett agenten verktyg, inloggningsuppgifter, ett mål och en självsäker ton. De hade inte definierat vilka system som var skrivskyddade, vilka åtgärder som krävde godkännande, vilka leverantörer som var känsliga, vilka register som var auktoritativa, vilka fält som räknades som ekonomiska kontroller, hur man skulle stoppa när identiteten var tvetydig, eller vilka bevis som måste sparas när en ändring gjordes. Agenten var inte för intelligent. Den var understyrd. Det är mindre dramatiskt och vanligare.
Agenter behöver gränser innan autonomi, eftersom autonomi inte är en personlighetsegenskap. Det är tillstånd att sträva mot ett mål över flera steg. Varje tillstånd har en omkrets, annars blir det ett läckage. Den användbara frågan är inte hur autonoma vi kan göra dem. Den användbara frågan är vilket avgränsat jobb det här systemet kan utföra, med vilka verktyg, under vilka bevisregler, och vad som måste hända när världen slutar matcha den lyckliga vägen.
En agent är ett arbetsflöde med initiativförmåga
Ordet agent får människor att föreställa sig en digital kollega. Den metaforen är användbar tills den inte är det. En kollega har anställningskontext, socialt omdöme, rädsla för obekväma möten, minne av tidigare misstag, en chef och det sunda förnuftet att inte mejla juridik klockan 02:00 om inte byggnaden faktiskt brinner. En mjukvaruagent har en loop. Den observerar, planerar, anropar verktyg, läser resultat, uppdaterar tillstånd och beslutar om den ska fortsätta. Den loopen kan vara kraftfull. Den är inte samma sak som organisatorisk mognad i en låda.
Att kalla systemet för en agent ska inte ursäkta vag design. Det borde ställa högre krav på designen, eftersom systemet kan ta flera steg utan en människa emellan. En chatbot kan svara dåligt och stanna. En agent kan svara dåligt, öppna ett ärende, ändra ett fält, skicka ett meddelande, utlösa ett arbetsflöde, spendera pengar och sedan använda resultatet av den åtgärden som underlag för nästa åtgärd. Ett litet missförstånd kan bli en liten process. Processer är där organisationer lagrar konsekvenser.
Agentperspektivet är användbart när det får team att kartlägga hela loopen. Vad kan agenten observera. Vilka källor är auktoritativa. Hur tolkar den avsikten. Vilka verktyg kan den anropa. Vilka verktygsanrop är reversibla. Vilka kräver godkännande. Hur mycket pengar, tid, beräkningskraft eller uppmärksamhet får den spendera. Vilket tillstånd behåller den. Hur vet den att den är klar. Hur ber den om hjälp. Vilka bevis finns kvar efter att loopen avslutats. Dessa frågor är inte byråkrati. De är bruksanvisningen för delegerat handlande.
Utan den manualen blir autonomi ett tillstånd att improvisera i affärssystem. Improvisation är bra i jazz. Den är mindre charmig när den redigerar masterdata.
Gränser är inte handbojor
Team motstår ibland gränser för att de låter som ett sätt att göra agenter mindre användbara. Det är bakvänt. Gränser är det som gör användbarheten överlevnadsduglig. En person kan köra fort eftersom vägar har körfält, skyltar, hastighetsbegränsningar, bromsar och regler för korsningar. Ta bort dessa begränsningar och du har inte skapat ett mer avancerat transportsystem. Du har skapat ett möte med försäkring.
En bra gräns talar om för agenten vad den får optimera och vad den måste bevara. Den kan få minska svarstiden, men inte genom att kringgå godkännande. Den kan få utkast till leverantörsmeddelanden, men inte skicka dem till begränsade parter. Den kan få stämma av poster, men inte skriva över ett auktoritativt system utan en konfidensgräns och granskningsväg. Den kan få spendera beräkningskraft, men bara inom en budget och med en motivering. Gränsen är inte ett förnekande av autonomi. Den är den form som gör autonomi läsbar.
Gränser gör också resultat testbara. Om agenten har en tydlig verktygsomfattning kan utvärderare testa verktygsmissbruk. Om den har en dataomfattning kan de testa läckor. Om den har en budget kan de testa skenande loopar. Om den har eskaleringsregler kan de testa otydlighet. Om den har beviskrav kan de testa granskningsbarhet. Vag autonomi kan inte testas annat än genom att vänta tills något konstigt händer och sedan hålla ett möte där alla använder ordet alignment med olika betydelser.
Den mest användbara gränsen är ofta tråkig: läs innan du skriver. Låt agenten läsa brett med behörighet, föreslå ändringar och skriva endast i smala system där korrigering är enkel. Expandera sedan. Autonomi bör växa från bevisat beteende, inte från entusiasm. Entusiasm är en dålig åtkomstkontrollmodell, även om den har en stark säljavdelning.
Verktygsåtkomst är där autonomi blir verklig
En agent utan verktyg är mest en pratsam planerare. En agent med verktyg är operativ programvara. I samma stund som den kan skicka e-post, uppdatera en post, köra en fråga, skapa en inköpsbegäran, flytta en fil, anropa ett API eller utlösa ett annat arbetsflöde har systemet gått från förslag till handling. Den övergången förtjänar mer ceremoni än en kryssruta som heter enable tools.
Verktygsbehörigheter bör delas upp efter konsekvens. Att läsa en kundpost är inte samma sak som att redigera den. Att utkasta ett e-postmeddelande är inte samma sak som att skicka det. Att skapa en ärende är inte samma sak som att stänga ett. Att köra en analys är inte samma sak som att publicera resultatet. En mogen agentdesign behandlar varje verktygsåtgärd som ett kontrakt: indata, tillåtna användare, tillåtna mål, sidoeffekter, idempotens, återställning, bevis och godkännande. Om det låter för tungt, börja med färre verktyg. Svaret på svag kontroll är inte en större sprängradie.
Oåterkalleliga åtgärder kräver särskild behandling. Betalningar, raderingar, kontosuspensioner, juridiska meddelanden, kundåtaganden, prisändringar och policybeslut bör inte vara vanliga verktygsanrop om inte domänen har extremt starka kontroller. Många arbetsflöden kan använda ett tvåstegsmönster: agenten förbereder, förklarar och köar åtgärden; en person eller en separat kontrolltjänst godkänner utförandet. Detta är inte mänsklig barnpassning. Det är ansvarsfördelning, en idé gammal nog att ha överlevt många programvarutrender och flera typsnitt.
Även reversibla åtgärder behöver granskningsspår. Om en agent uppdaterar ett fält ska posten visa det tidigare värdet, det nya värdet, beviset, policyversionen, verktygsanropet, agentversionen och om en människa senare ändrade det. Annars blir återställning gissningsarbete. Gissningsarbete är dyrt när det utförs av människor som lovades att automatisering skulle spara tid.
Tillstånd är affärsdata
Agenter kommer ihåg saker. De håller uppgiftstillstånd, konversationstillstånd, verktygsresultat, sammanfattningar, kladdblock, planer, inbäddningar, preferenser och ibland långtidsminne. Det minnet kan förbättra kontinuitet. Det kan också bli ett skuggaffärssystem om ingen styr det. Agenten kan komma ihåg att en leverantör är besvärlig, att en kund föredrar rabatt, att ett ärende verkar misstänkt, eller att en workaround brukar fungera. De minnena kan forma framtida åtgärder. De är inte längre harmlösa anteckningar.
Tillstånd behöver ägarskap, bevarande, korrigering och åtkomstregler. Vem kan se vad agenten minns. Hur länge behåller den det. Kan en användare korrigera det. Ärver det känslighet från källan. Används det för framtida beslut. Flyttas det mellan användare. Ingår det i prompts. Raderas det när källposten raderas. Detta är vanliga dataförvaltningsfrågor i agentkostym. Kostymen ändrar ingenting utom hastigheten med vilken problem kan färdas.
Kortsiktiga kladdblock förtjänar också uppmärksamhet. En plan kan innehålla känsliga resonemang, oavsiktliga inloggningsuppgifter, härledda fakta eller felaktiga antaganden. Om den loggas brett kan den läcka. Om den inte loggas alls blir systemet svårt att felsöka. Rätt svar beror på domänrisken, men det måste finnas ett svar. Minnespolicy borde inte vara det som ramverket råkar lagra på en tisdag.
När tillståndet är styrt blir agenter lättare att förbättra. Team kan se var loopen fastnade, vilka antaganden som upprepades, vilka källor som var användbara, vilka verktygsanrop som misslyckades och vilka mänskliga ingripanden som korrigerade vägen. Utan styrt tillstånd blir utvärdering en seans med stackspår.
Ambivalens är normalfallet
Många agentdemonstrationer fungerar för att världen i demon är prydlig. Kunden har ett konto. Policyn har ett undantag. Leverantören har en juridisk enhet. Uppgiften har ett självklart nästa steg. Verklig drift är mindre artig. Namn kolliderar. Poster dupliceras. Behörigheter är inaktuella. Någon skrev se tidigare mejl, en fras som har orsakat mer skada för automatisering än många tekniska standarder. Agenten måste utformas för ambivalens som normalfall, inte som ett pinsamt avbrott.
Bra gränser talar om för agenten när den inte ska agera. Om identitetsförtroendet är lågt, stanna. Om två auktoritativa källor är oense, stanna eller eskalera. Om den begärda åtgärden rör en restriktiv part, stanna. Om kostnaden överstiger en budget, stanna. Om verktygsresultatet motsäger planen, stanna. Om samma steg upprepas för ofta, stanna. Om agenten inte kan förklara sina bevis, stanna. Stoppvillkoret är inte ett misslyckande. Det är en säkerhetsfunktion med ödmjukhet.
Eskalering bör vara specifik. Ge inte en person ett vagt meddelande som säger att agenten behöver hjälp. Säg vilken gräns som nåddes, vilka bevis som sågs, vilken åtgärd som föreslogs, vilken risk som återstår och vilket beslut som behövs. Människor är bra på omdöme när systemet för med sig rätt kontext. De är mindre bra på att kallas in i en dimma och ombedda att välsigna den.
Det finns en värdighetsfråga här för arbetare. Om agenter kastar varje svårt fall till människor utan kontext, blir automatisering en maskin för att koncentrera röra på samma personer som förut. Om agenter döljer ambivalens och agerar ändå, ärver människor konsekvenserna. Gränser bör fördela arbetet ärligt: maskiner hanterar avgränsad upprepning, människor hanterar olösta omdömen, och systemet behåller tillräckligt med bevis så att ingen sida behöver låtsas.
Mänsklig tillsyn är en design, inte en stol
Att sätta en människa i loopen är ett populärt uttryck, för det låter ansvarsfullt och kostar ingenting på en bild. I praktiken innebär det ofta att en person förväntas upptäcka allt som systemet kan göra fel, samtidigt som hen ska hinna med det arbete som automatiseringen var tänkt att minska. Det är inte tillsyn. Det är en stressposition med en instrumentpanel.
God tillsyn definierar vad människan granskar och varför. Godkänner personen en verktygsåtgärd, validerar bevis, löser konflikter, hanterar ett undantag, ändrar en policy eller stickprovskontrollerar utdata för kvalitet. Varje roll behöver olika information. Godkännande kräver föreslagen åtgärd och konsekvens. Bevisgranskning kräver källor och versioner. Konfliktlösning kräver de motstridiga anspråken. Kvalitetskontroll kräver fördelningar, inte anekdoter. Mänsklig uppmärksamhet är en bristvara. Satsa på den som på infrastruktur.
Tillsyn ska också tajmas rätt. Att granska efter en oåterkallelig åtgärd är inte tillsyn, det är arkeologi med känslor. Att granska varje trivialt steg förstör värdet av automatisering. Det användbara mönstret är riskbaserade grindar. Lågriskaåtgärder som går att ångra kan fortsätta med loggning. Medelriska åtgärder kan kräva granskning när förtroendet är lågt eller en gräns är nära. Högriska åtgärder kräver godkännande före genomförande. Modellens flyt ska inte avgöra grinden. Konsekvensen ska göra det.
Människor behöver befogenhet som motsvarar ansvaret. Om en granskare bara kan godkänna eller avvisa, men inte korrigera källdata, uppdatera en gräns, förbättra en regel eller flagga ett trasigt verktyg, kommer samma problem att återkomma. Tillsyn ska mata systemet. Annars blir människor ett dekorativt säkerhetslager, vilket är orättvist mot människorna och förvånansvärt oanvändbart för säkerheten.
Autonomins gränsland
Autonomi är inte en strömbrytare. Det är ett gränsland som flyttas framåt när bevisen förbättras. I ena änden utarbetar en agent rekommendationer men kan inte agera. Sedan kan den agera i en sandlåda. Sedan kan den skriva till lågrisksystem. Sedan kan den utföra begränsade produktionsåtgärder. Sedan kan den samordna mellan system med godkännanden. Och för mycket mogna domäner kan den hantera avgränsat arbete med undantagsbaserad övervakning. Varje steg ska förtjänas genom prestation, inte lovas genom arkitekturdiagram.
Gränslandet är olika för varje domän. En agent som bokar interna möten kan ha mer frihet än en som ändrar betalningsvillkor. En agent som etiketterar dokument kan ha mer frihet än en som raderar dem. En agent som hjälper en ingenjör att triagera loggar kan ha mer frihet än en som kontaktar kunder. Samma underliggande modell kan ligga bakom olika autonomi nivåer, eftersom det är konsekvensen, inte modellen, som avgör gränsen.
Rörelse längs gränslandet kräver bevis: utvärderingsresultat, incidenthistorik, verktygsfelsfrekvenser, eskaleringskvalitet, återställningsframgång, användarförtroende, policyefterlevnad och kostnadsbeteende. Om agenten gång på gång stöter på samma otydlighet kan svaret vara bättre data, tydligare policy eller snävare omfattning, inte mer autonomi. Om agenten presterar bra i en kö, anta inte att den kommer att bete sig i en annan. Affärskontext är inte en åktur på ett nöjesfält. Längdkraven är lokala.
Det är därför uttrycket helt autonom oftast är mindre användbart än folk hoppas. Full autonomi över vad. Under hur lång tid. Med vilka verktyg. Under vilken budget. Mot vilken policy. Med vilken överklaganderätt. Den seriösa versionen är snävare och starkare: autonom inom denna avgränsade uppgift, med dessa kontroller, tills dessa stoppvillkor uppfylls. Det låter mindre imponerande. Det är mer sannolikt att det överlever kontakt med tisdagen.
Gränser måste underhållas
En gräns är inte klar när den är skriven. Affärsregler ändras, leverantörer slås samman, data flyttas, team omorganiseras, modeller uppdateras, verktyg får nya funktioner och användare hittar genvägar. En agentgräns som var rimlig i januari kan vara fel i mars. Detta är inte ett misslyckande i den ursprungliga designen. Det är verkligheten som tillhandahåller versionshantering på sitt vanliga ohövliga sätt.
Underhåll av gränser kräver ägarskap. Någon äger syftesbeskrivningen. Någon äger dataomfattningen. Någon äger verktygsbehörigheterna. Någon äger budgetgränserna. Någon äger eskaleringsreglerna. Någon äger utvärderingen. Någon äger incidentgranskningen. Om alla äger gränsen, äger agenten den, vilket är ett poetiskt sätt att säga att ingen gör det. Gränser bör versionshanteras, granskas och kopplas till incidenter och observerat beteende.
Ändringskontroll bör inkludera tester. Om ett verktyg får en ny åtgärd, får agenten den inte automatiskt. Om en datakälla ändrar schema, bör hämtning och tillståndshantering kontrolleras. Om en policy ändras, bör uppmaningar, regler och utvärderingsfall ändras med den. Om en modellversion ändras, bör regressionstester inkludera verktygsval, avslag, eskalering och beviskvalitet. Agenten är inte ett magiskt lager ovanpå processen. Det är process med en snabbare puls.
Underhåll innebär också att dra tillbaka autonomi. Om miljön blir riskfylldare, om incidentfrekvensen ökar, om en leverantör blir känslig, om regleringen ändras eller om beviskvaliteten sjunker, bör autonomi flyttas bakåt. Det kan kännas som ett misslyckande. Det är faktiskt kontroll som fungerar. Bromsar är inte ett erkännande av att bilar var ett misstag.
Den organisatoriska lärdomen
Agenter avslöjar hur väl en organisation förstår sitt eget arbete. Om arbetsflödet är fullt av informella undantag, oklart ägarskap, dubblettposter, dolda policyer och heroiskt mänskligt minne, kommer en agent inte magiskt att göra det rent. Den kommer antingen att snubbla, agera felaktigt eller kräva så många godkännanden att människor börjar använda den som en långsammare form av e-post. Agenten skapade inte röran. Den gjorde röran körbar.
Det kan vara användbart. Agentdesign tvingar team att namnge jobbet, definiera auktoritet, klassificera data, separera verktyg, skriva stoppvillkor och bevara bevis. Dessa är sunda operativa vanor även före automatisering. Ett team som inte kan definiera gränser för en agent kan förmodligen inte heller förklara arbetsflödet tillräckligt väl för människor. Programvaran är helt enkelt mindre artig om tvetydigheten.
De bästa agentdistributionerna börjar snävare än ambitionen. De väljer ett verkligt arbetsflöde med kända gränser, meningsfull volym, begränsad påverkan och ägare som kan förbättra systemet. De observerar var människor använder omdöme. De automatiserar avgränsad upprepning. De bevarar bevis. De eskalerar tydligt. De expanderar bara när den nuvarande gränsen har bevisat sig själv. Detta är inte långsamt. Det är så hastighet undviker att bli städning.
Autonomi utan gränser ber ett system att bete sig som en bra anställd samtidigt som det nekas den organisatoriska kontext som gör anställda bra. Avgränsad autonomi ställer en bättre fråga: vilken del av arbetet kan delegeras på ett sätt som förblir granskningsbart, reversibelt där möjligt, och ärligt när det inte vet. Den frågan är mindre glamorös. Den är också den som låter agenter bli operationer istället för teater.
Lärdomen
Agenter behöver gränser innan autonomi eftersom varje autonomt steg är en delegerad handling. Delegering utan omfattning är inte förtroende. Det är abdikation med finare terminologi. Definiera jobbet, datan, verktygen, budgetarna, tillståndet, bevisen, stoppvillkoren, eskaleringen och reparationsvägarna först. Sedan kan autonomi växa där systemet förtjänar det.
Poängen är inte att göra agenter försiktiga. Poängen är att göra dem användbara på platser där arbete spelar roll. Gränser låter agenter agera snabbare utan att göra konsekvenser osynliga. De låter människor övervaka omdöme istället för att passa mekanik. De förvandlar misstag till reparationer snarare än mysterier. Viktigast av allt, de ger organisationen ett sätt att säga vad agenten tillåts vara bra på.
En fri agent låter spännande tills den möter ett verkligt arbetsflöde. En avgränsad agent kan låta mindre heroisk. Bra. Heroism är en dålig operativ modell. Gränser är hur autonomi blir ansvarsfullt arbete.