AWS frigiver Pizza Bot som open source inbox for baggrundsagenter
Mange agent-interfaces forstyrrer for meget eller giver for lidt kontrol. Pizza Bot går efter det simple: et indbakke‑UI, hvor færdige leverancer og ventende beslutninger lander pænt sorteret, uden at kapre din skærm. AWS har gjort projektet offentligt som open source. Det er værd at bemærke, fordi formfaktoren afgør, om agenter kan leve i hverdagen – ikke kun i en demo.
Kernen er selv‑hosting: kør en backend, tilslut en klient, start opgaver. Når noget kræver godkendelse, parkeres det i Action. Når noget er færdigt, ligger det i Unread. Alt andet samles i All. Den enkle opdeling reducerer støj og bevarer overblikket.
Hvad Pizza Bot er, set fra brugerens stol
Pizza Bot organiserer tråde som en mailklient. Ifølge MarkTechPost er der tre visninger: All for hele trådhistorikken, Unread for færdigt arbejde, der venter på review, og Action for arbejde sat på pause, fordi agenten beder om input eller godkendelse. Man kan mappe tråde i mapper og følge de delegerede arbejderes aktivitet i et Activity‑panel. Ambitionen er at gøre agenter til en håndterbar del af arbejdet – ikke en konstant afbrydelse.
Fra intern prototype til offentlig release
Den offentlige udgave beskrives som genopbygget og udgivet under Apache 2.0‑licens (MarkTechPost). Uden et offentligt repository, en LICENSE‑fil og releases at pege på er licensen endnu ikke endeligt verificeret. Når repo’et er tilgængeligt, bør man tjekke LICENSE i roden og versionsmærkede assets under Releases.
Arkitekturen i mellemdybde
Ifølge MarkTechPost bruger Pizza Bot DeepAgents og LangGraph til tilstandsfuld eksekvering. En Hono‑baseret API‑server ejer runtime og lagring. Klienterne – Electron og browser – deler et React‑interface og taler med serveren via HTTP og server‑sendte events, så UI’et får en hændelsesstrøm uden hård polling.
LangGraph‑checkpoints fastholder trådens tilstand, inklusive pauser til godkendelser. Separate SQLite‑databaser holder tværgående hukommelse og applikationsmetadata. Når en klient forbinder igen, kan den afspille bufferede events – så overblikket bevares, forudsat at serveren kører videre.
Desktop kontra altid‑tændt backend
Lukker man desktop‑appen, stopper den indbyggede server og afbryder aktive kørsler. Checkpoints bevarer tråden, men det igangværende trin kan gå tabt. En altid‑tændt backend er derfor nødvendig, hvis arbejde skal fortsætte, når klienten lukkes. Valget står mellem lokal udviklingskomfort og robust serverdrift.
Opgaver kan trigges manuelt, efter cron‑skema eller via webhooks. Serveren ejer planlægningen. Efter nedetid laves der ifølge MarkTechPost én catch‑up‑kørsel for missede cron‑intervaller – ikke afspilning af alle forpassede tider.
Modelleverandører og konfiguration
Pizza Bot understøtter Amazon Bedrock, Anthropic, Google Gemini, OpenAI, OpenRouter og Ollama. Ifølge MarkTechPost konfigureres det via Settings > Providers, før man kører sine agentopgaver. Det giver fleksibilitet til at matche opgave og model uden at omskrive flows.
Omkostninger og latency varierer. AWS’ blog anbefaler at styre efter pris per korrekt leveret resultat – og i agent‑sammenhæng også antal turns – frem for kun tokenpris. Det er relevant, når man skifter mellem leverandører: færre turns og højere træfsikkerhed kan slå en lav tokenpris i praksis.
Sikkerhed og styring
MarkTechPost beskriver en sandboxet JavaScript‑fortolker uden netværks‑ eller host‑filsystemadgang, plus en filsystem‑layer med eksplicitte folder grants og persistent memory. Eksterne værktøjer eksponeres via MCP‑servere, og hver SKILL.md afgrænser instruktioner og værktøjsadgang. En skill er kun kaldbar, når dens deklarerede afhængigheder er opfyldt.
Godkendelser kan kræves via interruptOn og allowedDecisions, så specifikke handlinger stoppes for review. De overordnede principper er fornuftige, men præcise sikkerhedsdetaljer for plugin‑modellen og håndhævelsen af sandbox‑begrænsninger kræver dokumentation i det faktiske repository.
Drift, backup og fejltolerance
Vil man tættere på produktion: kør en altid‑tændt backend, læg SQLite på vedvarende storage, tag regelmæssige backups, og test genstartsscenarier. Antag, at et igangværende trin kan tabes ved crash eller luk – design derfor workflows til at være idempotente.
Test catch‑up‑logik for cron i staging. Beskyt webhooks med signaturvalidering og rate‑begrænsning. Håndter credentials til modeludbydere via en hemmelighedstjeneste med rotation – ikke i flade konfigfiler.
Arbejdsprocesser og adoption
En beslutnings‑indbakke flytter arbejdet fra “spørg nu” til “godkend når det passer”. Aftal, hvem der godkender hvad, hvornår tråde skifter status, og hvornår noget er “godt nok” til at ramme systemer som CRM. Forvent friktion de første uger, og styr på den med tydelige regler.
Kør en lille pilot: 2‑3 workflows (mødeforberedelse, kundeopfølgning, basal CRM‑logging), klare godkendelsesregler, og mål tre ting: tid sparet pr. uge, manuelle rettelser, samt hvor ofte agenter stopper op.
Åbne spørgsmål og risici
Ingen operationelle benchmarks for CPU, hukommelse eller omkostninger ved kontinuerlig drift er dokumenteret her. Sikkerhedsmodellen for plugins og JavaScript‑sandkassen bør gennem et egentligt review, før man eksponerer følsomme værktøjer. Det er en nødvendig to‑do før stabil produktion.
Sammenligning med alternativer
Cloud‑hostede agent‑SaaS er hurtige at komme i gang med, men giver mindre kontrol over data og styring. Pizza Bots selv‑hosting giver kontrol over data, plugins og omkostninger – mod at man selv tager ansvaret for opgraderinger, overvågning og sikkerhed. I regulerede miljøer kan selv‑hosting være eneste udvej; for små teams kan en SaaS‑løsning være rigeligt.
En kort pilotplan der faktisk holder
Fire til seks uger er ofte nok til at afklare nytteværdien:
- Uge 1: Find repository og læs README. Deploy en backend i testmiljø. Bekræft at LICENSE ligger i roden, og at version er tagget.
- Uge 2: Konfigurér to modeludbydere under Settings > Providers. Læg credentials i en hemmelighedstjeneste. Kør en hello‑world‑skill.
- Uge 3: Automatisér to konkrete workflows med stopklodser i Action. Tænd audit‑logning og bevar checkpoints.
- Uge 4: Lav kontrolleret nedlukning og genstart. Verificér at cron laver én catch‑up. Mål tid, fejl og manuelle rettelser.
- Uge 5‑6: Finpuds governance: hvem må godkende hvad, log‑retention, credential‑rotation. Sammenlign omkostning per godkendt leverance på tværs af modeller – ikke kun tokenpris.
Kilder og hvad de dækker
Primær: MarkTechPost (funktioner, UI‑paradigme, arkitektur, providers, licensangivelse). Supplerende: AWS‑blog (omkostningsperspektiv: pris per korrekt leveret resultat og turns).
Min vurdering
Hvem bør prøve først? Teams med gentagne opgaver og naturlige godkendelsesstop – og som gerne ejer deres egen drift. Alle andre kan roligt vente et par versioner og se, om en hosted variant med samme indbakke‑tænkning dukker op.
Faktatjek og praktiske noter
Demomateriale: MarkTechPost omtaler en interaktiv micro‑lab/animation, der illustrerer All/Unread/Action samt forskellen på embedded desktop‑server og altid‑tændt backend. Brug den som visuel intro, når den er tilgængelig via artiklens side.
