Vi har lenge snakket om AI som et verktøy vi bruker ved siden av arbeidet vårt. Men hva om AI-en faktisk var en del av teamet ditt? Det er nettopp dette Buzz AI, et nytt prosjekt fra Block (selskapet til Jack Dorsey), prøver å løse.
Buzz er ikke en ny chatbot. Det er et komplett arbeidsområde — tenk deg en blanding av Slack, GitHub og prosjektstyringsverktøy — der AI-agenter er fullverdige medlemmer av kanalene dine.
Fra chatbot til kollega
I Buzz fungerer AI-agenter på samme måte som menneskelige kolleger. Du legger dem til i en kanal med et tastetrykk. Men i motsetning til en enkel bot, har disse agentene sine egne digitale identiteter og nøkler. De kan åpne kodelagre, sende endringsforslag, vurdere kollegers arbeid og til og med delta i digitale statusmøter.
Dette skaper en helt ny dynamikk. Se for deg at du åpner en kanal for et nytt prosjekt. En AI-agent kan automatisk triagere feilmeldinger, foreslå løsninger og be om din godkjenning før den sender ut en oppdatering. Alt skjer i den samme tråden der du og teamet ditt diskuterer strategien.
"Incident Memory": Bedriftens kollektive hukommelse
En av de mest spennende funksjonene i Buzz er det de kaller "Incident Memory". Se for deg at det oppstår en kritisk feil klokken to om natten. Du spør i kanalen: "Har vi sett denne feilen før?".
En agent som har overvåket kanalen i månedsvis, søker umiddelbart gjennom all historikk. Den presenterer ikke bare vage svar, men viser til konkrete diskusjoner fra seks måneder tilbake, forklarer hva rotårsaken var den gangen, og foreslår hvem som bør kontaktes basert på hvem som fikset det sist.
Egen drift og sporbarhet – med reelt driftsansvar
Buzz er bygget rundt en Nostr-relay og kan selvhostes. I den enkleste distribusjonen betyr det at ett relay betjener ett arbeidsområde. Mennesker, agenter, arbeidsflyter og git-hendelser kan publisere signerte hendelser i samme logg, slik at samtaler, review og handlinger blir søkbare i sammenheng.
Dette kan være interessant når et teknisk team vil eie hvor prosjektkontekst og agenthistorikk ligger. Men selvhosting er ikke det samme som at sikkerheten er ferdig. Dere må fortsatt drifte relay, database, lagring, oppgraderinger, sikkerhetskopi, brukeridentiteter og tilganger. Hvilken sporbarhet dere faktisk får, avhenger også av at hendelser, logger og oppbevaring er satt opp riktig.
Buzz, ChatGPT Dots, Grok Bot og OpenRig
Buzz passer godt inn i samme utvikling som ChatGPT Dots, Grok Bot og OpenRig, men de løser ulike problemer.
| Løsning | Det viktigste den tilfører | Hva dere må eie |
|---|---|---|
| Buzz AI | Felles arbeidsrom for mennesker og agenter, med kanaler, prosjektminne, git-hendelser og sporbar historikk | Egen relay og driftsopplegg hvis dere selvhoster |
| ChatGPT Dots | En produktisert, vedvarende agent med sky-datamaskin og godkjenningssteg | Tilkoblede apper, dataflyt og tilgangsgrenser |
| Grok Bot | Flere skybaserte AI-kolleger som kan arbeide parallelt | Beta-testing, tilganger og godkjenning av handlinger |
| OpenRig | Koordinering av harnesser og roller i tekniske kodeprosjekter | Miljø, terminalkompetanse, modellvalg og agenttilganger |
Kort sagt: Dots og Grok Bot handler mest om hva en agent gjør. Buzz handler om hvor mennesker og agenter samarbeider og etterlater en felles historikk. OpenRig handler mest om hvordan tekniske harnesser og roller organiseres.
Hva videoene viser – og hva som fortsatt er umodent
De to videoene nedenfor viser Buzz som et felles digitalt kontor: mennesker og agentprofiler deler kanaler, oppgaver, kode og status. De viser også kombinasjonen Buzz + Paperclip + agentruntime på en VPS. Dette er relevante demonstrasjoner for tekniske team, men de må ikke tolkes som at alle deler er klare for kritisk drift.
Buzz sin egen dokumentasjon er mer presis enn en demo: selve reléet, identitet, søk, revisjonslogg, huddles og YAML-baserte workflows er dokumentert som tilgjengelige. Huddles har taleoverføring og livssyklushendelser, men opptak og spor-publisering er fortsatt planlagt. Workflow-motoren kan trigges av meldinger, reaksjoner, tid eller webhooks og lagrer spor, men godkjenningssteget som faktisk skal sette en kjøring på vent og fortsette etter godkjenning er fortsatt under utvikling. I nåværende dokumentasjon blir en kjøring som treffer et slikt `request_approval`-steg markert som feilet. [1] [2]
Det er en viktig forskjell: Et synlig «Approve»-grensesnitt er ikke nødvendigvis en teknisk håndhevet sikkerhetsport i alle arbeidsflyter ennå. Kritiske handlinger må derfor fortsatt være blokkert av tilgangsregler i underliggende systemer, egne testmiljøer og menneskelig kontroll – ikke bare av en agentinstruks.
Drift 24/7: VPS gir tilgjengelighet, ikke automatisk kontroll
En agent på en lokal Mac forsvinner når maskinen sover eller slås av. En VPS kan være et fornuftig sted å kjøre en avgrenset agent eller en Buzz-relay hvis oppgaven faktisk trenger tilgjengelighet døgnet rundt. Men da overtar dere ansvaret for oppdateringer, sikkerhetskopi, hendelseslogger, hemmeligheter, nettverk, kostnadsgrenser og hvem som kan koble seg til.
Start derfor ikke med en «autonom bedrift». Start med én intern kanal, ett prosjekt, avgrenset lesetilgang og et menneske som vurderer alle endringer. Paperclip- og Hermes-artikkelen viser hvordan oppgaver, review og stoppekriterier kan holdes synlige rundt et slikt team.
Er dere klare for hybrid-teamet?
Buzz er fortsatt i Developer Preview. Det er lovende for utviklingsteam som ønsker å teste et felles agentarbeidsrom, men det er ikke en grunn til å flytte kritisk kommunikasjon, produksjonstilganger eller kundedata inn i løsningen uten en avgrenset pilot.
Start heller med ett internt prosjekt, én eller to tydelige agentroller og lesetilgang til et avgrenset repo eller en kanal. La mennesker godkjenne patcher, eksterne meldinger og endringer i tilgang. Når samarbeidet er synlig og forutsigbart, kan dere gradvis utvide.
Hvis du vil utforske hvordan din bedrift kan begynne å bygge slike hybrid-team, kan du lese mer om hvordan koble systemer sammen med Composio eller se vår guide til Claude Cowork.
Vil du teste Buzz selv? Les utviklerforhåndsvisningen på buzz.xyz og se kildekoden på GitHub.
