Case study · Restaurants
Dayfolio
An AI agent that reads across every operational system a restaurant runs on, and delivers the day's briefing before the operator opens their laptop.

Restaurants run on a stack of systems that don't talk. POS, labor scheduling, recipes, accounting. Each a silo, most with thin APIs, almost none agent-ready. Until the systems speak a common language, no agent can reason across them.
Dayfolio's first job is to give them that common language: a domain ontology wrapped in a single MCP connector. From there, an agent does the work. It fetches across systems, reconciles the numbers, spots the anomalies, writes the narrative, flags what needs a decision. The operator gets a daily briefing in their inbox at 6am, not a chatbot to interrogate. When they do want to dig, the same agent is already grounded in the whole ontology.
Restaurants first. The method travels to any fragmented operational domain.
The mess
Restaurants run on a POS for sales, a scheduler for labor, a recipe system for food cost, and an accounting platform for everything that touches money. Each was built for one job, by a different vendor, over a different decade. Their APIs reflect that. Some thin, most legacy, several non-existent. None of them expects an agent on the other end.
Even where data is accessible, it arrives shaped for humans, not reasoning. Sales come in as itemized transactions, labor as shift blocks, recipes as nested ingredient lists. A cook's recipe and an invoice line have no shared vocabulary for “cost of a dish” until someone defines one.
The discovery work was slower than the connector work that followed it. Before anything could be automated, a durable domain ontology had to sit over the mess, one a human and an agent could both reason against.
Fragmented operational data is not a restaurant problem.
What actually matters
An ontology can be exhaustive, or it can be useful. Modelling every field of every system yields a schema that looks rigorous and ships nothing, because no single decision depends on most of it.
The decisions restaurant operators actually make each morning are narrow. Is prime cost in line. Are sales per labor hour tracking. Where did margin leak yesterday, and which vendor, shift, or menu item caused it. What needs a call before lunch. Five to ten signals, surfaced with enough context for a judgement.
The Dayfolio ontology was shaped around those decisions, not around the underlying systems. The POS is not modelled in full. It is modelled to the depth that prime cost, channel mix, and anomaly detection require. Everything else is deferred until a decision asks for it.
Every agentic project that drowns, drowns here.
One connector, one agent
Once the ontology is in place, the stack on top of it is small on purpose. A single MCP server exposes the whole domain to any agent that speaks the protocol. One connector. One vocabulary. One place to fix a field when a system changes.
The primary surface is not a chat interface. Every morning before the operator opens their laptop, an agent walks the ontology, pulls yesterday's numbers, reconciles them, flags anomalies, drafts the narrative, and delivers a briefing to their inbox at 6am. They read it with coffee, not a query bar.
Interactive chat exists, and it is useful when an operator wants to pull on a thread. But chat is a secondary surface on the same ontology. The agent arrives already grounded. The operator does not have to teach it what matters.
One connector per domain, not per system.
What stays human
Agents get faster, cheaper, and more capable every quarter. What does not change is who owns the call.
Dayfolio is built so the agent scans, and the operator decides. Thresholds are explicit, not implied. An anomaly is surfaced with its evidence, not buried inside a generated narrative. When the agent calls a shift over-labored, the briefing shows the target, the actual, the variance, and which day of the week drove it. When it flags a margin leak, the source invoice is one click away.
Every action the agent takes is logged against the ontology. The operator can trace any line of the morning briefing back to the transaction that produced it. Nothing is magic. Nothing is final.
Governance is what separates agentic systems from rubber stamps or theatre.
Dayfolio is what the method produced for restaurants. The same method, an ontology shaped to decisions, one connector per domain, an agent that arrives grounded, onboards any fragmented operational domain to agentic AI.