Så levererar CAIRE

Människor definierar vad. Agenter utför hur.

CAIREs leveransmodell är en agentisk PRD-till-PR-pipeline. En människa skriver en produktbeskrivning; specialiserade AI-agenter hanterar spec, tester, implementation, granskning och verifiering; människan godkänner en skärmbild. Beräkningskapacitet är flaskhalsen — inte antalet anställda.

flowchart LR Manniska(["👤
Människa
skriver en kort beskrivning"]) -->|PRD| Pipeline(["🤖
Åtta specialiserade agenter
spec · tester · kod · granskning · dossier"]) Pipeline -->|mergad PR + skärmbild| Godkann(["✅
Människa godkänner
tystnad = godkänt efter deadline"]) Godkann -->|metrikbevakning| Skala(["📈
Skala eller släck
auto-rampa · auto-rollback"]) style Manniska fill:#dbeafe,stroke:#2563EB,stroke-width:2px style Pipeline fill:#ede9fe,stroke:#9333EA,stroke-width:2px style Godkann fill:#dcfce7,stroke:#16a34a,stroke-width:2px style Skala fill:#fef3c7,stroke:#d97706,stroke-width:2px

Från en mening till levererad mjukvara. Människan dyker upp på två platser endast — när PRD:n skrivs, och när dossier-skärmbilden godkänns.

f / s / kr
Polstjärna: funktioner per sekund per dollar (och per token)
8
Steg från PRD till mergad PR
1
Mänsklig handling: godkänna en skärmbild
0
Leverantörsbindning — varje modellanrop går via en adapter

Mandatet

Det agentiska arbetsflödet är inte "AI-stöd för utvecklare". Det är leveransmodellen. Fyra åtaganden gör arbetsflödet distinkt.

Caire ska skala produktion 1000× utan att skala antalet anställda. Vi bygger inte team. Vi bygger leveranssystem. — CTO – AI Systems & Agent Workforce-mandat, 2026-04-29
A

Människor definierar vad och varför. Agenter utför hur.

Produktägare skriver PRD. Pipelinen tar PRD:n därifrån — spec, tester, kod, granskning, dossier, merge — utan en människa mitt i något steg.

B

Verktygs- och modelloberoende.

Varje modellanrop går via en adapter. Routning är konfiguration, inte kod. När en bättre eller billigare modell kommer är rotationen en kvartalsöversyn — inte en refaktorering.

C

Om det fungerar, skala automatiskt. Om det inte gör det, släck automatiskt.

Mätningar efter merge rampar en funktion 1% → 100%. Försämring slår tillbaka flaggan. Beslutet är mekaniskt — människor bestämmer inte "okej, rampa det här".

D

Leverans kopplad till affärssignaler.

Kassaflöde, intäkter och förbrukning är systemingångar. Orchestratorn vägrar starta en dyr körning om dagens budget är slut. Inget mänskligt "dra åt svångremmen".

Polstjärnan: funktioner per sekund per dollar

Varje arkitekturbeslut i pipelinen mäts mot en fråga: gör det att vi levererar fler funktioner per sekund, per dollar (och per token)? Mätvärdet är medvetet litet i absoluta tal. Det som spelar roll är banan.

Funktioner per sekund

Klocktid från PRD-intag till mergad PR. Att pressa det här betyder att parallellisera steg, cacha specifikationer och ta bort mänskliga rundresor. Varje levererad funktion landar en rad i .compound-state/agent-service.db med sin förlupna tid.

Per dollar

Total modellutgift över alla åtta steg, per mergad PR. Billigare leverantörer, mindre modeller för enklare routning, batch-API:er, prompt-cachning — varje hävstång pekar tillbaka hit. Orchestratorn vägrar körningar vars projicerade kostnad skulle överskrida dagens budget.

Per token

Totala in- + ut-tokens i pipelinen, per mergad PR. Ju renare specifikation och ju snävare dossier-kontrakt, desto färre tokens bränner editorn på iteration. Tokens är en ledande indikator för kostnad.

Banan spelar roll

En optimerings-mathematician-agent läser genomflödesloggen varje vecka och föreslår routningsförändringar — annan modell per roll, annan batch-storlek, annan cachstrategi. CPO/CTO-agenten ratificerar. Spärrhaken rör sig bara åt ett håll.

Den här sidan rör sig själv med mätvärdet. Nya routningsvinster, nya agent-promptar, nya dossier-format — varje förbättring som puffar funktioner-per-sekund-per-dollar landar här som en uppdatering.

Åtta steg, från PRD till PR

Varje steg producerar en kontrollerad artefakt. Nästa steg vägrar starta utan den. Pipelinen är ett kontinuerligt flöde, inte en checklista — varje steg lämnar över ett typat resultat.

flowchart TD PRD([📝 PRD
wiki/plans/<funktion>.md]) --> Spec([📐 Spec
Architect
Gherkin-acceptans]) Spec --> Tester([🧪 Misslyckande tester
Test-writer
vitest + Playwright]) Tester --> Implementera([💻 Implementera
Editor
iterera tills tester passerar]) Implementera --> Granska{🔍 Självgranskning
3 reviewer-subagenter} Granska -->|P1 hittad| Implementera Granska -->|ren| Verifiera([📦 Verifiera + Dossier
Verifier
trace.zip · skärmbild · summary.json]) Verifiera --> Push([🚢 Push till GitHub]) Push --> ExternGranska{🤝 Extern granskning
Codex + CodeRabbit} ExternGranska -->|P1 / P2| Implementera ExternGranska -->|ren| Godkann{👤 Människa godkänner
skärmbild-godkännande} Godkann -->|ja| Merge([🚀 Merge-kö
gh pr merge --auto --squash]) Godkann -->|nej| Spec Merge --> Klar([🎉 Levererad + genomflödesrad]) classDef agent fill:#ede9fe,stroke:#7C3AED,stroke-width:2px,color:#1a1a1a classDef gate fill:#fef3c7,stroke:#d97706,stroke-width:2px,color:#1a1a1a classDef terminal fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#1a1a1a classDef plumbing fill:#e0f2fe,stroke:#0284c7,stroke-width:2px,color:#1a1a1a class Spec,Tester,Implementera,Verifiera agent class Granska,ExternGranska,Godkann gate class PRD,Klar terminal class Push,Merge plumbing

De två återinträdes-kanterna (P1 hittad → återinträd editor) är de enda looparna. Allt annat är ett enkelriktat kontrakt från PRD till mergad commit.

Agentsteg Grind / beslut Infrastruktur Slutläge
# Steg Utdata Drivs av
0 Intag-normalisering
Konvertera chatt, brief eller Cursor-plan till en portabel PRD.
Kanonisk PRD-sökväg + funktionsslug. Orchestrator
1 PRD
En människa skriver beskrivningen: ändring, framgångsmått, icke-mål.
wiki/plans/<funktion>-ÅÅÅÅ-MM-DD.md Människa (enda obligatoriska steget)
2 Spec
Architect-agenten emitterar Gherkin-acceptansscenarier.
wiki/specs/<funktion>.md Architect (resonemangsmodell)
3 Test-stubbar
Test-writer kompilerar varje scenario till ett misslyckande test.
Vitest + Playwright-tester som misslyckas vid första körningen. Test-writer (mellanmodell)
4 Implementation
Editor itererar på diff:en tills varje test passerar.
Kod i en isolerad worktree; alla mål-tester gröna. Editor (mellanmodell)
5 Självgranskning
Tre reviewer-subagenter granskar diff:en parallellt.
P1 / P2 / P3-fyndlista, eller "ren". resolver-reviewer · dashboard-reviewer · perf-reviewer
6 Verifiering & dossier
Type-check, lint, tester, Playwright-trace + skärmbild.
docs/dossiers/<funktion>/{trace.zip, screenshot.png, summary.json} Verifier (mellanmodell)
7 Granskningsloop
Externa review-bot-kommentarer återinträder editor på P1 / P2.
Varje fynd åtgärdat eller motargumenterat med motivering. Reviewer-feedback (mellanmodell)
8 Merge + bevis
Auto-merge köad; dossier-skärmbild levereras för mänskligt godkännande.
Mergad commit på main + skärmbild till mänsklig kanal. Orchestrator + GitHub Merge Queue

Kontraktet är skarpt: ingen dossier, ingen merge. Varje stegs utdata är en typad, persisterad artefakt som nästa steg läser — och som en människa, en revision eller en framtida agent kan spela upp.

Vem dyker upp var

Det agentiska arbetsflödet får inte människor att försvinna — det gör dem strategiska. Varje roll har en eller två snäva platser att kliva in. Allt annat är mjukvara.

📝

Produktägare / PM

Definierar vad + varför
  • Skriver PRD:n i wiki/plans/ med ett framgångsmått och explicita icke-mål.
  • Godkänner (eller avvisar) dossier-skärmbilden före merge.
  • Sätter försämringströskeln som skala-eller-släck bevakar efter merge.
💻

Utvecklare

Granskar, skriver inte
  • Läser den auto-genererade specifikationen för avvikelse från PRD:n.
  • Motargumenterar P2-granskningskommentarer med motivering när agenten har fel.
  • Underhåller agent-promptar och modelladaptern — kod om hur kod skrivs.
🛠️

DevOps / SRE

Äger infrastrukturen
  • Driftar Darwin (orchestrator-runtime), launchd-jobsplatser, merge-kön.
  • Bevakar genomflödesloggen: kostnad per mergad PR, funktioner per sekund per token.
  • Godkänner modell-routningsrotationer från optimerings-mathematicianens veckoförslag.
🧪

QA / Testare

Skriver reglerna, inte fallen
  • Kuraterar Gherkin-mönstren som Test-writer-agenten kompilerar från.
  • Granskar dossier summary.json för hoppade scenarier eller tomma Playwright-trace.
  • Äger "ingen dossier, ingen merge"-grinden — det enda orchestratorn inte kan hoppa över.
📈

Investerare / Styrelse

Bevakar hävstången
  • Läser kostnad-per-mergad-PR sjunka månad för månad medan routningsmatrisen stramas åt.
  • Spårar funktioner-per-sekund-per-token som hävstångsförhållandet som inte beror på rekrytering.
  • Ratificerar kvartalsvisa modell-routningsbeslut; väljer inte modeller.
🔍

Kundutvärderare

Granskar spåret
  • Inspekterar docs/dossiers/<funktion>/ på en mergad PR — full Playwright-trace, skärmbild, konsollogg.
  • Läser PRD-frontmatter för att kartlägga en levererad funktion tillbaka till den ursprungliga beskrivningen.
  • Verifierar leverantörsoberoende genom att läsa routningskonfigurationen — ingen leverantörsbindning att ärva.

Vad som levereras på det här sättet

Pipelinen riktar in sig på stadig produktutveckling — det arbete som i ett traditionellt team fyller standups och sprintar. Större arkitektoniska drag får fortfarande en mänsklig-ledd plan.

🎨

Leverera en UI-funktion

En ny banner, en ny sida, en formvariation. PRD namnger acceptansscenarierna; pipelinen skriver vitest- + Playwright-tester; Editor implementerar; Verifier fångar skärmbild-dossiern.

🐛

Fixa en resolver-bugg

PRD ramar in buggen som ett misslyckande scenario. Test-writer kompilerar det; Editor fixar; resolver-reviewer + perf-reviewer fångar N+1-försämringar innan PR:n öppnas.

📊

Lägg till en mätning

Genomflödesrad, KPI-kakel, dashboard-diagram. Spec namnger datakällan; tester verifierar formen; dossiern visar mätningen renderas med realistisk seed-data.

🔀

Rotera en modell

Kvartalsvis: optimerings-mathematicianen föreslår en routningsändring baserat på kostnad, godkännandegrad, latens. CPO/CTO-agenten ratificerar. En config-redigering; adaptern hanterar resten.

📚

Uppdatera en wikisida

Granskningsomgång som agentic-workflow-granskningen själv: identifiera avvikelse, fixa dokumentet, kör yarn wiki:lint, leverera. Wiki-bara PR:er använder samma åtta steg med verifier i lättläge.

🌍

Lägg till en integration

Ny CSV-adapter, ny gate-leverantör, nytt externt flöde. PRD namnger kontraktet; tester täcker gränssnittet; dossier bevisar integrationen med riktiga fixtures och en inspelad trace.

Vad håller det på rätt spår

Autonoma loopar utan skyddsräcken är hur AI-projekt bränner budgetar och levererar försämringar. Varje steg av pipelinen är inhägnat. Editor-agenten sitter i centrum, omgiven av mekanismer som antingen kan sakta ner den, omdirigera den eller stoppa den helt.

flowchart TB subgraph Center [" "] direction TB Editor("💻
Editor-agent
skriver kod i worktree") end Spec("📐 Spec-kontrakt
kan inte avvika från Gherkin") MaxIter("🔁 MAX_ITERATIONS = 8
visa fel, mal inte vidare") Reviewers("🔍 3 review-subagenter
resolver · dashboard · perf") Codex("🤖 Codex + CodeRabbit
extern P1/P2-pollning") Dossier("📦 Ingen dossier, ingen merge
verklig webbläsarbevisning krävs") Budget("💵 Kostnadstak
opt-in · av i pilot") Worktree("🌳 Per-funktion worktree
redigerar aldrig main direkt") Approval("👤 Mänsklig godkännandegrind
skärmbild-godkännande före merge") Spec --> Editor MaxIter --> Editor Reviewers --> Editor Codex --> Editor Dossier --> Editor Budget --> Editor Worktree --> Editor Approval --> Editor classDef guard fill:#fff7ed,stroke:#d97706,stroke-width:2px,color:#1a1a1a classDef center fill:#ede9fe,stroke:#7c3aed,stroke-width:3px,color:#1a1a1a class Spec,MaxIter,Reviewers,Codex,Dossier,Budget,Worktree,Approval guard class Editor center

Åtta oberoende skyddsräcken. Inget enskilt förebygger buggar ensam; tillsammans gör de autonom leverans säker nog att människans enda obligatoriska handling är att läsa en skärmbild.

Spec är kontraktet

Editor kan inte leverera beteende som specifikationen inte namnger. Avvikelse mellan PRD och spec är i sig ett P2-fynd för verifier — och specifikationen är kort nog att rymmas i varje agents kontext, så avvikelse är alltid bevisbar.

Iteration är begränsad

MAX_ITERATIONS = 8 på editorns inre loop, plus max 3 återinträdes-cykler från review eller Codex-feedback. Träffa taket och körningen visar fel till en människa — den mal aldrig vidare.

Kostnad är begränsad — när du slår på det

Den valfria PIPELINE_BUDGET_ENFORCEMENT-flaggan (av i pilot, på när intäkter är verkliga) vägrar fler modellanrop när per-körning-kostnaden skulle överskrida taket. I pilot är människan enda PRD-producenten, så kostnaden är implicit begränsad.

Ingen dossier, ingen merge

En grön CI-körning är nödvändig men inte tillräcklig. Dossiern — Playwright-trace, slutskärmbild, konsollogg, maskinläsbar sammanfattning — bevisar att funktionen faktiskt renderades. Granskare kan spela upp tracet; människan ser skärmbilden.

Tre vägar in i loopen

Samma pipeline, tre sätt att gå in i den. Välj vägen som matchar stunden — en PRD i versionskontroll, ett formulär på Dashboard, ett meddelande på Telegram. Varje väg producerar samma dossier och samma merge-beslut.

Filbaserad PRD

Skriv wiki/plans/<funktion>-ÅÅÅÅ-MM-DD.md, skapa en isolerad worktree med ./scripts/git/worktree-add.sh, och pipelinen körs mot den grenen. Reviewer-subagenter granskar diff:en, verifier fångar dossiern, merge-kön landar PR:n. Bäst för utvecklare som levererar i versionskontroll.

Darwin Dashboard

Klistra in en PRD-sökväg, klicka start, se pipelinens framsteg på localhost:3010. Dossier-visaren visar skärmbild, konsollogg och maskinläsbar sammanfattning inline. Godkänn / Avvisa är en knapp — ingen GitHub-rundresa krävs. Bäst för produktägare som vill ha ett UI, inte ett CLI.

Telegram

Posta en PRD-länk till interface-agent. Samma backend kör pipelinen; dossier-skärmbilden postas tillbaka till den ursprungliga tråden. Svara godkänn och den merger. Den lättaste möjliga vägen — ett notis och en bild. Bäst för grundaren som läser på en telefon mellan möten.

Varför det fungerar

Pipelinen bygger på tre öppna mönster och en disciplin. Inget här är skräddarsytt för skräddarsydhetens skull.

Aiders architect/editor-uppdelning

En dyr resonemangsomgång producerar specifikationen; många billiga redigeringsomgångar implementerar mot den. ~1/14 av kostnaden för att köra varje anrop på resonemangsmodellen — kostnadsdrivaren är editorn, inte arkitekten.

Spec-driven utveckling (Gherkin)

Klarspråk är för oprecis för att koordinera flera agenter. Acceptansscenarier i Gherkin är korta nog att rymmas i varje agents kontext, precisa nog att kompilera till misslyckande tester, och greppbara.

Playwright-dossier (ingen dossier, ingen merge)

En grön CI-körning är nödvändig men inte tillräcklig. Dossiern — trace, skärmbild, konsollogg, maskinläsbar sammanfattning — bevisar att funktionen faktiskt renderades, i en verklig webbläsare, i tillståndet specifikationen namngav.

Reviewer-feedback-loop

Externa review-bots (Codex, CodeRabbit) postar kommentarer efter varje push. Pipelinen pollar dem, behandlar P1/P2 som misslyckande tester, och återinträder editorn automatiskt. Disciplinen är obligatorisk.

Utforska mer

🧠

AI-OS för verksamheter

Hur CAIRE komponerar AI-agenter till ett operativsystem för hemtjänstleverans.

🛣️

Routningsvetenskap

VRPTW, NP-svårighet och den hybrida människa-AI-optimeringsmodellen som driver schemaläggning.

🛡️

AI-efterlevnad

Hur CAIRE hanterar AI-reglering, granskningsspår och ansvarsfull driftsättning i sjukvård.

Vill du se pipelinen på nära håll?

Tolv guider beskriver varje steg i detalj — vision och mandat, agentroller, dossier-mönstret, granskningsåterkopplingen och orkestreraren som binder ihop allt.

Läs den långa versionen AI-OS för verksamheter