jd_

Quick update that I added issues for both the README update and overriding the model that a skill's subagent will use:

- https://github.com/pizza-bot-app/pizza-bot/issues/99

- https://github.com/pizza-bot-app/pizza-bot/issues/100

Thanks again!

Quick update. This doesn't work out of the box, but I've created an issue to enable this here: https://github.com/pizza-bot-app/pizza-bot/issues/98

Totally agree! I’ve got scheduled agents that run (a little slowly) overnight using Qwen 3.8 27B that are ready for me by the morning. :)

Thanks for the question!

I could maybe see that being the case for LangChain, specifically, if you’re just thinking about abstracting the LLM provider’s APIs. But here, we’re specifically using LangGraph to handle checkpointing and state management. This is a much more difficult challenge to get right in a sufficiently complex application like Pizza Bot.

Case in point: for the internal-only version, we wrote this ourselves. It works for the most part, but there are subtle edge cases and bugs that we’ve had to tackle like a game of whack-a-mole.

For the open source release, we looked at a few frameworks and deliberately settled on LangGraph (and DeepAgents). I’ve never been so happy to throw away code. :)

In our experience so far, it’s been rock solid. Most of the issues/bugs we’ve had have come from streaming to the frontend, so a simple Cmd-R / Ctrl-R will get you back up and running without having to worry about your data being lost.

Oh neat - thank you for sharing! I hadn’t seen this before, but we were definitely inspired by a post LangChain made about “ambient agents”: https://www.langchain.com/blog/introducing-ambient-agents

It seemed fitting to build Pizza Bot on top of LangChain’s tech, given the inspiration. :)

Thanks! I think it depends on how well Pizza Bot aligns with your mental model. Despite living in Claude Code for many things, I find the email-like UX we built for Pizza Bot matches my intuition for how I want to interact with agents beyond a simple chat interaction, including concepts like pinning, folders, filters, actionable threads, etc.

The bigger proof point for me was the adoption we saw from less technical folks at Amazon. Most of them immediately “got it.”

Thanks for the question! Similar to another user’s comment about Paperclip, Herdr looks to provide a layer on top of existing agent harnesses, whereas with Pizza Bot, we run the execution loops for each agent ourselves (built on LangGraph / DeepAgents). This gives us control over checkpointing, human-in-the-loop, etc., and the only “dependency” is your model provider.

I’ve been describing Pizza Bot as an “inbox” because it captures the UX, but this does seem to cause confusion and undercuts the fact that Pizza Bot actually is an agent harness itself, not just an orchestrator of agents hosted elsewhere.

Let me know if that makes sense!

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!

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...

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!

@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.

Love it. Maybe "inbox zero" for agents would have been a better tagline! :)

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!

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?

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?

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. :)

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...

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!

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.

Thanks! Just posted more details here: https://news.ycombinator.com/item?id=49713894

Posted some thoughts here: https://news.ycombinator.com/item?id=49713894

Author here - thanks for posting this! I’m planning to make a Show HN post tomorrow with lots of HN-friendly details. :)

Author here - thanks for posting this!

Some context for the HN crowd -- Pizza Bot started as a hacky Playwright script I wrote at Amazon to stop manually logging CRM activities. It eventually grew into an internal tool with a couple thousand internal users, and we rebuilt it from scratch in order to open source it. I'd like to do a proper Show HN to tell that story soon, but in the meantime, ask me anything!