Category Archives: General

Projekt Cumulus: Predictive Maintenance

Posted on by
Three technicians examining alerts on computer monitors in a control room, displaying predictive maintenance data and statistics.

Predictive Maintenance als Workflow: von Telemetrie-Signal zu Field Service – schnell, kontrolliert, skalierbar

IoT- und Asset-Teams haben heute viele Signale: Telemetrie, Fehlercodes, Anomalie-Detektoren, Health Scores. Die eigentliche Herausforderung beginnt aber danach: Welche Signale sind relevant? Was ist der nächste Schritt? Wer übernimmt? Und wie wird daraus zuverlässig ein Prozess – nicht nur ein Dashboard?

Cumulus setzt deshalb auf ein bewusstes Prinzip: Workflows entstehen agentisch (aus Signalen wird ein Plan) – werden aber kontrolliert und reproduzierbar ausgeführt (Steps, Regeln, begrenzte Fehlerpfade). Das macht Predictive Maintenance operativ nutzbar.

Kurzstory

Am Freitagabend steigt bei einem Asset-Typ die Temperatur leicht an. Das Monitoring schlägt an, aber niemand weiß: Ist das ein einmaliger Ausreißer, ein Sensorproblem oder der Beginn eines echten Ausfalls? Zwei weitere Alarme kommen dazu – und parallel fragt der Betrieb nach einer Entscheidung: „Dispatch ja/nein?“

Ein Predictive-Maintenance-Workflow bringt Struktur in diese Minuten: Er clustert Signale zu einem Case, ergänzt Kontext (Historie, Umgebung, letzte Wartung), priorisiert anhand klarer Regeln und stößt genau die nächste sinnvolle Aktion an – statt dass das Team im Alarmrauschen versinkt.

1) Warum Predictive Maintenance nicht im Monitoring endet

Ein Anomalie-Signal ist erst der Start. In der Praxis sind die Fragen:

  • Ist das ein echter Incident oder ein False Positive?
  • Wie dringlich ist es (Sicherheitsrisiko, Ausfallwahrscheinlichkeit, Kosten)?
  • Welche Kontextdaten brauchen wir (Asset, Standort, Wartungshistorie, Ersatzteile)?
  • Was tun wir als nächstes (Remote Diagnose, Ticket, Dispatch, Teile reservieren)?
  • Wie vermeiden wir Doppelarbeit, wenn mehrere Signale für das gleiche Asset kommen?

Das ist Triage – und Triage braucht Struktur.

2) Agentische Herkunft: Der Agent als Plan-Autor

Agenten sind hier stark bei:

  • Verdichten vieler Signale zu einem „Incident-Statement“
  • Vorschlägen für Priorisierung und nächste sinnvolle Checks
  • Formulieren von klaren Tasks/Work Orders
  • Generieren von Kundenkommunikation (Status, Erwartungsmanagement)

Der Agent liefert also einen Plan. Die Engine führt ihn in kleinen, klaren Steps aus.

3) Steps: vom Signal zur Aktion, ohne Blackbox

Predictive Maintenance ist ein klassischer Kandidat für Steps:

  • Normalisieren: Signal(e) → ein Asset-Incident
  • Kontext anreichern: Asset-Stammdaten, Historie, Umfeld
  • Entscheiden: „Beobachten“, „Remote Diagnose“, „Dispatch“, „Shutdown“
  • Ausführen: Ticket/Work Order anlegen, Zuständigkeiten setzen
  • Dokumentieren: Was wurde warum getan?

Wichtig: Jeder Step ist klein genug, um ihn zu testen und zu verbessern – ohne dass das ganze System „driftet“.

4) Agentic vs. Logic: Heuristik vs. verlässliche Ausführung

  • Agentische Steps: Diagnose-Hypothesen, Priorisierungsvorschläge, Textentwürfe.
  • Deterministische Steps: Deduplizierung, Routing, Status-Updates, Eskalationen, feste Checklisten.

So nutzt man die Stärken von Agentik, ohne operative Stabilität zu verlieren.

