Achyrix — an offline-first restaurant operating system with a 42-agent decision layer

What it is.

Two businesses, one company.

Why it's hard.

• A typical independent restaurant runs six to ten disconnected apps. None of them share a definition of a sale, an item or a shift, so the truth has to be stitched together manually every day.
• Legacy POS and BI tools report the past. They show what happened and never say what to do next, so an insight dies as a chart nobody acted on before the margin was already gone.
• Margin bleeds quietly: food waste, phantom stock, over-staffing, missed prep, suspicious refunds and delivery-channel losses accumulate invisibly — often several percent of revenue, noticed only at month end.
• Most 'AI features' in this category are a language model guessing over a prompt. In a system that moves money and stock, a plausible-sounding guess is worse than no answer at all.

Constraints

What I built.

• Bootstrapping and building the product from the ground up, with the goal of a scalable software company rather than a single deployment.
• Architected the whole system: tenancy model, data flow, offline sync semantics, desktop process boundaries and the agentic control plane.
• Designed the Agentic Decision Intelligence layer — the unified outlet snapshot, the 42 specialist agents, conflict arbitration and the Decision Card contract that carries action, evidence, confidence and expected impact.
• Built the React front ends (POS terminal, kitchen display, owner command centre, storefront) and the Fastify services behind them, packaged as an Electron client over local SQLite.
• Implemented the synchronisation engine: a persisted mutation queue with deterministic conflict resolution and replay signatures.
• Built the failure-path test harness — 596 automated tests that break the system on purpose and assert the ledger still reconciles.
• Designed the edge-compute strategy: routing between frontier models and locally fine-tuned open models on refurbished enterprise hardware.
• Wrote the investor narrative and the architecture story that goes with it, and run the services vertical that funds the build.

How it fits together.

1. 01

   Electron client

   React renderer for POS, KDS and command centre — no privileged APIs

2. 02

   IPC contextBridge

   Narrow, explicitly allowlisted surface between UI and system

3. 03

   Local SQLite (WAL, encrypted)

   Source of truth during service; every terminal is autonomous

4. 04

   Sync engine

   Queued mutation intents, deterministic conflict resolution, replay signatures

5. 05

   Fastify edge API

   Tenant-scoped domain services: ordering, menu, stock, labour, payments

6. 06

   Unified outlet snapshot

   One semantic KPI model combining sales, stock, labour, delivery and guests

7. 07

   ADI decision core

   42 specialist agents reading the shared snapshot, arbitrated into one queue

8. 08

   Decision Card contract

   Action + evidence + confidence + expected impact, audited and reversible

9. 09

   Approval & policy gate

   Human taps approve, or an earned-trust policy auto-executes within limits

10. 10

    Workflow executor

    Applies approved actions through the same validated domain operations a human uses

11. 11

    Model router

    Frontier models or locally fine-tuned open models on edge hardware

The AI layer, in depth.

Design principles

1. Deterministic-first, LLM at the edges

   Zero LLM tokens sit on the core decision paths. Detection, thresholds, forecasts and arbitration are explicit logic that can be replayed and audited; models are used where language, not correctness, is the deliverable.

2. Evidence-bound output

   An agent cannot emit a recommendation without the rows that justify it. Every card renders its own evidence — the counts, the covers, the invoices — so an owner is approving a fact, not a vibe.

3. Approval-gated execution

   100% of operational actions pass through human approval or an explicit policy the owner has set. Actions execute through the same validated domain operations a manager would trigger by hand, and each one is logged and reversible.

4. Earned trust, not blanket autonomy

   Agents start advisory. Once a class of action has a track record of being approved with the predicted impact, the owner can promote it to auto-execute inside bounded limits — autonomy is earned per action type, not granted up front.

5. Runs at the edge

   Because the OS is local-first, the intelligence has to work with the cloud gone. Locally fine-tuned open models on refurbished enterprise hardware keep inference available and insulate margins from cloud API price inflation.

Decision loop

1. 01

   Operate

   Every transaction, ticket, stock count and shift flows into one outlet-scoped model — a single trusted, real-time picture of the venue, built offline and reconciled on sync.

2. 02

   Detect

   Agents watch that snapshot continuously. Example: the weather and demand agents predict a slow evening for a hyper-local area.

3. 03

   Decide

   The decision core arbitrates the competing agent proposals and emits one Decision Card — reduce chicken prep by 15 lb — with the forecast, the historical waste and the expected saving attached.

4. 04

   Approve

   The manager reads the evidence in a plain-language brief and taps approve, adjusts the parameters, or lets a standing policy handle it automatically.

5. 05

   Execute

   The workflow executor updates the prep plan, alerts the kitchen display and adjusts the draft procurement order — through validated domain operations, fully audited and reversible.

6. 06

   Learn

   Realised impact is measured against the prediction. Overrides and outcomes tune thresholds and decide which action classes earn more autonomy.

