Anatomie eines KI-Geschäftsteams: Orchestrierung von Agenten mit LangGraph und FastAPI

Die meisten KI-Automatisierungen folgen nach wie vor dem Modell eines einzelnen Agenten: Ein Modell erhält eine Anfrage und gibt eine Antwort zurück. Das eignet sich gut für das Beantworten von Fragen, doch in der echten Geschäftswelt sind Aufgaben auf verschiedene Rollen verteilt, einige Schritte laufen parallel ab und andere müssen auf die Freigabe durch einen Menschen warten. In dieser Übersichtsbeschreibung wird eine Open-Source-Plattform namens Multi Agent for Business Automation analysiert, die ein kleines Startup-Team als koordinierte Agenten modelliert. Am Ende sollten Sie verstehen, wie ihre Orchestrierung, ihr Speichersystem, die Freigabeprozesse sowie die API-Schnittstelle miteinander verbunden sind, und welche Designentscheidungen Sie in Ihren eigenen Agentensystemen wiederverwenden können.

Von Chatbot zu virtuellem Büro

Betrachten Sie, wie ein neues Unternehmen tatsächlich geplant wird. Ein Gründer formuliert die Vision. Ein Manager wandelt sie in konkrete Aufgaben um. Die Finanzabteilung überprüft Einnahmen- und Kostenannahmen, das Marketing entwickelt die Positionierung, die Rechtsabteilung prüft Risiken und der Vertrieb bereitet Kontakte vor. Ein Teil davon erfolgt nacheinander, ein anderer gleichzeitig, und wieder ein anderer wird blockiert, bis eine Person den nächsten Schritt genehmigt.

Laut der README ist das Projekt eine Plattform zur Automatisierung von Geschäftsprozessen und Unterstützung bei Entscheidungen, bei der Agenten mit unterschiedlichen Rollen, Persönlichkeiten und Werkzeugen über LangGraph-Arbeitsabläufe, gemeinsamen Speicher sowie Genehmigungsmechanismen mit menschlicher Beteiligung koordiniert werden, ergänzt durch Berichtserstellung und externe Integrationen. Das Ziel ist ausdrücklich kein weiterer Chatbot, sondern ein virtuelles Büro, in dem Agenten so zusammenarbeiten wie ein Start-up-Team.

Die fünf Architekturschichten

Das System ist klar in fünf Schichten unterteilt:

• Frontend: Ein React-Dashboard für ein auf Chats basierendes Onboarding, Visualisierung von Workflows, Freigabeprozesse und Analysen.
• Backend API: FastAPI REST-Endpunkte, WebSocket-Streams, Authentifizierung, Berichte sowie Speichermanagement-APIs.
• Agentenschicht: Die Agenten für Gründung, Management, Finanzen, Marketing, Recht, Geldwesen und Verkäufe.
• Orchestrierungsschicht: LangGraph-Workflows in Kombination mit einem benutzerdefinierten Orchestrierer, Aufgabendelegation und Checkpointing.
• Speicher und Infrastruktur: Neo4j, Qdrant, Redis oder Upstash, Supabase sowie Speicherung von Berichten.

Laut der README besteht der Stack aus React 18 zusammen mit Vite, FastAPI, LangGraph sowie LangChain und CrewAI für Agenten-Arbeitsabläufe, Neo4j, Qdrant und Redis für Speicherung und Warteschlangen sowie Supabase als optionale Schicht für Authentifizierung und Persistenz.

Der gesamte Lebenszyklus verläuft von oben nach unten – von der Vision des Benutzers über die Leitagenten zu den Spezialisten und schließlich in gemeinsamen Speicher, Genehmigungen und Ergebnisse:

User Vision
   ↓
Cofounder Agent
   ↓
Manager Agent
   ↓
Specialist Agents
   ├── Finance
   ├── Marketing
   ├── Legal
   ├── Money
   └── Sales
   ↓
Shared Memory + Approval Gates
   ↓
Reports + Dashboard + Integrations

Die wichtigste Erkenntnis aus diesem Diagramm ist, dass es sich um ein Arbeitsablaufsystem handelt und nicht um eine Prompt-Kette. Zustand, Speicher, Genehmigungen, Wiederholungsversuche, Überwachbarkeit sowie persistierte Ergebnisse sind alle von zentraler Bedeutung.

