Pizza Bot, an AI-agent workspace developed at Amazon, has been released as an Apache 2.0 open-source project. Its central idea is operational rather than conversational: users start or schedule work, leave the interface, and return to an inbox where completed tasks appear in Unread and tasks requiring a human decision appear in Action.
That design addresses a persistent mismatch in current agent tooling. Chat interfaces assume an operator stays present for a back-and-forth exchange. Many useful business tasks—research, document preparation, monitoring, multi-step workflows and delegated tool use—take longer and may need a review or approval at an unpredictable point.
What changed
Pizza Bot combines a stateful DeepAgents/LangGraph runtime with desktop, browser and command-line clients. Those clients communicate with an API server over HTTP and server-sent events; the server must remain running for work to continue after a user closes or disconnects from a client.
The project supports scheduled and webhook-triggered runs, checkpointing, file attachments, long-term memory, desktop notifications and human-in-the-loop approval gates. It can also delegate work to specialist subagents built from skills, with activity shown in the interface.
For model access, Pizza Bot supports Amazon Bedrock, Anthropic, Google Gemini, OpenAI, OpenRouter and Ollama. It also supports Model Context Protocol (MCP) servers, custom skills and plugins—extensibility options that let teams connect agents to their own tools and workflows.
Why the inbox matters
The relevant product pattern is not simply “another agent UI.” It is a queue for supervising asynchronous software work.
For an operator, separating finished work from decisions awaiting attention creates a clearer handoff point than an open chat thread. A task can run in the background; the human is pulled back in only when review is needed. For teams experimenting with agent-assisted operations, that can make it easier to define accountability: agents prepare, investigate or execute within granted limits, while people retain control over consequential actions.
Pizza Bot’s architecture also separates the front ends from the runtime and model bindings. That matters for organizations that want agents accessible from a desktop application, a browser, scripts or a remote backend without rebuilding the core workflow logic for each interface.
The project says more than 2,000 Amazon users tested earlier versions internally. Its release under Apache 2.0 means developers can inspect, adapt and deploy the system without being locked into one hosted agent product.
Deployment and security trade-offs
The flexibility comes with operating responsibility. The default API server binds locally to `127.0.0.1`, while non-local binding requires authentication and an explicit origin allowlist. By default, threads, checkpoints, memories, attachments and logs are stored locally under the Pizza Bot data root.
Access to local files must be explicitly granted on a folder-by-folder basis, with read-only as the default. But MCP servers and plugins are explicitly trusted components: they may execute commands with the permissions of the user account. That makes plugin review, least-privilege file grants, secret handling and audit practices important before connecting the system to production data or systems.
Teams also need to operate a persistent backend and configure a model provider. The desktop app can supervise its embedded server, while browser, CLI and remote deployments can use a standalone backend. The project requires Node.js 24 or later for development from source.
What to watch next
Pizza Bot’s adoption will depend less on its chat experience than on whether its approval queues, checkpoints and integrations hold up in real operational workflows. Builders should test a narrow, repeatable process first: define what the agent may access, specify which actions require approval, and measure whether the resulting review queue reduces—not adds to—operator overhead.
More broadly, the release is a useful signal of where agent interfaces may be heading. As agents handle longer tasks, the durable unit of work may increasingly be an inbox item with a state, a record of activity and a clear human decision point—not a transient conversation.
