Skalierbarkeit
Die Plattform ist so gebaut, dass die nächste Bereitstellung immer schneller ist als die vorherige. Workflows, Komponenten und Agenten sind modulare Bausteine, die jedes Team und jede Region wiederverwenden kann, sodass sich die Abdeckung potenziert und der Weg zur Superintelligenz kürzer wird.
Demo buchenWiederverwendbare Workflow-Komponenten
Gemeinsame Logik lässt sich in eine wiederverwendbare Komponente packen und dann in mehrere Workflows importieren, sodass die nächste Bereitstellung mit Bausteinen startet, die frühere Bereitstellungen bereits genutzt haben. Aktualisierungen an einer Komponente wirken sich sofort auf alle Agenten aus und helfen, Bereitstellungen über Regionen und Funktionen hinweg massiv zu skalieren.
- IdentitätsprüfungIn 14 Workflows verwendetPrompt
- GuardrailsIn 22 Workflows verwendetPrompt
- TMS-AbfrageIn 9 Workflows verwendetNode
- SMS sendenIn 17 Workflows verwendetNode
- Technikerbesuch buchenIn 6 Workflows verwendetWorkflow
- AdressabfrageIn 12 Workflows verwendetNode
Statusanruf beim Frachtführer
- GuardrailsVersion 6
- IdentitätsprüfungVersion 8
- TMS-AbfrageVersion 3
Verschachtelte Workflows
Ein Workflow ruft einen anderen auf und nutzt dessen Antwort, sodass ein Prozess mit hundert Schritten als eine Handvoll untergeordneter Workflows läuft statt als ein Monolith. Jeder untergeordnete Workflow wird von dem Team verantwortet, getestet und versioniert, das ihm am nächsten steht, sodass große Prozesse sich weiter verändern können, ohne jedes Mal vollständig neu getestet zu werden.
Entwicklungsumgebungen
Entwicklung, Staging und Produktion halten jeweils ihre eigene aktive Version, Zugangsdaten und Endpunkte. Mehrere Teams können gleichzeitig bauen und validieren, ohne auf ein Release-Fenster zu warten oder den Prozess zu berühren, den Kunden gerade nutzen. Wie viele Personen gleichzeitig ausliefern können, wird also nicht durch das Risiko für den Live-Traffic begrenzt.
Version 14
Entwurf
Version 13
Im Test
Version 12
Live
- Zugangsdaten
- TMS-Live-Schlüssel
- Endpunkt
- /checks
- Bereitgestellt
- 26. Sep., 11:02
- Läufe heute
- 2.140
Rollenbasierte Zugriffssteuerung
Die Rollen Owner, Editor und Viewer legen fest, wer einen Workflow bearbeiten, in die Produktion veröffentlichen oder die dahinterliegenden Daten lesen darf. Ein neues Team beginnt mit dem Aufbau, ohne jede Änderung über einen zentralen Owner leiten zu müssen und ohne die Teile berühren zu können, die es nicht verantwortet. Mehr Entwickelnde bedeuten also nicht mehr Risiko.
- Workflow bearbeiten
- In Produktion veröffentlichen
- Laufdaten lesen
- Mitglieder verwalten
- Zugangsdaten rotieren
Agenten-Orchestrierung
Workflows lassen sich mit einem Orchestrator-Agenten aufbauen, der triagieren und an Sub-Agenten weiterleiten kann, jeder mit eigenem Prompt, eigenen Tools und eigenem Wissen, und der die Kontrolle jederzeit zurücknehmen kann, um erneut zu triagieren. So deckt der Betrieb mehr Terrain ab, ohne dass ein einzelner Agent schwerer testbar wird.
- 01An Scheduling-Agent weitergeleitetTermin auf Donnerstag 08:00 verschoben
- 02Kontrolle zurück an OrchestratorZweite Anfrage gefunden
- 03Über MCP an Billing-Agent weitergeleitetRechnungsfrage übergeben
FAQs
Ein Agent mit vielen Tools funktioniert so lange, bis die Anweisungen für unterschiedliche Situationen miteinander konkurrieren. Die Aufteilung in spezialisierte Agenten, jeder mit eigenem Prompt, eigenen Tools und eigenem Wissen, hält jeden einzelnen eng gefasst und testbar, während ein Orchestrator die Triage zwischen ihnen übernimmt. Übergaben können auch Kanäle überschreiten: Ein Sprach-Agent kann ein Gespräch an einen Text-Agenten übergeben, und externe Agenten lassen sich über MCP anbinden.
Eine Workflow-Komponente wird importiert: Die Sequenz wird Teil des Workflows, der sie nutzt. Ein aufgerufener Workflow wird invoziert: Er läuft als eigener untergeordneter Lauf, gibt eine Antwort zurück, und der übergeordnete Workflow wird fortgesetzt. Importieren Sie, wenn die Logik inline und gemeinsam genutzt sein soll; rufen Sie auf, wenn der untergeordnete Workflow ausgeführt, überwacht und unabhängig versioniert werden soll.
Das ist der Standard: Sie aktualisieren einen gemeinsam genutzten Prompt, Node oder Workflow-Baustein an einer Stelle, und jeder Agent, der ihn verwendet, übernimmt die Änderung, ohne dass Sie einzelne Instanzen suchen müssen. Wo sich ein Workflow erst bewegen soll, wenn Sie bereit sind, lässt sich ein aufgerufener Workflow auf eine bestimmte Version und Umgebung festlegen, sodass der übergeordnete Workflow auf dem getesteten Release bleibt.
Ja. Jeder untergeordnete Workflow bringt eigene Timeouts und eine eigene Fehlerbehandlung mit, sodass ein Fehler eingegrenzt wird, statt sich fortzupflanzen. Jeder untergeordnete Lauf ist separat beobachtbar und rollback-sicher, das heißt, Sie können genau nachvollziehen, welcher verschachtelte Lauf fehlgeschlagen ist, und ihn zurücksetzen, ohne den übergeordneten Prozess drumherum aufzurollen.
Die gemeinsame Schicht liegt auf Workspace-Ebene: dieselbe Komponentenbibliothek, dieselben Northstars, sodass jede Region von einem Standard ausgeht. Jede Region behält dann ihre eigenen Workflow-Versionen, Umgebungen und Zugangsdaten, sodass lokale Regeln und Integrationen abweichen können, ohne dass die Bereitstellungen auseinanderlaufen.
