---
stepsCompleted:
  - step-01-init
  - step-02-vision
  - step-03-users
  - step-04-metrics
  - step-05-scope
  - step-06-complete
inputDocuments:
  - README.md
  - CLAUDE.md
date: 2026-03-12
author: Mary (BMAD Analyst Agent)
bmadSkill: 'Analyst Agent (Mary) — /bmad-agent-bmm-analyst → [PB] Create Product Brief'
bmadWorkflow: '_bmad/bmm/workflows/1-analysis/create-product-brief/workflow.md'
---

<!-- 📊 Generated by BMAD Analyst Skill — Agent: Mary (Business Analyst) -->
<!-- Skill Command: /bmad-agent-bmm-analyst → Create Product Brief -->
<!-- Workflow: _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

1. **LangGraph** ist das nicht-verhandelbare Herzstück — alle anderen Frameworks werden nach diesen Anforderungen gewählt.
2. **Zyklen First** — Die Architektur muss echte Loops unterstützen; DAG-Vereinfachungen sind verboten.
3. **State als einzige Wahrheitsquelle** — `CouncilState` TypedDict wird zwischen allen Agents geteilt.
4. **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.