5) Beispiel-Blueprint: IoT-Incident → Field Service in 7 Schritten

  1. Telemetrie/Alarm normalisieren und zusammenfassen
  2. Deduplizieren und zu einem Asset-Incident clustern (kein Ticket-Spam)
  3. Kritikalität bestimmen (Sicherheit, Stillstand, SLA, Kosten)
  4. Kontext ergänzen (Wartungshistorie, letzte Eingriffe, Standortbedingungen)
  5. Nächste Aktion wählen (Remote Diagnose vs. Dispatch)
  6. Work Order / Ticket erstellen, Verantwortliche zuweisen, Teile/Slots reservieren
  7. Abschluss: Ergebnis dokumentieren und Prävention ableiten (Thresholds, Monitoring)

6) Regelwerk statt „LLM entscheidet alles“

In Operations ist die Frage nicht „kann das Modell das?“, sondern „läuft das robust?“

  • Klare Regeln für Eskalation (Severity, Wiederholung, Zeit)
  • Klare Stop/Go-Gates (z. B. Sicherheitsrisiko → Mensch muss bestätigen)
  • Begrenzte Fehlerpfade (fehlende Daten → gezielte Rückfrage/Task)

Das macht aus Predictive Maintenance einen Prozess, der im Alltag funktioniert.

7) Repair & Human-in-the-loop: kontrollierte Unsicherheit

Wenn Inputs unklar sind, braucht es saubere Korrekturpfade:

  • Repair-then-Retry: Vorschläge werden gezielt präzisiert, statt „neu zu raten“.
  • Human-in-the-loop: Bei riskanten Aktionen (Shutdown, Sicherheitsimpact) wird ein Mensch gezielt eingebunden.

Kurzablauf als Diagramm (high level)

A flowchart illustrating a process involving telemetry and alarms, with steps for incident planning, execution by an engine, decision-making rules, and repair processes, including human involvement.

Für Ops/Leitung: Was sich messbar verbessert

  • Weniger ungeplante Ausfälle: Signale führen schneller zu Aktionen statt zu Alarmrauschen.
  • Bessere Dispatch-Effizienz: Priorisierung und Kontext reduzieren unnötige Einsätze.
  • Klarere Verantwortlichkeiten: Jeder Case hat Owner, Deadlines und definierte nächste Schritte.
  • Governance statt Bauchgefühl: Eskalationen und Stop/Go-Gates sind standardisiert.
  • Skalierung mit der Flotte: Mehr Assets bedeuten nicht linear mehr manuelle Koordination.

Fazit

Predictive Maintenance wird dann wertvoll, wenn sie Handlung erzeugt – konsistent und nachvollziehbar. Cumulus verbindet:

  • agentische Planung für sinnvolle nächste Schritte
  • kontrollierte Ausführung über kleine Steps und Regeln
  • robuste Reparatur- und Interaktionspfade

So skaliert der Prozess mit der Asset-Flotte – statt im Alarmrauschen unterzugehen.

Nächster Schritt

Wenn Sie möchten, kann ich aus Ihrem aktuellen Signal-Setup (welche Alarme, welche SLAs, welche Rollen) einen konkreten Blueprint ableiten – mit klaren Eskalationsregeln und KPIs, aber ohne interne Implementierungsdetails.

Projekt Cumulus: Andon / Line-Stop Triage als Agentic Workflow

Posted on by
Workers in hard hats and safety vests discussing operations in a factory setting.

Andon / Line-Stop Triage als Workflow: schnell reagieren, sauber eskalieren, nachvollziehbar dokumentieren

In der Fertigung zählt bei Störungen jede Minute. Gleichzeitig ist genau diese Phase oft chaotisch: Viele Beteiligte, wenige gesicherte Informationen, parallele Maßnahmen – und später ist schwer zu rekonstruieren, was wann entschieden wurde.

Cumulus setzt deshalb auf ein bewusstes Prinzip: Agentische Planung (aus Signalen wird ein sinnvoller Plan) – kontrollierte Ausführung (kleine Steps, Regeln, begrenzte Fehlerpfade). Das macht Triage schnell, aber auch belastbar.

Kurzstory