Der fünfstufige Arbeitsablauf

Stufe 1: Eine vage Idee in einen strukturierten Kontext umwandeln

Alles beginnt damit, dass der Nutzer erklärt, was er möchte: ein Produktkonzept, eine Geschäftsidee oder ein operatives Ziel. Der Cofounder Agent erhält diese Angaben, die bereits in Form eines einzigen Satzes sehr unstrukturiert sein können:

Input:
"I want to build an AI tool for small businesses."

Ihre Aufgabe besteht darin, diese Angaben in einen strukturierten Kontext umzuwandeln, an dem sich der Rest des Teams orientieren kann:

Cofounder Output:
- Vision statement
- Target users
- Problem definition
- Market opportunity
- Strategic assumptions
- Initial business direction

Die README-Datei bezeichnet diesen Schritt als „Vision intake“. Im Backend kann er über mehrere Eingangspunkte ausgelöst werden, je nachdem, ob der Kunde ein einmaliges Projekt, ein Gespräch oder eine erweiterte Sitzung wünscht:

POST /api/start-project
POST /api/conversation/start
POST /api/enhanced/start-session

Egal welcher Weg gewählt wird, der Backend erstellt ein Projekt oder eine Sitzung, speichert den Anfangszustand und leitet die Nachricht an den richtigen Agenten weiter.

Phase 2: Planung und Delegation durch den Manager

Sobald die Vision strukturiert ist, übernimmt der Manager-Agent und unterteilt die Strategie in konkrete Aufgaben, die tatsächlich umgesetzt werden können:

Manager Responsibilities:
- Convert vision into roadmap
- Break work into functional domains
- Create agent assignments
- Define task dependencies
- Decide which agents should execute in parallel

Im benutzerdefinierten Orchestrator wird dies in AgentOrchestrator.start_project() umgesetzt, das sich in backend/flows/orchestrator.py befindet. Dabei wird eine Projekt-ID generiert, zunächst der Cofounder ausgeführt, dessen Ergebnis an den Manager übergeben wird, und anschließend werden die Spezialisten entsprechend den Aufgaben des Managers gestartet. Im Pseudocode:

cofounder_result = await Cofounder.execute(vision_task)
manager_result = await Manager.execute(manager_task)
specialist_results = await execute_specialists(manager_result)
generate_outputs(all_results)

Der Manager bildet die Steuerungsschicht. Ohne ihn würde jeder Spezialist isoliert an der ursprünglichen Idee arbeiten und Ergebnisse liefern, die nicht miteinander verknüpft sind. Die Zentralisierung der Aufgabenverteilung in einem Agenten sorgt dafür, dass die Ergebnisse der Spezialisten zu einem kohärenten Plan zusammenwirken.

Phase 3: Parallelisierung der Spezialisten

Sobald Aufgaben festgelegt sind, übernehmen die Domain-Agenten. Die Standardliste sowie ihre Verantwortlichkeiten lauten wie folgt:

• Mitbegründer: Vision, Strategie und Marktchancen.
• Manager: Roadmap, Aufgabenteilung und Delegation.
• Finanzen: Einnahmemodell, Kostenmodell, ROI und Prognosen.
• Marketing: Positionierung, Kampagnen und Inhaltsstrategie.
• Recht: Konformität, Risiken, Verträge und Richtlinienprüfungen.
• Kosten: Preisgestaltung, Monetarisierung und Einnahmenverwaltung.
• Verkäufe: Verkaufsprozess, Kontaktaufnahme und Verkaufsstrategie.

Jeder Agent ist in backend/agents/personalities.py definiert, und jede Definition umfasst Eigenschaften, einen Kommunikationsstil, Fachgebiete sowie tools spezifisch für die jeweilige Rolle. Das ist wichtig: Die Agenten werden als rollenspezifische Ausführende mit eigenem Verhalten, Zuverlässigkeitsschwellenwerten und Aufgabenkontext modelliert – nicht lediglich als unterschiedliche Systemanweisungen.