The agent matrix

Engineering choices.

1. Local-first, not cache-first

   The local SQLite database is the authority during service, not a cache of the server. Writes land locally and are queued for replay, so the interface never blocks on the network and there is no degraded 'offline mode' branch in the UI.

2. One semantic context, computed once

   Agents read a unified outlet snapshot rather than each querying its own endpoints. That removes the disagreement between modules that makes restaurant data untrustworthy — and means adding an agent is cheap.

3. Deterministic decision core, language models at the edges

   Anything that can move money or stock is explicit logic that can be replayed. The moment a recommendation depends on a model's guess, it stops being auditable — and unauditable automation is not deployable in a kitchen.

4. The Decision Card as the only interface to automation

   Every agent output has the same shape: action, evidence, confidence, expected impact. One contract means one approval UI, one audit trail, one reversal path, no matter how many agents exist.

5. Tenancy enforced below the handlers

   Tenant scoping lives in the data access layer, not in individual route handlers, so a new endpoint cannot accidentally read across restaurants.

6. Renderer process holds no privileges

   All privileged work crosses an explicit IPC contextBridge with a hand-written allowlist, so UI code cannot reach the filesystem, the database or a model provider directly.

7. Model optionality as an architectural decision

   Inference sits behind a router, so the same decision path can run on a frontier model or a locally fine-tuned open model on owned hardware. It keeps the product working offline and keeps unit economics under our control rather than a vendor's price list.

Building it.

• React front ends for the POS terminal, kitchen display, owner command centre and storefront, packaged with Electron for the on-premise client.
• Fastify services expose tenant-scoped endpoints for ordering, menu, stock, labour and payment domains, with idempotency keys across the transaction and refund loop.
• Stock deducts on sale against recipe definitions, which is what makes phantom-stock and waste detection possible downstream.
• A persisted mutation queue records intent against a known base state, replays in order on reconnect and resolves conflicts deterministically instead of last-write-wins by accident.
• The ADI layer builds the outlet snapshot on a schedule and on significant events, fans it out to agents, arbitrates proposals and writes Decision Cards into an approval inbox.
• Zero-trust posture around the agent layer: secure-by-default RBAC, full audit logging, and no agent capability that isn't an existing validated domain operation.
• 596 automated tests, weighted towards failure paths — connection loss mid-transaction, process kill during payment, concurrent terminals editing one open order.

What fought back.

1. Reconciling concurrent terminals

   Two terminals editing the same open order while offline is the hard case. Mutations are modelled as intents against a known base state so replay can detect divergence instead of silently overwriting a colleague's work.

2. Proving data loss cannot happen

   Confidence had to come from tests, not careful reading. The breakage matrix kills the connection and the process at deliberately inconvenient points, then asserts the ledger still reconciles to the rupee.

3. Forty-two agents that don't shout over each other

   Independently sensible agents produce contradictory advice. Arbitration — ranking by confidence and expected impact, suppressing dominated proposals, collapsing duplicates — turned out to be harder and more valuable than any individual agent.

4. Keeping a language model inside the rules

   An agent that can call arbitrary operations is a liability in a system that moves money. Constraining it to validated domain operations, with approval gates and reversal, was a design problem long before it was a prompt problem.

5. Making intelligence affordable at the edge

   Cloud inference per outlet per day does not survive a $250/month price point. Fine-tuning smaller open models to run on depreciated enterprise hardware was the only way the economics and the offline promise both hold.

6. Trust before autonomy

   Owners do not hand a machine the keys on day one. Designing a graduated path — advisory, then policy-bounded, then auto-executing per action class — was as much product psychology as engineering.

Where it stands.

• The platform is pre-launch, so I would rather show the engineering than invent customer metrics.
• What exists: the operating core done end to end — POS, orders, payments and refunds with idempotency, multi-gateway processing and stock deduction on sale.
• Local-first sync with deterministic conflict resolution and replay signatures, so a venue keeps trading through a full outage.
• A zero-trust ADI engine with 42 agents implemented, approval-gated actions, secure-by-default RBAC and audit logging.
• 596 automated tests green across four product surfaces; roughly 60% of the way to production, with the remaining work being field-hardening, hardware bundling and pilot tuning rather than unknown R&D.

What I took from it

Where it's going.

1. Now · Q3 2026

   Prove value

   Pilot the inventory and labour agents with design-partner restaurants and measure adoption, override rates and realised savings against predicted impact.

2. Next · Q4 2026

   Scale trust

   Ship the hardware bundle, the onboarding playbook and outcome tracking, and run the first paid multi-outlet rollouts.

3. Then · Q1 2027

   Close the loop

   Policy-controlled automations, cross-outlet benchmarking, and installs scaling towards the target.

4. Goal · Mar 2027

   A restaurant-intelligence network

   1,000 live restaurants and a compounding proprietary decision dataset that makes every subsequent install smarter.

Tools and technology.