Eine Station steht. Der Bediener meldet „Teil klemmt“, Instandhaltung vermutet Sensorik, Qualität fragt nach Ausschuss, die Schichtführung will eine ETA für „läuft wieder“. Während parallel Handgriffe passieren, gehen Informationen in Chat-Threads verloren.

Ein Andon-Triage-Workflow sorgt dafür, dass die ersten Schritte standardisiert sind: Event wird sauber erfasst, Severity ist klar, Erstchecks sind gezielt, Routing/Eskalation folgen Regeln – und am Ende ist dokumentiert, was wirklich passiert ist.

1) Warum Andon-Triage mehr als „Alarm weiterleiten“ ist

Ein Andon-Event ist nicht nur ein Signal, sondern der Start eines Prozesses:

  • Was ist die wahrscheinlichste Fehlerklasse (Material, Maschine, Prozess, Bedienung)?
  • Welche Checks sind sofort sinnvoll – ohne Zeit zu verlieren?
  • Wer muss wann ran (Schichtführer, Instandhaltung, Qualität, Prozessingenieur)?
  • Wann eskalieren wir (SLA/MTTR, Sicherheitsimpact, Kundenrelevanz)?
  • Welche Maßnahmen sind erlaubt, welche brauchen Freigabe?

Die Herausforderung: Man braucht Geschwindigkeit und Wiederholbarkeit.

2) Agentische Herkunft: Der Agent als Plan-Autor (nicht als Autopilot)

Agenten sind stark bei:

  • knapper Zusammenfassung („Was wissen wir?“)
  • Ableiten von sinnvollen Erstchecks je Fehlerklasse
  • Formulieren von klaren Tasks und Rückfragen
  • Strukturieren von Informationen für Schichtübergaben

Der Agent schlägt also einen Plan vor. Entscheidend ist, dass die Umsetzung in kleinen, klaren Schritten passiert – und nicht als ein großer, unkontrollierter „Mach mal“.

3) Steps: Standardisieren, ohne zu versteinern

Andon-Triage ist ideal für Steps:

  • Jeder Step ist klein und eindeutig.
  • Jeder Step ist überprüfbar (hat er das geliefert, was er soll?).
  • Steps lassen sich pro Linie/Produkt variieren, ohne das Grundprinzip zu verlieren.

So entsteht „standard work“ – ohne starre Checklisten, die in der Praxis oft umgangen werden.

4) Agentic vs. Logic: Text/Heuristik vs. operative Aktionen

  • Agentische Steps: Klassifikation, Hypothesen, Task-Formulierungen, Zusammenfassungen.
  • Deterministische Steps: Routing, Eskalation, Status-Updates, saubere Zeitstempel/Ereignislog.

Das ist ein wichtiger Unterschied: In der Störung darf man denken – aber operative Änderungen müssen konsistent passieren.

5) Beispiel-Blueprint: Andon-Triage in 6–8 Schritten

  1. Event normalisieren (Linie/Station/Fehlercode/Zeit) und kurz zusammenfassen
  2. Kritikalität einschätzen (Sicherheit, Qualitätsrisiko, Lieferimpact)
  3. Erstchecks vorschlagen (z. B. Materialwechsel? letzte Umrüstung? häufige Störung?)
  4. Routing entscheiden (Wer übernimmt?) und Tasks anlegen
  5. Informationslücken identifizieren → gezielte Rückfragen/Datenerhebung
  6. Eskalationslogik anwenden (Zeit, Wiederholung, Severity)
  7. Abschluss: Störgrund + Maßnahmen dokumentieren
  8. Übergabe/Lessons Learned (für Wiederholstörungen)

Der Schlüssel ist die Trennung von „schnell handeln“ und „sauber dokumentieren“ – beides muss passieren, ohne dass es sich gegenseitig ausbremst.

6) Regelwerk statt „im Moment entscheiden“

Störungen werden besser, wenn man Entscheiden standardisiert:

  • Eskalationsregeln sind explizit (Zeit/Severity/Wiederholung)
  • erlaubte Sofortmaßnahmen sind klar
  • Stop/Restart-Freigaben sind eindeutig geregelt
  • Rückfragen sind gezielt (statt „schick mal alles“)