Die Ausführung wird durch _execute_specialists() gesteuert, welches für jeden Spezialisten eine Aufgabe vorbereitet (Finanzen, Marketing, Recht sowie Geldwesen; zusätzlich Vertrieb, sofern aktiviert). Jeder Aufruf eines Agenten ist mit einer 60-sekündigen Timeout-Frist versehen:

parallel_executions = [
    asyncio.wait_for(agent.execute(task), timeout=60.0)
    for agent_name, task in specialist_tasks
]

Sämtliche so umhüllten Aufrufe werden anschließend gemeinsam abgewartet:

specialist_results = await asyncio.gather(
    *parallel_executions,
    return_exceptions=True
)

Weil asyncio.gather() mit return_exceptions=True aufgerufen wird, wird ein Timeout oder Absturz eines Agenten als Ausnahmeelement in der Ergebnisliste zurückgegeben, anstatt die gesamte Aufgabengruppe abzubrechen. Der Kompromiss besteht darin, dass der Aufrufcode jedes Ergebnis überprüfen muss, um zu entscheiden, ob ein fehlgeschlagener Agent erneut versucht, übersprungen oder weitergeleitet werden soll. Die übergeordnete Designentscheidung ist sinnvoll: Wenn die Finanzanalyse niemals die Marketing-Ergebnisse benötigt oder umgekehrt, gibt es keinen Grund, sie nacheinander auszuführen.

Phase 4: gemeinsamer Speicher und Kontextverbreitung

Ein Mehr-Agenten-System leidet schnell darunter, wenn jeder Agent nur seinen eigenen Kontext sieht. Die Plattform begegnet diesem Problem mit einer einheitlichen Speicherschicht, in der jeder Speicher eine spezifische Aufgabe hat:

Neo4j      → graph memory and relationships
Qdrant     → vector memory and semantic retrieval
Redis      → task queue, cache, runtime coordination
Local data → fallback storage and exported outputs

In der README wird dies als Graphen-Speicher von Neo4j, Vektorabfragen mit Qdrant, Warteschlangen von Redis oder Upstash sowie lokaler Caching mit sanftem Fallback zusammengefasst. Jeder Speicher dient einem anderen Zweck.

Graphen-Speicher speichert Beziehungen zwischen Agenten, Aufgaben, Projekten und Ergebnissen:

Agent → executed → Task
Task → belongs_to → Project
Agent → produced → Output
Output → depends_on → PriorContext

Diese Struktur ermöglicht es, die Zusammenarbeit zu visualisieren und genau nachzuvollziehen, welcher Agent welches Ergebnis aus welchem vorherigen Kontext erzeugt hat.

Vektor-Speicher in Qdrant unterstützt semantisches Abrufen, sodass ein Agent nach früheren Arbeiten anhand von Bedeutungen statt anhand von IDs suchen kann:

"Find previous market assumptions."
"Retrieve prior financial analysis."
"Use the earlier legal risk summary."

Warteschlangenspeicher mit Redis-Unterstützung kümmert sich um die Koordination während der Ausführung:

- Event streaming
- Task queues
- Cache
- Agent activity updates
- WebSocket event propagation

Das Projekt funktioniert auch weiterhin einwandfrei, wenn bestimmte Dienste fehlen. Bei der lokalen Entwicklung kann Redis durch einen In-Memory-Adapter ersetzt werden, und Aufrufe an große Sprachmodelle können an einen Mock-Anbieter geleitet werden. Dadurch wird es einfacher, das gesamte System auf einem Laptop zu betreiben, ohne alle Produktionsabhängigkeiten bereitzustellen – allerdings werden bei lokalen Tests auch keine Probleme aufgetreten, die nur mit echten Diensten auftauchen.

Phase 5: Genehmigung durch einen Menschen

Aktivitäten mit hohem Einfluss sollten nicht blind ausgeführt werden; hier ist die menschliche Genehmigung ein Bestandteil des Kernworkflows und nicht etwas Zusätzliches. Solche Kontrollmechanismen gelten für Entscheidungen, die Folgen haben können:

- Customer-facing campaigns
- Pricing recommendations
- Legal-sensitive outputs
- CRM updates
- Social media publishing
- Financial projections
- Business-critical recommendations

