Én superagent er ikke et team
Når AI-agenter begynner å bruke verktøy, skrive kode og løse oppgaver over flere steg, er det fristende å gi én agent mest mulig kontekst og be den «ordne alt». Det kan fungere for en liten, reverserbar oppgave. Men i arbeid som berører systemer, kunder, dokumenter, budsjett eller kode blir det fort vanskelig å se hvem som gjorde hva, hvorfor en beslutning ble tatt og hvor en feil oppstod.
Et lite AI-team er en annen modell. Her deler en en større oppgave i tydelige deler: én agent undersøker, én lager et utkast, én kontrollerer mot kriterier, og et menneske godkjenner før en handling får konsekvenser. Agentene styrer ikke virksomheten; de koordinerer avgrenset arbeid innenfor rammene dere har satt.
Et nyttig AI-team har ikke flest mulig agenter. Det har klare roller, korte oppgaver, synlige avhengigheter og en ansvarlig person som kan stoppe løpet.
To byggesteiner: Paperclip og Hermes Kanban
Paperclip er en åpen kildekode-løsning som beskriver seg som en kontrollflate for å ta med egne agenter, gi dem mål og følge arbeid og kostnad. Prosjektet fremhever blant annet vedvarende agenttilstand, oppgaveutførelse i små enheter, skills og prosjektkontekst, samt godkjenningsporter med mulighet for rollback. Dette er produktets egne funksjonsbeskrivelser, ikke en garanti for at systemet er riktig eller sikkert i deres miljø. [1]
Hermes Kanban er en vedvarende oppgavetavle for flere Hermes-profiler. Dokumentasjonen beskriver at oppgaver og overleveringer lagres i en lokal SQLite-database, og at arbeiderne kjører som separate prosesser med egen identitet. Tavlen støtter blant annet oppgavekontekst, deloppgaver, avhengigheter, review, tilbakeføring for endring og blokkering når en agent trenger menneskelig input. [2]
| Byggestein | Praktisk rolle | Det løser ikke av seg selv |
|---|---|---|
| Paperclip | Samler mål, agentarbeid, status, kostnad og godkjenning på ett sted. | Tilgangsstyring, datakvalitet, juridisk ansvar eller god teknisk arkitektur. |
| Hermes Kanban | Holder oppgaver, overleveringer og review ved like på tvers av agentprofiler. | Faglig kvalitet; en feil antakelse kan fortsatt sendes effektivt fra agent til agent. |
| En ansvarlig person | Eieskap til mål, data, beslutninger og stoppekriterier. | Kan ikke erstattes av en «godkjenn»-knapp etter at skaden allerede er gjort. |
Det finnes også en Paperclip-adapter for Hermes som beskriver hvordan Hermes Agent kan kjøre som en administrert agent i en Paperclip-organisasjon. Det er et interessant integrasjonsspor, men bør først prøves i et lite testløp med få verktøy og tydelig budsjett. [3]
Hva videoene viser – og hva de ikke beviser
De to gjennomgangene nedenfor viser hvorfor Paperclip og Hermes Kanban er interessante sammen: Paperclip kan holde mål, roller, budsjett, rutiner og godkjenninger synlige, mens Hermes kan gi agentene en arbeidsflate, verktøy og Kanban-overleveringer. I demonstrasjonene får flere agentroller blant annet undersøke et IT-problem, sette opp faste rutiner, lage innholdsutkast og forberede analyser.
Det er viktig å skille mellom en god demo og driftsklar automatisering. Paperclip dokumenterer oppgavehistorikk, rollefordeling, kostnadsoppfølging, rutiner og godkjenningsporter. Hermes dokumenterer Kanban, planlagte oppgaver, flere terminalbakender og egen sikkerhets- og godkjenningskonfigurasjon. Ingen av disse funksjonene gjør det trygt å la en agent starte tjenester på nytt, nullstille passord, endre brannmurregler eller sende meldinger uten en bevisst tilgangsmodell.
Et lite team med fem tydelige roller
For de fleste er det nok å starte med tre roller. Fem roller nedenfor viser likevel hvordan ansvaret kan deles når oppgaven blir større.
| Rolle | Agentens jobb | Tillatelser og grenser |
|---|---|---|
| Orkestrator | Deler mål i mindre kort, setter rekkefølge og ber om status. | Oppretter og kobler oppgaver, men gjør ikke selve fagarbeidet eller godkjenner egne resultater. |
| Undersøker | Leser godkjente kilder, dokumenterer funn og peker på mangler. | Lesetilgang til avgrensede kilder. Ingen endring, utsending eller ny tilgang. |
| Utfører | Lager et utkast: en rapport, en kodeendring eller et prosessforslag. | Arbeider i sandbox eller egen branch. Ingen deploy eller publisering. |
| Reviewer | Sjekker resultatet mot en forhåndsdefinert test, sjekkliste eller policy. | Kan be om endring eller blokkere. Må ikke være samme profil som laget utkastet. |
| Ansvarlig menneske | Bestemmer mål, godkjenner unntak og eier konsekvensene. | Godkjenner handlinger som påvirker kunder, økonomi, ansatte, sikkerhet eller produksjon. |
Denne fordelingen er et praktisk harness: laget rundt modellene som bestemmer kontekst, verktøy, rekkefølge, tester og eskalering. Les mer om hvorfor dette betyr mer enn bare modellvalg i AI-orkestrering: Modellen er ikke hele løsningen.
Et konkret eksempel: rydde opp i intern kunnskap før et nytt kundeløp
Tenk dere at dere skal forbedre oppfølgingen av nye kundehenvendelser. Det finnes gamle maler i en mappe, et par prosessbeskrivelser, notater fra tidligere møter og en CRM-rutine som noen kjenner godt, men som ikke er skrevet ned.
Den dårlige oppgaven er: «La agentene finne ut av hvordan vi skal følge opp leads.» Den gode oppgaven deler arbeidet og bestemmer hva som teller som ferdig.
| Fase på tavlen | Eier | Leveranse før neste fase |
|---|---|---|
| Avklaring | Menneskelig prosesseier + orkestrator | Mål, tillatte kilder, målgruppe, hva som ikke skal endres og hvem som godkjenner. |
| Kartlegging | Undersøker | Kildeliste med dato, eier, status og synlige hull eller motstridende rutiner. |
| Utkast | Utfører | Et kort prosessforslag med antakelser, alternativer og lenker tilbake til kildene. |
| Review | Reviewer + prosesseier | Sjekk mot kundetone, samtykke, CRM-felter, kapasitet og faktiske arbeidsvaner. |
| Pilot | Menneskelig eier | En liten, reverserbar test. Ingen automatisk utsending eller endring av kunderutiner uten godkjenning. |
Dokumentene kan være organisert i en Obsidian Vault og LLM Wiki, slik at forskeren får korte, godkjente noter fremfor en usortert filserver. Da blir oppgavetavlen ikke bare en liste med AI-arbeid, men en synlig arbeidsflyt med sporbar kontekst.
Review er ikke det samme som at en agent sier «ser bra ut»
Når agenter lager og vurderer arbeid i samme loop, oppstår en åpenbar risiko: De kan dele samme gale antakelse. Derfor bør review ha en egen sjekkliste, andre kilder eller en annen testmetode.
Eksempel på enkel reviewregel: Et prosessutkast får ikke gå videre før det viser hvilke tre kilder det bygger på, hva som er usikkert, hvilke roller som får nye oppgaver, og hvilken handling som er reverserbar. Et kodeutkast får ikke gå videre før vanlige tester, sikkerhetssjekk og menneskelig review har passert.
Dette bygger videre på Anti-Trendslop-skillen: Bruk eval-drevne loops som forbedrer en leveranse mot synlige kriterier, ikke selvforsterkende loops som bare produserer mer tekst med mer selvtillit.
Et driftsnært eksempel: undersøk først, endre senere
En video kan vise et digitalt IT-team som finner en mulig årsak til en nettverksfeil eller en agent som bruker en ekstern sikkerhetstjeneste. Den forsvarlige første piloten er langt smalere:
| Rolle | Tillatt første oppgave | Ikke tillatt uten særskilt godkjenning |
|---|---|---|
| Undersøker | Lese status, logger og godkjente hendelser; lage en kort feilhypotese med kilder. | Kjøre kommandoer som endrer nettverk, tjenester eller kontoer. |
| Sikkerhetsagent | Varsle om mulig eksponering og lage en sak til ansvarlig person. | Nullstille passord, sperre brukere eller hente bredere data på egen hånd. |
| Utfører | Lage endringsforslag i sandbox eller egen kode-branch. | Deploye, merge, åpne brannmur eller skrive til produksjonsdata. |
| Reviewer + menneske | Sjekke test, påvirkning, rollback og hvem som varsles. | Godkjenne egen leveranse uten en uavhengig kontroll. |
Dette er forskjellen mellom et AI-team som gir bedre oversikt, og en uforutsigbar samling med nøkler til produksjon. Bruk Buzz AI hvis dere også trenger et felles rom for kanalhistorikk og samarbeid med agenter; bruk Paperclip og Hermes når målene, oppgavene, budsjettet og reviewløpet må styres tydelig.
Start med en tavle, ikke en autonom «bedrift»
Det er fristende å sette opp mange roller, agenter og bakgrunnsjobber fra dag én. Men jo flere overleveringer, integrasjoner og rettigheter dere legger inn, desto vanskeligere blir det å feilsøke og ta ansvar.
Start med én oppgave som er hyppig nok til at dere merker verdien, men trygg nok til at den kan stoppes: sammenligne dokumenter, lage ukentlig avviksrapport, forberede testtilfeller eller oppdatere et utkast til intern rutine. Bruk ett mål, to eller tre roller, et lite budsjett og et fast reviewpunkt.
| Før dere legger til en ny agent | Spør dette |
|---|---|
| Gir rollen et reelt nytt perspektiv? | Hvis ikke, er det ofte bedre med én agent og en god sjekkliste. |
| Kan oppgaven spores fra input til resultat? | Krev kort, kilder, testresultater og tydelig overlevering. |
| Hva skjer når oppgaven feiler eller blir uklar? | Den må blokkere og varsle. Den skal ikke finne på ny tilgang eller oppgave på egen hånd. |
| Hva er den største mulige konsekvensen? | Legg handlinger med kunde-, økonomi-, HR-, sikkerhets- eller produksjonseffekt bak menneskelig godkjenning. |
| Kan testen reverseres? | Begynn med leseoppgaver, utkast og sandbox før skriving, utsending eller deploy. |
Bruk 4D til å bestemme hvor langt teamet får gå
Paperclip, Hermes Kanban og andre agentplattformer er verktøy. De tar ikke avgjørelsen om hvilke oppgaver virksomheten faktisk bør delegere. Bruk 4D-rammeverket for å avgjøre dette før dere kobler på nye agenter.
| 4D | Spørsmål for et lite AI-team |
|---|---|
| Delegering | Er dette en avgrenset, reverserbar oppgave — eller krever den faglig skjønn og ansvar? |
| Beskrivelse | Hvilke kilder, verktøy, budsjett, tidsfrist og ferdigkriterier gjelder? |
| Dømmekraft | Hvilken uavhengig test eller person kontrollerer leveransen før den går videre? |
| Aktsomhet | Hvem kan stoppe løpet, tilbakeføre endringer og informere berørte dersom noe går galt? |
Når disse svarene er på plass, kan agenter gjøre mer av det kjedelige og sporbare arbeidet. Uten dem er «agenter som styrer agenter» ofte bare et komplisert system for å miste oversikt fortere.
Kilder
[3] Nous Research — Hermes Paperclip Adapter