Das reduziert nicht nur MTTR, sondern auch die Varianz zwischen Schichten.

7) Repair & Human-in-the-loop: Wenn die Realität unklar ist

In Störungen sind Inputs oft unvollständig. Cumulus kann robust damit umgehen:

  • Repair-then-Retry: Wenn Klassifikation/Tasks unpräzise sind, wird gezielt nachgeschärft.
  • Human-in-the-loop: Bei riskanten Entscheidungen (Sicherheit, Qualität) wird ein Mensch gezielt eingebunden.

Wichtig: keine Endlosschleifen – die Fehlerpfade sind begrenzt.

Kurzablauf als Diagramm (high level)

Flowchart illustrating the exception handling process, including steps like case planning, controlled steps execution, decision making, and closure with lessons learned.

Für Ops/Leitung: Was sich messbar verbessert

  • MTTR sinkt: Erstchecks, Routing und Eskalation laufen konsistenter ab.
  • Weniger Stillstand-Minuten: Der Prozess startet schneller und verliert weniger Zeit durch Unklarheit.
  • Bessere Schichtübergaben: Informationen sind strukturiert, nicht nur “in Köpfen”.
  • Weniger Varianz zwischen Teams: Regeln ersetzen situatives Improvisieren.
  • Nachvollziehbarkeit: Störgründe, Entscheidungen und Maßnahmen sind sauber dokumentiert.

KPI-Kasten: Woran Sie Erfolg messen

  • MTTA / Time-to-First-Action (vom Andon-Event bis zur ersten wirksamen Maßnahme)
  • MTTR (Mean Time To Repair/Recover)
  • Downtime-Minuten je Linie/Schicht (und Anteil Wiederholstörungen)
  • Eskalationen innerhalb SLA (rechtzeitig, nicht “zu spät, wenn’s brennt”)
  • Störgrund-Qualität (vollständige, konsistente Abschlussdokumentation)

Fazit

Andon-Triage braucht Geschwindigkeit, aber auch Disziplin. Cumulus verbindet:

  • agentische Planung für die ersten sinnvollen Schritte
  • kontrollierte Ausführung, Regeln und begrenzte Fehlerpfade
  • nachvollziehbare Ereignisse und saubere Übergaben

So wird aus “Alarm & Chaos” ein wiederholbarer Ablauf – ohne die Teams zu überregulieren.

Nächster Schritt

Wenn Sie möchten, erarbeiten wir daraus ein wiederverwendbares Andon-Playbook:

  • 60–90 Minuten: Rollen, Eskalationsstufen, erlaubte Sofortmaßnahmen, Stop/Restart-Gates
  • Ergebnis: ein Triage-Blueprint (Steps + Regeln) als Template pro Linie/Produktfamilie
  • Optional: 3 häufigste Störungsklassen als Varianten (z. B. Material, Sensorik, Umrüstung)
Support Triage

Projekt Cumulus – Agentic Workflows im Einsatz

Posted on by

Wenn Support-Triage zum Wettbewerbsvorteil wird: Wie agentische Workflows schneller helfen – ohne Chaos

Support ist oft der ehrliche Spiegel eines Produkts: Hier treffen reale Probleme auf reale Erwartungen. Und genau hier entscheidet sich, ob ein Team skaliert – oder ob es im Ticket-Rauschen untergeht.

Viele Organisationen testen Chatbots, um Antworten schneller zu formulieren. Das ist ein guter Start. Aber im Alltag kommen die harten Fragen:

  • Wer priorisiert zuverlässig nach Impact und SLA?
  • Wer sorgt dafür, dass Routing und Eskalation immer korrekt sind?
  • Wer verhindert riskante Aussagen (Security/Datenschutz/Compliance)?
  • Wer schafft Nachvollziehbarkeit, wenn es später kritisch wird?

Cumulus setzt dafür auf eine einfache Idee: Agentik ja – aber als Workflow.

Das Problem: Support ist nicht nur Text, sondern Entscheidung + Aktion