In der README-Dokumentation werden die Slack-Benachrichtigungs-Hooks sowie konfigurierbare Zeitlimits für diese Genehmigungsprozesse hervorgehoben. Auf der API-Seite werden die Genehmigungen über Endpunkte wie folgt bereitgestellt:

GET  /api/approvals/pending
POST /api/approvals/{approval_id}/respond
GET  /api/approvals/advanced/pending
GET  /api/approvals/stats

Der grundlegende Lebenszyklus einer Genehmigung sieht wie folgt aus:

Agent generates action
   ↓
System evaluates confidence/risk
   ↓
Approval request is created
   ↓
Frontend or Slack notifies human
   ↓
Human approves/rejects/provides feedback
   ↓
Workflow continues or stops

Das Ergebnis ist ein modulares Autonomiemodell: Arbeiten mit geringem Risiko laufen automatisch ab, während alle für Kunden relevanten, finanziellen oder rechtlich sensiblen Aufgaben auf eine menschliche Entscheidung warten. Wenn Sie ähnliche Kontrollmechanismen entwerfen, behandelt ein entsprechender Leitfaden zu Routing-, Fan-Out- und Genehmigungsmustern in LangGraph die Mechanismen auf Graphenebene ausführlicher.

Im Inneren des FastAPI-Backends

Der Haupt-Eingangspunkt des Backends, backend/main.py, initialisiert bei Start der Anwendung eine Reihe globaler Dienste:

AgentOrchestrator
Enhanced Orchestrator
ReportGenerator
SimplePredictor
AgentCollaborator
AdvancedApprovalManager
AgentService
ReportService
LangGraphOrchestrator
Queue Manager

Laut der README wird jede Route von backend/main.py bereitgestellt; backend/api/main.py ist ein kompakterer Alternative-Eingangspunkt, der nur einen Teil der Routen bereitstellt. Der Code ist nach Verantwortungsbereichen strukturiert:

backend/
├── main.py                 # Primary FastAPI app
├── api/                    # Route controllers
├── agents/                 # Agent implementations and personalities
├── workflows/              # LangGraph and HITL orchestrators
├── flows/                  # PRD DAG orchestrator
├── memory/                 # Graph, vector, cache managers
├── task_queue/             # Redis/Upstash queue with fallback
├── integrations/           # HubSpot, Slack, Instagram clients
├── approvals/              # Approval managers
├── collaboration/          # Cross-agent communication
├── outputs/                # Report generation
├── analytics/              # Predictions and metrics
├── auth/                   # Supabase auth
├── services/               # LLM, agent, report services
└── tools/                  # Search and tool registry

Die Trennung zwischen workflows/ (LangGraph und HITL Orchestratoren) und flows/ (der PRD-gesteuerte DAG-Orchestrator) ist bemerkenswert: Das Projekt verwendet gleichzeitig zwei Orchestrierungsansätze, was flexibel ist, aber bedeutet, dass man prüfen muss, welchen Pfad ein bestimmter Endpunkt verwendet.

Die API-Oberfläche, gruppiert nach Gruppen

Authentifizierung

POST /api/auth/signup
POST /api/auth/signin
GET  /api/auth/user

In Produktionsmodus verlassen sich diese Endpunkte auf die Authentifizierung von Supabase. Im lokalen oder Demo-Modus kann die Anwendung Supabase vollständig überspringen und auf eine leichte Entwicklungslogik zurückgreifen. Zu den in der README genannten Konfigurationsoptionen gehören DEMO_MODE, die Supabase-Variablen sowie die Variablen des LLM-Anbieters. Die entsprechenden Handler:

signup()          → creates user account
signin()          → authenticates user
get_current_user()→ verifies token and returns user profile

Projektlebenszyklus

GET  /api/projects
POST /api/projects
POST /api/start-project
POST /api/auto-execute
GET  /api/auto-execute/status

Diese entsprechen den folgenden Funktionen:

get_user_projects()       → fetch projects for authenticated user
create_project()          → create new project record
start_project()           → execute Cofounder → Manager → Specialists workflow
auto_execute_project()    → start automated coordination from raw vision
get_auto_execution_status() → return execution progress and logs

