The runtime
Not a chat session. Both products, incident triage and governed tool access, run on the same core runtime: an investigation opens on an incident event, accumulates evidence under default-deny policy, and closes with a report that either satisfies review or escalates to a human, every step on the ledger.
every action → an entry on the provenance ledger
Architecture-first, cloud-agnostic
An investigation starts the way a real incident does, an alert, a declared incident, an operator-dispatched event, so the workflow matches operations, not a demo of a chat window.
Capabilities are enumerable and granted explicitly, tools, queries, namespaces, egress. What wasn't granted doesn't execute, and the denial is recorded.
Tool servers are treated as a governed platform interface, not a generic subprocess call: approved identity, typed projection, runtime resolution, drift control.
Node messages, tool calls and outputs, model prompts and responses, and configuration overlays are written to a ledger that only grows. History can be read; it can't be revised.
Real investigations run for hours across distributed systems and unknown unknowns. The runtime holds context, survives restarts, and keeps the trail continuous across responder handoffs.
A report is a proposal, not an action. Engineers review, confirm, or challenge, and the review itself joins the record, so accountability never silently shifts to the machine.
The model
An investigation is created in the investigating state. The agent, tool set, and policy are resolved from the trigger's configuration, not baked into the call site, the same trigger can run a tighter policy in production than in staging.
const run = await sentinel.investigations.open({ trigger: "alert/5xx-telemetry-ingest", agent: "incident-triage", policy: policyFor(env), // per-environment tools: ["grafana", "kubernetes", "kafka"] }) // run.state === "investigating"
The agent never holds credentials or raw endpoints. It requests a tool; the runtime resolves the request against the approved registry and active policy, executes it, and writes both the call and its output to the ledger.
// in policy: executed and recorded await run.tools.grafana.query({ panel: "ingest-5xx", window: "15m" }) → ledger: call + output · artifact ev-07 // not granted: fails closed, recorded await run.tools.k8s.deletePod("ingest-7f2") → denied by policy · entry written
The posted report cites its evidence and links to the full transcript and provenance trail. An engineer confirms or challenges it; either way the decision is recorded, and the investigation reaches exactly one final state.
Why it matters
The question a platform team actually has to answer isn't whether an agent can answer questions about an outage. It's whether they can safely let an agent operate inside production workflows, collect evidence, use tools, maintain context, and support engineers, without becoming an ungoverned source of operational risk. Sentinel exists to make the answer yes, and to make the proof of that answer a property of the runtime itself.
Cloud-agnostic, architecture-first, and modeled around the way vehicle data platforms actually run. Start building against the Sentinel runtime.