Your AI Agents Need an Inbox, Not a Chat Window: What AWS's Open Source Pizza Bot Teaches Businesses

Last Updated: October 5, 2026

Key Takeaways

• AWS open sourced Pizza Bot on September 10, 2026: a self-hosted, Apache 2.0 licensed email-style inbox for AI agents that work in the background.
• More than 2,000 Amazon employees used earlier versions for meeting prep, email drafting, Slack summaries, and CRM logging before the open source rebuild.
• The core pattern: finished agent work lands in an Unread queue, pending decisions land in Action, and an Activity panel shows what the main agent delegated to specialists.
• Everything lives on your machine: one folder holds threads, checkpoints, memories, and logs as SQLite and plain files, with an explicit list of what may leave.
• For a business, the pattern matters more than the product: agents that checkpoint to disk, ask before consequential actions, and come back when done, on infrastructure you control.

Give an AI agent a task worth delegating and you end up watching a chat window scroll. Ask it what needs your attention this morning and it reads your mail, your messages, and your task list before answering, then stops halfway because one step needs your approval. That is babysitting, not collaboration. According to Joseph Dolivo and Igor Fil, the two AWS maintainers who shipped the project, Pizza Bot is an open source application that runs agents in the background so the agent comes back to you when it is finished or stuck, "and not before."

The release landed on September 10, 2026, and The New Stack and InfoQ both covered it within four weeks. Under the hood it runs on DeepAgents and LangGraph, LangChain's stateful agent runtime, an interesting choice given AWS ships its own Strands Agents SDK. This post unpacks the inbox pattern itself, because that pattern, not the particular app, is what a business should steal.

What is Pizza Bot?

Pizza Bot is a finished desktop application that runs AI agents in the background and collects their work in an inbox shaped like an email client. It was built inside Amazon, where more than 2,000 people used earlier versions for meeting preparation, email drafting, Slack summaries, CRM logging, and web research. The code now lives in its own GitHub organization under the Apache 2.0 license: 428 stars and 40 forks at the time of writing, with signed builds only on macOS so far. It is a community project, not an AWS service, so there is no AWS support or SLA; keeping it running, backed up, and up to date is yours.

Why an inbox, not a chat window?

Because live chat assumes both parties are present, and agent work breaks that assumption constantly. A thread that takes 20 minutes, pauses for your approval, or fires on a schedule has nothing to do with a chat bubble. The authors draw the line with an email analogy: you don't send a message and then watch the outbox until the reply lands. A thread is a unit of work you come back to, not a session you have to attend.

The design rests on four requirements the team saw across every workflow they built: the agent inspects several sources, prepares a result in the background, asks before taking a consequential action, and comes back to the person who asked. None of those describe how anyone uses a chat window. They describe how people already work with each other.

The inbox resolves into three queues you already know how to read. All is the thread history. Unread is completed work you have not looked at yet. Action is work paused, waiting on your approval or your answer. Alongside them, an Activity panel shows what the main agent handed to specialist agents, each with its own transcript, so a long task stays legible while it runs.

"The interface assumes you are not watching," the authors write. "Nothing else we've seen starts there, and that one assumption is what buys you pauses that outlast the session that created them, notifications worth acting on, and scheduled work that produces threads instead of logs." That sentence is the whole thesis, and it echoes what LangChain's Harrison Chase called "ambient agents" back in January 2025: agents that respond to event streams and involve a human only when needed. Pizza Bot's maintainers credit that article as inspiration on Hacker News. LangChain built a reference Agent Inbox; Amazon shipped the polished product.

How Pizza Bot works under the hood

Pizza Bot splits into a server and a client. The server runs the agent, owns its state, and answers over HTTP. The client is whatever you are looking at: an Electron desktop app, a browser, or a terminal. Because work lives on the server, a run keeps going when you close the thread or switch devices, and a reconnecting client catches up on what it missed. Put the server on an always-on machine or a container and your schedules fire while your laptop is closed.

The runtime is DeepAgents on LangGraph, which checkpoints a run as it proceeds, so messages, tool activity, and a pause waiting on your approval live on disk rather than in memory. Everything sits in one folder you control: threads, checkpoints, memories, attachments, settings, and logs, as SQLite databases and ordinary files. One folder holds everything worth backing up. A machine that slept through a schedule gives you one run of the missed occurrence instead of replaying thirty.

