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!

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.

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?

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!