Inspiration

Managing a household kitchen is deceptively difficult. People constantly make decisions about what is available, what needs to be bought, who will be home, allergies, schedules, leftovers, and what the family has already eaten.

KitchenOS was inspired by the idea that meal planning should feel like a helpful household conversation, not another spreadsheet or rigid planning system. I thought of this once while in college trying to learn to optimize 2 meals from almost nothing in my fridge.

What it does

KitchenOS connects household profiles, allergies, meal routines, inventory, meal history, meal planning, recipe research, and grocery management.

Users can:

  • Add inventory through text, voice, photos, receipts, or manual entry.
  • Ask KitchenOS to prepare a multi-day meal plan.
  • Review, accept, reject, remove, or refine individual meals.
  • Plan different meals for different household members and meal occasions.
  • Receive mandatory allergy warnings.
  • See grocery needs derived from the accepted plan and reduced by confirmed inventory.
  • Confirm purchases with editable quantities before they enter the kitchen inventory.

The system is designed around human control: agents propose and explain and users confirm meaningful changes.

How we built it

KitchenOS is a full-stack TypeScript application built with Next.js and React.

The backend is organized around domain services for:

  • Inventory and auditable inventory events.
  • Meal plans and meal approvals.
  • Shopping requirements and purchase confirmation.
  • Household profiles, meal routines, and safety context.
  • Agent workflows, retries, validation, and tracing.

The planning workflow uses multiple specialized agents. An orchestrator considers household context, inventory, history, and meal routines. A recipe researcheres validates proposed candidates in parallel. Deterministic checks handle structured concerns such as allergy conflicts, inventory coverage, and plan completeness.

I used Codex throughout the project to design the architecture, implement the application, build regression tests, debug agent failures, improve the interface, and iterate on the product experience. GPT-5.6/Codex was especially useful for rapidly moving between product design, backend workflows, frontend UX, and debugging. I'm more used to Claude Code but I have to say this is a great harness and I think it is more test/validation oriented.

Challenges we ran into

The hardest challenge was making agentic behavior reliable without removing human control. Early versions could produce incomplete plans, repeat dates, lose context during refinements, or fail when one research attempt failed.

We addressed this with:

  • Explicit agent roles and structured schemas.
  • Research retries and candidate fallback behavior.
  • Validation gates before applying changes.
  • Persistent run traces and error states.
  • Human review before inventory or plan mutations.
  • Careful separation between planned quantities, confirmed inventory, and grocery needs.

We also had to solve practical UX issues around multiple meals per day, individual household schedules, allergy warnings, mobile chat, receipt review, and keeping the grocery list synchronized with inventory.

Accomplishments that we're proud of

We are proud that KitchenOS became more than a meal generator. It is a connected household operations loop:

  1. Understand the household.
  2. Track what is actually in the kitchen.
  3. Prepare a plan around real constraints.
  4. Validate recipes and safety conditions.
  5. Let the user refine and approve.
  6. Keep grocery needs and inventory connected.

We are especially proud of the human-centered safety model. An allergy warning is always shown to the user, even when the orchestrator believes a meal is intended for someone else.

What we learned

We learned that agentic systems need strong boundaries. The best result was not one giant agent with access to everything, but specialized agents with clear responsibilities and structured handoffs. And have retries

We also learned that uncertainty should be visible. Unknown quantities, incomplete research, mismatched units, and failed runs should become obvious so hallucinations or errors do not create distrust.

Finally, we learned that good AI UX is conversational, but the underlying system still needs deterministic state transitions, validation, auditability, and recovery paths.

What's next for KitchenOS

Next, we want to deepen inventory-aware planning and household personalization.

Planned improvements include:

  • Better unit reconciliation and package-size intelligence.
  • More complete breakfast and lunch planning.
  • Per-person calendars and work/school routines.
  • Chat-based onboarding.
  • Household accounts with adult and child permissions.
  • Better receipt and image understanding.
  • More robust recipe research fallback.
  • Notifications and optional planning “heartbeats.”
  • Richer meal history and waste reduction insights.

Built With

Share this project:

Updates