start_project() ist das Herzstück dieser Gruppe. Seine interne Abfolge lautet:

1. Generate project_id
2. Execute Cofounder Agent
3. Log Cofounder result
4. Execute Manager Agent with Cofounder context
5. Log Manager result
6. Execute specialist agents in parallel
7. Export and persist final outputs
8. Return project status and timeline

Diese Abfolge entspricht direkt AgentOrchestrator.start_project() sowie _execute_specialists() im Orchestrator-Modul.

Erweiterte Sitzungen

POST /api/enhanced/start-session
POST /api/enhanced/continue-session
POST /api/enhanced/approve-and-execute
GET  /api/enhanced/session-status
GET  /api/enhanced/live-logs
GET  /api/enhanced/session-results
GET  /api/enhanced/system-metrics
POST /api/enhanced/cancel-session
POST /api/enhanced/cleanup-sessions

Jeder Endpunkt hat einen spezifischen Zweck:

start-session        → create enhanced automation session
continue-session     → continue existing multi-turn planning session
approve-and-execute  → approve captured vision and run workflow
session-status       → inspect session state
live-logs            → stream logs for UI monitoring
session-results      → return final session output
system-metrics       → expose high-level runtime metrics
cancel-session       → stop active session
cleanup-sessions     → remove old sessions

Das ist der für die Produktion geeignetere Ansatz, da er Gespräch, Freigabe, Ausführung, Überwachung und Ergebnisabruf in separate Aufrufe aufteilt. Ein Client kann den Status abfragen oder Logs streamen, ohne eine lange Anfrage offen zu halten, und eine Sitzung kann explizit abgebrochen oder bereinigt werden.

Agentenverwaltung

GET  /api/agents/status
GET  /api/agents/list
GET  /api/agents/personalities
GET  /api/agents/configs
POST /api/agents/configs
POST /api/agents/execute
GET  /api/agents/logs/live

Was jede Route bewirkt:

agents/status       → current status of all agents
agents/list         → available agent inventory
agents/personalities→ UI-visible personality metadata
agents/configs      → current agent runtime settings
update configs      → update temperature, approval mode, priority, enabled flag
agents/execute      → execute a single agent manually
logs/live           → recent agent execution logs

Wenn Sie /api/agents/list aufrufen, wird die Liste in vier Kategorien (strategisch, geschäftlich, operativ, spezialisiert) sortiert zurückgegeben, und die Endpunkte für die Laufzeitkonfiguration ermöglichen es einem Operator, Temperatur, Freigabemodus, Priorität sowie die Aktivierung eines Agenten zu ändern.

Gespräche

POST /api/conversation/start
POST /api/conversation/{conversation_id}/message
POST /api/conversation/{conversation_id}/approve

Die dahinterliegenden Handler:

start_conversation()     → starts a Cofounder-led discovery conversation
continue_conversation()  → continues the existing conversation with stored context
approve_conversation()   → approves the captured vision and starts task distribution

Dieser Ablauf existiert, damit das System genügend Details sammeln kann, bevor es Ressourcen in spezialisierte Agenten investiert. Intern verläuft der Prozess wie folgt:

1. User sends initial idea
2. Cofounder Agent asks clarifying questions or structures the vision
3. Conversation state is persisted
4. System detects whether vision is ready for approval
5. User approves
6. System starts agent coordination

Im Orchestrator weist start_conversation() eine neue Gesprächs-ID zu, speichert, was der Benutzer eingegeben hat, ruft den Cofounder Agent auf, speichert die Antwort ab und gibt ein ready_for_approval-Flag zurück, das dem Client mitteilt, ob die Vision ausreichend fertig ist, um freigegeben zu werden.

LangGraph-Abläufe

POST /api/workflow/execute
POST /api/workflow/resume/{thread_id}

Die entsprechenden Funktionen:

execute_langgraph_workflow() → runs a LangGraph-based workflow
resume_workflow()            → resumes workflow from checkpoint

