AI in Restaurant Automation

Where AI helps

Demand and prep: Predicting covers or order mix for the next service lets the kitchen prep the right amount. That’s a classic forecasting problem: historical data, maybe some exogenous signals (day of week, events), and a model that’s updated regularly. The value is less waste and fewer stockouts. The key is defining the horizon (same day, next day) and the granularity (by dish or by category).

Inventory and ordering: Similar idea: predict what you’ll need and suggest order quantities. The constraint is lead time and minimum order sizes. The model has to respect those and surface confidence so humans can override.

Kitchen flow: Optimizing sequence or timing of tickets is harder, the state space is large and the cost of being wrong (late food, wrong order) is high. Here AI is more assistive: suggest a sequence, but let the expediter decide. Full autonomy in the kitchen is a long way off.

Where it’s hype

Replacing the human at the register or in the dining room with a chatbot is often a solution in search of a problem. So is “AI-powered menus” that don’t change the underlying economics. The real gains are in the back: forecasting, inventory, and decision support. Front-of-house automation that annoys customers or adds friction is a net negative.

Implementation notes

Data quality is the bottleneck. You need consistent point-of-sale and inventory data, and you need to align it with outcomes (waste, stockouts, satisfaction). Start with one workflow, e.g. prep list for the next day, and prove value before expanding. Use simple models first; complexity is rarely justified in this domain. And always have a fallback: when the model is down or wrong, the restaurant should still run.

Summary

AI in restaurant automation is most valuable in the back: demand forecasting, inventory, and prep. Front-of-house and “AI everywhere” are often hype. Focus on one workflow, good data, and a human in the loop.

While founding engineering on a restaurant SaaS pilot (200+ sites), the wins came from the back of the house, not chatbots at the register. Restaurants run on thin margins and chaotic inputs: weather, events, no-shows, and daily specials. AI can help in narrow, well-defined areas. It can also waste time and money if applied where the problem is process, not prediction. This post is about the former; the [restaurant forecasting case study](/work/restaurant-saas-demand-forecasting/) covers what we shipped. ## Where AI helps **Demand and prep:** Predicting covers or order mix for the next service lets the kitchen prep the right amount. That’s a classic forecasting problem: historical data, maybe some exogenous signals (day of week, events), and a model that’s updated regularly. The value is less waste and fewer stockouts. The key is defining the horizon (same day, next day) and the granularity (by dish or by category). **Inventory and ordering:** Similar idea: predict what you’ll need and suggest order quantities. The constraint is lead time and minimum order sizes. The model has to respect those and surface confidence so humans can override. **Kitchen flow:** Optimizing sequence or timing of tickets is harder, the state space is large and the cost of being wrong (late food, wrong order) is high. Here AI is more assistive: suggest a sequence, but let the expediter decide. Full autonomy in the kitchen is a long way off. ## Where it’s hype Replacing the human at the register or in the dining room with a chatbot is often a solution in search of a problem. So is “AI-powered menus” that don’t change the underlying economics. The real gains are in the back: forecasting, inventory, and decision support. Front-of-house automation that annoys customers or adds friction is a net negative. ## Implementation notes Data quality is the bottleneck. You need consistent point-of-sale and inventory data, and you need to align it with outcomes (waste, stockouts, satisfaction). Start with one workflow, e.g. prep list for the next day, and prove value before expanding. Use simple models first; complexity is rarely justified in this domain. And always have a fallback: when the model is down or wrong, the restaurant should still run. ## Summary AI in restaurant automation is most valuable in the back: demand forecasting, inventory, and prep. Front-of-house and “AI everywhere” are often hype. Focus on one workflow, good data, and a human in the loop.

General arrangement

G-000 Key Plan — General arrangement of the complete set

A-101 The Architect — Biography, trajectory, and operating principles

R-301 Research — Published work and experimental directions

S-201 Structural Principles — The decisions that outlast implementation

W-400 Works — Case studies, as built

E-600 Essays — Longer arguments about systems, cost, and trust

B-500 Field Notes — What the work taught, written down while it was fresh

C-700 Correspondence — Open a line

Works · details

W-401 Forward-Deployed: Multi-Tenant Fertility & Surrogacy AI — Three coordinated chatbots, a governed NL-to-SQL reporting agent, and a shared LLM platform layer across multiple client programs, with a roadmap to production on AWS CDK.

W-402 AIDA: Health Programme Intelligence You Can Brief From — Turning facility assessment rows into screening rates, management gaps, and district rollups, with optional LLM narratives that never invent the numbers.

