Vom ersten Agenten bis zum produktiven Multi-Agenten-System – eine vollständige Schritt-für-Schritt-Anleitung
Release am 25. November 2026. Beta verfügbar ab Release. Vor dem Release gibt es keine nutzbare Version. Wer jetzt kauft, sichert sich die vorläufige Mitgliedschaft zum 50 %-Preis — gültig bis einschließlich 2. Dezember 2026; danach gilt der reguläre Listenpreis (79 / 199 / 399 / 799 €).
HYPDB.ONE ist mehr als ein Dashboard – es ist eine vollständige Plattform zur Orchestrierung von KI-Agenten. Diese Anleitung zeigt dir, wie du in wenigen Schritten eigene KI-Workflows aufbaust, automatisierst und produktiv einsetzt. Du benötigst keine Programmiererfahrung, nur einen Browser und einen HYPDB.ONE-Zugang.
Die folgende Tabelle beschreibt nicht die Theorie, sondern das System, auf dem diese Anleitung läuft. Jeder Wert wird beim Öffnen dieser Seite gemessen — nichts davon ist hinterlegt. Quelle: /api/automation und /api/status.
| Kennzahl | Gemessen | Hinweis |
|---|---|---|
| Messung läuft … | ||
Die Zustandsverteilung der Aufträge, ebenfalls live gezählt. Das Feld leistung.aktiv in derselben Antwort zählt die eingeschalteten Aufträge — die Differenz zur Zustandsliste ist ein Widerspruch der Datenquelle, den diese Anleitung sichtbar macht statt ihn zu verstecken.
| Zustand | Anzahl |
|---|---|
| Messung läuft … | |
Die Anleitung unten beschreibt Konfigurationsfelder (Wiederholung, Fehlerbehandlung, Zustellwege). Ob das laufende System diese Felder wirklich führt, ist messbar. Ergebnis: die API liefert je Auftrag die Felder id, nr, name, typ, state, enabled, schedule, last, profile, script — und keine einzige Wiederholungs-, Zustell- oder Fehlerverlaufsangabe. Die YAML-Beispiele unten sind als Muster zu lesen, nicht als Beschreibung der laufenden API.
| Feld der Anleitung | In /api/automation | Route |
|---|---|---|
| retry / max_attempts / backoff | nicht geführt | — |
| on_failure / notify | nicht geführt | — |
| last_status / last_error | nicht geführt (nur last) | — |
| next_run_at | nicht geführt (nur schedule) | — |
| deliver (Zustellweg) | nicht geführt | — |
| Test-Modus | kein Endpunkt | /api/testmodus |
| Workflow-Dashboard | kein Endpunkt | /api/dashboard |
| Abo-Kündigung | kein Endpunkt | /api/cancel |
Diese Skills sind laut /api/skills im System freigeschaltet (gefiltert auf Tarif starter). Der Katalog beschreibt, was die Plattform kann — nicht, was dein Konto nach dem Kauf enthält.
| Skill | Kategorie | Mindest-Tarif |
|---|---|---|
| Messung läuft … | ||
Die Antwort auf /api/automation führt oben zwei weitere Felder, die auf keiner Zeile dieser Anleitung vorher standen: die dienste des Hosts und die profile, unter denen die Aufträge laufen. Beides wird beim Laden gemessen — es beschreibt den Server dieses Anbieters, nicht dein Konto.
| Dienst | Port | Zustand |
|---|---|---|
| Messung läuft … | ||
| Auftragsprofil | Aufträge |
|---|---|
| Messung läuft … | |
Das Feld schedule mischt zwei Schreibweisen: klassische Cron-Ausdrücke und die Kurzform every Nm. Die Tabelle trennt beide Formen, statt sie als eine Liste auszugeben.
| Form | Verschiedene Ausdrücke | Aufträge | Hinweis |
|---|---|---|---|
| Messung läuft … | |||
Melde dich im HYPDB.ONE-Dashboard an und navigiere zum Bereich Agenten. Klicke auf Neuen Agenten erstellen und wähle einen Namen, der die Aufgabe beschreibt – zum Beispiel „Content-Recherche" oder „E-Mail-Assistent".
HYPDB.ONE ist modell- und providerneutral: du wählst in der Agenten-Konfiguration selbst das Modell und den Provider. Für den Einstieg empfiehlt sich ein schnelles, günstiges Modell; für datenschutzkritische Aufgaben ein lokal betriebenes Modell (z. B. über Ollama), das ohne externen Aufruf auskommt. Welche Modelle und Provider in deinem Konto verfügbar sind, zeigt dir die Modell-Auswahl im Dashboard.
Die Agentenzahl je Tarif ist begrenzt — die verbindlichen Werte stehen in der Tarifauswahl (pricing.html) und werden dort live aus /api/tiers geprüft. Diese Anleitung nennt bewusst keine Zahlen, die sich morgen ändern könnten.
Beginne mit einem einzelnen Agenten und einer klaren, abgegrenzten Aufgabe. Ein Agent, der „nur" E-Mails kategorisiert, ist wertvoller als ein vager Alleskönner.
Jeder Workflow braucht einen Auslöser. HYPDB.ONE unterstützt verschiedene Trigger:
Definiere, was passieren soll, wenn der Trigger auslöst. Eine typische Kette sieht so aus:
Dieses Beispiel ist ein Muster für die Struktur — keine Beschreibung der laufenden API. Welche Aktionen das System heute tatsächlich ausführt, sagt der Skill-Katalog oben; einen Test-Modus, der die Kette vor dem Scharfschalten prüft, gibt es in der API nicht (siehe Lückentabelle oben).
Prüfe deine Kette im kleinen Rahmen: ein einzelner Durchlauf mit sichtbarem Ergebnis ist mehr wert als ein theoretisch durchdachter Workflow. Wiederholungs- und Fehlerfelder solltest du vorerst selbst im Auge behalten — das System führt sie nicht.
Sobald du mit einzelnen Agenten vertraut bist, kannst du mehrere Agenten zu einem Workflow verbinden. Jeder Agent übernimmt eine spezialisierte Aufgabe und reicht das Ergebnis an den nächsten weiter.
Ein typischer Multi-Agenten-Workflow für Content-Erstellung:
Bestimme, wie Agenten miteinander kommunizieren. HYPDB.ONE bietet drei Übergabemodi:
Parallel laufende Agenten verbrauchen mehr Ressourcen. Achte auf die Modell-Limits deines Providers und starte mit maximal 2-3 parallelen Agenten.
HYPDB.ONE enthält ein vollständiges Cron-Job-System. Du kannst Workflows zu festen Zeiten, in Intervallen oder zu bestimmten Anlässen automatisch starten lassen. Das System, auf dem diese Seite läuft, führt selbst — Aufträge — die Zustandsverteilung steht in der Tabelle oben.
Daneben akzeptiert das laufende System auch die Kurzform every 5m — beides steht in den Zeitplänen der aktuellen Auftragsliste. Für klassische Crontabs ist die Kurzform ungültig; im System ist sie erlaubt.
Lasse dir Ergebnisse direkt auf Telegram senden – perfekt für tägliche Reports oder Status-Updates:
Der Zustellweg („telegram" oben) ist ein Muster. Ob dein Auftrag Ergebnisse an einen Kanal ausgibt, hängt an deiner Konfiguration — die API führt pro Auftrag kein Zustellfeld.
Der Systemstatus des laufenden Servers ist jederzeit über die Startseite abrufbar — die Anleitung hier beschreibt deine Aufträge, nicht den Betrieb der Plattform.
Ein automatisierter Workflow ist nur so gut wie seine Fehlerbehandlung. Diese Anleitung beschreibt unten die Muster, die du selbst einsetzen kannst — die laufende API führt die Felder nicht (siehe Lückentabelle oben). Was das System heute trotzdem protokolliert: 25 Protokollzeilen aus /api/automation, abrufbar in der Startseiten-Diagnose.
Die mittlere Zeile ist ein Muster, keine Beschreibung des Systems — der Zustellweg ist wie oben nicht in der API geführt. Die Protokollierung läuft über die Plattform, nicht über deinen Auftrag.
Die Plattform kann fehlgeschlagene Aufträge erneut anstoßen; Wiederholungslogik (max. Versuche, Wartezeit) führst du selbst im Skript. Das Muster unten zeigt die Struktur, die das laufende System nicht in der API abbildet:
Setze max_attempts nicht zu hoch – 3 Wiederholungen sind in der Regel ausreichend. Sonst kann ein dauerhafter Fehler unnötig Ressourcen verbrauchen.
Welcher Tarif deine Agentenzahl, Projekte und Skills freischaltet, prüft die Preisseite beim Laden live gegen /api/tiers. Diese Anleitung nennt keine Zahlen — die verbindlichen Werte stehen dort, nicht hier.
Weitere Anleitungen: Workflows mit Cron automatisieren · Workflows mit Telegram steuern · Workflows überwachen und optimieren
Du hast jetzt die Grundlagen, um eigene KI-Workflows mit HYPDB.ONE zu automatisieren. Hier sind deine nächsten Schritte:
Bei Fragen hilft dir die FAQ oder der Telegram-Support. Viel Erfolg beim Automatisieren!