Darwin som orkestrerare

Maskinöversatt från engelska — källa: darwin-as-orchestrator.md.

Implementeringsstatus: Designanteckning — Darwin existerar idag som agent-service-runtimen (Darwin Dashboard). Att koppla den som orkestrerare för PRD-till-PR-pipelinen är arbetet denna sida beskriver.

Byggt idag: Darwin-runtime på localhost:3010 (be-agent-service/apps/server/src/index.ts), SQLite-state på .compound-state/agent-service.db, launchd-jobslots, interface-agent Telegram-brygga, 30 namngivna agenter i be-agent-service/agents/prompts/ (engineering / management / marketing / optimization).

Mål-tillägg: POST /api/prd-to-pr/<feature>-ändpunkt, in-process pipeline-runner som driver de åtta stegen, dossier-visnings-rutt på Dashboarden, Telegram → pipeline-routnings-regel i interface-agent. Insats + ordning spårat i darwin-component-map.md §(c).

Visionen säger att människor definierar vad; agenter exekverar hur. Darwin är implementeringen: en enskild adresserbar entitet (Telegram, så småningom webb-UI) som tar en PRD och returnerar en mergad PR med bevis. Människans enda obligatoriska handling är att läsa skärmbilden.

Detta är vägen till att ersätta den mänskliga CTO:n med agent-CTO:n som beskrivs i vision-and-mandate.md.

Flöde från ända till ända

1. Människa postar PRD-länk till Telegram
       ↓
2. interface-agent tar emot, validerar frontmatter, postar bekräftelse
       ↓
3. interface-agent → orkestrerare (engineering-team)
       ↓
4. orkestreraren kör 7-stegs pipelinen (PRD → PR med dossier)
       ↓
5. Efter merge postar Darwin dossier-skärmbilden tillbaka till Telegram
       ↓
6. Människan tittar på skärmbilden, svarar "approve" eller "reject"
       ↓
7a. approve → klart. Skala-eller-stäng-av-agenten tar över för rampning.
7b. reject → öppna spec igen för förtydligande, återgå till steg 2.

Vad Darwin är, idag

Per darwin-dashboard.md:

• Enad API + UI på localhost:3010 (be-agent-service/apps/server/src/index.ts:42).
• Ändpunkter: /api/repos/<repo>/{status,priorities,logs}.
• Backas av sqlite-databasen compound-state/agent-service.db.
• Hostar schemaforsknings-loopen, marknadsföringsteamet, och engineering-sammansatta körningar.

Vad som saknas för Darwin-som-orkestrerare:

• /api/prd-to-pr/<feature>-ändpunkt som accepterar en PRD-sökväg och startar pipelinen.
• Telegram → orkestrerar-routning för PRD-meddelanden (idag routas meddelanden till generella underagenter, inte pipelinen).
• Pipelinen själv (den är dokumenterad över detta avsnitt men ännu inte en enskild körbar körning).

Beslut: orkestrerar-runtime är en tunn intern Node-loop

Registrerat 2026-04-30 för att stoppa nästa byggare från att omtvista detta. Pipeline-runnern bor inuti be-agent-service som en tunn (~200 LOC) Node-tillståndsmaskin, inte som en LangGraph (Python)-sidecar eller något externt arbetsflödesengine.

Resonemang:

• Matchar den befintliga be-agent-service/apps/server/src/routes/*-stilen — inget nytt språk, ingen ny processgräns.
• Persisterar tillstånd i .compound-state/agent-service.db, som redan finns och redan läses av genomströmnings-loggern.
• Återanvänder launchd-jobslots som redan hostar schemaforsknings-loopen och sammansatt nattligt arbetsflöde.
• Varje pipeline-steg är en funktion som anropar modelladaptern (se model-and-vendor-agnosticism.md) eller shellar ut (gh, playwright, yarn). Inget DAG-bibliotek behövs för åtta linjära steg med en återinträdes-kant (steg 7 → steg 4).
• Återbesök endast om tillståndsmaskinen växer ur ~500 LOC eller återinträdes-topologin blir icke-trivial.

Varför en enda orkestrerare

Om vi bygger N agenter som alla gör "PRD-till-PR" med små variationer får vi N versioner av spec-formatet, N granskar-feedback-loopar, N dossier-format. Visionsregeln "människor definierar vad" implicerar ett enda, väldefinierat gränssnitt — många orkestrerare bryter mot det.

Darwin är den valda orkestreraren eftersom:

• Den äger redan agent-service-runtimen.
• Den har redan launchd-jobslots för långlivade loopar.
• Den brokerar redan Telegram-gränssnittet via interface-agent.
• Den har redan sqlite-state-DB:n som genomströmnings-loggern skriver till.

Vad Darwin behöver från detta avsnitt

Sidorna i detta avsnitt definierar kontrakten som Darwins orkestrerare måste implementera:

Att ersätta den mänskliga CTO:n

Visions-citat:

Caires långsiktiga flaskhals ska vara compute, inte headcount.

CTO-ersättningen sker när:

1. PRD:er går rakt till Darwin utan att gå genom en mänsklig engineering manager.
2. Routnings-beslut över de fyra agent-teamen (engineering, optimization, marketing, management) kommer från cpo-cto (agenten), inte människan.
3. Skala-eller-stäng-av-beslut sker dagligen utan att en människa beslutar "låt oss rampa detta" eller "låt oss stänga av det".
4. Budget-allokering sker vid ledningsagent-kadens (CEO + CPO/CTO) med människan som endast ratificerar vid kvartalsvisa kontrollpunkter.

Varje punkt är en konkret, testbar övergång. Vi är inte vid någon av dem ännu. Ordningen de ska landa i:

1. PRD → Darwin → PR (detta avsnitts huvud-deliverable). Lättast. Fångar arbetet med högsta volym.
2. Skala-eller-stäng-av-automation. Härnäst. Tar bort den dagliga ramp/tillbakarullnings-overheaden.
3. Budget-allokering av ledningsagenter. Trea. Kräver finansintegration + förtroendekalibrering.
4. Tvärteam-routning av cpo-cto. Sist. Kräver att (1)–(3) är solida; annars fattar tvärteam-routern beslut med dåliga inputs.

Var människan fortfarande dyker upp

Efter att allt detta landat:

• Skriva PRD:er.
• Läsa dossier-skärmbilden innan merge.
• Kvartalsvis ratificering av cpo-cto:s routnings-beslut.
• Strategisk riktning på CEO-agent-input-nivån.

Det är allt. Allt annat är mjukvara. Det är visionen.

Korsreferenser

• Vision och mandat.
• Darwin Dashboard — vad Darwin är idag.
• Ledningsagenter — interface-agent, cpo-cto, ceo.
• Engineering-agenter — teamet Darwin orkestrerar.
• Sammansatt arbetsflöde — nuvarande nattlig approximation av pipelinen.
• Wiki som agent-substrat (roadmap) — konkreta leveransskivor.