Nach Sprint 1 umgebaut: Fast alles wird bei Marcus über Mails angesteuert — Aufgaben, Termine, Beziehungen — und das Wissen steckt gleich mit drin. Damit stehen die Use Cases nicht mehr nebeneinander: Das Postfach ist die Basis, auf der 03, 04, 05 und 07 aufsetzen. Nur das Dashboard steht daneben, weil es aus Systemdaten lebt.

Die Prototypen sind bewusst klickbar und nicht schön gemalt: Sie sollen Widerspruch provozieren. Wo Zahlen mit ◆ ECHTE DATEN markiert sind, stammen sie aus produktiven LAVA-Systemen; alles mit DEMO ist Platzhalter und wird durch Marcus' echte Fälle ersetzt.

Die drei Anforderungen, an denen jeder Use Case gemessen wird: Transparenz — jede Zahl und jeder Vorschlag zeigt seine Quelle.  ·  Nachvollziehbarkeit — jede Aktion des Agenten steht im Protokoll und ist widerrufbar.  ·  Ansteuerbarkeit — Marcus stellt pro Fall ein, wie viel der Agent selbst entscheiden darf.

Die sieben Use Cases aus dem Vorgespräch

01
Dashboard & Morning Briefing
Kennzahlen unternehmensübergreifend, frei zusammenstellbar. Entwicklung + qualitative Signale. Briefing morgens, Drill-Down auf Wunsch.
◆ LÄUFT MIT ECHTEN DATEN
312 Verträge · 339 Anlagen · 21.058 Belege — und vier Datenprobleme, die dabei aufgefallen sind.
02
Mail-Cockpit — die Zentrale
Nicht ein Use Case von acht, sondern die Basis: Aufgaben, Nachverfolgung, thematische Suche und Wissen — alles aus demselben Postfach.
L3 · autonom (Regeln) ◆ M365 FREIGEGEBEN
03
Jour Fixe → Aufgaben
Fireflies läuft mit, der Agent leitet Action Items ab, aktualisiert Aufgaben und führt die Termin-Historie. Kill-Switch für die Aufzeichnung.
L2 · Freigabe
04
Termin-Vor- und Nachbereitung
Termin anklicken → aktueller Stand, Historie, Ziel, Risiken. Danach: Nachbereitung mit Zusagen und Wiedervorlage.
L1 · Vorschlag
05
Kontakte & Beziehungspflege
CRM + Postfach zusammengeführt: Wann bestand zuletzt Kontakt, wo reißt eine Beziehung ab, wen sollte er wieder treffen.
L1 · Vorschlag
06
Markt- & Wettbewerbs-Agents
Wettbewerber, Regulatorik, Energiemarkt — jede Meldung immer mit der Frage: Was heißt das für LAVA?
L3 · autonom (Recherche)
07
2nd Brain
Status geändert: Die Wissensbasis fehlt nicht — sie liegt im Postfach. Entscheidungen, Zusagen, Erklärungen stehen in Mailverläufen.
L0 · nur Wissen läuft über UC 02

Ergänzung von AIRA — der achte Baustein

08
Steuerstand & Autonomie-Regler
Der Ort, an dem Marcus AIRA steuert: Was darf der Agent, was hat er getan, was wurde widerrufen. Ohne diesen Baustein bleibt „hoher Automatisierungsgrad" ein Vertrauensproblem.
Voraussetzung für alles andere

Warum ein eigener Steuerstand

Die Anforderung war: Automatisierungsgrad so hoch wie möglich, gleichzeitig flexibel gestaltbar, transparent, nachvollziehbar und ansteuerbar. Diese fünf Punkte stehen in Spannung zueinander — hohe Automatisierung ohne Kontrolle erzeugt Misstrauen, und ein misstrauter Agent wird abgeschaltet.

Die Auflösung ist ein gemeinsames Autonomie-Modell, das für jeden Use Case gilt und das Marcus jederzeit pro Regel hoch- oder runterdrehen kann. Der Automatisierungsgrad wird damit nicht vorab festgelegt, sondern verdient: Eine Regel startet auf L1 und wandert nach oben, wenn Marcus ihre Vorschläge wiederholt bestätigt.

Das Autonomie-Modell — gilt für alle Use Cases

StufeDer Agent…Marcus…Typisches Beispiel
L0 beobachtet und sammelt sieht nur die Auswertung, nichts passiert automatisch 2nd Brain, Kennzahlen-Historie
L1 schlägt vor — Entwurf liegt bereit liest, ändert, versendet selbst Antwortentwurf, Termin-Briefing, Kontakt-Wiedervorlage
L2 handelt nach Freigabe — ein Klick bestätigt gesammelt, z. B. morgens 5 Minuten Action Items aus Jour Fixe, Aufgaben zuweisen
L3 handelt selbstständig und meldet es sieht es im Protokoll, kann widerrufen Wiederkehrende Weiterleitung, Markt-Recherche, Nachfass-Erinnerung
Regel für L3: Nichts verlässt das Haus ohne Freigabe. Der Agent darf autonom sortieren, recherchieren, erinnern, vorbereiten und intern weiterleiten — aber keine Mail an Externe senden, keine Zusage machen und keine Zahlung freigeben. Diese Grenze wird am Hackathon mit Marcus verhandelt und hier festgeschrieben.

Woher die Daten kommen — Stand heute

QuelleSpeistStatus
AIRA-CLMUC 01, 06angebunden 312 Verträge, tagesaktuell — bereits im Prototyp verarbeitet
EMS / aleonUC 01angebunden 339 aktive Anlagen, 118 Standorte
Flowwer (Rechnungseingang)UC 01angebunden 21.058 Belege · Spiegel 16 Tage alt
AURORA · PMI-CockpitUC 01vorhanden 208 GETEC-Liegenschaften, Integrationsstand 61 %
Q-Billing / TOMUC 01verfügbar, nicht genutzt Umsatz und Instandhaltung — am Hackathon anzubinden
CAS Genesis World (CRM)UC 04, 05lesend verfügbar Schreibrecht zu klären
Microsoft 365 (Postfach, Kalender)UC 02–05nicht angebunden Zugriffsweg, Berechtigung, Datenschutz-Rahmen — der kritische Blocker
FirefliesUC 03, 04offen Lizenz, API, Einwilligung, Aufbewahrungsdauer
Aufgaben-/PM-SystemUC 03offen es gibt heute kein durchgängiges System — Entscheidung von Marcus nötig
Marcus' WissensbasisUC 07fehlt muss am Hackathon inventarisiert werden
Was das für die Priorisierung bedeutet: Vier Quellen stehen bereits — sie tragen UC 01 und in Teilen UC 06. Alles, was Marcus' Tagesgeschäft direkt entlastet (UC 02–05), hängt an einem einzigen Zugang: Microsoft 365. Wenn dieser Zugang am Hackathon nicht herstellbar ist, wird nachmittags UC 01 + UC 06 gebaut, nicht UC 02 + UC 03.

Offene Punkte — bewusst nicht erfunden

Prototypen im LAVA-Design · Quelle Design-System: 00_System/01_Vorlagen/design/ · Alle dargestellten Werte sind Demo-Platzhalter und stammen nicht aus Produktivsystemen.