Tilfeldig rant om hvor vi er med AI-agenter:

Noen kaller dem ikke agenter, men "arbeidsflytagenter" med deterministiske flyter er overalt og fungerer. hvem som helst kan bygge enkle arbeidsflytagenter, til og med starte med kodefrie verktøy som Zapier og n8n. Komplekse arbeidsflytagenter krever mye mer omtanke for å bygge pålitelig og effektivt. en kompleks arbeidsflyt for et felles og verdifullt brukstilfelle, med relevante integrasjoner bakt inn, kan stå alene som en bedrift, og også en flott GTM for å utvide senere til andre arbeidsflyter eller mer autonomt arbeid.

Mer dynamiske/autonome agenter begynner å fungere og er nyttige for forskning (spesielt hvis de er nettbaserte) og koding. mindre pålitelig når du begynner å legge til flere datakilder (f.eks. APIer). Skrivebeskyttede agenter føles trygge og enkle å teste, men å la autonome agenter utføre handlinger (skrive) er skummelt. (tilfeldig idé om dette: ville vært kult hvis verktøy som et CRM lar deg "forgrene" et utviklerspeil og kjøre automatiseringseksperimenter som du kan rulle tilbake eller slå sammen igjen.)

Dynamiske agenter fungerer bra når de kan (1) lage og spore en god plan og (2) utføre oppgaver riktig, mens de (3) finner riktig kontekst å mate inn i hvert trinn (både planlegging og hver oppgave). Til slutt må den (4) reflektere underveis (enten med eller uten menneskelig innspill) slik at den kan justere planen på riktig måte, og også forbedre måten den utfører mislykkede eller dårlige oppgaver på.

Oppgaveplanlegging: LLMs resonneringsevner fungerer fint for enkle oppgavelister som ikke krever noen privat kontekst (som dyp forskning, bare en rekke nettsøk mens du oppsummerer). Hvis du vil undersøke mange enheter, fungerer ikke dyp forskning like bra fordi oppgavelisteadministrasjonen er relativt grunnleggende. regnearkbaserte AI-verktøy fungerer bedre for å undersøke mange enheter fordi du effektivt avlaster oppgavebehandlingen til regnearket, siden det ikke fungerer å sende lange oppgavelister mellom ledetekster her. Oppgavebehandling i kodeagenter fungerer med enkle problemer, enkel kode eller når du starter fra bunnen av. Når du går inn i mer komplekse eksisterende prosjekter, er de mindre pålitelige – og utviklere øker påliteligheten ved å dokumentere hvordan koden fungerer og er organisert (MD-filer), noe som gjør det mulig for agenten å bygge bedre informerte oppgavelister. kompleks kode krever flere dokumenter og til slutt dynamisk henter bare relevant kontekst fra disse dokumentene. Mange mennesker/bedrifter har sterke udokumenterte meninger om riktig rekkefølge/tilnærming/verktøy for å takle et prosjekt, og vi trenger flere tilnærminger for å dokumentere dette på forhånd og i farten. En annen grunn til at koding og nettbaserte forskningsagenter fungerer bra, er at de alle bruker det samme settet med verktøy, så du trenger ikke å "lære" hvordan du bruker disse verktøyene (mer om dette neste).

Oppgaveutførelse: Oppgaver er vanligvis API-kall (som krever godkjenning og forståelse av hvordan du bruker API-en, og underliggende datastruktur - som kan være unik som i en CRM eller db med tilpassede tabeller/kolonner), LLM-resonnement (f.eks. oppsummere), en kombinasjon og til og med arbeidsflytagenter*. En forskningsagent er egentlig bare nettsøk og oppsummering i en løkke. kodeagenter er CRUD på kodebasen din, og kanskje nettsøk etter lærings-APIer. AUTH og grunnleggende API-tilgang føles løst (MCP-er passer her), men jeg vil gjerne se mer rundt verktøyspesifikk kontekst (spør brukeren, men analyser også ved første tilkobling, grav i eksisterende data for å forstå hvordan verktøyet brukes, hvordan dataene er strukturert, hvilke scenarier/prosjekter vi bruker verktøyet til.), feil/refleksjon/tilbakemelding må bli til organisert læring som blir matet tilbake som kontekst når det er relevant. De samme verktøyene kan brukes til forskjellige formål og på forskjellige måter mellom organisasjoner, og vi må fange opp/dokumentere dette på en eller annen måte for å utføre oppgaver godt.

