Architecture

How Hyground turns a signal into action

A signal arrives, agents investigate in a sandboxed workspace, and the result lands in the tools your team already runs. Every step happens inside your own infrastructure, on the model you choose.

The whole picture

Three stages, one loop

Inbound adapters carry alerts, chats, and messages into Hyground. Agents reason over them, act in a sandboxed shell, and draw on your runbooks and past investigations. What comes back is a filed ticket, written documentation, or an answered thread. Nothing leaves your cluster.

Bring your own model

Agents reach their model through LiteLLM, so the choice stays yours: Anthropic, OpenAI, Google, or a model you host yourself. Swap providers without touching the rest of the system. No vendor lock-in, no data sent to a model you didn't pick.

Inside Hyground

Four parts do the work: agents that reason, adapters that read your systems, a sandbox where they act, and a memory of how you operate.

Agents

A multi-agent system that plans, investigates, and decides. Specialised agents work logs, metrics, and knowledge in parallel, then aggregate what they find into one answer.

Adapters

Hardened, read-only wrappers around the tools you already trust: Kubernetes, cloud, observability, databases. They refuse to start if the principal can write.

Workspace

A sandboxed shell where the agents do the actual work. Each task runs in an isolated container with a fixed set of pre-authenticated CLIs: kubectl, logcli, promtool, psql. Nothing else.

Knowledgebase

Your runbooks, documentation, and past investigations, embedded for retrieval. Agents recall how your systems work and how you fixed things last time.

A real run

What happens when a signal arrives

An alert lands: a Prometheus rule fires through Herald, a PagerDuty page comes in, or someone mentions Hyground in a Slack thread. Herald takes any of these as JSON, and a triage step decides whether it is a real incident worth investigating or noise to summarise. Before any work starts, the payload passes an injection and jailbreak check, so a crafted alert can't steer the agent into doing something it shouldn't.

From there an agent takes the case. It plans the investigation and fans out to specialised agents that work logs and metrics in parallel, each one running in the Workspace: a fresh, isolated container with pre-authenticated, read-only CLIs like kubectl, logcli, and promtool. They run real commands against your systems but can only read. As they go, they pull the relevant runbooks and past investigations from the Knowledgebase, so the reasoning is grounded in how your systems actually work instead of starting from scratch.

When the agents converge, their findings are correlated into one structured root cause, and Hyground acts on it: a Jira ticket filed with the evidence attached, or the summary posted straight back to the thread. Every step runs inside your cluster. The only thing that ever leaves is the prompt to the model you chose, and if you host that model yourself, nothing leaves at all.

Connected to everything you run

The same loop plugs into the tools your team already lives in, inbound and outbound.

Signals in

Alerts, chats, and AI tools reach Hyground through inbound adapters.

  • Alerts: Prometheus, PagerDuty, Grafana via Herald
  • Chat: Slack, Teams, Email
  • AI tools: Claude Code, Cursor, any MCP client

Results out

Findings come back as work, not notifications, in the tools your team already uses.

  • Tickets: Jira, ServiceNow, GitHub, GitLab
  • Conversations: Slack, Teams, Email
  • Code & docs: commits and PRs via GitHub, GitLab

Self-hosted & sovereign

Security is enforced at the architecture level

Hyground ships as a Kubernetes Helm chart and runs entirely inside your perimeter. There is no Hyground SaaS in the path: no control plane, no phone-home, no operator access into your cluster.

Runs in your cluster

A self-hosted Helm chart with no vendor access path. No SaaS control plane, no central key, no shared infrastructure. The vendor has no operational route in.

We never see your data

Zero data egress, zero telemetry, no phone-home. The only outbound traffic is the prompt to the LLM you chose, and secrets are stripped before the model sees them. Host that model yourself and nothing leaves at all.

Hardened and read-only

Chainguard distroless images, non-root, read-only root filesystem. Adapters are read-only by default and refuse to start if the principal can write.

See Hyground in action

Check out our sandbox or schedule a demo with our team and experience sovereign AI firsthand.