Eine gute Triage besteht selten aus einem einzigen Schritt. Sie ist eine Abfolge aus:

  • Verstehen (Was ist wirklich los?)
  • Einordnen (Wie dringend ist es? Welche Kategorie?)
  • Kontext ergänzen (Kunde, SLA, Historie)
  • Entscheiden (Routing, Eskalation, nächste Frage)
  • Handeln (Ticket aktualisieren, Team informieren, Status setzen)

Wenn diese Kette nicht zuverlässig funktioniert, entstehen typische Symptome:

  • Prio1/Prio2 Fälle werden zu spät erkannt
  • Tickets landen im falschen Team
  • Kunden bekommen widersprüchliche Aussagen
  • Prozesse hängen an Einzelpersonen („Frag mal Alex…“)
  • Nach Wochen weiß niemand mehr, warum etwas entschieden wurde

Cumulus: Agentische Geschwindigkeit, workflow-basierte Verlässlichkeit

Cumulus verbindet das Beste aus zwei Welten:

  • Agentische Assistenz für das, was Menschen Zeit kostet (Verstehen, Zusammenfassen, Entwurf, Formulierungen)
  • Workflow-Disziplin für das, was Teams schützt (klarer Ablauf, kontrollierte Aktionen, robuste Fehlerpfade)

Das Ergebnis ist kein „Chat, der manchmal hilft“, sondern ein skalierbarer Prozess, der sich wiederholen und verbessern lässt.

Szenario 1: „Prio 1 erkannt – bevor das SLA brennt“

Stell Sie sich einen SaaS-Anbieter mit wachsender Enterprise-Kundschaft vor: Einige Tickets wirken harmlos, sind aber in Wirklichkeit SLA-kritisch. Die Folgen kennt fast jedes Team: Eskalationen, unzufriedene Stakeholder, Ad-hoc-Feuerwehr.

Mit Cumulus lässt sich die Triage so gestalten, dass sie zuverlässig:

  • Ticket-Inhalte schnell auf den Punkt bringt
  • Dringlichkeit und Impact konsistent einordnet
  • Kundenkontext und SLA-Signale berücksichtigt
  • bei Unsicherheit gezielt eine Rückfrage stellt
  • bei klarer Lage automatisch in die richtige Spur routet

Typische Effekte:

  • Schnelleres Erkennen kritischer Fälle
  • Weniger Eskalationsdruck, weil Entscheidungen früh und sauber getroffen werden
  • Höhere Konsistenz im Umgang mit großen Kunden

Szenario 2: „Weniger Ping-Pong, mehr First-Touch-Resolution“

Stell Sie sich ein Support-Team mit mehreren Produktlinien vor: Eine hohe Quote an Ping-Pong-Tickets entsteht, weil Informationen fehlen oder das Routing uneindeutig ist.

Cumulus kann helfen, die ersten Minuten eines Tickets zu standardisieren:

  • klare, wiederholbare Fragen, wenn Informationen fehlen
  • konsistente Kategorisierung und Zuordnung
  • Antworten, die im Ton zur Marke passen
  • sichere Updates im Ticket-System, ohne manuelle Routinearbeit

Typische Effekte:

  • Mehr Tickets beim ersten Kontakt gelöst
  • Weniger interne Reibung zwischen Teams
  • Entlastung für Senior Engineers, die sonst als „Router“ fungieren

Was Teams daran mögen: Ergebnisse, die man spürt

Cumulus ist darauf ausgelegt, dass Support messbar besser werden kann:

  • Schnellere Reaktionszeiten durch strukturierte, assistierte Triage
  • Bessere Priorisierung (SLA/Impact werden konsequent berücksichtigt)
  • Mehr Konsistenz in Klassifikation, Routing und Kommunikation
  • Weniger Risiko durch kontrollierte Abläufe und klare Eingriffsoptionen
  • Bessere Skalierung: neue Produkte/Queues/Regeln lassen sich gezielt ergänzen
Flowchart illustrating a process involving ticket/intents, agent plan creation, engine step execution, decision-making by rules, and human-in-the-loop interaction.

Robust im Alltag: Wenn’s unklar wird, wird nicht geraten

