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.

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.

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

Ein Signal geht ein - und dann?

Es beginnt mit einem Alert: Eine Prometheus-Regel feuert über Herald, ein PagerDuty-Page geht ein, oder jemand erwähnt Hyground in einem Slack-Thread. Herald nimmt all das als JSON entgegen, und ein Triage-Schritt entscheidet, ob ein echter Incident vorliegt, der eine Untersuchung wert ist, oder nur Rauschen, das zusammengefasst wird. Bevor die eigentliche Arbeit beginnt, durchläuft das Payload eine Injection- und Jailbreak-Prüfung, damit ein präparierter Alert den Agenten nicht zu etwas verleiten kann, das er nicht tun sollte.

Von hier übernimmt ein Agent den Fall. Er plant die Untersuchung und verteilt sie auf spezialisierte Agenten, die Logs und Metriken parallel bearbeiten, jeder davon im Workspace: einem frischen, isolierten Container mit vorauthentifizierten, schreibgeschützten CLIs wie kubectl, logcli und promtool. Sie führen echte Befehle gegen Ihre Systeme aus, können aber nur lesen. Dabei ziehen sie die passenden Runbooks und früheren Untersuchungen aus der Knowledgebase, sodass ihr Reasoning darauf fußt, wie Ihre Systeme tatsächlich funktionieren, statt bei null zu beginnen.

Laufen die Agenten zusammen, korreliert Hyground ihre Ergebnisse zu einer strukturierten Root-Cause-Analyse und handelt: Ein Jira-Ticket entsteht, mit den Belegen im Anhang, oder die Zusammenfassung geht direkt zurück in den Thread. Jeder Schritt läuft in Ihrem Cluster. Das Einzige, was ihn je verlässt, ist der Prompt an das Modell Ihrer Wahl, und wenn Sie dieses Modell selbst hosten, verlässt gar nichts den Cluster.

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.