Kontekst: Tenk deg å være nyansatt i et selskap. Du lærer mye under onboarding (og jo bedre onboarding, jo mer effektiv er du ute av porten), og så er det læring på jobben som brytes ned i læring av organisasjonens erfaring («Slik gjør vi ting») og læring av egen erfaring – tidligere mer dominerende i store organisasjoner. Kontekststyring er lik. det er lag med kontekst som meta (bruker/selskap), prosjekt/avdelingsspesifikk, oppgavespesifikk, verktøyspesifikk, etc. vi har utviklet oss fra enkle systemforespørsler til hybride RAG-strategier (vektor, nøkkelord, graf), men utover å ha dataene/konteksten, trenger vi veiledning om når og hvordan vi skal hente kontekst, som vi ser tidlige versjoner av i dag - men mye rom for forbedring. Dette er ikke bare et teknisk problem, men også et forretningsproblem - siden du i utgangspunktet må lage et onboarding-dokument som dekker alle scenarier du forventer. Etter hvert som prosjekter blir mer kompliserte, krever det mer omtanke å beskjære konteksten riktig, slik at bare relevant informasjon blir inkludert i spørsmålet, samtidig som irrelevant kontekst minimeres.

refleksjon: vi har agentovervåkingsverktøy som dekker LLM/API-kostnader, observasjon, men å tildele suksess/fiasko er en utfordring - et område der kodeagenter har et bein på andre er en deterministisk måte å legge merke til feil på (gjennom testing av koden). For mange andre agentiske oppgaver finner vi fortsatt ut den riktige måten å samle inn menneskelige innspill på for å forbedre fremtidige resultater. Afaik, refleksjon i dag er menneske-i-løkken, der tilbakemeldingene i stor grad blir matet til menneskelige utviklere for å forbedre agenten, men opplåsingen kommer når vi finner ut hvordan vi kan gjøre refleksjon til selvforbedring - der agenten tar innsikt fra feil i oppgavelistegenerering og oppgaveutførelse for å gjøre det bedre neste gang. I utgangspunktet må refleksjonen bli til en godt organiserende kontekst som kan trekkes inn i spørsmål når og bare når det er relevant. dette utvikler seg til finjustering av deler av agenten, og deretter agentiske RL-miljøer - føles fortsatt ganske tidlig her

*Tidligere nevnte jeg overlevering av oppgaver til arbeidsflytagenter, som begynner å gi mening når agenten din vil dra nytte av å ikke ha arbeidsflytagenter som verktøy (i motsetning til å finne ut en kjent oppgaveliste hver gang) eller når systemet ditt er komplisert nok til at spesialiserte agenter med spesialisert kontekst og verktøy yter bedre. Eller hvis du utnytter agenter bygget av andre PPL (et mønster jeg har begynt å se her er API-endepunkter for naturlig språk for enklere agentsamarbeid).

hvis vi hadde dagens modellkvalitet med uendelig innholdsvindu (ingen forringelse i kvalitet), uendelig databehandling, uendelig lagring, nettlesertilgang og en betalingsmetode, er en enkelt LLM-sløyfe sannsynligvis nok til å få gjort mye poenget med det meningsløse poenget ovenfor (ingenting er uendelig) er at agentorkestrering i stor grad handler om å håndtere begrensninger ved å konstruere måter å avlaste arbeid fra LLM gjennom struktur og kode.

Agenter i produksjon kommer i forskjellige smaker: som interne verktøy, som et frittstående produkt som kombinerer ulike verktøy, og bakt inn som en funksjon til et kjerneverktøy. De kan være generiske eller spesialiserte. chat-, tale- og bakgrunnsagenter ser ut til å være det vanligste grensesnittet for brukergrensesnitt for å utløse agentflyter.

Hva annet går jeg glipp av?