A look at the agentic architecture behind Dinnerbell, and what three complete rewrites taught us about building an assistant families can actually rely on.
Dinnerbell is an AI assistant for busy families. It handles the logistics that keep a household running—the shared calendar, personalized meal plans, grocery lists, curated recipes, shared to-dos, and the family chores—and it meets families where they already are, over whatever channel they actually use: text, email, the app, or out loud in the kitchen.
AI models and agentic design patterns are a moving target and evolve weekly, so please consider this a snapshot in time. We know this because we’ve completely re-architected Dinnerbell three times already. We started where everyone starts—a single model with an ever-growing prompt. When that buckled, we built the architecture that was in vogue at the time—an intent classifier routing each message through a dispatcher. Then we went further down that road, splitting the work across a team of specialist agents—a calendar agent, a grocery agent, a meal-planning agent with handoffs between them. Each version worked, until it didn’t. What runs today is the fourth iteration: a single orchestrator that loads skills and deep capability just-in-time. Like everyone in this space, we are learning as we go. This is the best system we’ve built so far, and we fully expect to rewrite parts of it again (and again).
What those four rewrites really trace is a moving line—the balance between what the model does and what context and structure the harness provides, redrawn every time the models improved. Our classifier, our dispatcher, our specialist handoffs each sat on the wrong side of that line eventually. But one principle has survived every redrawing: the model reasons; the harness decides what it can see and the guardrails in place to keep it useful, accurate and safe.
A walk through the layers
Channels. Four front doors—voice, SMS, email, and in-app chat. Each one is a full ingestion pipeline, not just transport. Voice runs speech-to-text in and natural speech out. The text channels accept the messy artifacts of family life: photos of school lunch calendars, screenshots, PDFs, forwarded school emails. Computer vision, OCR, and semantic parsing turn all of it into structured form before the agent ever reasons about it.
Normalizers. One thin dispatcher per channel handles the round-trip plumbing: authenticate the sender, resolve them to their family, timezone, and conversation history. And, after the agent answers, deliver the reply in the channel’s native form (i.e., conversational for voice, shortened for SMS). What the dispatchers deliberately don’t do is think. There’s no classifier and no routing logic here anymore…that job moved into the model, and we’ll come back to why.
Context assembly. Once per turn, the system builds the agent’s working context: load the cross-turn conversational state, compile memory (always-on family facts plus memories matched to this message), and—most importantly—ground data questions. If a message asks about live data (“what’s on the calendar Friday?”), the real read runs before the model does, so the answer always comes from the source of truth and never from a stale remembered copy from injected memories or conversational history. The stable parts of the prompt are cached for speed and cost savings.
The Orchestrator. One agent, one loop. A function-calling loop—call the model, execute its tool calls, feed back results, repeat until a final reply. To keep the context clean and reduce noise, the prompt has a deliberately tiny surface consisting of a stable prompt, a small always-on set of commonly required utilities, and loadSkill (the meta-tool). Everything else lives in a registry of described skills the agent loads at its own discretion, just-in-time, as the conversation needs them. A request like “move dinner with Daniel to 7 and text him to confirm the sitter” crosses calendar and messaging in one reasoning pass—no more handoffs and no context lost at the seams between specialists.
Execution. Every tool follows a defined contract with the guardrails built into the tools themselves: validation, confirmation flows for bulk writes, family-scoped data access. As much of the non-reasoning logic and safe guards as possible are built into the tools and functions themselves. The less the model has to reason about the better.
Workflows and subagents. Heavy and longer-running jobs are delegated outside of the conversational loop. Digitizing a recipe from a photo, running semantic analysis on an uploaded family document, extracting events from an uploaded schedule—these are delegated to purpose-built pipelines that do the heavier work off to the side and hand back finished results.
Fit-for-purpose models. No single model does everything, so each job runs on the model best suited to it. More and more, token cost is becoming an important factor. Claude Sonnet and Opus are the primary brains of the operation—orchestration and multi-step reasoning, with Opus stepping in when a turn demands it. Claude Haiku handles fast classification and memory transactions. GPT does specialist work inside tools and workflows: writing, entity extraction, recipe parsing, computer vision. Gemini covers grounded search and current information. Even imagery is split by purpose: GPT Image for stylized imagery and Stability AI for simple, lower-cost recipe-step images.
The skill registry. Skills are capability packs in plain markdown, covering six household domains. Each pack teaches one domain: when to use it—and explicitly when not to—it’s rules, its scoped tools, its response formatting, and working examples. Because skills are text, improving the agent’s calendar behavior is editing a document, not retraining anything.
Memory. Memory holds the durable, fuzzy things that don’t fit a schema—preferences, routines, relationships. Reads compile into the prompt synchronously; writes extract asynchronously in the background, never on the user’s hot path. And one hard line: memory never stores tool-owned facts. The calendar, the meal plan, the lists—those are always read live, so no stale copy exists for the agent to hallucinate from. When there’s a memory injected right there in the prompt—it’s often too tempting for the model to use it rather than the heavier lift of calling a ‘read’ tool to get the latest.
Production hardening. Hard-won heuristic guards, deterministic re-prompts, and edge-case handling that run on every turn: data questions trigger a real read before the model can answer. Past-tense success verbs are only allowed if the tool actually fired (using regex). A user correction fixes the agent’s transcript, never the family’s data. And the assistant never exposes its internals—no tools, no skills, no model talk, and on voice, no URLs read aloud. Nothing wrecks the user experience more than having the model’s internal dialogue seep into the responses it gives.
What three rewrites taught us
1. Routing belongs inside the model now. We built the classifier. We built the specialist agents. And we watched real user requests that cross domains constantly lose context as conversations bounced between agents. Reasoning models turned out to be better at choosing which capability to load than our classifier ever was at guessing user intent. When we collapsed the org chart into one agent picking skills off a menu, routing stopped being a layer we maintained and became a reasoning decision the model makes in the context of a single conversation.
2. Control the field of view. Models get wonky at tool selection as the visible tool count grows. The answer wasn’t fewer capabilities…it was fewer visible capabilities. A tiny, always-hot surface with commonly needed skills and utilities…with deep capability one loadSkill call away reduced noise and completely changed the game. Most of agent engineering has become deciding what the model is allowed to see in context at any given moment.
3. Put guardrails in the tools, not the prompt. Every hard behavioral guarantee we’ve ever gotten came from code, not prompt instructions. Prompt rules bend under pressure and complex logic. If a guarantee matters—like “never blind-write thirty events from a photographed sports schedule”—it lives in the executing tool function where the model can’t route around it. It doesn’t mean the guardrails can’t be in the prompt (they can and often should)—just backstop them with logic in the tools.
4. Never expose the model to what tools own. Our single strongest anti-hallucination rule isn’t a prompt instructions—it’s data-architecture. Memory keeps preferences and routines. It is programmatically forbidden from keeping calendar events, meals, or list items. Those are always read live. An agent can’t recite a stale copy of your calendar if no copy is exposed to it.
5. Be deliberate about models—fit for purpose, and increasingly fit for cost. Every job gets the model that’s best for it — and “best” increasingly means the cheapest model that clears the bar, not the most capable one available. You don’t route “what’s the weather?” through your deepest reasoning model and you don’t burn tokens on a fast classification a lighter model nails for a fraction of the cost.
6. Your execution layer outlives your architectures. After multiple rewrites we’ve learned that the model/harness architecture changed every time, and the tool-execution layer survived every time. The functions that actually write calendar events and update grocery lists have outlived a monolith, a classifier, and a specialist-agent team. Invest in clean tool contracts early—they are the asset that (thankfully!) carries forward.
7. Build the loop that makes the system improve itself. An agent is never finished—it’s a system you get better at, night after night. So we built the improvement loop into the operation. Test scripts run agents against real interaction patterns and flag the ones that didn’t land. And every evening, a review agent walks the day’s actual user conversations, identifies the turns that failed or fell short, and writes up concrete recommendations handed off to the coding agents that implement them.
We’ll no doubt be rewriting parts of this again…and again. There’s never been a more exciting time to build and we’re all figuring it out as we go. We hope that some of this resonates or informs something you’re working on. And if you disagree with a point we made or you’ve landed somewhere different in your own building we genuinely want to hear it. This space is moving too fast for any one of us to navigate alone.
Dinnerbell is an AI assistant that helps busy families run the household — shared calendar, meal planning, grocery lists, and more, over text, email, voice, and app. See it at dinnerbell.ai.