Support ist nie perfekt vorhersehbar. Darum ist Robustheit in Cumulus kein „nice to have“, sondern Teil des Designs:

  • Wenn ein Ergebnis „fast richtig“ ist, kann es gezielt korrigiert werden.
  • Wenn Unsicherheit bleibt, wird ein Mensch eingebunden – nicht die Vermutung automatisiert.

So entsteht ein Ablauf, der im Alltag stabil bleibt – auch wenn Fälle selten, heikel oder unvollständig beschrieben sind.

Für wen das besonders spannend ist

  • Support-Organisationen mit wachsenden Ticketzahlen
  • Teams mit Enterprise-SLAs und On-Call-Strukturen
  • Produktlandschaften mit mehreren Queues/Teams
  • Unternehmen, die konsistente Kommunikation und Governance brauchen

Fazit

Agentik ist ein Beschleuniger. Workflows sind ein Stabilitätsanker.

Cumulus kann Support-Triage schneller, konsistenter und robuster machen – indem es Agentik in einen wiederholbaren Ablauf übersetzt, der Entscheidungen und Aktionen zuverlässig zusammenbringt.

Nächster Schritt

Wenn Sie möchten, erstellen wir daraus eine Version, die noch stärker auf Ihre Realität passt:

  • Welche Ticket-Plattform nutzen Sie?
  • Welche 3–5 Kategorien/Produkte sind am wichtigsten?
  • Welche SLA-/Eskalationsregeln sind kritisch?

Daraus kann man in kurzer Zeit einen schlanken, praxisnahen Triage-Workflow ableiten – ohne Interna offenzulegen, aber mit klarer Wirkung im Alltag.

Projekt Cumulus – Agentic Workflows

Posted on by

Cumulus

Governed Agentic Workflows – nachvollziehbar, wiederholbar, produktionsfähig

Viele Teams erleben gerade dasselbe Muster: Ein KI‑Prototyp ist schnell gebaut – aber sobald daraus ein produktionsreifer Prozess werden soll, beginnen die harten Fragen.

  • Warum hat das System „das“ getan?
  • Wie kann ich Entscheidungen auditieren und später erklären?
  • Was passiert bei Fehlern – und wie verhindere ich Endlosschleifen?
  • Wie mache ich aus einem einmaligen Erfolg einen wiederholbaren Ablauf?

Cumulus ist unsere Antwort auf genau diese Lücke: eine Workflow‑Plattform, die agentische Fähigkeiten nutzbar macht – aber unter klarer, deterministischer Kontrolle.

Die Kernidee: Agenten schreiben vor – die Engine führt aus

Cumulus trennt bewusst zwei Verantwortlichkeiten:

  • Agenten (Authorship): schlagen Pläne, Zwischenergebnisse und optional nächste Aktionen vor.
  • Engine (Authority): führt Schritte aus, vermittelt Tool‑Zugriffe, wendet Regeln an und protokolliert alles als Ereignisse.

Wichtig dabei: Agenten lösen keine Ausführung als Side‑Effect aus. Externe Effekte (z. B. Tool‑Calls, Datenabfragen, RAG‑Abrufe) passieren engine‑vermittelt.

Das Ergebnis ist ein System, das sich weniger wie „Chatbot“ anfühlt – und mehr wie ein laufender Workflow mit expliziten Schritten, Kontrollfluss und Audit‑Trail.

Was bedeutet das konkret? Jeder Lauf ist ein Event‑Stream

Cumulus speichert jeden relevanten Zustand als unveränderliche Events (append‑only). Beispiele:

  • Planung startet/endet, Plan wird vorgeschlagen und übernommen
  • Schritt startet/endet, Schritt scheitert mit Fehlerdetails
  • Nächste Aktion wird vorgeschlagen und (deterministisch) übernommen
  • Human‑in‑the‑loop wird angefordert, Feedback wird erfasst, Lauf wird fortgesetzt

Dadurch ist ein Lauf:

  • nachvollziehbar (Was ist wann passiert?)
  • replay‑fähig (State entsteht aus Event‑Replay, nicht aus „hidden state“)
  • auditierbar (Entscheidungen sind als Fakten protokolliert)

