Agenten
Ein Multi-Agenten-System, das plant, untersucht und entscheidet. Spezialisierte Agenten bearbeiten Logs, Metriken und Wissen parallel und führen ihre Ergebnisse zu einer einzigen Antwort zusammen.
Architektur
Wie Hyground aus einem Signal eine Aktion macht
Ein Signal geht ein, Agenten untersuchen es in einem abgeschotteten Workspace, und das Ergebnis landet in den Tools, mit denen Ihr Team ohnehin arbeitet. Jeder Schritt läuft in Ihrer eigenen Infrastruktur, auf dem Modell Ihrer Wahl.
Das Gesamtbild
Drei Phasen, ein Kreislauf
Inbound-Adapter bringen Alerts, Chats und Nachrichten zu Hyground. Agenten analysieren sie, handeln in einer abgeschotteten Shell und greifen dabei auf Ihre Runbooks und frühere Untersuchungen zurück. Zurück kommt ein fertiges Ticket, eine geschriebene Dokumentation oder ein beantworteter Thread. Nichts verlässt Ihren Cluster.
Bringen Sie Ihr eigenes Modell mit
Agenten erreichen ihr Modell über LiteLLM, die Wahl liegt also bei Ihnen: Anthropic, OpenAI, Google oder ein Modell, das Sie selbst hosten. Wechseln Sie den Anbieter, ohne am Rest des Systems etwas zu ändern. Kein Vendor-Lock-in, keine Daten an ein Modell, das Sie nicht selbst gewählt haben.
Hyground von innen
Vier Bausteine erledigen die Arbeit: Agenten, die analysieren, Adapter, die Ihre Systeme auslesen, eine Sandbox, in der sie handeln, und ein Gedächtnis dafür, wie Sie arbeiten.
Adapter
Gehärtete, schreibgeschützte Wrapper um die Tools, denen Sie ohnehin vertrauen: Kubernetes, Cloud, Observability, Datenbanken. Sie verweigern den Start, wenn der Principal schreiben darf.
Workspace
Eine abgeschottete Shell, in der die Agenten die eigentliche Arbeit erledigen. Jede Aufgabe läuft in einem isolierten Container mit einem festen Satz vorauthentifizierter CLIs: kubectl, logcli, promtool, psql. Sonst nichts.
Knowledgebase
Ihre Runbooks, Ihre Dokumentation und frühere Untersuchungen, eingebettet für den Abruf. Agenten erinnern sich, wie Ihre Systeme funktionieren und wie Sie ein Problem beim letzten Mal gelöst haben.
Ein echter Durchlauf
Derselbe Vorfall. Andere Erfahrung.
Was es braucht, vom Alert zur strukturierten Ursache zu kommen: mit und ohne Hyground im Spiel.
Ohne Hyground
- 00:00
Alert feuert. Die diensthabende Person wird gepiept und springt zwischen Dashboards hin und her.
- +5min
Logs und Metriken werden in einzelnen Tabs geöffnet. Manuelles Filtern nach dem betroffenen Service beginnt.
- +15min
Ein cross-team Slack-Thread wird aufgemacht, um jemanden zu finden, der den Service und die letzten Änderungen kennt.
- +45min
Zeitstempel werden manuell zwischen Logs, Traces und Deployment-Historie korreliert.
- +2h
Nach Trial-and-Error und einer Suche in alten Incident-Notizen taucht eine wahrscheinliche Ursache auf.
- +3h
Die Ergebnisse werden manuell verschriftlicht, das Jira-Ticket wird angelegt, das Post-Mortem terminiert.
Gesamtzeit: rund 3 Stunden
Stark abhängig davon, wer dienstlich erreichbar ist und was diese Person aus dem letzten ähnlichen Vorfall erinnert.
Mit Hyground
- 00:00
Ein Alert trifft am Ingest-Endpoint ein. Die Payload durchläuft eine Injection- und Jailbreak-Prüfung, bevor irgendetwas startet.
- +30s
Der Agent plant die Untersuchung und führt sie aus.
- +2min
Logs, Metriken, Traces und Deployment-Historie werden parallel aus einer schreibgeschützten Ausführungsumgebung abgefragt.
- +4min
Passende Runbooks und frühere Untersuchungen werden aus der Wissensdatenbank gezogen, das Reasoning ist in Ihren Systemen verankert.
- +6min
Eine strukturierte Ursache liegt vor: betroffene Services, Belege, empfohlene nächste Schritte, jeder Schritt protokolliert.
- +1h
Ein Post-Mortem-Entwurf wird automatisch aus der Untersuchung erstellt: Verlauf, Ursache, beitragende Faktoren, To-dos.
Zeit bis zur Ursache: rund 6 Minuten
Jeder Schritt läuft innerhalb Ihres Clusters. Jede Abfrage, jeder Beleg, jeder Reasoning-Schritt ist protokolliert und nachvollziehbar.
Verbunden mit allem, was Sie betreiben
Derselbe Kreislauf klinkt sich in die Tools ein, in denen Ihr Team ohnehin arbeitet, eingehend wie ausgehend.
Eingehende Signale
Alerts, Chats und KI-Tools erreichen Hyground über Inbound-Adapter.
- Alerts: Prometheus, PagerDuty, Grafana über Herald
- Chat: Slack, Teams, E-Mail
- KI-Tools: Claude Code, Cursor, jeder MCP-Client
Ausgehende Ergebnisse
Ergebnisse kommen als Arbeit zurück, nicht als Benachrichtigung, in den Tools, die Ihr Team bereits nutzt.
- Tickets: Jira, ServiceNow, GitHub, GitLab
- Konversationen: Slack, Teams, E-Mail
- Code & Docs: Commits und PRs über GitHub, GitLab
Selbst gehostet & souverän
Sicherheit greift auf Architekturebene
Hyground kommt als Kubernetes-Helm-Chart und läuft vollständig innerhalb Ihres Perimeters. Im Pfad sitzt kein Hyground-SaaS: keine Control Plane, kein Phone-home, kein Betreiberzugriff in Ihren Cluster.
Läuft in Ihrem Cluster
Ein selbst gehostetes Helm-Chart ohne Zugriffspfad für den Anbieter. Keine SaaS-Control-Plane, kein zentraler Schlüssel, keine geteilte Infrastruktur. Der Anbieter hat keinen operativen Weg hinein.
Wir sehen Ihre Daten nie
Kein Daten-Egress, keine Telemetrie, kein Phone-home. Der einzige ausgehende Verkehr ist der Prompt an das von Ihnen gewählte LLM, und Secrets werden entfernt, bevor das Modell sie sieht. Hosten Sie dieses Modell selbst, verlässt überhaupt nichts mehr Ihre Infrastruktur.
Gehärtet und schreibgeschützt
Chainguard-Distroless-Images, non-root, schreibgeschütztes Root-Dateisystem. Adapter sind standardmäßig schreibgeschützt und verweigern den Start, wenn der Principal schreiben darf.
Hyground in Aktion erleben
Testen Sie unsere Sandbox oder vereinbaren Sie eine Demo mit unserem Team und erleben Sie souveräne KI aus erster Hand.