Coordinator
The shift lead
Collects every report, removes duplicates, decides who needs to know and sends the message. It is the only agent people ever hear from.
Autonomous production support
Every ticket read. Only the real ones wake you up.
Sentinel is a team of Claude agents that watches your support queue and batch schedules around the clock. It triages each ticket the way a good first-line engineer would, attaches the right runbook, and hands people a short list of what actually needs them.
Humans paged tonight: 1 · Tickets read: 5
The problem
On-call is mostly reading, sorting and waiting.
Most of a support shift goes on work that follows the same pattern every night. People burn out on the noise, and the one ticket that matters can sit in a queue behind fifty that don't.
What happens today
- Every alert pages someone, including the ones that clear themselves.
- Engineers hunt for the runbook after they are already awake.
- Medium and low tickets go quiet for hours without anyone noticing.
- A failed batch job is found when the job after it doesn't start.
What Sentinel changes
- Every ticket is read and ranked within [2] minutes of arriving.
- A page arrives with the matching runbook already attached.
- Quiet tickets are chased on a clock, so nothing is forgotten.
- Late, long-running and failed jobs are flagged with what they hold up.
How it works
The same five steps, for every ticket, every time.
Receive
Each new ticket is picked up and reported to the coordinator. No exceptions and no sampling.
Rank
Urgency comes from the ticket's own priority. Sentinel can raise it, never lower it.
Find the runbook
It checks the ticket, the knowledge base and known problems for a fix that already exists.
Check it's real
High-priority alerts that are duplicates or have already recovered are held back with a reason.
Tell the right person
Genuine urgent tickets go to on-call with the runbook. Everything held back shows up in the hourly report.
| Priority | What Sentinel does | When a person hears about it |
|---|---|---|
| P1 · P2 | Full triage, runbook lookup and false-positive check | Immediately, if genuine |
| P3 | Triage and runbook lookup, never filtered out | After 1 hour with no human action |
| P4 · P5 | Triage and runbook lookup, never filtered out | After 4 hours idle |
Architecture
How the pieces fit together.
Sentinel sits between the systems you already run and the people who support them. It reads from one side and reports to the other.
Your systems
Ticket queueincidents, problems, changes
Batch schedulersjob status and history
Monitoringapp and API health
Knowledge baserunbooks and known errors
read-only
Project Sentinel
Ticket triage
Batch monitor
Outage check
Change planning
▼ reports
Coordinatordedupes, ranks, decides who to tell
Claude for judgment calls · fixed rules for priority and timers · full audit log
alerts and reports
approvals
Your team
On-call pagewith the runbook attached
Hourly reportalerts held back, and why
End-of-batch reportsucceeded, failed, total time
Approval requestspeople decide every change
Everything runs inside your own network. Agents only read, and anything that changes production goes to a person first.
The team
Five agents, one voice.
Each agent watches one part of production. None of them talk to people directly. Everything goes through the coordinator, so your team hears from Sentinel once and in one format.
Ticket triage
The first-line engineer
Reads each incident, ranks it, finds the runbook and checks whether a high-priority alert is real before anyone is paged.
Batch monitor
The scheduler watcher
Compares each job with its own history. Flags long runs, failures and jobs that didn't start on time, plus the jobs stuck behind them.
Outage check
The first responder
When an outage is reported, it runs a health check across key applications and APIs and tells on-call straight away if anything is affected.
Change planning
The change advisor
Suggests quieter windows for planned changes and lists the monitors to pause first. It recommends; a person approves.
What your team receives
Fewer messages, each one complete.
Page · on-callP1 · genuine
Payments API returning errors for 6 minutes. Three related alerts merged into this one.
- Runbook
- Restart payment worker pool
- Seen before
- [2] times this quarter
- Impact
- Checkout failing for some users
Hourly report · 02:00held back: 4
4 high-priority alerts were not paged.
- 2 ×
- Duplicate of an open incident
- 1 ×
- Recovered on its own in 40 s
- 1 ×
- Test alert from a non-production host
End of batch · 05:30on time
Overnight batch finished.
- Succeeded
- [1,182]
- Failed
- [3], successors listed
- Total time
- [4 h 12 m]
Guardrails
Built to be trusted on day one.
Sentinel starts as a reader and an advisor. It earns any wider role one step at a time, with people deciding when.
R/ORead-only access
Agents read tickets, schedules and monitoring. They do not change production systems.
HITLPeople approve changes
Closing, reassigning, rescheduling and muting stay with your engineers.
LOGEvery decision explained
Each alert held back is listed with its reason, so the team can check Sentinel's judgment every hour.
OFFOne-step kill switch
A single switch stops every agent and hands the queue back to the existing rota.
Expected impact
What a pilot is designed to measure.
[60%]
fewer pages sent to on-call
[2 min]
from ticket to triage
100%
of tickets read and logged
[45 min]
saved per urgent incident
Figures in brackets are targets, to be replaced with measured results from the pilot.
See Sentinel on your own queue.
We are running early pilots with production support teams. Tell us how your shifts work today and we'll show you what Sentinel would have done last night.
Email us
hello@sentinelprojectai.com