Wie ein Run abläuft

  1. Man stellt eine Frage in natürlicher Sprache.
  2. Das System analysiert Intent und plant einen Workflow (Schritte + Regeln).
  3. Der Plan wird als Datenobjekt übernommen („Plan Adopted“) und als Snapshot gespeichert.
  4. Die Engine führt Schritt für Schritt aus und streamt live Fortschritt.
  5. Bei Fehlern greift ein sicherer, begrenzter Mechanismus:
    • Repair‑then‑Retry (begrenzt) oder
    • Human Intervention (Pause → Feedback → Resume/Replan)

Ein wichtiges Detail: Bei der Neuplanung setzt Cumulus eine klare Plan‑Epoch‑Grenze. Das verhindert, dass alte Outputs unkontrolliert in den neuen Plan „hineinleaken“.

Human‑in‑the‑loop ist kein Notnagel, sondern Design

Wenn Automatisierung bricht, darf sie nicht heimlich weiter „raten“. Cumulus macht Blocker sichtbar und steuerbar:

  • Der Lauf pausiert mit einem expliziten „HumanInterventionRequested“.
  • Ein Mensch liefert Feedback/Entscheidung.
  • Resume/Replan wird als Event protokolliert.

So bleibt auch die menschliche Entscheidung Teil der Nachvollziehbarkeit.

UI‑Highlights: Live‑Transparenz statt Black Box

Die Cumulus‑UI ist darauf ausgelegt, Runs nicht nur zu starten, sondern zu verstehen:

  • Live‑Streaming: Fortschritt als Event‑Timeline (WebSocket).
  • Workflow‑Diagramme: Planung und Ausführung als Diagramm (Mermaid).
  • Run‑Detail: komplette Ereignisfolge, Resume/End‑Kontrollen bei Blockern.
  • Editoren: Schritt‑Katalog und Agent‑Specs können angepasst werden (configuration‑first).

Typische Einsatzfälle

Cumulus passt besonders gut, wenn KI nicht „frei chatten“, sondern kontrolliert handeln soll:

  • Analytics‑Copilots, die Queries erzeugen und validieren müssen (z. B. KQL)
  • Data‑Quality‑Investigations als wiederholbare Runbooks
  • Operational Triage (Alert → Enrichment → Entscheidung)
  • Support‑Workflows, bei denen Schritte und Entscheidungen nachvollziehbar sein müssen

Kurz-Demo: So sieht das in der Praxis aus

Ich habe eine kurze Übersichtsdemo aufgenommen, die genau diesen Ablauf zeigt: von der Frage über Planung und Ausführung bis zur Transparenz im Run‑Detail.

  • Projekt Cumulus Demo-Video:

Wie wir das liefern (Business Accelerator)

Cumulus ist nicht nur ein Code‑Repository – es ist ein Accelerator‑Ansatz, um in kurzer Zeit produktionsfähige agentische Workflows aufzusetzen:

  • typischerweise in 2–4 Wochen
  • mit 1–3 konkreten Workflows in Ihrer Umgebung
  • inklusive Observability/Audit‑Trail, Human‑Intervention‑Controls und Übergabe‑Doku

Nächster Schritt

Wenn Sie ein konkretes, „messy but valuable“ Problem haben (Analytics, Operations, Support), lassen Sie uns darüber sprechen. Wir schauen uns gemeinsam den Workflow‑Kandidaten an und zeigen, wie er als gesteuerter, wiederholbarer Workflow in Cumulus aussieht.

Kontakt: info@wechsler-consulting.de

Happy New 2026!

Posted on by

to all customers, colleagues and friends of Wechsler Consulting!
Let us all hope for more sanity, respect, empathy and kindness in our turbulent times.

A frosty landscape with a castle in the background under a bright blue sky, featuring a shining sun and white snow covering the ground.

We have a lot of interesting stuff coming up the next months.
So stay tuned!

A vibrant display of fireworks over a serene lake at night, with reflections shimmering on the water's surface and a pier visible in the distance.

All the best
Alexander