Investigate-only AI agents on AWS Bedrock, Lambda, and SQS. iSimplifyMe-built. iSimplifyMe-operated. About $0.08 per investigation.
What is Sentinel?
Sentinel is iSimplifyMe’s production AI ops layer running on AWS Bedrock, Lambda, SQS, and DynamoDB. Inside iSimplifyMe’s 31-tenant AWS fleet it watches CI across 82 repositories (as of September 2026) and the multi-site content pipeline. Each agent investigates root cause with its own tools (HTTP and DNS probes, a Cloudflare 5xx breakdown, the GitHub workflow API, a content-pipeline lock probe) and files tickets with written diagnoses at roughly $0.08 per investigation — under a $0.30 soft and $1.00 hard cost ceiling. Three workloads have run in production since May 2026, on Claude Sonnet 5 since July 2026: a Diagnostics Agent for tenant-site outages firing every 5 minutes behind per-tenant activation, a GitHub Triage Agent firing every 15 minutes, and a Pipeline Hang Detector firing every 15 minutes. It has run on the AWS Bedrock Converse API since 2026-05-05.
The setup
iSimplifyMe operates 31 active tenants on AWS — client websites, multi-tenant platforms, and internal infrastructure. Each tenant generates the same labor pattern: an alert fires, an engineer stops what they are doing, investigates, and files a ticket with the root cause.
Sentinel is the layer that folds detection, investigation, and ticketing into one AWS-native pattern. Investigate-only. Cost-ceilinged. Generic detector plus runner.
Architecture
Every Sentinel workload follows the same shape: a signal reaches a detector, the detector queues an investigation on SQS, a Bedrock Claude session runs it, and the result lands as a ticket and a Slack notification for an admin to review in the Apex tickets queue. Nothing auto-remediates; every workload is investigate-only by design.
Detectors: one generic detector handler, deployed by SST once per workload, each with its own EventBridge cron and SENTINEL_AGENT_SLUG value. One generic runner: SQS-triggered Lambda dispatching investigation logic via a typed SentinelAgent registry — no per-agent runner code duplication. Atomic locks: DynamoDB attribute_not_exists(pk) conditional writes prevent the same incident from being investigated twice when detectors run in parallel. Shared tool library: file_ticket and notify_slack , plus per-agent tools.
Bedrock inference layer: the runner Lambda calls Bedrock via ConverseStreamCommand on the US-bounded inference profile for Claude Sonnet 5. IAM scope: bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on foundation-model and inference-profile ARNs. Production migrated from Anthropic Managed Agents to Bedrock Converse on 2026-05-05 and to Claude Sonnet 5 on 2026-07-16.
Why this is harder than it looks
Detection without investigation
AIOps platforms detect signals well — uptime drops, deploy failures, performance regressions — but stop at the alerting boundary. The expensive labor happens after the alert fires: a senior engineer reads logs, correlates timestamps across services, runs diagnostic queries, identifies root cause, and files a ticket. Across a multi-tenant production fleet running 24/7, this overhead does not scale. Sentinel puts a detector in front of a Bedrock session: the detector finds the signal, the session investigates it and files the ticket.
Cost ceilings on LLM ops agents
An ops agent without a cost ceiling can consume hundreds of thousands of tokens if tool use goes pathological. Sentinel enforces a $0.30 soft ceiling that warns and a $1.00 hard ceiling that aborts the Bedrock Converse session. Synthetic runs measured $0.065 to $0.0941 per investigation across the three workloads.
Same-incident race conditions
Detectors firing on a cron (every 5 minutes for Diagnostics; every 15 for GitHub Triage and Pipeline Hang) will race — two parallel detectors can find the same incident before either has filed a ticket. Sentinel uses DynamoDB conditional writes with attribute_not_exists(pk) as the atomic lock primitive. The first detector that writes the lock owns the incident; subsequent detector ticks see the lock and skip the duplicate investigation. No distributed locking infrastructure required.
N workloads should not require N runners and N queues
A naïve implementation deploys one detector Lambda and one runner Lambda per workload. At three workloads that is six Lambdas; at the eight-workload roadmap state that is sixteen Lambdas, eight IAM policies, and eight SQS queues. Sentinel uses one generic detector handler, which SST deploys once per workload with its own EventBridge cron and SENTINEL_AGENT_SLUG value, one generic runner Lambda that dispatches by registry lookup, and one SQS queue. At eight workloads that is eight detector functions from one handler, one runner, and one queue. Adding a fourth workload is a new entry in the typed SentinelAgent registry — its detection logic and per-agent tools — and a new EventBridge cron rule. No new runner code, no new queue.
What’s running in production today
| Workload | Cron | Tools | Cost |
|---|---|---|---|
| Diagnostics Agent | rate(5 minutes) | curl_url, dns_lookup, get_cf_5xx_breakdown, file_ticket, notify_slack | $0.0822 / investigation |
| GitHub Triage Agent | rate(15 minutes) | get_workflow_run, get_workflow_run_logs, get_recent_commits, get_workflow_file, file_ticket, notify_slack | $0.065 / investigation |
| Pipeline Hang Detector | rate(15 minutes) | singleton-lock probe, owner-tenant correlation, file_ticket, notify_slack | $0.0941 / investigation |
Three workloads live since May 2026; Diagnostics Agent activation is per tenant. About 14,400 detector cron ticks per month across all three (one every 5 minutes and two every 15). Under $50/month total operating cost at the current three-workload state. Per-investigation costs are from synthetic runs; Claude Sonnet 5 carries the same list rates as the model they were measured on. iSimplifyMe-operated. Not handed off.
Build log
- Phase 0
Audit + cost ceiling design (April 2026)
Audit of existing manual investigation workflows across the multi-tenant AWS fleet. Cost-ceiling design: $0.30 soft and $1.00 hard per investigation, with a session-abort path at the hard ceiling. Initial substrate: Anthropic Managed Agents.
- Phase 1
Diagnostics Agent live in production (April 2026)
Production detector firing every 5 minutes. First workload live on Anthropic Managed Agents; the move to Bedrock came in May. An early canary measured about $0.063 per investigation. A 7-day canary observation window confirmed zero false positives; activation is per tenant from there.
- Phase 1.5
GitHub Triage Agent live (April 2026)
Second workload reusing the same generic detector and runner pattern. Per-workload tool library: GitHub API client (workflow run, logs, recent commits, workflow file). Scoped to a canary repository before broadening to every iSimplifyMe repository via a dynamic exclusion list in DynamoDB — 82 repositories as of September 2026. Synthetic runs put it at about $0.065 per investigation.
- Phase 1.6
Pipeline Hang Detector live (May 2026)
Third workload — detects hung runs in the multi-site content pipeline, such as a singleton lock held past its timeout. New tools: singleton-lock probe and owner-tenant correlation. Atomic lock primitive (DynamoDB conditional write) prevents same-incident race conditions during parallel detector ticks. About $0.0941 per investigation.
- Phase 2
Migrated to AWS Bedrock Converse (May 2026)
Substrate migration from Anthropic Managed Agents to AWS Bedrock via the ConverseStreamCommand API on a US-bounded inference profile. Production deploy succeeded on 2026-05-05. The pre-migration runner remains deployed as a rollback path behind the same per-tenant activation. Synthetic runs after the migration measured $0.0822 for Diagnostics and $0.0941 for Pipeline Hang.
- Phase 2.5
Claude Sonnet 5 (July 2026)
Every Sentinel agent moved from Claude Sonnet 4.6 to Claude Sonnet 5 on 2026-07-16, on the same US-bounded inference profile and at the same list rates, so the per-investigation ceilings carried over unchanged. Extended thinking stays off for every Sentinel call; an investigate-only session does not need it.
- Phase 3+
Roadmap workloads (planned; same detector handler and runner)
Issue/PR Triage Agent · Lighthouse Regression Detector · Cost Anomaly Detector · AEO Drift / Citation Surveillance · DNS Watcher. Eight total workloads planned. Each new workload requires only a new entry in the typed SentinelAgent registry and a new EventBridge cron rule.
Built and operated, not delivered.
Most AI ops engagements end with a slide deck about future AI agents.
iSimplifyMe runs Sentinel inside its own 31-tenant production AWS fleet, today. Three workloads firing on EventBridge crons every 5–15 minutes. Investigate-only. Cost-ceilinged. The same architecture is deployable into a client AWS account on the same SST-wired pattern.
Frequently asked questions
Does Sentinel replace Datadog or PagerDuty?
No. Monitoring platforms detect signals and route alerts to people. Sentinel starts where the alert ends: it investigates root cause with its own tools — HTTP and DNS probes, a Cloudflare 5xx breakdown, the GitHub workflow API — then files a ticket with a written diagnosis. It is deployable into your own AWS account, and every investigation carries a $0.30 soft and $1.00 hard cost ceiling. The work that monitoring platforms hand to senior engineers is what Sentinel does inside one Bedrock session, at about $0.08.
Why investigate-only and not auto-remediation?
Auto-remediation requires the AI to be right every time about a destructive action. Investigate-only requires it to be right most of the time about a non-destructive diagnosis. A Sentinel-pattern agent that misdiagnoses costs you the price of a ticket (some senior-engineer time to read and dismiss it). An auto-remediating agent that misdiagnoses can take down production. Investigate-only is the model that scales with current LLM reliability; auto-remediation is not.
What does the per-investigation cost include?
The Bedrock Converse session for one investigation, measured on synthetic runs: $0.0822 for a Diagnostics run with DNS and HTTP probes and a Cloudflare 5xx breakdown, $0.0941 for a Pipeline Hang investigation that walked a singleton lock and an owner-tenant correlation, $0.065 for a GitHub Triage run that pulled workflow logs and recent commits before classifying the failure. Every investigation has a $0.30 soft ceiling and a $1.00 hard ceiling that aborts the session.
Can Sentinel run inside our AWS account, not iSimplifyMe’s?
Yes — that is the deployment model for a client engagement. The Sentinel-pattern infrastructure (detector Lambdas, runner Lambda, SentinelQueue, DynamoDB locks, EventBridge crons, IAM-scoped Bedrock invocation perimeter) is deployable via SST into a client AWS account. The same generic-detector-plus-runner pattern carries forward; per-workload registry entries adapt to the client’s monitored surface. iSimplifyMe operates it after deployment.
How long does a first Sentinel workload take to deploy?
About three weeks from kickoff to the first workload live in the client’s AWS account, deployed on the same SST pattern Sentinel runs on today. Subsequent workloads reuse the same runner, queue, and detector handler; each one is a new registry entry and a new cron rule.
Deploy a Sentinel-pattern AI ops layer
If you run production workloads on AWS and your senior engineers spend hours per week investigating failed CI runs and site outages, we can talk through what the Sentinel-pattern deployment looks like for your stack.
- Discovery call30 min · Free · No deck — actual mechanics
- First workloadAbout three weeks to live in production
- iSM-operatedBedrock, IAM, alerts — all on us