AI-assisted operations, without your data leaving your environment
The repetitive part of being on call — gathering the state of a service, cross-referencing logs and metrics, comparing against the last deployment, drafting the incident summary — can be assisted by an agent with read access to Kubernetes, logs and metrics over MCP. We build it deployed inside your environment, on-premise or in your own cloud, with write actions behind human approval. It is meant for sectors that cannot send their operational data to a third-party SaaS tool.
Last updated:
Taking the mechanical work out of on-call
Who it is for
For teams that already have a working incident process and want the mechanical work taken out of it, and for organisations that cannot use SaaS assisted-operations tools because their data cannot leave the environment: health, public sector, defence, financial entities and their providers.
What it solves
The first twenty minutes of an incident are almost always the same twenty minutes: open five tabs, check pod status, find the spike on the dashboard, see whether there was a deployment, read the logs of the service next door. That can be gathered and summarised on its own, and the time saved is the time of the person deciding what to do.
What it is NOT
It is not automated remediation, and we do not recommend that as a starting point. The agent reads, correlates, proposes and drafts; executing what it proposes is a person's decision, and write actions sit behind explicit, logged approval. It does not replace written runbooks either: it uses them, and in fact it forces you to keep them in order.
The three parts
Agentic runbooks
The procedures you already have written, executable step by step by an agent, with the checks automated and the decisions marked as human.
Incident copilot
It gathers the context as soon as the alert fires: state, logs, metrics, recent changes and similar past incidents, summarised in the channel you already work in.
Inside your perimeter
Deployed on-premise or in your cloud, with MCP connectors read-only, least privilege and a log of everything the agent queries and proposes.
How it is built
Connectors
MCP servers for what you already have: Kubernetes, the log platform, the metrics, the repository and the deployment system, the incident tracker. Each with its own service account, least privilege and, by default, read-only.
Model and deployment
The model can be one of your own running on your infrastructure, or a commercial one with the connection under your contract and your retention terms. We decide that with your security lead, and it is written down which data the model sees, what never leaves the perimeter and what is logged. If the answer is that no data can leave, it is built with a local model and we say what capability is given up in exchange.
Guardrails
An allowlist of actions, mandatory human approval for any write, scope limits per environment — production separately — and a full trace of requests and responses. It is tested first in staging and against past incidents, to see whether its conclusions would have been useful before letting it speak during a real one.
What you keep
The connector and runbook code in your repository, the configuration as code and the documentation. None of it depends on us staying.
How we work
Use case
Which part of on-call hurts most. We start with one or two specific procedures, not with «connect the AI to everything».
Read-only connectors
Least access to Kubernetes, logs, metrics and deployments, with dedicated accounts and logging from day one.
Testing against past incidents
Measured against real, already-closed incidents: what it would have answered and whether that would have helped. If it does not help, it does not get deployed.
Deployment and guardrails
Rollout in your environment, human approval for writes and periodic review of what the agent proposes.
Frequently asked questions
Will it touch production on its own?
Not with our default configuration. Connectors are read-only, write actions require explicit human approval and are logged, and production has a separate scope. Widening that is your decision and it is done service by service, not all at once.
Does our operational data leave for a third party?
That depends on what you decide, and it is written down before anything is built. With a local model, nothing leaves the perimeter. With a commercial model, what leaves is whatever the agent sends as context, under your contract and your retention terms, and the design includes which fields are filtered before sending.
What if the model gets it wrong?
It will, and the design starts from that: it proposes with the sources visible so they can be checked, it does not assert without a link, and it does not execute. Testing against past incidents is there precisely to measure how often it is right before anyone trusts it.
Do we need a good observability platform already?
You need the data to exist and be queryable. If instrumentation is poor, the agent will be too: in that case the honest answer is to start with observability and leave this for later.
Which tools do you work with?
Kubernetes and Terraform for infrastructure, ArgoCD for GitOps, OpenTelemetry for telemetry, and Prometheus, Grafana, Loki and Tempo to look at it. Open, standard tooling on purpose: any engineer on the market can pick the work up, and you can stop working with us without having to redo it.
We do not run Kubernetes. Does this still apply?
Yes. SLOs, alerts with an owner, an incident process and postmortems work just as well on virtual machines, plain containers or your own servers. Kubernetes is a common tool, not a requirement, and we do not recommend it where there is no volume to justify it.
Do we have to change cloud provider to start?
No. Reliability work happens on what you already have, whether that is AWS, Azure, Google Cloud, a European provider or your own hardware. Migration is a separate service and only makes sense if there is a reason for it.
Tell us which part of on-call hurts
A couple of your procedures and the inventory of tools is enough to say whether this is for you. We reply within 24 working hours.
or write to us at info@esdis.es