Lösung · AI Operations

Du hast mehrere KI-Agenten. Was du nicht hast, ist ein System.

Wenn jeder Agent für sich arbeitet, ist das Problem nicht mehr der Prompt, sondern die Aufteilung: wer macht was, in welcher Reihenfolge, mit welchem Kontext und wer antwortet, wenn die Kette reißt. Diese Orchestrierungsschicht wird gebaut und betrieben. Improvisiert wird sie nicht.

Bau es in meinem Betrieb Sehen, wie es läuft

Das Problem

Fünf Agenten, die nicht miteinander reden, sind kein System. Sie sind fünf Inseln mit derselben Rechnung.

Zwei Agenten fassen denselben Datensatz an, und es gewinnt, wer zuletzt schreibt; niemand weiß, welcher von beiden recht hatte.
Die Arbeit wandert per improvisiertem Webhook von einem Agenten zum nächsten, ohne Vertrag über Ein- und Ausgabe: ändert sich einer, bricht der daneben still.
Der Kontext reist nicht mit. Der zweite Agent fragt den Kunden erneut nach der Angabe, die der erste schon hatte, und der Kunde merkt es.
Wenn etwas schiefgeht, weiß niemand, bei welchem Agenten es kippte: es gibt Logs von jedem einzeln und keine Spur des gesamten Falls.
Eine Lastspitze feuert alle fünf gleichzeitig gegen dasselbe ERP, und was hochgeht, ist nicht die KI: es ist das System nebenan.

Was es kostet, alles zu lassen

Jeder neue Agent addiert nicht, er multipliziert das Chaos: mehr Flächen, die sich überschneiden, mehr Wege ohne Eigentümer, mehr Vorfälle, die niemand zuordnen kann. Am Ende verbringt das Team mehr Zeit damit herauszufinden, welcher Agent was getan hat, als mit der Arbeit, die die Agenten abnehmen sollten. Und die Decke kommt früher als es scheint: nicht beim hundertsten Agenten, sondern beim vierten.

Die Lösung

Wir bauen die Orchestrierungsschicht —Aufteilung, Reihenfolge, Kontext und Spur— und wir betreiben sie

1Bevor wir irgendetwas orchestrieren, prüfen wir, ob es nötig ist. Lässt sich die Arbeit nicht wirklich in Stücke teilen, die vorankommen, ohne sich bei jedem Schritt abzustimmen, gewinnt ein einziger gut gebauter Agent gegen fünf koordinierte —und das sagen wir dir. Komplexität zu orchestrieren, die es nicht gibt, ist die teuerste Art, nichts zu tun.
2Wir definieren die Aufteilung: was jeder Agent tut, was er NICHT tut, was er bekommt und was er zurückgibt. Explizite Verträge über Ein- und Ausgabe, damit ein Agentenwechsel den daneben nicht bricht.
3Wir bauen den Motor, der die Reihenfolge entscheidet: was parallel läuft, was auf was wartet, was wiederholt und was abgebrochen wird. Mit geteiltem Zustand, damit der Kontext zwischen den Schritten mitreist, statt ihn erneut beim Kunden abzufragen.
4Wir setzen Nebenläufigkeits- und Zugriffskontrolle: Limits pro System, damit eine Spitze dein ERP nicht umlegt, Berechtigungen mit begrenztem Umfang pro Agent und Sperren auf den Datensätzen, die zwei Agenten gleichzeitig anfassen könnten.
5Wir schließen mit durchgängiger Spur ab: eine Fall-Kennung, die die ganze Kette durchläuft, damit sich ein Vorfall beim konkreten Agenten und Schritt lokalisieren lässt und nicht durch das Öffnen von fünf Dashboards.
6Wir betreiben es: Eigentümer pro Agent, Version, wiederholbares Deployment, Alarme, wenn ein Zweig degradiert, und regelmäßige Prüfung, was in der Aufteilung überflüssig ist.

Was sich ändert

Was du nicht mehr verlierst

Die Übergabe zwischen Agenten ist kein improvisierter Webhook mehr: sie wird zu einem Vertrag mit Eingabe, Ausgabe und Wiederholung, den man ändern kann, ohne die Kette zu brechen.
Mechanismus
Der Kontext reist mit dem Fall. Der Kunde wiederholt einem Agenten nicht mehr, was er einem anderen schon erzählt hat.
Mechanismus
Der Vorfall ist keine Ermittlung mehr: die durchgängige Spur zeigt auf den Agenten und den Schritt, wo es kippte, nicht auf die ungefähre Uhrzeit.
Mechanismus
Was wir messen: durchgängig ohne Eingriff abgeschlossene Fälle, Fehler bei der Übergabe zwischen Agenten, Zeit bis zur Ursache eines Vorfalls und Last, die jeder Agent in die Systeme nebenan drückt.
Was wir messen

