Human in the loop by construction
The graph interrupts before any action. The agent gathers and explains; people decide.
Agentic SRE · 2026 · LangGraph on GCP
From a vague alert to an evidence-backed hypothesis
A LangGraph agent that investigates production incidents on Google Cloud. It classifies the signal, gathers logs, metrics, releases and feature-flag changes through the investigation skills, writes a structured report and waits for a person before anything changes.
- 45→8
- minutes median time-to-context in production
- ~25
- alerts a week triaged
- 0
- state-changing actions without human approval
- 1
- manifest per tenant, no per-case code
The problem
Most of an incident's first hour is spent collecting context: which release went out, what the logs say, whether a flag flipped, whether the SLO is actually burning. That work is repetitive, and a tired engineer at 3 a.m. skips steps.
The agent does the collection the same way every time and hands over a report a human can check in minutes. It never fixes anything on its own.
How it works
Alert path
- TriageRoute: a firing alert, or a business signal such as "conversions dropped"
- ParseAlert policy converted into the graph's input
- InvestigateTool loop over the skill scripts: logs, time series, revisions, SLOs, flags
- ReportStructured findings, root cause separated from symptoms
- WaitGraph interrupts; a person approves, rejects or asks for more
- DecideOnly then any follow-up action
Business-signal path
- MapBusiness concern resolved to its service funnel from the tenant manifest
- Fan outEach service checked for latency, errors, traffic and slow queries against a seasonal baseline
- CorrelateDeviations ranked and lined up with deploys, flags and config changes
- ReportOne hypothesis with the evidence behind it
A tenant is a file, not code
The manifest turns a business signal into a technical subgraph. Adding a company means writing one of these.
manifests/acme.yaml
conversions:
funnel: [web, checkout, payments]
checkout:
runtime: gke
slis:
latency_p95: { gcp_monitoring: "…" }
error_rate: { gcp_monitoring: "…" }
datastore: orders-db
deploy_source: "argocd:checkout"
deploys: { gke: argocd, cloud_run: revisions }
feature_toggles: { experiments: optimizely }Decisions that mattered
Change correlation first
Most incidents follow a change. Releases, Argo CD syncs and flag updates are checked before anything else.
Skills, not prompts
Every step calls a versioned script from the skills catalogue, so the investigation is repeatable and reviewable.
One implementation, many tenants
Services, SLIs, datastores and change sources come from a manifest. No per-customer branches in the code.
Retrieval behind a port
Runbook retrieval (BGE-M3, reranker, pgvector) lives in its own service and plugs in by import, injection or HTTP.
Runs on local models
Any OpenAI-compatible endpoint; the default is a 14B model on Ollama, so logs stay inside the network.
Stack
| Layer | Choice | Why |
|---|---|---|
| Orchestration | LangGraph | Explicit state, interrupts for approval |
| Evidence | Cloud Logging, Monitoring, Cloud Run, Datadog | Through the skill scripts |
| Retrieval | BGE-M3 + cross-encoder, pgvector | Two-stage retrieval over runbooks |
| LLM | Qwen 14B on Ollama | OpenAI-compatible, swappable |
| Config | Tenant manifests (YAML) | Business concern to technical subgraph |
Where it stands
The alert path runs in production on two platforms on GCP, a Swiss fintech SaaS and an online travel marketplace, with a regression evaluation suite gating every change. The manifest-driven business-signal path is the current work.
Company names, projects and alert data are withheld.
More work
Have an AI project stuck at the prototype stage?
Tell us the problem, the data and where it needs to run. We'll come back with an architecture and scope proposal.
Email contato@laloop.ai