AI-Org Prototype Architecture

Zweck dieses Dokuments

Dieses Dokument ist der technische Einstiegspunkt für die Root-Ebene des Repositories. Es fasst die aktuelle Architektur, Laufzeitkomponenten, Datenflüsse und wichtigsten Grenzen zusammen. Detail-ADRs und Phasendokumente liegen ergänzend unter docs/architecture/.

AI-Org ist ein Monorepo mit einem FastAPI/Celery-Backend, einem React/Vite-Frontend, relationalen und graphbasierten Datenmodellen, Vektorspeicher, Queueing, Monitoring und Docker-Compose-Betrieb.

Architektur auf einen Blick

flowchart LR
    User["User / Operator"]

    subgraph Frontend["Frontend Workspace"]
        Web["React 18 + Vite<br/>apps/web"]
        UI["Shared UI<br/>packages/ui"]
        APIClient["API Client<br/>packages/api-client"]
    end

    subgraph Backend["Backend Runtime"]
        API["FastAPI API<br/>ai_org_backend.main"]
        Intent["Intent Compiler"]
        Graph["PipelineGraph Contracts"]
        Orchestrator["Orchestrator Scheduler"]
        Celery["Celery Workers<br/>tenant:role queues"]
    end

    subgraph Data["State and Memory"]
        Postgres[("PostgreSQL<br/>SQLModel + Alembic")]
        Neo4j[("Neo4j<br/>graph projection / traversal")]
        Redis[("Redis<br/>broker, cache, budget")]
        Qdrant[("Qdrant<br/>vector memory")]
        Workspace[("workspace/<br/>artifact files")]
    end

    subgraph Observability["Observability"]
        Metrics["/metrics"]
        Prom["Prometheus"]
        Exporter["Celery Exporter"]
        Grafana["Grafana"]
        Traces["Run / Cost / Lineage contracts"]
    end

    User --> Web
    Web --> APIClient --> API
    API --> Intent
    API --> Graph
    API --> Postgres
    API --> Redis
    API --> Qdrant
    API --> Workspace
    API --> Metrics

    Orchestrator --> Postgres
    Orchestrator --> Neo4j
    Orchestrator --> Redis
    Redis --> Celery
    Celery --> Postgres
    Celery --> Qdrant
    Celery --> Workspace
    Celery --> Neo4j

    Metrics --> Prom
    Exporter --> Prom
    Prom --> Grafana
    API --> Traces
    Celery --> Traces

Systemgrenzen

Laufzeitkomponenten

Kern-Domänenmodell

