| stepsCompleted |
inputDocuments |
date |
author |
bmadSkill |
bmadWorkflow |
| step-01-init |
| step-02-vision |
| step-03-users |
| step-04-metrics |
| step-05-scope |
| step-06-complete |
|
|
2026-03-12 |
Mary (BMAD Analyst Agent) |
Analyst Agent (Mary) — /bmad-agent-bmm-analyst → [PB] Create Product Brief |
_bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md |
Product Brief: CouncilOS (KI-Rat Baukasten)
Autor: Mary (📊 BMAD Analyst Agent)
Datum: 2026-03-12
1. Problem & Vision
Das Problem
Wissensarbeiter verschwenden täglich Stunden damit, KI-Tools manuell zu dirigieren. Die aktuelle Interaktionsparadigma — ein Mensch, eine KI, eine lineare Konversation — ist für komplexe, mehrstufige Aufgaben fundamental ungeeignet.
Kernprobleme:
- Qualitätslücke: Einzelne KI-Antworten sind oft unzureichend; Nutzer müssen manuell iterieren.
- Expertise-Lücke: Kein einzelnes KI-Modell ist in allen Domänen gleich stark.
- Transparenzlücke: Nutzer sehen nicht, wie und warum die KI entscheidet.
- Kontroll-Lücke: Unternehmenskritische Prozesse können nicht blind KI-Loops überlassen werden.
Die Vision
CouncilOS ist eine visuelle No-Code-Plattform, auf der Nutzer spezialisierte KI-Agenten zusammenstellen, verbinden und als iterativen „Rat" ausführen — bis das Ergebnis die definierte Qualitätsschwelle erreicht.
„Nicht die KI denkt für dich. Du dirigierst ein Orchester aus KI-Experten."
2. Zielgruppen & Jobs-to-be-Done
Primäre Zielgruppe A: Content-Ersteller & Marketing
| Job-to-be-Done |
Schmerz |
CouncilOS-Lösung |
| Hochwertigen Content produzieren |
Stundenlange manuelle Prompt-Iteration |
Automatische Critic→Master-Schleifen |
| SEO-konforme Texte erstellen |
Vergisst SEO-Regeln in langen Sessions |
Dedizierter SEO-Kritiker-Agent |
| Brand-Voice sicherstellen |
KI weicht vom Stil ab |
System-Prompt pro Agent |
Primäre Zielgruppe B: Software-Entwickler
| Job-to-be-Done |
Schmerz |
CouncilOS-Lösung |
| Code reviewen und verbessern |
Review kostet Senior-Zeit |
Architekt-KI + Tester-KI-Schleife |
| Tests und Docs generieren |
Vergessen oder aufwendig |
Doku-KI als Terminal-Node |
Sekundäre Zielgruppe: Analysten & Researcher
| Job-to-be-Done |
Schmerz |
CouncilOS-Lösung |
| Lange PDFs zusammenfassen |
Zeitaufwendig und subjektiv |
PDF-Reader-Tool + Analyse-Kette |
3. Markt & Wettbewerb
| Wettbewerber |
Stärke |
Schwäche vs. CouncilOS |
| ChatGPT / Claude (direkt) |
Bekannt, einfach |
Keine Zyklen, kein Multi-Agent |
| LangChain |
Entwickler-Framework |
Kein No-Code, keine visuelle UI |
| AutoGen (Microsoft) |
Multi-Agent |
Keine visuelle Canvas-UI |
| Zapier AI |
No-Code-Automatisierung |
Kein iteratives Schleifen-Paradigma |
| Make / n8n |
Workflow-Automation |
Kein KI-nativer Iteration-Loop |
Differenzierungsmoment: CouncilOS ist das einzige Tool, das zyklische Multi-Agenten-Pipelines visuell (No-Code) aufbaubar und kontrollierbar macht.
4. Erfolgsmetriken (SMART)
| Metrik |
Zielwert |
Messzeitraum |
Messmethode |
| Zeit bis erstem Council-Run |
< 5 Minuten |
First-Run |
Timestamp-Telemetrie |
| Durchschnittlicher Critic-Score |
≥ 8/10 |
Pro Run |
Aggregierte Critic-Scores |
| God-Mode-Nutzungsrate |
≥ 20% aller Runs |
Monatlich |
Run-Statistik |
| API-Fehlerrate |
< 1% |
Wöchentlich |
Error-Logging |
| Gleichzeitige Runs (Skalierbarkeit) |
≥ 10 |
Load-Test |
Performance-Test |
5. Scope (MVP → Enterprise)
In-Scope (MVP — Phasen 1–4)
- ✅ Visueller Canvas mit Drag & Drop (React Flow)
- ✅ Agent-Konfiguration: Name, System-Prompt, LLM-Modell, Tools
- ✅ Lineare und bedingte Edges
- ✅ Blueprint-Speicherung (PostgreSQL JSONB)
- ✅ Council-Ausführung (Auto-Pilot + God Mode)
- ✅ WebSocket-Live-Updates
- ✅ Tavily Web-Suche als Agent-Tool
- ✅ PDF-Upload + ChromaDB-Suche als Agent-Tool
Out-of-Scope (Post-MVP)
- ❌ Nutzer-Authentifizierung (Auth0 / JWT)
- ❌ Multi-User / Team-Collaboration
- ❌ Kostenkontrolle per LLM-Aufruf
- ❌ Mobile UI
- ❌ Lokale LLM-Anbindung (Ollama)
- ❌ Versionsverwaltung für Blueprints (Git-ähnlich)
6. Technische Kernannahmen
- LangGraph ist das nicht-verhandelbare Herzstück — alle anderen Frameworks werden nach diesen Anforderungen gewählt.
- Zyklen First — Die Architektur muss echte Loops unterstützen; DAG-Vereinfachungen sind verboten.
- State als einzige Wahrheitsquelle —
CouncilState TypedDict wird zwischen allen Agents geteilt.
- API-Keys bleiben server-seitig — Kein Frontend-LLM-Aufruf; alle LLM-Calls laufen im Backend.
7. Nächster Schritt
→ PM Agent John erstellt auf Basis dieses Briefs das vollständige PRD.
→ Dann: Architect Agent Winston entwirft die Systemarchitektur.
→ Dann: UX Designer Agent erstellt das UI-Design.
→ Dann: PM Agent John zerlegt in Epics & Stories.