The ecosystem story is where the internal version truly differed. Most of Pizza Bot's day-one usefulness inside Amazon came from an internal marketplace of ready-made skills and MCP servers for Amazon's own systems, which came out during the rebuild. What ships today is a generalist main agent, two bundled skills (browser automation via Playwright MCP, and a guide to Pizza Bot itself), and a framework: skills written as ordinary SKILL.md files, two directives added. A tools list restricts which MCP tools a specialist may call, keeping its reach reviewable at a glance. An interruptOn policy forces approval before specific tools run, with an edit decision that lets you correct a proposal instead of rejecting the whole run. A Claude Code-compatible .mcp.json drops straight in.

What leaves your machine, and what never does

The data boundary is explicit. Pizza Bot sends prompts and attachments to the model provider you chose, and tool calls to the MCP servers you enabled. Those servers can act on your behalf, which the authors flag as worth remembering when you install one. Provider credentials go to the operating system's secret store, never a plaintext config file, and never to a browser client. A remote deployment requires an API token and an explicit allow-list of origins before the server will serve a remote client. Model choice is yours: Anthropic, Amazon Bedrock, Google Gemini, OpenAI, OpenRouter, or a local model through Ollama, which matters when data should not leave at all.

In our own fleet at Flowtivity we run Hermes agents on dual NVIDIA DGX Spark machines with local DeepSeek models, and the boring details decide adoption: checkpointing that survives a disconnect, secrets that never sit in a config file, and one folder to back up. Pizza Bot ships all three defaults. That local-first discipline is why an inbox pattern lands better with compliance-sensitive teams than a hosted chat product, and it is the same reason we put hot-loading and subprocess isolation in our own stack.

Running it yourself: a quick-start checklist

Getting a background-inbox agent running in a business is a step-by-step job. According to the project's own release builds and docs, here is the order that works:

• 1. Pick a host that stays on. A spare desktop, a container, or a small server. The desktop app quits stop their own server, so an always-on host is what makes schedules trustworthy.
• 2. Configure a provider. Point it at your chosen API or a local model via Ollama. Credentials land in the OS secret store.
• 3. Drop in your .mcp.json. Existing Claude Code-compatible server configs work as-is; install-time confirmation is explicit because MCP servers run code with your permissions.
• 4. Write one SKILL.md. Start with one real workflow, give it a short tools allow-list, and set interruptOn on the tools that touch anything consequential.
• 5. Turn on Automations. Cron schedules and secret-protected webhooks live on an always-on server, and every occurrence is recorded.
• 6. Back up the data folder. One folder (default ~/.pizza-bot-oss) holds everything: copy it with the server stopped.
• 7. Pilot with a small team. Inside Amazon this spread from engineers to less-technical teams, who needed a real UI rather than a terminal. That is the adoption path a business should expect.

Where Pizza Bot fits in a business stack

It fits where the work is asynchronous but not fully autonomous. Meeting prep that assembles a brief before the meeting and waits in Unread. CRM logging that fires after customer calls on a webhook. Day-prioritization that runs at 7am and leaves a thread. Research that inspects ten sources, drafts the memo, and asks one question before it publishes anything. Those were the internal Amazon workflows, and none of them need a chat window.

Be skeptical in the right places. Hacker News commenters praised the asynchronous model and local-first architecture while asking the fair question: can an open source project recreate the ecosystem of skills and integrations that made the internal version successful? Structured output enforcement, one commenter's must-have, does not work out of the box yet (tracked in the repo's issue tracker). The desktop app is Electron, 145 to 160 MB per build. And the honest limitation the authors state themselves: the day-one magic inside Amazon came from a marketplace of internal skills and MCP servers nobody outside can use. Budget your time for writing skills, not just installing the app.

The takeaway for business AI

Chat was the demo pattern for AI agents; the inbox is the production pattern. It gives you attention-appropriate notifications, a durable pause for approvals, schedules that leave artifacts rather than logs, and a data boundary you can draw on one page. Pizza Bot is the most credible open source implementation of it to date, free under Apache 2.0, with 2,000 internal users as prior art. You can adopt the app, or adopt the pattern in your own stack: checkpointed runs, an Unread queue for finished work, an Action queue for decisions, and specialists whose tool reach is reviewable at a glance. Either way, the chat window was never where agent work belonged.