Hi HN - long-time lurker (since 2012!), first time poster.
Pizza Bot is a self-hosted desktop app for Mac, Windows, and Linux that runs AI agents in the background and exposes them through an email-like UI. Finished work shows up in Unread, and anything waiting on your approval shows up in Action. It's Apache 2.0-licensed, there's no signup and no telemetry, and you bring your own model provider: Anthropic, Amazon Bedrock, Google Gemini, OpenAI, OpenRouter, or a local model through Ollama. There are builds on the releases page, or you can run it from source.
Pizza Bot started as an internal passion project I worked on with a small team at Amazon.
The whole thing came out of my frustration at having to manually log CRM activities through a browser form. I built a simple REST API called "JoeBot" that connected to my authenticated browser session over CDP and filled out the form for me using Playwright. Then I hacked up a quick Obsidian plugin so I could trigger it from my local notes (no AI and no MCP servers involved).
This caught on quickly. My fellow AWS Solutions Architect Igor Fil joined up with me, and we rebranded the project as "Pizza Bot," named after Amazon's two-pizza teams. We started seeing what other automations we could build. We found a GraphQL API we could query and hacked up some "recipes" to pull data out of the CRM to help with meeting prep. That worked great, and it was right around the time MCP servers seemed to be taking off, so we decided to expose Pizza Bot as an MCP server instead, so it would be available to AI tools through natural language.
This was a decent solution for technical users, but the Account Managers who live inside our CRM system wanted something too. We decided to rebuild Pizza Bot as an Electron desktop app modeled after an email inbox, so it would be familiar to non-technical users and would run on both Mac and Windows. We also bundled internal MCP servers as OCI images and hosted them in Amazon ECR as an "addon marketplace" so users could install them with one click without having to set up Amazon developer tooling.
The project took off organically and expanded outside of AWS into the wider Amazon organization globally. More than 2,000 people ended up using it for meeting prep, email drafting, Slack summaries, CRM logging, prioritizing their day, and web research.
Once apps like Claude Cowork and Amazon's own Quick Desktop came out, we realized the real growth opportunity was outside of Amazon. Rather than try to rip out the Amazon-specific integrations, we rebuilt Pizza Bot once more as an open source project. We leaned on coding agents heavily, which is the only reason a team our size could pull off a full rewrite. I'm pleased to say it's finally public, and we're hoping to bring in community members and see where it goes. We'd like to do for knowledge workers what Claude Code and Codex have done for programmers.
A couple of things to know up front. Most of what made Pizza Bot useful on day one inside Amazon came from that internal catalog of skills and MCP servers for Amazon's own systems, and none of it could come out with the app. So it ships thinner than the version those 2,000 people used, and building that catalog back up for tools other people actually use is where we need the most help. It's also a community project and not an AWS service, so there's no support or SLA behind it. The Windows and Linux builds aren't signed yet either.
On the technical side, Pizza Bot is a server and a client. The desktop app bundles both, or you can point a client at a remote backend; personally, I self-host the server on my home network and reach it from my phone over Tailscale. The server owns the thread lifecycle and checkpoints state with DeepAgents and LangGraph, and clients rehydrate from it as needed, so you can disconnect mid-run and pick the thread back up from another client. Approval pauses outlive the session that created them and collect in an Action filter, so you can answer an hour later from a different device. The agent you talk to has a sandboxed QuickJS interpreter that can reach your filesystem only if you grant it a folder, but its main job is to delegate. Each subagent is a 1:1 mapping of a Skill, and an Activity bar shows that subagent and the tool calls it's making as it works. Memory is opt-in and stored as plain markdown files on your machine. Every tool call is explicit, including looking up a memory - we err on the side of transparency to reduce surprises. Tools come from MCP servers, and skills are ordinary SKILL.md files with a per-tool approval policy, so existing skills that don't require a code interpreter should still work.
What I'd most like to hear about is where the app itself gets in your way, the kind of problem you can't fix by writing a skill or an MCP server. I'm around today to answer questions!
congrats on the public launch! it's been clear to me for a while now that agents will need their own ways to communicate and an asynchronous inbox/task system is a necessity already. will point my agents at the repo to see how we can leverage
Thanks! I was pleasantly surprised with how naturally a lot of email idioms seemed to align here. In retrospect, it makes sense if you think of human-to-agent communication as another form of asynchronous communication.
Think of Pizza Bot as the "harness"/interface your agents actually run in. You'd still hook up Linear via their MCP server (https://linear.app/docs/mcp) for "what needs doing." Pizza Bot is what handles the run itself (scheduling the interaction, routing tool-call approvals to you, and holding conversation/agent state).
The part that's actually different from "agent in a terminal" or "agent posting to Slack" is that it's built for having a bunch of these running at once. Instead of N terminal tabs or N ticket comment threads to figure out which agent is stuck waiting on you, they land in one inbox — jump between threads, see which ones are paused on an approval or a question, answer, and move on.
It’s both! The Releases page indeed links to the Electron app so it’s easy to get started, but you can also run just the backend and web app separately. I have it running in a Docker container on my home network that I connect to from my phone using Tailscale. Check out the docs here: https://github.com/pizza-bot-app/pizza-bot/blob/main/docs/ST...
This looks great. I've been playing around with GrokBot, and like a lot of what it does, but would much, much prefer an open source project to manage various asynchronous tasks.
What I like about GrokBot is the combination of freeform agent discussions, scheduled jobs, agent-to-agent communication, per-agent memory, and the fact that they all get a sandboxed instance with a browser. It's very well implemented. I think they have a very similar vision to yours.
Thanks for the feedback! I’ll give GrokBot a closer look. We’re focused on being open source and decoupled from any particular model provider, but it’s great to see a lot of capable tools popping up in this space.
We do ship a QuickJS code interpreter, but otherwise, sandboxing is something we deferred until after launch to make sure we have time to get it right. LangGraph / DeepAgents, which we’re built on, already have the right hooks in place, though. :)
Do you have a list of a few mcp servers or other tools you would add to help with the pizza-bot specific workflow? For example, how would you enforce structured output, should that be an mcp server, a plugin, already in the box?
There are so many! Personally, I’ve been able to get remarkably far with the built-in filesystem tools (courtesy of DeepAgents) paired with a web search MCP (Kagi is great!). Were there any particular workflows you had in mind?
I need to be able to enforce structured output easily (json, and xml if possible). That would be my number one slightly less than typical requirement.
Other than that, I like to insert agents into deterministic workflows, so some way to easily have deterministic steps (calling a script rather than delegating to an agent, but determined by the workflow rather than the agent). However this second one is likely out of scope for a while, since it is the inverse of the typical agent workflow. I could probably work this out clunkily by polling the cli from an external master script, but it would be cool to have it all inside the box.
Ah, this may actually work out of the box if you tell Pizza Bot to use its `task` tool to dynamically launch a subagent (which maps 1:1 with a Skill), and provide it with a `responseSchema`. I’ll test this when I’m back at a computer and report back!
Thanks! I'm not overly familiar with Paperclip, but from the website, it looks to provide orchestration over a fleet of existing agent harnesses, whereas with Pizza Bot, we run the execution loops for each agent ourselves (built on LangGraph / DeepAgents). We also stick to a "thread" model (similar to email), whereas Paperclip seems to work on a task-based model.
It's an interesting alternate UX framing, for sure. It's possible there are scenarios where a different abstraction makes more sense, but I'm personally curious to see how far we can extend the email idiom!
In our case, we wanted to borrow the UX of email (to be intuitive to knowledge workers) but not necessarily the implementation.
Full control of your data was a design principle from the beginning, including being able to run fully offline with local models, so we didn’t want to add a dependency on email.
With that said, you can certainly hook up an MCP server and have the agents read and send emails (with human-in-the-loop approval) on your behalf.
Had a bit of jankiness during setup as I fought with llama.cpp bugs. There are a few issues around models reported by the provider changing, refreshing as they change, had a few instances of "New Chat" showing one model then hitting llama.cpp with another, etc. Sorry, been traveling for a bit and didn't have the energy to properly recreate and put together a real bug report. Just a heads up that the onboarding there is a bit rough, though anyone running their own local models is probably more than able to get it figured out.
I'm really liking it. I wish I had something more substantial to say than "it's easy and clean" but... it's easy and clean. And as far as "AI tooling" goes, the setup was an absolute breeze even with the issues. The fact that I can just install a single app and go rather than spending hours and hours on setup, configuration, etc makes me way more likely to use this going forward... it's a lot easier to rely on a tool when I know it will be quick to fix if it breaks.
One note and one feature request, if you want 'em:
Though now that I understand the concepts better it's obvious, it _wasn't_ immediately obvious why the MCP server I added wasn't working. Tools are called via "tasks", and "tasks" are defined based on the skills. I had to create a skill. I'm sure it's somewhere in the documentation but I (and most people) don't read that kind of stuff, so would be good to surface somewhere obvious in the UI maybe?
And I would absolutely _love_ if you could override the provider and model per task. I run a small model locally as it's good enough for most of what I want to do (and cheap! and private!), but it would be great if I could define a "write-code" skill that was run via Claude instead or something so I could delegate tasks that aren't really suitable for a tiny local model out to something more capable.
Anyway... Cool tool. Hope to see it continue to grow and evolve! Thank you for releasing this!
Thanks so much for the feedback! The README arguably needs a diagram that shows the orchestrator-subagent delegation pattern and how they map to Skills, since you’re right - it’s not intuitive without reading the docs, and it’s somewhat unique from other agent harnesses I’ve seen.
The internal-only predecessor actually did let you specify the individual model for the subagent calls. DeepAgents supports this, so it shouldn’t be a big lift. I’ll add an issue on GitHub. Thanks for the request!
Pizza Bot is a self-hosted desktop app for Mac, Windows, and Linux that runs AI agents in the background and exposes them through an email-like UI. Finished work shows up in Unread, and anything waiting on your approval shows up in Action. It's Apache 2.0-licensed, there's no signup and no telemetry, and you bring your own model provider: Anthropic, Amazon Bedrock, Google Gemini, OpenAI, OpenRouter, or a local model through Ollama. There are builds on the releases page, or you can run it from source.
Pizza Bot started as an internal passion project I worked on with a small team at Amazon.
The whole thing came out of my frustration at having to manually log CRM activities through a browser form. I built a simple REST API called "JoeBot" that connected to my authenticated browser session over CDP and filled out the form for me using Playwright. Then I hacked up a quick Obsidian plugin so I could trigger it from my local notes (no AI and no MCP servers involved).
This caught on quickly. My fellow AWS Solutions Architect Igor Fil joined up with me, and we rebranded the project as "Pizza Bot," named after Amazon's two-pizza teams. We started seeing what other automations we could build. We found a GraphQL API we could query and hacked up some "recipes" to pull data out of the CRM to help with meeting prep. That worked great, and it was right around the time MCP servers seemed to be taking off, so we decided to expose Pizza Bot as an MCP server instead, so it would be available to AI tools through natural language.
This was a decent solution for technical users, but the Account Managers who live inside our CRM system wanted something too. We decided to rebuild Pizza Bot as an Electron desktop app modeled after an email inbox, so it would be familiar to non-technical users and would run on both Mac and Windows. We also bundled internal MCP servers as OCI images and hosted them in Amazon ECR as an "addon marketplace" so users could install them with one click without having to set up Amazon developer tooling.
The project took off organically and expanded outside of AWS into the wider Amazon organization globally. More than 2,000 people ended up using it for meeting prep, email drafting, Slack summaries, CRM logging, prioritizing their day, and web research.
Once apps like Claude Cowork and Amazon's own Quick Desktop came out, we realized the real growth opportunity was outside of Amazon. Rather than try to rip out the Amazon-specific integrations, we rebuilt Pizza Bot once more as an open source project. We leaned on coding agents heavily, which is the only reason a team our size could pull off a full rewrite. I'm pleased to say it's finally public, and we're hoping to bring in community members and see where it goes. We'd like to do for knowledge workers what Claude Code and Codex have done for programmers.
A couple of things to know up front. Most of what made Pizza Bot useful on day one inside Amazon came from that internal catalog of skills and MCP servers for Amazon's own systems, and none of it could come out with the app. So it ships thinner than the version those 2,000 people used, and building that catalog back up for tools other people actually use is where we need the most help. It's also a community project and not an AWS service, so there's no support or SLA behind it. The Windows and Linux builds aren't signed yet either.
On the technical side, Pizza Bot is a server and a client. The desktop app bundles both, or you can point a client at a remote backend; personally, I self-host the server on my home network and reach it from my phone over Tailscale. The server owns the thread lifecycle and checkpoints state with DeepAgents and LangGraph, and clients rehydrate from it as needed, so you can disconnect mid-run and pick the thread back up from another client. Approval pauses outlive the session that created them and collect in an Action filter, so you can answer an hour later from a different device. The agent you talk to has a sandboxed QuickJS interpreter that can reach your filesystem only if you grant it a folder, but its main job is to delegate. Each subagent is a 1:1 mapping of a Skill, and an Activity bar shows that subagent and the tool calls it's making as it works. Memory is opt-in and stored as plain markdown files on your machine. Every tool call is explicit, including looking up a memory - we err on the side of transparency to reduce surprises. Tools come from MCP servers, and skills are ordinary SKILL.md files with a per-tool approval policy, so existing skills that don't require a code interpreter should still work.
What I'd most like to hear about is where the app itself gets in your way, the kind of problem you can't fix by writing a skill or an MCP server. I'm around today to answer questions!
congrats on the public launch! it's been clear to me for a while now that agents will need their own ways to communicate and an asynchronous inbox/task system is a necessity already. will point my agents at the repo to see how we can leverage
Thanks! I was pleasantly surprised with how naturally a lot of email idioms seemed to align here. In retrospect, it makes sense if you think of human-to-agent communication as another form of asynchronous communication.
yep. as someone who is inbox zero and treats my inbox(es) as task management, it all makes sense to me!
Love it. Maybe "inbox zero" for agents would have been a better tagline! :)
I have a more basic question; I am trying to understand its purpose.
How does this compare with connecting your agent to your ticket tracker? Linear can dispatch the agents: https://linear.app/agents https://linear.app/docs/coding-sessions
If it is about local work, how does it compare with simply having your agent monitor a directory for ticket files?
Thanks for the question!
Think of Pizza Bot as the "harness"/interface your agents actually run in. You'd still hook up Linear via their MCP server (https://linear.app/docs/mcp) for "what needs doing." Pizza Bot is what handles the run itself (scheduling the interaction, routing tool-call approvals to you, and holding conversation/agent state).
The part that's actually different from "agent in a terminal" or "agent posting to Slack" is that it's built for having a bunch of these running at once. Instead of N terminal tabs or N ticket comment threads to figure out which agent is stuck waiting on you, they land in one inbox — jump between threads, see which ones are paused on an approval or a question, answer, and move on.
Let me know if that helps to clarify things!
Why does it have to be a desktop app vs a self hostable web app?
That way it can truly run asynchronously, even with the computer switched off.
It’s both! The Releases page indeed links to the Electron app so it’s easy to get started, but you can also run just the backend and web app separately. I have it running in a Docker container on my home network that I connect to from my phone using Tailscale. Check out the docs here: https://github.com/pizza-bot-app/pizza-bot/blob/main/docs/ST...
This looks great. I've been playing around with GrokBot, and like a lot of what it does, but would much, much prefer an open source project to manage various asynchronous tasks.
What I like about GrokBot is the combination of freeform agent discussions, scheduled jobs, agent-to-agent communication, per-agent memory, and the fact that they all get a sandboxed instance with a browser. It's very well implemented. I think they have a very similar vision to yours.
Thanks for the feedback! I’ll give GrokBot a closer look. We’re focused on being open source and decoupled from any particular model provider, but it’s great to see a lot of capable tools popping up in this space.
We do ship a QuickJS code interpreter, but otherwise, sandboxing is something we deferred until after launch to make sure we have time to get it right. LangGraph / DeepAgents, which we’re built on, already have the right hooks in place, though. :)
Why not use real email?
You mean giving each agent its own real email address? Startups like AgentMail are certainly doing that!
In our case, we wanted to borrow the UX of email (to be intuitive to knowledge workers) but not necessarily the implementation.
Was there a particular workflow you had in mind here?
Do you have a list of a few mcp servers or other tools you would add to help with the pizza-bot specific workflow? For example, how would you enforce structured output, should that be an mcp server, a plugin, already in the box?
There are so many! Personally, I’ve been able to get remarkably far with the built-in filesystem tools (courtesy of DeepAgents) paired with a web search MCP (Kagi is great!). Were there any particular workflows you had in mind?
I need to be able to enforce structured output easily (json, and xml if possible). That would be my number one slightly less than typical requirement.
Other than that, I like to insert agents into deterministic workflows, so some way to easily have deterministic steps (calling a script rather than delegating to an agent, but determined by the workflow rather than the agent). However this second one is likely out of scope for a while, since it is the inverse of the typical agent workflow. I could probably work this out clunkily by polling the cli from an external master script, but it would be cool to have it all inside the box.
Ah, this may actually work out of the box if you tell Pizza Bot to use its `task` tool to dynamically launch a subagent (which maps 1:1 with a Skill), and provide it with a `responseSchema`. I’ll test this when I’m back at a computer and report back!
Nice work! Can you comment on how this differentiates from Paperclip?
Thanks! I'm not overly familiar with Paperclip, but from the website, it looks to provide orchestration over a fleet of existing agent harnesses, whereas with Pizza Bot, we run the execution loops for each agent ourselves (built on LangGraph / DeepAgents). We also stick to a "thread" model (similar to email), whereas Paperclip seems to work on a task-based model.
It's an interesting alternate UX framing, for sure. It's possible there are scenarios where a different abstraction makes more sense, but I'm personally curious to see how far we can extend the email idiom!
why not an actual inbox? set up a gmail and have the agent email you?
@aaronax had a similar thought!
In our case, we wanted to borrow the UX of email (to be intuitive to knowledge workers) but not necessarily the implementation.
Full control of your data was a design principle from the beginning, including being able to run fully offline with local models, so we didn’t want to add a dependency on email.
With that said, you can certainly hook up an MCP server and have the agents read and send emails (with human-in-the-loop approval) on your behalf.
Got it installed, been playing with it for a bit.
Had a bit of jankiness during setup as I fought with llama.cpp bugs. There are a few issues around models reported by the provider changing, refreshing as they change, had a few instances of "New Chat" showing one model then hitting llama.cpp with another, etc. Sorry, been traveling for a bit and didn't have the energy to properly recreate and put together a real bug report. Just a heads up that the onboarding there is a bit rough, though anyone running their own local models is probably more than able to get it figured out.
I'm really liking it. I wish I had something more substantial to say than "it's easy and clean" but... it's easy and clean. And as far as "AI tooling" goes, the setup was an absolute breeze even with the issues. The fact that I can just install a single app and go rather than spending hours and hours on setup, configuration, etc makes me way more likely to use this going forward... it's a lot easier to rely on a tool when I know it will be quick to fix if it breaks.
One note and one feature request, if you want 'em:
Though now that I understand the concepts better it's obvious, it _wasn't_ immediately obvious why the MCP server I added wasn't working. Tools are called via "tasks", and "tasks" are defined based on the skills. I had to create a skill. I'm sure it's somewhere in the documentation but I (and most people) don't read that kind of stuff, so would be good to surface somewhere obvious in the UI maybe?
And I would absolutely _love_ if you could override the provider and model per task. I run a small model locally as it's good enough for most of what I want to do (and cheap! and private!), but it would be great if I could define a "write-code" skill that was run via Claude instead or something so I could delegate tasks that aren't really suitable for a tiny local model out to something more capable.
Anyway... Cool tool. Hope to see it continue to grow and evolve! Thank you for releasing this!
Thanks so much for the feedback! The README arguably needs a diagram that shows the orchestrator-subagent delegation pattern and how they map to Skills, since you’re right - it’s not intuitive without reading the docs, and it’s somewhat unique from other agent harnesses I’ve seen.
The internal-only predecessor actually did let you specify the individual model for the subagent calls. DeepAgents supports this, so it shouldn’t be a big lift. I’ll add an issue on GitHub. Thanks for the request!
Author here - thanks so much for the great questions! Our post on the AWS Open Source blog has more screenshots and an architecture diagram if you want to give it a skim: https://aws.amazon.com/blogs/opensource/introducing-pizza-bo...