W-403 Agentic Video Intelligence for 24/7 Operations — Real-time CCTV triage with LangGraph and MCP: Kafka ingestion, sub-200ms paths, and defense-grade on-prem deployment.

W-404 Neural Map Personal Site: Spatial Navigation as Homepage — A scroll-driven Three.js constellation where clusters replace nav bars, with hover, fly-in, and iframe overlays for essays, work, and writing.

W-405 AURIXA: Conversational AI Orchestration at Scale — Multi-tenant microservices platform for real-time LLM routing, RAG, agent execution, safety guardrails, and voice, built as a production Turborepo monorepo.

W-406 Alzheimer's Classification: Master's Thesis Research — Benchmarking nine machine learning models on OASIS longitudinal biomarkers for dementia detection: rigorous preprocessing, grid search, and clinical interpretability.

W-407 Agentic Finance & Multimodal Healthcare AI — LangGraph workflows across portfolio logic and onboarding, plus QLoRA clinical imaging pipelines on HIPAA-aware AWS with hybrid RAG at sub-800ms p95.

W-408 Publishing AI Automation: Multi-Channel Support at Scale — Multi-channel author query automation with intent classification, hybrid RAG, unified identity across WhatsApp and email, and confidence-gated human escalation.

W-409 Restaurant SaaS Forecasting at Scale — Founding-engineer delivery for inventory and demand sensing: XGBoost and Prophet, Node APIs, Next.js ops dashboard, and 2M+ events/day pipelines.

W-410 Insurance Document Intelligence on AWS — Multimodal RAG, Claude and GPT-4 Vision, LayoutLMv3 extraction, and ensemble underwriting models: 95%+ accuracy at 10K+ queries/day.

W-411 Clinical NLP from Unstructured EHRs — BioBERT and spaCy NER pipelines extracting 47+ structured variables at 91.5% accuracy, across 5K+ documents/day, with risk scoring at scale.

Essays · details

E-601 The Model That Refuses to Draw — Generative models predict pixels; JEPA predicts what the pixels mean. Why the refusal to reconstruct is the most important architectural decision in world models, and what it teaches anyone who builds systems.

E-602 Minimalism as Engineering — Why less is more in system design: fewer dependencies, fewer features, fewer moving parts, and how to get there without sacrificing capability.

E-603 The Architecture of Trust — How system design either builds or erodes trust, and what to optimize for when the user can’t see inside the black box.

E-604 Why Performance Is a Feature — Performance is not a nice-to-have. It’s a product requirement that affects conversion, retention, and trust. Here’s the case and the practice.

E-605 The Cost of Convenience — Why every dependency and every abstraction has a price, and how to pay it consciously.

E-606 What Systems Thinking Actually Is — A long-form look at systems thinking: feedback loops, leverage points, and why it’s a discipline, not a buzzword.

Field notes · details

B-501 Reinforcement Learning After the Reward Model — How reasoning models are actually trained now: verifiable rewards instead of learned ones, GRPO and its descendants, RL compute that scales on a curve, and agents trained inside environments. With the engineering lessons for anyone shipping LLM systems.

B-502 World Models, As Issued: The State of the Set in October 2026 — A field survey of where world models actually stand: V-JEPA 2.1, LeJEPA, Dreamer 4, Genie 3, Marble and Atlas, Cosmos, and a billion-dollar bet in Paris. What shipped, what it cost, and what it is for.

B-503 Experimental UI as an Engineering Discipline — Why treating experimental UI and creative front-end as engineering, not “designer code”, raises the bar for both art and performance.

B-504 Architecture Design for Healthcare AI — How to design AI systems in healthcare: compliance, safety, and the primacy of the clinician in the loop.

B-505 AI in Restaurant Automation — Where AI actually helps in restaurant operations, order prediction, inventory, and kitchen flow, and where it’s hype.

B-506 Systems Thinking for Founders — Why founders who think in systems ship better products and make fewer irreversible mistakes.

B-507 Performance Engineering on Static Hosting — How to hit Lighthouse 95+ and sub-second FCP when you have no server: budgets, critical path, and discipline.

B-508 Building SaaS with a Zero-Dependency Mindset — Why minimizing dependencies is a strategic advantage in SaaS, and how to do it without reinventing the wheel.

B-509 DNS-Level Ad Blocking. System Design — How to design a DNS-based ad blocking system: architecture, tradeoffs, and what you give up when you block at the resolver.

B-510 AI Infrastructure Philosophy — Why the best AI systems treat infrastructure as a first-class product, and how to think about reliability, scale, and operator experience.