A shared review surface
Approval happens where the team can see it, not in one engineer's terminal.
Caskade moves the review upstream: review intent before execution. Scope, blast radius, validation, and stop conditions get approved at plan time — before the repo is touched.
For teams already running coding agents on real repos and feeling approval fatigue set in.
outcome: add rate limiting to /api/export
blast_radius:
allow: src/app/api/export/** · src/lib/rate-limit.ts
deny: src/lib/auth/** · migrations/**
validation: bun run test · bun run build
stop_on: scope_drift · failing_checks · denied_path_write
▸ agent executing inside boundary
✎ writesrc/lib/rate-limit.tsok
✎ writesrc/lib/auth/session.tsBlocked
⤷ outside blast_radius — returned to review
✓ handoff:reviewed change + evidence packet
of permission prompts get approved by Claude Code users — Anthropic's own number.
Anthropic engineering ↗In Anthropic's own eval, its dangerous-action classifier missed 17% of genuinely overeager actions.
Published auto-mode evaluation ↗“The user becomes a rubber stamp.” Approval that happens mid-run decays into reflex.
Provider guardrails ask one question, mid-run: allow this command? They can't ask whether this is the change your team agreed to make. That question only makes sense before the run, against the whole plan — transcripts and diffs answer it even later.
An independent stress test of the permission gate found its main failure mode: it hunts for approval-shaped evidence in the conversation without checking whether that approval covers the actual blast radius of the action.
Independent stress test · arXiv:2604.04978 ↗
Runtime guardrails are the last line of defense. Keep them. They were never designed to be the first.
Plan mode was the right instinct: look before the agent leaps. But generated plans run long, repeat themselves, and live in one engineer's terminal. A plan that gets skimmed puts you back to trusting the model by default.
A reviewable plan is short, structured, and binding: an outcome, a verification surface, constraints, a blast radius, an iteration policy, and stop conditions. Something a second engineer can edit and approve — not scroll past.
"The new plan mode is too verbose… one conversation already used 42% of my 5-hour quota."
The plan becomes a Goal Contract — outcome, verification surface, constraints, blast radius, iteration policy, stop conditions — reviewed by your team before the repo is touched.
The work starts as an explicit outcome, verification surface, constraints, blast radius, iteration policy, and stop conditions.
Humans review and edit the contract before execution proceeds.
The agent run stays inside the approved blast radius.
Meaningful scope changes escalate back to review — they don't become another mid-run prompt to click through.
The outcome is a reviewed change with evidence, not transcript archaeology.
Governance isn't only about blocking bad runs. A reviewed contract is a shared artifact: the team sees what was approved, why drift came back, and what evidence shipped — and the review habits worth standardizing emerge from that record.
Approval happens where the team can see it, not in one engineer's terminal.
When a run escalates, the whole team sees what changed and who re-approved.
Handoffs carry the contract and its verification, not a transcript to excavate.
Reviewed intent teaches the next contract. Hidden transcripts don't.
Caskade is for founder-engineers, small AI-native engineering teams, and technical leads already using Claude Code, Cursor, OpenCode, Codex-style tools, or similar workflows in live repos.
These teams do not need another pitch for agent upside. They need a cleaner way to decide what agents are allowed to do, when drift needs review, and whether the finished work matches the original intent.
It is also for the platform, security, and DevOps leads being asked how agent changes are governed — who today have nothing upstream of a permission prompt to point at.
It is not another IDE agent, generic copilot, or CI replacement. It doesn't compete with your provider's runtime guardrails either — it's the review that happens before they ever fire.
It competes with the messy gap between an agent saying "done" and a change you can trust.
We are opening Caskade to a small first wave of beta testers already using coding agents on live repos.
You leave your email and share the kind of coding-agent workflow you want reviewed.
We review fit for the current invite-only private beta wave.
If it is a fit, we send a private app link and work with you on a tighter intent-review loop.
Caskade is that upstream review layer. The app is invite-only for now; leave your email if you want to be considered for the first beta wave.