AWS Releases Pizza Bot, an Open Source Inbox for Background AI Agents

The tool ships as desktop builds for macOS, Windows and Linux, alongside browser and terminal clients that connect to either a local or a standalone backend. Its code is licensed under Apache 2.0.

Pizza Bot splits work into three inbox views: All, which holds thread history; Unread, for completed work awaiting review; and Action, for work that has paused to await approval or an answer. Threads can be organized into folders, and an Activity panel shows the delegated workers running on a user's behalf. Tasks can be started manually, on cron schedules, or through webhooks. Scheduling belongs to the server, so after downtime missed cron intervals produce a single catch-up run instead of replaying every interval that was skipped, and trigger occurrences are recorded durably.

The runtime is built on DeepAgents and LangGraph for stateful execution, with a Hono API server owning runtime execution and storage. Electron and browser clients share a React interface, and all clients communicate with the server over HTTP and server-sent events. LangGraph checkpoints retain thread state and approval pauses, while separate SQLite stores hold cross-thread memory and application metadata. Reconnecting clients can replay buffered events, and closing a thread or disconnecting a client does not stop a running server.

Quitting the desktop application behaves differently: it stops the embedded server and ends active runs. Checkpoints preserve the thread, but the step in flight can be lost, so an always-on backend is required for work to continue after the desktop app exits. Each SQLite data directory supports one backend process.

Pizza Bot supports Amazon Bedrock, Anthropic, Google Gemini, OpenAI, OpenRouter and Ollama, and a provider must be configured under Settings > Providers before tasks run. The agent has scratch-file operations and a sandboxed JavaScript interpreter without network or host-filesystem access, and can delegate through task when ready skill workers exist. The filesystem layer separately supports explicit folder grants and persistent memory. MCP servers expose external tools, and each SKILL.md file defines a worker's instructions and scoped tool access; a skill becomes callable only when its declared dependencies are available. Existing Claude Code-compatible .mcp.json configurations are supported, and plugins package skills together with MCP servers.

Approval controls are configured tool by tool. Skill authors set interruptOn and allowedDecisions to require approval for specific tools, and depending on that policy users can approve an action, edit its proposed arguments, or reject it. MarkTechPost noted that these controls must be set for the relevant tools, and that configured providers and tools can receive task data.