-
-
Kitchen Prep Taskmaster operational dashboard
Inspiration
Restaurant prep planning is still driven by spreadsheets, intuition, and repeated manual checks. Every morning, kitchen teams must reconcile expected demand, current inventory, shelf life, recipes, and staffing—often under severe time pressure. Kitchen Prep Taskmaster was inspired by that real operational problem: give the team a reliable first plan before the shift starts, while keeping every important quantity transparent and reviewable.
What it does
Kitchen Prep Taskmaster runs an autonomous, event-driven workflow that converts sales history, weather-informed demand signals, menu recipes, and inventory into a daily kitchen plan. It:
- validates the incoming forecast and falls back safely when model output is unavailable or rejected;
- calculates authoritative preparation quantities with deterministic code;
- applies FEFO (first-expired, first-out) inventory logic;
- separates today's immediate prep shortages from future replenishment orders;
- produces a concise, explainable briefing for the kitchen team;
- records the plan and step-by-step run log for traceability; and
- requires human approval for menu or portion changes.
The result is a practical plan rather than a chat response: what to prepare, what stock to consume first, what is missing today, and what should be reordered for future service.
How we built it
The scheduled production path is a Python FastAPI service orchestrated by deterministic application code. Cloud Scheduler invokes a private Cloud Run worker with OIDC, and the worker uses the Google Gen AI SDK to call Gemini 3.5 Flash at two controlled reasoning and communication steps. Gemini never calculates or changes authoritative quantities. Forecast validation, recipe expansion, FEFO allocation, shortage detection, and replenishment are deterministic and covered by tests. An optional Google ADK adapter exposes the same orchestrator as a tool for interactive development; the scheduled production path does not route through ADK.
The service runs on Cloud Run and stores daily plans, inventory state, published Markdown, and durable run logs in Firestore. Cloud Scheduler triggers the workflow each morning so the agent works asynchronously without hand-holding. A lightweight /plans/latest view makes the latest plan easy to inspect on mobile. Open-Meteo provides weather context, while all restaurant sales, menu, recipe, and inventory data used in the demo is synthetic.
Challenges we ran into
The hardest design problem was deciding where agentic reasoning should end and deterministic software should begin. Letting a language model modify quantities would make the system difficult to audit and unsafe for real operations, so we designed strict data contracts and validation boundaries around Gemini.
Inventory logic also exposed subtle failure modes. In particular, demand can be double-counted when today's prep shortage and future replenishment are treated as the same problem. We corrected this by modeling them as separate outputs with separate time horizons. Another challenge was preserving useful run history when a pipeline step fails; the logging layer therefore records each step independently instead of writing only after a successful run.
Accomplishments that we're proud of
- A complete multi-step workflow that runs autonomously on a schedule.
- Clear separation between probabilistic AI output and deterministic quantities.
- Safe forecast fallback behavior for rejected output, server errors, network failures, and rate limits.
- Auditable daily plans and run logs persisted in Firestore.
- Synthetic demo data that shows the full system without exposing restaurant information.
- Human approval gates for decisions that should never be silently automated.
What we learned
We learned that trustworthy agents are defined as much by their boundaries as by their autonomy. Gemini is strongest when interpreting context and communicating a plan; deterministic code is stronger for quantities, inventory accounting, and safety constraints. Combining both produces a system that is useful, explainable, and testable.
We also learned that autonomy must be visible in the architecture. A scheduled background run, durable state, failure-aware logging, and a published result demonstrate agentic behavior more convincingly than a conversational interface alone.
What's next
Next we want to pilot the workflow with opt-in, anonymized restaurant data; add manager feedback loops; improve confidence reporting; and measure reductions in waste, stockouts, and morning planning time. Any future menu or portion optimization will remain recommendation-only and require explicit human approval.
Disclosures
All restaurant, supplier, sales, menu, recipe, booking, and inventory data in the demonstration is synthetic and generic. No confidential restaurant or customer data is used. AI coding assistants, including OpenAI Codex, supported implementation, review, diagnostics, and documentation. The entrant selected the problem and architecture, directed and reviewed the work, performed the deployments, and remains responsible for the submission. Third-party open-source libraries and APIs are identified in the repository.
Log in or sign up for Devpost to join the conversation.