Mange forestiller sig først, at AI-kolleger skal fungere som et team, med én agent pr. rolle. Én til engineering, én til marketing, én der kun skriver blogindlæg.
Sådan byggede vi det også. I Okou kunne du oprette mange agenter i et workspace, hver med sit eget navn, sin egen avatar, sine egne Instruktioner og Workflows. I august udgav vi endda et indlæg om, hvordan flere agenter fordeler arbejdet og giver det videre til hinanden. Vores eget workspace havde masser af dem. Lucas skrev vores blogindlæg, Lisa tog sig af bogføringen, Iris håndterede investor relations, og jeg havde en, der hed Emily, som sorterede min e-mail.
Men brugernes intuition er kun et pejlemærke. Før Notion mente folk, at et dokumentværktøj skulle have sidehoveder og sidefødder.
Multi-agent er heller ikke en grundlæggende funktion. De grundlæggende funktioner er dem, som alle AI-produkter før eller siden får brug for: chat, at lave slides og hjemmesider, at betjene en computer. Flere agenter står ikke på den liste.
Tag Lucas, vores tidligere blogagent. Omkring en tredjedel af dens Instruktioner er den samme generiske skabelon, som standard-Okou bruger. Resten er tre specifikke procedurer: hvordan man udgiver et blogindlæg i Strapi, hvordan man skriver use case-sider til vores hjemmeside, og hvordan man laver den daglige rapport om signup-konvertering. Alle 13 Workflows, der er tilknyttet Lucas, er offentlige i workspacet. Ingen af dem tilhører Lucas alene.
Så forskellen mellem Lucas og standard-Okou koger ned til et navn, en avatar og tre procedurer, der burde have været Workflows. De procedurer er låst inde i Lucas. Beder du standard-Okou om at udgive et blogindlæg, kender den ingen af de regler.
Efterhånden som antallet af agenter voksede, voksede antallet af kombinationer også. Mange agenter, mange Workflows og mange samtaler spiller sammen, og hver kombination er logik, vi skal vedligeholde, og som brugerne skal lære. Vi stødte på spørgsmål, vi ikke kunne svare godt på set fra brugerens side:
- Hvorfor kan to agenter ikke dele det samme Workflow?
- Hvorfor kan jeg kun tale med Okou i Slack og ikke med min egen private agent? Hvis Lucas er en person, burde jeg kunne nå den overalt.
- Hvorfor deler alle agenter den samme hukommelse? Hvis hver agent er en person, burde hver have sin egen hukommelse.
Hvert af dem kan løses, men hvert kræver reelt udviklingsarbejde. Lader man dem ligge, forbliver multi-agent en halvfærdig oplevelse. Vi havde også svært ved at finde et problem, som kun flere agenter kunne løse. Den klage, vi hørte oftere, var, at der var for mange agenter at holde styr på.
Derfor besluttede vi, at hver person får én Okou. Modellen er enklere:
- Hver person har én standard-Okou.
- Din Okou tilhører dig og er privat.
- Din Okou og en kollegas Okou er ikke den samme agent.
- Din Okou kan bruge ethvert Workflow, som nogen i din organisation har gjort Public.
De ting, der før hang på en agent, ligger nu dér, hvor de passer bedre:
- Instruktioner tilhører dig. Du skriver ét sæt, og Okou følger det på nettet, i Slack og i automatiseringer.
- Workflows tilhører workspacet. Alle kan bruge et Public Workflow, som en kollega udgiver, og du kan kopiere et og gøre det til dit eget.
- Forbundne konti tilhører dig, så du skal ikke længere vælge, hvilken agent der får adgang.
- Samtaler samles i Projekter, efter kunde, projekt eller emne.
I denne model er en agent ikke meget mere end et sæt Instruktioner. De tre procedurer i Lucas bør blive til Workflows, som alle kan bruge.
Multi-agent er i virkeligheden en ledelsespraksis i en organisation, en måde at styre, hvad AI kan gøre. Hver organisation har sine egne ledelsesmetoder, og ingen enkelt opskrift passer til alle. En enkelt agent minder mere om et værktøj, og værktøjer er lettere at forstå og tage i brug. Det, brugerne har mest brug for, er at få opgaven løst. Dernæst kommer et værktøj til at løse den. Det, de har mindst brug for, er en metode til at gøre det.
Anthropics Applied AI-team så noget lignende i et nyligt indlæg om agent-udrulninger i virksomheder. I deres sammenligninger på tværs af flere udrulninger klarede en enkelt agent med Skills sig ofte bedre på kvalitet end et design opdelt i specialiserede subagenter, og ofte med lavere omkostninger og latenstid pr. opgave. De skriver også: »Alt for ofte ser vi virksomheder give hvert team eller hver problemtype sin egen subagent, så agentarkitekturen ender som en kopi af deres organisationsdiagram.« Deres indlæg handler om agentarkitektur og ikke om produktdesign, men ræsonnementet kan sagtens overføres.
Ser vi på nutidens AI-produkter, finder vi fire modeller:
- Mange agenter, mange samtaler. Det var Okou.
- Én agent, mange samtaler. Sådan fungerer ChatGPT, Codex og Claude Cowork.
- Én agent, én samtale. Sådan fungerer Instinct.
- Mange agenter, hver med én enkelt samtale. Sådan fungerer Grok bot.
Vi havde den mest komplekse kombination, og den løste ikke flere problemer.
Vi ved godt, at det er en gennemgribende ændring. To ting holdt os tilbage fra at gøre det før: at vi beder dig lære en ny måde at arbejde på, med én Okou plus Workflows, og at der ikke var en klar vej for det, du allerede havde bygget. Her er den vej:
- Dine samtaler er der stadig. Du kan finde dem via Projekter, søgning og deres oprindelige links.
- Hvis du brugte forskellige agenter til at sortere samtaler, så brug Projekter i stedet. At holde samtaler grupperet efter kategori var hovedgrunden til, at mange oprettede ekstra agenter. Claude og ChatGPT løser samme behov med Projekter.
- Hvis du skrev forskellige Instruktioner til forskellige agenter, så læg det fælles i dine personlige Instruktioner, og gør de specifikke procedurer til Workflows.
Jo før vi holder op med at bygge abstraktioner oven på flere agenter, jo bedre. Når du åbner Okou, behøver du ikke længere at beslutte, hvilken agent du skal spørge. Fortæl Okou, hvad du skal have gjort, så klarer Okou resten.
