Operativsystemet för restauranger

Pidza.se är idag ett AI-nativt restaurangsystem riktat mot svenska pizzerior och snabbmatsverksamheter: beställning, meny, restaurangadministration, dashboards och AI-stöd i ett gränssnitt. Analysen av navigation, arbetsflöden och varumärke pekar mot en produkt som byggts orderdriven först och administrativ i andra hand — en klassisk och riktig startpunkt, men också den punkt där de flesta restaurangplattformar fastnar.

Den långsiktiga riktningen är tydlig: Pidza vill inte vara en kassa med AI-funktioner, utan ett operativsystem där varje ansluten tjänst — bank, bokföring, leverantör, budplattform, telefoni — blir en resurs som AI-agenter kan resonera kring och agera på. Det kräver ett arkitektoniskt skifte från 'plattform med API:er' till 'MCP-nativ plattform'.

Model Context Protocol standardiserar hur en modell upptäcker och anropar verktyg samt hämtar kontext. Värdet ligger inte i protokollet i sig utan i att det gör verktygsytan komponerbar: när Fortnox, Swish, Foodora och Pidzas egen orderdomän alla exponeras som MCP-verktyg kan en agent utföra kedjor som ingen enskild integration designats för.

┌──────────────────────── PIDZA AI PLANE ─────────────────────────┐
│  Agent Runtime (multi-agent orkestrering, planering, approval)  │
│   ├─ MCP Client Pool ── tool discovery ── policy filter         │
│   └─ Memory Fabric: episodiskt · semantiskt · organisatoriskt   │
└───────────────▲─────────────────────────────▲───────────────────┘
                │ MCP (streamable HTTP, OAuth 2.1)
     ┌──────────┴──────────┐        ┌─────────┴──────────┐
     │ FIRST-PARTY SERVERS │        │ THIRD-PARTY SERVERS│
     │ order · meny · kök  │        │ Fortnox · Klarna   │
     │ lager · kund · HR   │        │ Foodora · Tink     │
     │ ekonomi · analys    │        │ Quinyx · Twilio    │
     └──────────▲──────────┘        └─────────▲──────────┘
                │                              │
        ┌───────┴──────────────────────────────┴────────┐
        │ SERVICE REGISTRY + CAPABILITY GRAPH           │
        │ verktygsschema · scope · kostnad · SLA · risk │
        └───────────────────▲───────────────────────────┘
                            │
        ┌───────────────────┴───────────────────────────┐
        │ CONTROL PLANE: authz · tenant · audit · quota │
        └───────────────────────────────────────────────┘

Klienter: Web · POS · Kiosk · Mobil · Partner · AI-agenter
         │            │              │
   ┌─────▼────────────▼──────────────▼─────┐
   │  EDGE GATEWAY (WAF, rate limit, authn)│
   └──┬────────────┬───────────┬───────────┘
      │REST        │GraphQL    │MCP
   ┌──▼───┐    ┌───▼────┐  ┌───▼─────┐
   │ REST │    │ GQL    │  │ MCP     │
   │ v1   │    │Gateway │  │ Servers │
   └──┬───┘    └───┬────┘  └───┬─────┘
      └──────┬─────┴───────────┘
        ┌────▼──────────────────────────┐
        │ DOMÄNTJÄNSTER (bounded ctx)   │
        └────┬──────────────────────────┘
        ┌────▼──────────┐   ┌───────────────┐
        │ EVENT BUS     │──▶│ WEBHOOK ENGINE│
        └───────────────┘   └───────────────┘

• Versionering: URL-major (/v1), additiv evolution inom major, deprecation-fönster 12 månader med Sunset-header och e-post till nyckelägare.
• Idempotens: Idempotency-Key obligatoriskt på alla POST som rör pengar eller order.
• Kontraktstest: OpenAPI 3.1 och GraphQL-schema i CI, breaking-change-detektor blockerar merge.
• Felmodell: RFC 9457 problem+json, svensk och engelsk meddelandetext, stabil felkod.

Prioritering utgår från hur många manuella timmar per vecka en integration tar bort hos en genomsnittlig pizzeria, multiplicerat med hur många kunder som berörs, delat med teknisk komplexitet.

1. 1Kund lägger order (web, app, telefon, marknadsplats, kassa)
2. 2AI validerar lager, allergener, kapacitet och ETA
3. 3Köket får en tillagningsplan optimerad mot ugnsbeläggning
4. 4Lagersaldo avräknas per recept, leverantörsbehov uppdateras
5. 5Verifikat förbereds med rätt momskod och betalmetod
6. 6Marknadsföring triggas: kvitto, merförsäljning, återvinningsflöde
7. 7Lojalitetspoäng och kundprofil uppdateras
8. 8Ägardashboard och realtids-KPI uppdateras
9. 9AI prognostiserar morgondagens försäljning per artikel
10. 10Inköpsförslag genereras och skickas till leverantörsagent
11. 11Personalschema optimeras mot prognos och kollektivavtal

Varje steg är ett MCP-verktygsanrop utfört av en agent med begränsad behörighet. Endast tre lägen bryter automationen: belopp över tröskel, avvikelse mot prognos över konfigurerad varians, och regelkonflikt (t.ex. schemaförslag som bryter mot vilotidsregler). Då eskaleras ärendet till ägaren med förslag och ett klick.

• Kuvert: CloudEvents 1.0 med tenant_id, trace_id, actor (människa eller agent-id) och schemaversion.
• Leverans: minst-en-gång med idempotenta konsumenter; ordningsgaranti per aggregat-id.
• Webhooks: signerade enligt Standard Webhooks, exponentiell retry, dead letter efter 10 försök, replay från portal.
• Event sourcing endast för order och betalning; övriga domäner använder CDC-derived events.

Differentieringen är inte 'AI i en restaurangapp'. Den är att Pidza är den enda plattformen där restaurangens hela verktygslåda — bank, bokföring, leverantör, budplattform, telefon — är maskinläsbar och maskinstyrbar genom ett gemensamt protokoll. Konkurrenterna kommer att exponera API:er. Pidza exponerar förmågor.

• Teknisk skuld idag: avsaknad av händelsemodell och tenantmodell är den dyraste posten — kostar 3–4x mer att införa efter 500 kunder.
• Skalning: läsvägen skalas via read replicas och materialiserade KPI-vyer; skrivvägen via partitionering per tenant och månad.
• Kapacitetsmål: 2 000 order/minut i topp, p95 orderbekräftelse under 400 ms, KDS-latens under 150 ms.
• Observability: OpenTelemetry end-to-end med trace_id från kundklick till verifikat i Fortnox.

• Frys funktionsutveckling i 8 veckor och bygg fundamentet: tenantmodell, event bus, auth och de fem första MCP-servrarna. Allt annat blir dyrare utan detta.
• Välj betalningsbredd före betalningsdjup: Swish, Klarna, Stripe. Terminaler kan vänta.
• Fortnox är den enskilt högsta ROI-integrationen — den tar bort flera timmar per vecka per restaurang.
• Ge inga agenter skrivbehörighet till pengar under år 1 utan godkännandeflöde.
• Bygg developer-plattformen först när 10 partners aktivt efterfrågar den — inte tidigare.
• Mät en enda nordstjärna: andel operativa beslut som fattas av plattformen utan mänsklig inblandning.