Datenblatt

Wegfallende Arbeit: von Hand mehrere Agenten koordinieren, die sich in die Quere kommen: die Reihenfolge entscheiden, den Kontext von einem zum anderen tragen und herausfinden, bei welchem die Kette riss
Übliche Einrichtung: 3–6 Wochen
Eingang: ein Fall, der mehr als einen Agenten braucht, um durchgängig geschlossen zu werden
Ausgang: der abgeschlossene Fall mit Reihenfolge, geteiltem Kontext, Wiederholungen und einer einzigen Spur, die die ganze Kette durchläuft
Kompatibel mit: Agentes construidos sobre cualquier framework (LangGraph, n8n, Temporal, Inngest, código propio)Modelos de OpenAI, Anthropic, Google o self-hostedMCP como conector estándar hacia tus sistemas
Kann sich verbinden mit: Deine Geschäftssysteme (ERP, CRM, Helpdesk, Data Warehouse)Deine aktuelle Observability, damit die Spur nicht in einem separaten Dashboard lebtDeine Verwaltung von Berechtigungen und Identitäten
Was wir messen: durchgängig ohne Eingriff abgeschlossene FälleFehler, die einer Übergabe zwischen Agenten zuzuordnen sindZeit bis zur Ursache eines VorfallsLast, die jeder Agent in den Systemen nebenan erzeugt
Geeignet für: Unternehmen mit mehreren Agenten bereits in Produktion, die sich in die Quere kommen, sich gegenseitig brechen oder keinen Kontext teilen
Nicht geeignet für: wer einen einzigen Agenten hat, oder wer mehrere will, weil es modern klingt: teilt sich die Arbeit nicht wirklich, fügt Orchestrierung nur Kosten hinzu

Häufig gestellte Fragen

Nein, und der Unterschied zählt, weil er entscheidet, was du brauchst. Eine Flotte zu skalieren ist ein Volumenproblem: wie schaffst du es, dass der hundertste Agent so wenig kostet wie der sechste. Orchestrieren ist ein Koordinationsproblem, und es taucht viel früher auf: es trifft dich mit vier Agenten, wenn diese vier denselben Prozess berühren, sich Datensätze überschreiben und die Arbeit ohne Vertrag weiterreichen. Du kannst hundert unabhängige Agenten haben und keine Orchestrierung brauchen, und vier haben und sie dringend brauchen. Geht es bei dir um Volumen, ist das Gespräch das über das Skalieren einer Flotte; stören sich deine Agenten gegenseitig, ist es dieses.

Sagen wir, und dabei bleibt es: die meisten Büroarbeiten löst ein Agent mit guten Werkzeugen und durchgehendem Kontext besser als ein Komitee von Bots, das sich den schwarzen Peter zuschiebt. Deshalb ist der erste Schritt dieser Arbeit zu prüfen, ob Orchestrierung wirklich nötig ist, und deshalb besteht die Lieferung manchmal darin, drei Agenten zu einem zu verschmelzen. Wir orchestrieren, wenn sich die Arbeit wirklich teilt —Stücke, die vorankommen, ohne sich bei jedem Schritt abzustimmen, verschiedene Systeme, verschiedene Takte, verschiedene Berechtigungen—, nicht wenn das Bot-Organigramm auf einer Folie gut aussieht.

Nein. Die Schicht kommt auf das, was du schon hast, egal aus welchem Framework. Was sich ändert, ist nicht das Innere jedes Agenten: es ist, dass es jetzt einen expliziten Vertrag darüber gibt, was er bekommt und was er zurückgibt, einen Motor, der Reihenfolge und Wiederholungen entscheidet, einen geteilten Zustand, damit der Kontext mitreist, und eine einzige Spur für den gesamten Fall. Taucht dabei ein überflüssiger Agent auf oder zwei, die dasselbe tun, zeigen wir darauf —aber das ist eine Empfehlung mit Daten, keine Voraussetzung, um anzufangen.

Bauen wir es in deinem Betrieb?

Du hast das Problem benannt. Wir liefern die Lösung und lassen sie gemessen laufen.

Zum Service