Governed agent runtime · electric vehicle data

Let agents work your EV data platform. Keep the proof.

A fleet of electric vehicles streams telemetry into your cloud around the clock, battery state, charging sessions, diagnostics. When that pipeline breaks, Settlegate's Sentinel runtime puts a policy-governed agent on the investigation, and captures every tool call, every piece of evidence, and every recommendation as an auditable record.

Default-deny tool policy · one provenance trail per investigation · every action audited

sentinel · investigations
3Open investigations
184Tool calls audited
0Out-of-policy calls

INC-4212 · telemetry-ingest

Elevated errors after deploy · vehicle-to-cloud

Investigating
TriggerAlert · 5xx rate 14× baselineAuto
Evidence14 artifacts · metrics, logs, tracesCited
DiagnosisTimeout on battery-state dependencyDraft
Policyread-only observabilityEnforced
investigate.ts
// an incident event opens an investigation
const run = await sentinel.investigations.open({
  trigger: alert.id,        // not a chat prompt
  agent:   "incident-triage",
  policy:  "observability-readonly",
  tools:   ["grafana", "kubernetes", "kafka"]
})

// report posted, evidence cited
await run.report()
→ posted  ·  provenance: 47 events recorded

Composes with the platform you already run

KubernetesGrafanaKafkaPulsarOpenTelemetryPagerDuty

The 3 a.m. problem

Vehicle data platforms break in ways no runbook predicted

Millions of telemetry events per hour across Kubernetes, service mesh, message streams, and two clouds. When something breaks, an on-call engineer reconstructs what happened by hand, across every one of those systems. Sentinel changes who does that work, without giving up control of how it's done.

Triage by hand

The pager fires and a human starts hunting, dashboards, logs, traces, deploy history, stream lag, across every system the telemetry touches. The clock runs on their judgment alone.

Evidence reconstructed after the fact

What actually happened gets pieced together later from memory, screenshots, and chat scrollback. The post-incident timeline is only as complete as whoever was awake.

Agents as ungoverned risk

Point a chatbot at your dashboards and it will produce an answer, with no record of which tools it called, which evidence it used, or which it ignored. Nobody can sign off on that.

Investigation starts on trigger

The incident event itself opens the investigation. By the time the responder joins, the agent has gathered metrics, logs, traces, and deployment annotations, and drafted a diagnosis that cites them.

Evidence preserved as it's collected

Every artifact the agent retrieves is captured at the moment of collection and bound to the investigation. The timeline builds itself, forensically complete, while the incident is still live.

Governed, not just capable

The agent operates under default-deny tool policy: approved tools, read-only capabilities, secrets it never sees. Every action, and every refusal, lands in an append-only provenance ledger.

One runtime

Sits between your agents and your platform

Agents reach your observability stack, your clusters, and your data streams only through the Sentinel runtime. It resolves which tools an agent may touch, executes the calls, and records everything, the same governed path whether the platform spans one cloud or several.

Your vehicle data platform
Sentinel runtime govern · investigate · record

Governed tool access

Grafana · metrics, logs, traces
Kubernetes & service mesh
Kafka · Pulsar · Postgres signals
Alerting & incident tooling

Two products, one runtime

Both run on the same governed execution engine

Incident Triage

Agentic triage for vehicle-to-cloud incidents

When the ingestion pipeline starts throwing errors after a deploy, an agent begins the investigation the moment the alert fires. It gathers evidence from metrics, logs, traces, stream health, and deployment annotations, then posts a report where every claim cites the artifact behind it, ready for the on-call engineer to review, confirm, or challenge.

Explore incident triage
Governance & Provenance

Default-deny policy and an append-only record

Before an agent acts, its tools are approved: pinned identity, typed capabilities, controlled secrets, allowlisted egress. While it acts, everything it does, tool calls and outputs, model prompts and responses, evidence retrieved, decisions made, is written to a provenance ledger nothing can silently edit. That record is how you audit an agent, and how you evaluate one.

Explore governance

The lifecycle

An investigation is a record that moves through states

