An Inbox for Your Agents: AWS Open-Sources Pizza Bot, Born From 2,000 Internal Users

On September 10, 2026, AWS quietly published a blog post titled “Introducing Pizza Bot, an open source inbox for AI agents that work in the background.” By the weekend it had crossed into the broader tech press. The premise is deceptively simple, and it lands on one of the most awkward unsolved problems in consumer-facing AI tooling: chat windows are a terrible interface for work that takes longer than thirty seconds.

Pizza Bot is a self-hosted, open source application — Apache 2.0, community project, no AWS support contract or SLA behind it — that runs AI agents in the background and surfaces their output in an email-style inbox. The agent comes back to you when it has finished something, or when it is genuinely stuck and only a human can decide. Not before.

The problem it names out loud

The AWS post opens with a diagnosis anyone who has used an agent product will recognize. Give an agent a task actually worth delegating and you’ll be waiting a while. Ask it what needs your attention this morning and it has to read your mail, your messages, and your task list before it can answer. Then it stops halfway, because one step needs your approval. Meanwhile you’re watching a chat window — or a terminal — scroll. “That is babysitting, not collaboration.”

The design answer is borrowed from the oldest asynchronous collaboration tool we have: email. You don’t send a message and then sit watching the outbox until the reply lands. Live chat assumes both parties are present, which holds for a quick exchange and breaks the moment a task takes several minutes, waits on approval, or runs on a schedule while you’re away. Pizza Bot treats an agent the way you’d treat a colleague who has gone off to do work: it comes back when there’s something to read, or something only you can decide.

What actually shipped

The interface is built around three queues. Unread collects finished work awaiting your review. Action collects runs paused for an approval or an answer — and those pauses are durable, so you can respond an hour later, from a different device, without killing the run. All is the thread history, and threads can be organized into folders without hiding matching work from the global queues. An Activity panel shows work the main agent delegated to specialist workers, including each specialist’s own transcript, so a long task stays legible while it’s still running.

Under the hood, the runtime is stateful. Pizza Bot is built with DeepAgents on LangGraph, which checkpoints a run as it proceeds — messages, tool activity, and pending approval pauses land on disk rather than in memory. A Hono API server owns execution and storage; Electron desktop, browser, and terminal CLI clients all talk to it over HTTP and server-sent events. Because the work lives on the server, a run keeps going when you close the thread, reload the page, or switch devices, and a reconnecting client replays what it missed.

The scheduling model is notably thoughtful. The server owns cron schedules and secret-protected webhooks, records every occurrence, and — when it wakes up after being off — runs a missed schedule once rather than replaying every occurrence it slept through. A machine that spent a month switched off gives you one result instead of thirty.

Local-first, provider-agnostic, and explicit about trust

Two positioning choices separate Pizza Bot from the hosted-assistant wave. First, it is self-hosted with no telemetry: the server binds to 127.0.0.1 by default, and a non-loopback deployment requires an API token plus an explicit origin allowlist. All state — threads, checkpoints, memories, attachments, settings, logs — lives in one folder you own (default ~/.pizza-bot-oss) as SQLite databases and ordinary files. One folder holds everything worth backing up.

Second, the model provider is a menu, not a mandate: Amazon Bedrock, Anthropic, Google Gemini, OpenAI, OpenRouter, or a local model through Ollama. The post is candid that prompts and attachments go to whichever provider you chose, and that MCP servers you enable can act on your behalf — “which is worth remembering when you install one.” Credentials go to the operating system’s secret store rather than a plaintext config, and are never sent to a browser client. Local disk is out of reach until you grant access to a specific folder, read-only or read-write, per grant.

The extensibility story leans on conventions the ecosystem already has. Tools come from MCP servers (a Claude Code-compatible .mcp.json drops straight in), and specialists are defined as Agent Skills — the Markdown SKILL.md convention Anthropic introduced. Each skill declares its own short list of tools and an interruptOn approval policy, with allowedDecisions controlling which buttons you get; an “edit” decision lets you correct what the agent proposed rather than rejecting the run and starting over. Keeping each specialist’s tool list short is the point: delegated tasks stay focused, and the agent’s total reach is reviewable at a glance.

Provenance, and the caveats that come with it

Pizza Bot is not a greenfield experiment. It began inside Amazon, where the authors say more than 2,000 people used earlier versions for meeting preparation and follow-ups, email drafting, Slack summaries, CRM logging, day prioritization, and web research. The name comes from Amazon’s two-pizza teams — small teams with broad ownership. The public version was rebuilt from the ground up as an open source project, something the authors credit coding agents with making practical for a small team (“Chefs” Joseph Dolivo and Igor Fil, plus four named contributors).

The caveats are stated plainly. It’s a community project, not an AWS service — keeping it running, backed up, and updated is your job. And it is “young in a particular way”: most of its day-one usefulness inside Amazon came from an internal marketplace of ready-made skills and MCP servers built against Amazon’s own tools, which were stripped out during the rebuild. Replacing that library for the systems the rest of us use is explicitly where the team says it most needs help.

The GitHub repository (76 commits at time of writing, 109 stars and climbing, macOS builds signed and notarized, SHA256SUMS attached to every release) shows the shape of a real product rather than a demo: a monorepo with an api-server, CLI, desktop shell, and web client; isolated runtime packages; LangGraph compatibility and protocol conformance tests.

Why this matters

Most agent tooling in 2026 is aimed at people who are building something. Pizza Bot is aimed at people who just need the work done — and its founding interface assumption is one sentence long: the interface assumes you are not watching. Nothing else in the current landscape, the authors claim, starts there. Whether or not that’s literally true, it’s the right framing for where consumer agents are heading: away from sessions you attend and toward threads you return to.

The inbox metaphor is doing more work than it appears to. Email needed no explanation — threads, unread state, search, pinning, notifications — because a billion people already know how to read a queue. Mapping agent labor onto that grammar converts ambient AI from a thing you supervise into a thing you triage. Combined with durable approvals, checkpointed runs, and local-first data ownership, Pizza Bot is one of the more complete open-source answers yet to the question of what an agent product looks like when it stops pretending to be a chatbot.