Diese Endpunkte stellen die LangGraph-Schicht direkt zur Verfügung. In der README wird sie als Zustandsmaschine von LangGraph beschrieben, die ihren Fortschritt speichert, sich selbst korrigieren kann und Interrupt-Node enthält, an denen ein Mensch eingreifen kann. Die Wiederaufnahmemöglichkeit ist die entscheidende Eigenschaft: Wenn ein lang andauernder Workflow zur Freigabe pausiert wird oder auf halbem Weg fehlschlägt, sollte er von seinem letzten Checkpoint aus weiterlaufen, anstatt neu zu beginnen und wieder für jeden LLM-Aufruf zu zahlen. Unsere Betrachtung von wie LangGraphs InMemorySaver Checkpoints speichert erklärt, was bei jedem Schritt tatsächlich gespeichert wird.

Berichte

GET  /api/reports/comprehensive
GET  /api/reports/{report_type}
POST /api/reports/generate-pdf
GET  /api/reports/download/{filename}
GET  /api/reports/domains
GET  /api/reports/domains/{domain}

Was jede Berichtsroute erzeugt:

comprehensive report → generate full business report
specific report      → generate executive, marketing, financial, etc.
generate PDF         → convert report data into downloadable PDF
download report      → serve generated PDF/HTML
domain reports       → return modular reports by business domain

Die Erstellung von Berichten ist eine zentrale Funktion: Führungskräfte-, Marketing-, Finanz- und umfassende Berichte im JSON-Format, wobei die PDF-Ausgabe über WeasyPrint erzeugt wird. Das unterscheidet das System von Chatbots, da das Endergebnis ein Geschäftsdatenprodukt und nicht eine Chatnachricht ist.

Gedächtnis

GET    /api/memory/graph
GET    /api/memory/stats
POST   /api/memory/export
DELETE /api/memory/clear

Und was sie zurückgeben:

memory/graph  → return graph nodes and edges for visualization
memory/stats  → return vector/graph memory statistics
memory/export → export stored memory and outputs
memory/clear  → clear memory stores