Not a chat session that evaporates when the window closes. An investigation opens on an incident event, accumulates evidence under policy, and closes with a report bound to the full trail of how it was produced.

01 · TRIGGER

It starts like an incident, not a prompt

An alert on the telemetry pipeline, an incident declared in your on-call tooling, or an operator dispatching a scenario by hand, each arrives as an event that opens an investigation. The agent, its tool set, and its policy are resolved from configuration, not improvised in the moment.

See the runtime
event.trigger
POST /v1/investigations
{
  "trigger": "alert/5xx-telemetry-ingest",
  "agent":   "incident-triage",
  "policy":  "observability-readonly"
}
→ state: investigating  ·  ledger open
02 · INVESTIGATE

Evidence is gathered under policy

The agent queries dashboards, pulls logs and traces, checks stream consumer lag, and reads deployment annotations, through governed tools only. Each call is resolved against the approved registry before it executes, and each artifact it returns is preserved and bound to the investigation as evidence.

See incident triage
evidence · INC-4212
03:07 · grafana.query · 5xx by route captured
03:08 · k8s.rollout · deploy 03:02 captured
03:09 · traces · timeout to battery-state captured
03 · REPORT

Every claim cites its evidence

The report the agent posts isn't a plausible-sounding answer, it's a diagnosis where each finding links to the artifact that supports it, and the whole document links back to the transcript and provenance trail. The on-call engineer reviews it with the full record of what the agent did, used, and ignored.

Read the model
report · INC-4212
Diagnosis · aggressive client timeout cites 3
Next step · raise timeout, redeploy proposed
Provenance trail · 47 events linked

Who it's for

Designed around the team running vehicle-to-cloud data

A platform organization ingesting telemetry from electric vehicles at fleet scale, distributed systems, observability-heavy operations, on-call pressure, and auditability requirements that arrive before trust does.

On-call engineers

Join an incident with the evidence already gathered and a cited diagnosis waiting, instead of an empty terminal at 3 a.m.

Platform & SRE leads

Lower time-to-diagnosis and cleaner handoffs between responders, with post-incident timelines that assemble themselves.

Engineering leadership

Adopt agents in production workflows with a governance answer that survives scrutiny: policy before action, provenance after.

New engineers

Ask how the platform works and get answers grounded in documentation plus live system state, services, dependencies, recent incidents.

Architecture-first

Every agent action is a distinct, auditable entry

The runtime enforces what the policy allows and records what the agent did, without ever trusting the agent's own account of itself. Tool calls, outputs, model prompts and responses, evidence, and human interventions land in an append-only ledger, the record that lets an engineer challenge a diagnosis and an auditor reconstruct an investigation months later.

How the runtime works
provenance · append-only
47Events / investigation
0Silent edits
1:1Action → record
trigger → investigating recorded
tool call · grafana.query recorded
report posted · 3 citations recorded

The questions that matter

The bar isn't "can an agent answer?" It's "can we let it operate?"

Can we safely let an agent inside our platform workflows?

That is the question Sentinel is built to answer yes to. The agent collects evidence, uses tools, maintains context across a long-running investigation, and supports engineers, without becoming an ungoverned source of operational risk, because every capability it has was granted explicitly and every action it takes is recorded.

What stops it from touching something it shouldn't?

Default-deny policy. A tool that isn't in the approved registry doesn't exist as far as the agent is concerned, and a call outside its granted capabilities never executes.

How do we know the diagnosis isn't just plausible-sounding?

Every claim in the report cites the evidence artifact behind it, and the artifacts were captured live during the incident, not reconstructed afterward.

How do we evaluate whether the agent actually works?

From the full execution trace: which tools it called, which evidence it used, what it ignored, where a human intervened. You can't benchmark an agent on its answers alone.

What happens when it's wrong?

A human reviews before anything is acted on. The report is a proposal with an evidence trail, and the trail is exactly what lets an engineer challenge it.

Put a governed runtime between your agents and your platform.

Talk to us about running Sentinel against your vehicle data infrastructure, or start building against the API today.