Skip to main content
This is the active launch plan. It replaces the older scattered priority matrices, immediate action lists, fix summaries, and phase reports now kept in docs/archive/.

​
Launch Objective

Ship a credible beta for teams that need runtime control of AI agents:
  • instrument Python agents quickly;
  • enforce budgets, policies, guardrails, approvals, and kill switches;
  • sync telemetry to the platform;
  • operate from the console;
  • prove what happened through the ledger, exports, replay, and compliance metadata.

​
Positioning

Agent Sentinel is runtime authority for AI agents. Keep product language focused on shipped capabilities:
  • Use: runtime policy enforcement, intervention tracking, approvals, replay, ledger, cost controls, kill switch, and compliance/audit workflows.
  • Avoid: unqualified certification claims such as “SOC 2 certified” unless certification exists.
  • Clarify: cost tracking is based on SDK/integration estimates unless actual provider reconciliation has shipped.
  • Label: roadmap items as roadmap, not current product.

​
Launch Pillars

​
1. SDK Adoption

The SDK launch path is strongest when a developer can install, instrument, and see value in minutes. Required launch state:
  • clear installation and quickstart docs;
  • @guarded_action examples for sync and async functions;
  • policy, guardrail, approval, replay, and integration examples;
  • local ledger docs that explain exactly what is recorded;
  • remote sync docs with API key setup and shutdown/flush behavior.
Canonical docs:
  • /quickstart
  • /sdk/python/installation
  • /sdk/python/instrumentation
  • /sdk/python/policies
  • /sdk/python/guardrails
  • /sdk/python/replay
  • /sdk/python/framework-integrations
  • /sdk/python/llm-integrations

​
2. Platform Reliability

The platform must make SDK telemetry useful and trustworthy. Required launch state:
  • authenticated ingest with API keys;
  • tenant-scoped runs/actions/ledger APIs;
  • policy sync;
  • approval APIs and decision history;
  • intervention and replay APIs;
  • WebSocket updates for console workflows;
  • deployment and migration notes for the chosen production path.
Canonical docs:
  • /platform/overview
  • /platform/ingest
  • /platform/auth
  • /platform/runs
  • /platform/policies
  • /platform/approvals
  • /platform/interventions
  • /platform/replay
  • /platform/websockets
  • /platform/self-hosting

​
3. Console Operations

The console should support the operator workflows that make runtime control credible. Required launch state:
  • quickstart/onboarding path;
  • runs explorer;
  • intervention review;
  • approval inbox;
  • policy management;
  • kill switch;
  • replay hub and determinism analysis;
  • agent overview;
  • ledger export and audit workflows;
  • analytics sufficient to show cost and operational signals.
Canonical docs:
  • /console/overview
  • /console/quickstart
  • /console/runs
  • /console/interventions
  • /console/approvals
  • /console/kill-switch
  • /console/replay
  • /console/ledger
  • /console/agents
  • /console/analytics
  • /console/settings

​
Critical Launch Work

Track active delivery here instead of creating new root-level plan docs. Every row has a named owner and an evidence link. A claim with no evidence link is not a claim we make publicly.

​
Launch Readiness Checklist

Last run 2026-07-27 against local infrastructure: Postgres 18.1 + Redis in Docker, migrations applied, API on :8848, SDK installed into a clean venv from a local build. 8 pass, 1 partial, 1 was failing and is now closed.

​
Known gaps, owned

Resolved 2026-07-27: email templates now built; gym budget test fixed; root uv run pytest collision fixed; platform coverage gate set to a real ratchet. The platform and gym CI jobs are blocking as a result.
  • Console lint backlog — 115 errors — resolved 2026-07-27 (PR #18). 115 errors and 74 warnings are now zero, with no eslint-disable suppressions: the four set-state-in-effect sites were fixed by moving design/theme/quick-start from a localStorage mount effect to server-resolved cookies. The console lint job is blocking, and a tsc --noEmit gate was added alongside it — typing useApi’s wrapper (previously as any) surfaced 20 real mismatches, including compliance signing metadata the console could never render and a crash on a missing intervention_type.
  • Marketing site collects no analytics. agentsentinel.dev throws three console errors, all telemetry: /_vercel/insights/script.js 404 (Vercel Web Analytics referenced but not enabled for the project), events.agentsentinel.dev/.../sw_iframe.html 503, and the GA4 collect call blocked by CORS — no Access-Control-Allow-Origin on events.agentsentinel.dev. Found 2026-07-27 while browser-testing the production deploy; predates PR #18, which did not touch apps/web. Net effect is zero analytics on the public site, so any traffic claim is currently unevidenced. Owner: @jimmystacks.
  • Railway environment is named staging but serves production. The GitHub deployment environment for the platform is agent-sentinel / staging, and it is what backs api.agentsentinel.dev. Nothing is broken, but the label will eventually cause someone to deploy believing production is untouched. Rename when convenient. Owner: @jimmystacks.
  • Platform coverage is 58%. --cov-fail-under is set to 55 — a ratchet at the measured baseline, not an aspiration. The previous 80 was never met, so the gate never ran green and was effectively off. Raise the number as coverage improves. Owner: @jimmystacks.
  • Console onboarding (checklist item 3) — offline auth bypass — resolved 2026-07-27 (PR #18). The five NEXT_PUBLIC_OFFLINE_* / CLERK_DISABLED vars really were referenced zero times in the console, but the platform half had existed all along in app/core/clerk_dev.py. The console half is now implemented: lib/offline-auth.ts gates it (explicit flag and a non-production deploy; a flag reaching production is ignored and reported), components/auth.tsx is the single decision point, and scripts/mint_dev_token.py regenerates the token — the hardcoded one had expired on 2026-07-06 with no email claim, which is why the path silently did nothing. It is a token swap, not a bypass: no token 401, dev token 200, tampered token 401. get_current_user_ws gained the same dev-token branch, without which offline WebSocket handshakes 403’d and real-time updates never arrived. Verified 2026-07-27 in production, signed in: all 15 routes 200 with zero console errors and zero hydration warnings, real data loading (71 runs, 100 ledger rows, 25 agents), tab deep-links, ?run= legacy aliases, and sidebar navigation. Protected routes still refuse an unauthenticated visitor.
  • First-run log noise — resolved 2026-07-27. mcp.py logged httpx not installed via logging.warning on the root logger at import, so a bare pip install printed WARNING:root: before the user did anything; now a module-logger debug, matching approval.py. The fail-open warning is kept — for a safety product, “nothing is being enforced” warrants one, and it fires once per process — but the quickstart now explains it instead of being surprised by it.

​
Rule

A row in the table above may not move to a “Verified” status without an evidence link naming what was run and what was observed. Re-run this checklist before each release.

​
Historical Sources

The launch plan condenses these archived inputs:
  • docs/archive/legacy-plans/EXECUTIVE_SUMMARY.md
  • docs/archive/legacy-plans/CODEBASE_REVIEW_AND_ROADMAP.md
  • docs/archive/legacy-plans/IMPLEMENTATION_PRIORITY_MATRIX.md
  • docs/archive/legacy-plans/IMMEDIATE_ACTIONS.md
  • docs/archive/legacy-plans/HONEST_CLAIMS_AUDIT.md
  • docs/archive/legacy-plans/PHASE_7_SUMMARY.md