erDiagram
    TENANT ||--o{ PURPOSE : owns
    TENANT ||--o{ TASK : scopes
    PURPOSE ||--o{ TASK : contains
    PURPOSE ||--o{ FEEDBACK : receives
    PURPOSE ||--o{ PIPELINE_GRAPH : selects
    TASK ||--o{ ARTIFACT : produces
    TASK ||--o{ TASK_DEPENDENCY : from_task
    TASK ||--o{ TASK_DEPENDENCY : to_task
    ARTIFACT ||--o{ CHAT_MESSAGE_ARTIFACT : tagged_by
    CHAT_MESSAGE ||--o{ CHAT_MESSAGE_ARTIFACT : links
    PIPELINE_GRAPH ||--o{ PIPELINE_NODE : contains
    PIPELINE_GRAPH ||--o{ PIPELINE_EDGE : contains
    PIPELINE_GRAPH ||--o{ RUN : executed_as

    TENANT {
        string id
        string email
        string name
    }
    PURPOSE {
        string id
        string tenant_id
        string name
        string mode
        boolean is_active
    }
    TASK {
        string id
        string tenant_id
        string purpose_id
        string status
        string owner
        int tokens_plan
        int tokens_actual
        int version
    }
    ARTIFACT {
        string id
        string task_id
        string repo_path
        string media_type
        string sha256
        string status
        int version_number
    }
    PIPELINE_GRAPH {
        string id
        string template_family
        string checksum
        int version
    }

PostgreSQL ist die autoritative Persistenz für Geschäftsobjekte und Graph-v2-Records. Neo4j dient als graphoptimierte Projektion für Abhängigkeiten, Traversal und Scheduling-Sichten. Direkte, manuelle Neo4j-Mutation ist nicht das primäre Schreibmodell; Änderungen laufen über Backend-Services, Sync/Reconciliation und SQLModel-nahe Verträge.

Request- und Ausführungsfluss

sequenceDiagram
    actor U as User
    participant UI as React UI
    participant API as FastAPI API
    participant IC as Intent Compiler
    participant PG as PostgreSQL
    participant G as PipelineGraph
    participant R as Redis
    participant O as Orchestrator
    participant W as Celery Worker
    participant VS as Qdrant
    participant FS as workspace/

    U->>UI: Purpose anlegen oder Anfrage stellen
    UI->>API: POST /api/purposes oder /api/intent/*
    API->>IC: Absicht strukturieren und validieren
    IC-->>API: UserIntent + Constraints
    API->>PG: Purpose, Tasks, Reviews oder Graph Records speichern
    API->>G: Template matchen / Graph validieren
    API->>R: Budget, Pause-State und Queue-Kontext setzen

    O->>PG: Ausführbare Tasks / Runs lesen
    O->>R: Budget und Locks prüfen
    O->>R: Task auf tenant:role Queue legen
    R-->>W: Agent Task ausliefern
    W->>VS: Kontext suchen oder speichern
    W->>FS: Artefakt schreiben
    W->>PG: Status, Artifact, Tokens, Feedback aktualisieren
    W-->>O: Abschluss / Fehler / Retry-Signal
    UI->>API: Graph, Status, Artifacts, Reports lesen
    API-->>UI: Kontrollierbarer Projektstatus

Backend

FastAPI

backend/ai_org_backend/main.py ist der API-Einstiegspunkt. Die App installiert:

• Request IDs,
• Security Headers,
• HTTP Metrics,
• Rate Limiting,
• Input Sanitization,
• CORS,
• globale Exception Handler,
• Health- und Readiness-Probes,
• /metrics via Prometheus ASGI App.

Wichtige Router:

• auth: Registrierung und Login,
• pipeline: Purposes, Backlog, Graph, Artifacts, Pause/Resume, Pipeline-Konfiguration,
• intent: Compile, Validate, Intent Review,
• chat: Chat, WebSocket, Artifact-Tags,
• artifact_bridge: Artifact-Metadaten und feedbacknahe Zugriffspfade,
• purposes: Purpose Lifecycle,
• settings: Theme und Research-Settings,
• templates: Template Studio.

Celery

backend/ai_org_backend/tasks/celery_app.py definiert Broker, Backend, Routing, Timeouts, Budget-Gate und Lifecycle-Signale.

Wichtige Eigenschaften:

• Redis ist Broker und Result Backend.
• Tasks werden dynamisch auf tenant_id:role Queues geroutet.
• Vor dem Publish wird Budget geprüft.
• Beim Start einer Task wird Status doing, Version und Heartbeat gesetzt.
• Fehler schreiben failed oder verschieben nach Retry-Erschöpfung in DLQ-/Watchdog-Flows.
• Terminale Tasks werden gegen doppelte Ausführung geschützt.

Orchestrator

Der Orchestrator ist die Scheduling-Schicht. Er liest Graph-/Task-Zustand, prüft Abhängigkeiten, Budget und Locks, aktualisiert Status und dispatcht Arbeit an Celery. Er ist bewusst getrennt von der HTTP-Schicht, damit API-Zugriffe, Scheduler und Worker unabhängig skalierbar bleiben.

Agenten

Agenten sind Celery Tasks mit rollenbezogener Verantwortung. Beispiele:

• agent.po: PRD und Produktanforderungen,
• agent.architect: Architektur-Blueprint,
• agent.planner: Entwicklungsplan und Tasks,
• agent.dev: Implementierungsartefakte,
• agent.qa, agent.integration, agent.security, agent.performance: Qualitätssicherung,
• agent.reviewer: Review-Artefakte,
• agent.vision: Vision-Dokumente,
• graph.sync und graph.reconcile: Graph-Synchronisation.

Intent, Graph und Templates

AI-Org trennt Nutzerabsicht, Workflow-Vertrag und Runtime-Ausführung.

flowchart TB
    Prompt["Raw user request"]
    Intent["UserIntent<br/>domain, action, deliverable, target, risk"]
    Gate{"Clarification<br/>needed?"}
    Template["Template Matcher"]
    Synth["Bounded Synthesizer"]
    Graph["PipelineGraph<br/>nodes, edges, schemas, budgets"]
    Validate["Graph Validator"]
    Runtime["Legacy/Celery Engine Adapter"]

    Prompt --> Intent --> Gate
    Gate -- yes --> Review["Intent Review / Clarification"]
    Gate -- no --> Template
    Template -- confident match --> Graph
    Template -- no match --> Synth --> Graph
    Graph --> Validate --> Runtime

Der aktuelle Stand ist additiv:

• Legacy-Pipeline und bestehende Celery Tasks bleiben ausführbar.
• PipelineGraph-v2 definiert den Zielvertrag für neue Workflows.
• Template-Familien liegen unter backend/ai_org_backend/graph/templates/*.yaml.
• Capability-Kataloge liegen unter backend/ai_org_backend/graph/capability_catalog/*.yaml.
• Validierung verhindert tote Knoten, inkompatible Datenkanten, ungebundene Zyklen und High-Risk-Ausführung ohne Approval.

Frontend

Das Frontend ist ein pnpm-Workspace unter frontend/.

Die App nutzt:

• React 18,
• Vite 5,
• Tailwind,
• React Router,
• Zustand,
• React Flow,
• Mermaid-Rendering für Markdown,
• Monaco Editor für Template-/Textarbeit.

Private Routen prüfen den JWT aus localStorage. API-Aufrufe laufen in der Entwicklung über den Vite-Proxy auf /api; im Containerbetrieb übernimmt Nginx/Compose die Kopplung.

Datenhaltung und Artefakte

PostgreSQL

PostgreSQL hält die transaktionale Wahrheit:

• Tenants und Auth-Kontext,
• Purposes,
• Tasks und Dependencies,
• Artifacts,
• Feedback und Chat Messages,
• Pipeline Templates und Phase-Konfiguration,
• PipelineGraph-v2 Records,
• Runs,
• Audit-/Review-/Statusdaten.

Migrationen liegen unter backend/ai_org_backend/alembic/versions/.

Neo4j

Neo4j optimiert Graphabfragen. Es spiegelt Task- und Artifact-Beziehungen für Traversal, Statussicht, Scheduling und Reconciliation. Die Datenquelle für fachliche Persistenz bleibt PostgreSQL.

Qdrant

Qdrant speichert semantische Vektoren für Kontextsuche, Memory und relevante Snippets. Services wie vector_store.py, memory.py und kontextnahe Agenten verwenden diese Schicht.

Redis

Redis ist:

• Celery Broker,
• Celery Result Backend,
• Budget-/Pause-/Runtime-Cache,
• Heartbeat- und Watchdog-Hilfsspeicher.

workspace/

Dateibasierte Artefakte werden unter workspace/ abgelegt und in PostgreSQL mit Pfad, MIME-Type, Größe, SHA-256, Version und Status referenziert.

Rework, Review und Invalidation

Rework ist kein freier Loop. Die Architektur verlangt begrenzte Revisionen:

• max_revisions,
• cost_budget,
• convergence_predicate.

Artefakte können fresh, stale, invalidated oder archived sein. Downstream-Invalidation soll dafür sorgen, dass Änderungen nicht nur lokal gespeichert werden, sondern betroffene Folgeartefakte sichtbar veraltet werden.

Observability

Die Observability-Schicht umfasst zwei Ebenen:

1. Betrieb: Prometheus-Metriken aus FastAPI und Celery Exporter, Grafana-Dashboards, Health-/Readiness-Probes.
2. Ausführung: Run-Traces, Cost Records und OpenLineage-artige Events als adapterfähige Verträge unter backend/ai_org_backend/observability/.

Ziel ist, KI-Arbeit wie einen Produktionsprozess zu betreiben: Status, Kosten, Fehler, Durchlaufzeit und Lineage müssen sichtbar sein.

Security und Governance

Aktuelle Schutzschichten:

• JWT-basierte Authentifizierung,
• Tenant-Scoping über API-Dependencies und Modelle,
• Rate Limiting,
• Security Headers,
• Input Sanitization,
• CORS-Konfiguration,
• Budget-Gates vor Task-Publish,
• Approval Gates für risikoreiche Graph-Knoten,
• Audit- und Review-Modelle.

Für produktiven Mehrmandantenbetrieb bleiben Secrets Management, Rollen-/Rechtekonzept, Datenisolation, Backups, Audit-Export und Policy Enforcement explizite Ausbaupunkte.

Deployment und lokale Entwicklung

Docker Compose

Der persistente lokale Stack liegt in ops/persistent.yml:

docker compose --env-file .env -f ops/persistent.yml up -d

Optionale Profile und Overlays können Frontend oder Monitoring aktivieren. Ports können lokal durch zusätzliche Compose-Override-Dateien angepasst werden, wenn Standardports belegt sind.

Lokales Backend

pip install -e backend/.[dev]
uvicorn ai_org_backend.main:app --reload --port 9102

Lokales Frontend

cd frontend
corepack pnpm install
corepack pnpm dev

Das Frontend erwartet in der Entwicklung standardmäßig einen /api-Proxy zum Backend.

Quality Gates

CI-Workflows liegen unter .github/workflows/ und nutzen Node 20 mit pnpm 10.13.1 für den Frontend-Workspace.

Architekturprinzipien

1. Postgres für Wahrheit, Graph für Struktur

Fachliche Zustände sind relational nachvollziehbar. Graphprojektionen dienen Traversal, Planung und Visualisierung.

1. Runtime ist asynchron

LLM- und Agentenarbeit läuft nicht im Request-Thread, sondern über Queues, Worker, Heartbeats und Statusupdates.

1. Graph Contracts sind stabiler als Rollennamen

Rollen bleiben wichtig, aber die langfristige Workflow-Semantik liegt in typisierten Knoten, Kanten und Capabilities.

1. Jede Autonomie braucht Grenzen

Budget, Timeout, Retry, Approval, Revision Limits und Validation sind Teil des Ausführungsvertrags.

1. Artefakte sind prüfbare Outputs

Antworten ohne persistierten Output gelten nicht als belastbare Lieferung.

1. Beobachtbarkeit ist kein Add-on

Health, Metrics, Cost, Lineage und Audit müssen mitwachsen, wenn Agenten autonomer werden.

Bekannte Grenzen

• PipelineGraph-v2 ist als Contract Layer vorhanden, aber Legacy-Tasks und Adapter sind weiterhin Teil der Runtime.
• Einige Rework- und Review-Flows sind historisch gewachsen und werden schrittweise in zentrale Services konsolidiert.
• Neo4j-Sync und Reconciliation sind operativ wichtig, aber nicht die alleinige Quelle der fachlichen Wahrheit.
• Produktionsreife Mandantenisolation, RBAC, Secrets und Billing sind noch Ausbaupunkte.
• Externe LLM-Provider und Research-Integrationen brauchen konsequente URL-, Kosten- und Datenkontrollen.

Weiterführende Dokumente

• VISION.md - Produktvision und Leitprinzipien.
• README.md - Setup, Features und API-Überblick.
• README_local__setup.md - lokales Docker-Setup.
• READMEpipeline.md - Pipeline- und Agentenabläufe.
• docs/architecture/00-glossary.md - Begriffe.
• docs/architecture/01-intent-compiler.md - Intent-Compiler.
• docs/architecture/02-pipeline-graph.md - PipelineGraph-v2.
• docs/architecture/03-templates.md - Template-Familien.
• docs/architecture/04-rework-invalidation.md - Rework und Invalidation.
• docs/architecture/05-observability.md - Tracing, Cost und Lineage.
• docs/architecture/06-test-harness.md - Test-Harness.

AI-Org Prototype Vision

Kurzfassung

AI-Org ist ein autonomes, graphgesteuertes Agenten-System, das aus einem menschlichen Ziel ein prüfbares Projekt macht: Anforderungen, Architektur, Arbeitsplan, Implementierungsartefakte, Reviews, Reports und Auslieferungspakete entstehen in einem kontrollierten Ablauf mit Budgetgrenzen, Traceability und menschlichen Freigabepunkten.

Das Produktversprechen ist nicht "ein Chatbot schreibt Code", sondern: eine nachvollziehbare KI-Organisation plant und liefert Arbeitsergebnisse so, dass Menschen sie steuern, prüfen und freigeben können.

flowchart LR
    A["Purpose<br/>Was soll erreicht werden?"]
    B["Intent<br/>Was ist gemeint?"]
    C["Graph<br/>Welche Arbeitsschritte sind nötig?"]
    D["Agents<br/>Wer erledigt welchen Schritt?"]
    E["Artifacts<br/>Was wurde erzeugt?"]
    F["Review<br/>Ist es gut genug?"]
    G["Delivery<br/>Was wird ausgeliefert?"]

    A --> B --> C --> D --> E --> F --> G
    F -- "Feedback / Rework" --> C

Problem

LLM-basierte Arbeit ist heute oft schnell, aber schwer kontrollierbar. Einzelne Prompts liefern punktuelle Ergebnisse, doch komplexe Projekte brauchen mehr:

• belastbare Zielklärung,
• explizite Abhängigkeiten,
• wiederholbare Workflows,
• Kosten- und Budgetkontrolle,
• nachvollziehbare Artefakt-Versionen,
• Review- und Freigabeprozesse,
• Monitoring für Laufzeit, Qualität und Fehler.

AI-Org adressiert diese Lücke, indem es KI-Arbeit nicht als Gespräch, sondern als operatives System aus Rollen, Graphen, Queues, Artefakten und Reviews modelliert.

Mission

AI-Org soll Organisationen ermöglichen, wissensintensive Arbeit mit KI-Agenten auszuführen, ohne Kontrolle, Nachvollziehbarkeit und Verantwortlichkeit zu verlieren.

Das System übersetzt menschliche Absichten in strukturierte Workflows und macht jeden Schritt beobachtbar:

• Warum wurde eine Aufgabe erzeugt?
• Welcher Agent oder welche Capability ist verantwortlich?
• Welche Inputs und Artefakte wurden verwendet?
• Welche Kosten und Risiken sind entstanden?
• Welche Freigabe oder welches Feedback ist noch offen?

Zielnutzer

Produktprinzipien

1. Purpose vor Prompt

Jede Ausführung beginnt mit einem fachlichen Ziel, nicht mit einer isolierten Chat-Nachricht.

1. Graph vor Magie

Komplexe Arbeit wird als expliziter Graph aus Knoten, Kanten, Bedingungen, Budgets und Freigaben modelliert.

1. Artefakte vor Antworten

Wert entsteht durch persistierte, versionierte Ergebnisse: Dokumente, Code, Reports, Reviews, Konfigurationen und Archive.

1. Menschliche Kontrolle bleibt Teil der Architektur

Kritische Schritte brauchen Approval Nodes, Review Gates oder manuelle Freigaben. Auto-Modus ist ein Betriebsmodus, kein Kontrollverlust.

1. Kosten sind ein First-Class Constraint

Tokenbudgets, Budget-Gates und Cost-Traces sind nicht nachgelagert, sondern steuern Scheduling und Risiko.

1. Traceability ist Produktqualität

Ergebnisse müssen erklärbar sein: von Purpose über Intent und Graph bis zu Task, Agent, Artefakt und Review.

1. Templates schlagen Improvisation

Wiederholbare Arbeitsformen werden als deklarative Template-Familien gepflegt. Freie Synthese bleibt begrenzt und validiert.

Produktpfeiler

1. Purpose Workspace

Ein Purpose ist der Arbeitskontext eines Projekts. Er bündelt Ziel, Modus, Pipeline, Tasks, Chat, Artefakte, Feedback und Status. Der Workspace soll die zentrale Oberfläche sein, in der Menschen die KI-Organisation steuern.

2. Intent Compiler

Freitext wird in strukturierte Absichten übersetzt: Domain, Aktion, Deliverable, Zielartefakte, Risiken, Constraints und Konfidenz. Unsichere oder riskante Absichten werden nicht blind ausgeführt, sondern in Review- oder Clarification-Flows überführt.

3. PipelineGraph

Der PipelineGraph beschreibt die Arbeit als ausführbaren Vertrag: Knoten, Kanten, Schemas, Retry-Policy, Timeouts, Human Approval, Revision Limits und Budgets. Legacy-Tasks bleiben ausführbar, aber neue Workflows orientieren sich am Graph-Vertrag.

4. Agentenorganisation

Agenten sind Rollen und Capabilities mit klarer Verantwortung: Product Owner, Architect, Planner, Developer, QA, UX/UI, Reviewer, Security, Performance, Integration, Research und weitere spezialisierte Worker.

5. Artifact System

Artefakte sind die eigentlichen Ergebnisse. Sie werden persistiert, versioniert, mit Feedback verknüpft und für Download, Review, Rework und Lineage genutzt.

6. Observability und Governance

Metriken, Run-Traces, Cost Records, Lineage Events, Audit Logs, Health Checks und Dashboards machen das System betreibbar. Ziel ist, KI-Arbeit wie einen Produktionsprozess zu beobachten.

North-Star Outcomes

AI-Org ist erfolgreich, wenn es die folgenden Ergebnisse zuverlässig erzeugt:

• Ein Nutzer kann aus einem Purpose eine nachvollziehbare Pipeline starten.
• Das System erzeugt PRD, Architektur, Plan und Lieferartefakte mit Review-Status.
• Jede Aufgabe ist einem Tenant, Purpose, Agenten, Status und Budgetkontext zugeordnet.
• Artefakte sind versioniert, auffindbar, kommentierbar und exportierbar.
• Rework-Schleifen sind begrenzt, budgetiert und nachvollziehbar.
• Fehlerzustände bleiben sichtbar und wiederaufnehmbar statt still zu verschwinden.

Qualitätsmaßstab

Ein Ergebnis gilt erst als gut, wenn es:

• fachlich zum Purpose passt,
• auf nachvollziehbaren Inputs basiert,
• im Graph korrekt eingeordnet ist,
• Kosten- und Risikogrenzen respektiert,
• als Artefakt gespeichert ist,
• Review- oder Freigabestatus besitzt,
• bei Änderungen downstream invalidiert oder aktualisiert werden kann.

Betriebsmodi

Roadmap-Leitbild

Jetzt

• Stabiler End-to-End-Prototyp für Purpose -> PRD -> Architektur -> Plan -> Tasks -> Artefakte.
• Mandantenfähigkeit, Auth, Budget-Gates, Monitoring und Docker-Compose-Betrieb.
• React Admin UI mit Pipeline-, Graph-, Reports-, Template- und Chat-Flows.
• Additive Architekturphasen für Intent, Graph Contracts, Templates, Rework, Observability und Test Harness.

Als Nächstes

• Graph-v2 stärker als Runtime-Quelle etablieren.
• Intent Review und PipelineGraph-Auswahl in der UI enger zusammenführen.
• Artefakt-Lineage und Invalidation vollständig in Nutzerflows sichtbar machen.
• Replay-, Evaluation- und Cost-Dashboards produktnäher ausbauen.
• Template-Bibliothek mit mehr Domänen und besseren Acceptance-Kriterien erweitern.

Später

• Mehrmandantenfähiger Betrieb mit klaren Isolation-, Billing- und Admin-Konzepten.
• Capability Marketplace für interne und externe Agentenfähigkeiten.
• Produktionsreife Governance: Rollen/Rechte, Audit, Policy Enforcement, Secrets, Compliance.
• Integrationen in GitHub, Dokumentensysteme, Kalender, Ticketsysteme und Deployment-Pipelines.

Nicht-Ziele

AI-Org soll nicht:

• unkontrolliert beliebige Arbeit im Hintergrund ausführen,
• menschliche Verantwortung verschleiern,
• Ergebnisse ohne Artefakt-, Kosten- oder Review-Kontext als erledigt deklarieren,
• ein reiner Chat-Wrapper sein,
• eine monolithische "Alleskönner"-Agentenrolle aufbauen,
• unbegrenzte Rework- oder Suchschleifen erlauben.

Design-Ton

Das Produkt soll sich wie ein operatives Kontrollzentrum für KI-Arbeit anfühlen: ruhig, präzise, nachvollziehbar, dicht genug für echte Arbeit und klar genug für schnelle Entscheidungen. Die UI dient nicht der Inszenierung der KI, sondern der Steuerung des Arbeitsprozesses.

Leitentscheidung

AI-Org priorisiert kontrollierte Autonomie. Das System darf Arbeit selbständig ausführen, aber nur innerhalb expliziter Verträge: Purpose, Intent, Graph, Budget, Approval, Trace und Artefakt.

AI-Org Prototype 2.0

Hinweis: Dieses Dokument ist ein deploybarer Fallback aus dem Contributors-Projektprofil. Sobald eine Projektquelle README, Vision oder Architektur liefert, wird sie hier bevorzugt gerendert.

Audit Snapshot

AI-Org experimentiert mit einer Delivery-Pipeline, in der Agenten vorschlagen und Menschen die bindenden Gates halten.

Reifegrad

• Vorhanden: 9-Phasen-Plan, Agenten-Idee, Human-in-the-loop-Doktrin und starke Kopplung an Contributors.
• Fehlt: Eingegrenzte Pilot-Domäne, State-Modell, Eval-Plan, Demo-Hosting und UI-Narrativ.

Lead Ask

Multi-Agent-Architektur-Mentor: Architekt/in für Multi-Agent-, Graph- oder Orchestrierungs-Systeme, der den 9-Phasen-Plan auf Scope, State, Eval und Human Gates reduziert.