139 lines
5.3 KiB
Markdown
139 lines
5.3 KiB
Markdown
---
|
||
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.
|