Die README-Datei gruppiert diese unter /api/memory/* für die Exportierung von Diagrammen und Statistiken. Mit diesen können Sie das angesammelte Wissen der Agenten überprüfen, ihre Ausgaben nachverfolgen und sehen, wie viel Speicherplatz jede Gedächtnis-Backend-Lösung verwendet. Beachten Sie, dass das Lösch-Endpunkt zerstörerisch ist und daher dieselben Zugriffskontrollen wie jede andere Admin-Aktion benötigt.

Analysen

GET /api/analytics/predictions
GET /api/enhanced/system-metrics
GET /api/communication/stats

Ihr Zweck:

predictions          → analyze generated outputs and estimate success/revenue/market timing
system metrics       → return enhanced orchestrator metrics
communication stats  → return inter-agent communication analytics

Hinter ihnen befinden sich einfache Hilfsfunktionen:

_analyze_project_success()
_analyze_revenue_trend()
_analyze_market_timing()

Diese überprüfen die Ausgaben der Agenten und ergeben für das Geschäft relevante Kennzahlen wie die Erfolgswahrscheinlichkeit, die Richtung des Umsatzwachstums sowie empfohlene Zeitpunkte. Es handelt sich dabei um Heuristiken auf Basis generierten Textes, weshalb ihre Ergebnisse eher als Anhaltspunkte denn als Prognosen angesehen werden sollten.

Integrationen

/api/integrations/*

Im Repository sind HubSpot, Slack sowie die Instagram Business API aufgeführt, wobei jede eine spezifische Rolle hat:

HubSpot   → CRM workflows
Slack     → HITL approval notifications
Instagram → marketing automation with compliance checks

Die zugrundeliegende Idee ist, dass Agenten Ergebnisse in reale Geschäftssysteme übertragen sollten, anstatt nur Inhalte zu erzeugen, wobei Genehmigungsmechanismen vor allem Sensiblen schützen.

WebSockets und Streaming

WS  /ws/agent-updates
WS  /ws/agent-events
GET /api/stream/logs

Was jeder Stream enthält:

/ws/agent-updates → periodically sends agent status updates
/ws/agent-events  → streams queue/Redis events to frontend
/api/stream/logs  → streams recent logs via server-sent response

Für eine UI mit mehreren Agenten ist diese Sichtbarkeit unerlässlich. Die Operator müssen erkennen können, welcher Agent gerade läuft, welche Aufgabe aktiv ist, ob eine Genehmigung wartet und an welcher Stelle der Workflow fehlschlug.

Die React-Frontend

Der Client basiert auf folgender Technologie-Stack:

React 18
Vite
React Router
Tailwind CSS
React Flow
Recharts

Laut der README kombiniert das Dashboard einen auf Chats basierenden Onboarding-Flow, den Echtzeit-Status der Agenten, eine visuelle Karte des Aufgabenaufwands sowie Ansichten zur Überprüfung der Konformität mit dem PRD. Zu seinen Aufgaben gehören:

1. Capture the user’s project vision
2. Display agent execution status
3. Visualize task flow
4. Show pending approval requests
5. Display reports and analytics
6. Show memory/monitoring data
7. Connect to WebSocket streams
8. Communicate with FastAPI through api.js

Die Quellansicht ist kompakt gestaltet:

frontend/
└── src/
    ├── App.jsx
    ├── pages/
    ├── components/
    └── services/api.js

App.jsx dient als authentifizierte Oberfläche, pages/ enthält die Ansichten für Workflow, Analytik und Überwachung, während components/ die Bausteine bereitstellt: Paneele für das Dashboard, Freigabebildschirme, Ansichten zur PRD-Konformität sowie Integrationseinstellungen. Jeder HTTP-Anfrage geht über services/api.js, das Wiederholungsversuche und Caching an einem Ort abwickelt und Netzwerkprobleme von den Komponenten fernhält.

Der End-to-End-Fluss

Insgesamt verläuft der Hauptweg durch das System wie folgt:

1. User submits business vision from React UI
2. Frontend sends request to FastAPI
3. FastAPI creates project/session
4. Cofounder Agent structures vision
5. Manager Agent converts vision into roadmap and assignments
6. Specialist agents execute assigned tasks
7. Results are stored in memory
8. HITL approval is requested where required
9. Reports are generated
10. Frontend displays logs, status, graph, reports, and outputs

Wenn man dies auf tatsächliche Module und Methoden überträgt, sieht derselbe Fluss so aus:

React UI
   ↓ HTTP/WebSocket
FastAPI main.py
   ↓
AgentOrchestrator / EnhancedOrchestrator
   ↓
CofounderAgent.execute()
   ↓
ManagerAgent.execute()
   ↓
_execute_specialists()
   ↓
FinanceAgent / MarketingAgent / LegalAgent / MoneyAgent / SalesAgent
   ↓
MemoryManager + GraphMemory + VectorMemory
   ↓
ReportGenerator
   ↓
Dashboard + PDF/HTML/JSON Output

Jede Schicht hat eine bestimmte Aufgabe: Die UI kümmert sich um die Interaktion, die Orchestrierer koordinieren, die Agenten führen aus, die Speichermanager speichern den Kontext und der Berichtsgenerator formt die Ausgabe.

Warum ein Graph-Orchestrator statt einer Kette

Mehre-Agenten-Arbeitsabläufe benötigen mehr als nur eine Abfolge von Funktionsaufrufen. Sie brauchen:

- State transitions
- Conditional routing
- Checkpointing
- Retry behavior
- Human approval interruptions
- Recovery after failure
- Resume from previous state

Die README bezeichnet die Zustandsmaschinen von LangGraph ausdrücklich als Orchestrierungsschicht aufgrund dieser Fähigkeiten. Eine einfache Prompt-Kette ist linear:

A → B → C → Done

Ein Geschäftsprozesswechsel erfolgt aufgrund von Zwischenergebnissen:

A → B
    ├── if finance confidence low → retry Finance
    ├── if legal risk high → ask human approval
    ├── if marketing ready → generate campaign
    └── if all complete → generate report

Niedriges Vertrauen in die Finanzen führt zu einem Neversuch, hohe rechtliche Risiken erfordern eine menschliche Überprüfung, und der endgültige Bericht wartet, bis alle Äste abgeschlossen sind. Die Umsetzung als fest codierte sequenzielle Aufrufe führt schnell zu einem Gewirr aus Bedingungen; ein Graph mit expliziten Knoten, Kanten und Kontrollpunkten hält ihn übersichtlich und ermöglicht das Wiederaufnehmen.

Was das Design richtig macht

• Klare Grenzen der Agenten: Jeder Agent ist für ein eigenes Geschäftsfeld zuständig, was zu konsistenten Ergebnissen führt und das Hinzufügen neuer Rollen erleichtert.
• Orchestrierung mit Fokus auf Workflows: Die Ausführung wird als Workflow modelliert und nicht als Abfolge von Prompt-Antworten.
• Parallel arbeitende Spezialisten: Finanzen, Marketing, Recht, Buchhaltung und Vertrieb laufen dort gleichzeitig ab, wo Abhängigkeiten es zulassen, wodurch die Gesamtzeit verkürzt wird.
• Gemeinsamer Speicher: Neo4j, Qdrant, Redis sowie lokaler Speicher bilden zusammen eine Lösung für Beziehungen, semantische Abfragen, Warteschlangen, Caching und Fallback-Möglichkeiten.
• Sicherheit durch menschliche Einmischung: Freigabeprozesse sorgen dafür, dass das System für Entscheidungen mit tatsächlichen Folgen einsetzbar ist.
• Echtzeit-Überwachungsfähigkeit: WebSockets, Logs, Zeitlinien, Dashboards und Analysen zeigen an, was die Agenten gerade tun.

Gestrukturierte Berichte: Die Ausgabe ist ein Dokument, das man an Interessengruppen weitergeben kann, kein Chat-Transkript.

Integrationstauglichkeit: Die Unterstützung für HubSpot, Slack und Instagram zeigt, dass das System dazu gedacht ist, mit echten Geschäftswerkzeugen zu arbeiten.

Absicherung für die Produktion

Die Grundlagen sind solide: ein modulares Backend, dedizierte Agenten, eine Speicherverabreichung, ein Genehmigungsfluss sowie eine überwachbare Benutzeroberfläche. Die offensichtlichen nächsten Schritte betreffen Zuverlässigkeit, Sicherheit, Überwachung, Bewertung und Kosteneinschränkung:

1. Add distributed tracing with OpenTelemetry
2. Add LangSmith or custom LLM evaluation dashboards
3. Add cost tracking per agent and per workflow
4. Add stronger RBAC for users, agents, and approvals
5. Add persistent workflow checkpoints in Postgres or Redis
6. Add retry policies per agent type
7. Add queue-based background execution with Celery/RQ/Arq
8. Add structured output validation with Pydantic schemas
9. Add agent-level unit tests and golden-output evaluation
10. Add Docker production profiles and deployment manifests

Zwei Aspekte verdienen besondere Betonung. Die Kostenverfolgung pro Agent und pro Workflow ist wichtig, da parallele Spezialisten die Anzahl der LLM-Aufrufe erhöhen, und Kosten bleiben unsichtbar, solange sie nicht gemessen werden. Die strukturierte Validierung der Ausgaben mit Pydantic-Schemata ist entscheidend, denn jeder nachgelagerte Schritt – von Speicherzugriffen über Berichte bis hin zu CRM-Updates – ist nur so zuverlässig wie die Struktur der von einem Agenten zurückgegebenen Daten.

Kernpunkte

• Betrachten Sie die Orchestrierungsschicht als das Produkt; das LLM ist lediglich ein Bestandteil davon.
• Setzen Sie einen managerähnlichen Agenten ein, der für die Aufteilung der Aufgaben zuständig ist, damit die Ausgaben der Spezialisten kohärent bleiben.
• Führen Sie unabhängige Agenten gleichzeitig mit zeitbasierten Timeout-Werten aus und handhaben Sie teilweise fehlgeschlagene Abläufe explizit.
• Weisen Sie jedem Speicher eine bestimmte Aufgabe zu: Graphen für die Herkunftsverfolgung, Vektoren für das Abrufen von Informationen sowie Warteschlangen für die Koordination.

Machen Sie Genehmigungsmechanismen, Kontrollpunkte sowie Echtzeit-Überwachungsmöglichkeiten zum Kern des Designs und nicht zu später hinzugefügten Elementen.