← Back to Use Cases
Legal · Engineering

Review Before Sensitive Change

Some work cannot jump straight from instruction to execution. This workflow analyzes impact, builds a reviewed plan, and keeps the approval context visible before any sensitive change happens.

Electron App · Deep Research

Review The Change As A Governed Research Problem First

Use Deep Research to understand blast radius, define approval points, and keep the reasoning attached before any sensitive change moves forward.

Research Question
Analyze the change before execution, determine where approval is mandatory, and preserve the rationale so later runs understand why the work is gated.
Kendr Electron app Deep Research workspace for sensitive-change review
Output package
Risk assessment, gated plan, checkpoint definitions
The work should slow down in the right places, not everywhere.
Decision motion
Review risky changes before anything acts
This workflow exists to keep speed without losing control.
Reusable memory
Approval context for related work
Later runs should know why the work was gated.
Focus
Blast radius, approvals, rollback, verification
The run should make risk visible before action starts.
Source families
Change request, repo docs, policies
Use the request, the system context, and the governing rules together.
Output package
Risk review, gated plan, checkpoint list
Keep the result reviewable by humans before any change lands.
Knowledge retention
Approval context + related work
The reasoning should stay attached to future runs.

Primary workflow

Governed Agentic Work

Analyze risky changes before the system acts on them.

Secondary value

Approval Trail

Keep the rationale, risks, and checkpoints attached to the work.

Why Kendr

Control without losing speed

This is where approval-aware orchestration becomes the product, not just a backend detail.

Use with a real sensitive workflow

Run these prompts on an actual system or document change that requires oversight. Later, replace the placeholders with the resulting risk review, gated plan, and approval logic.

What The Team Needs

Teams need to understand blast radius, approval points, fallback paths, and what evidence justifies moving forward before any consequential action is taken.

What Kendr Should Produce

A risk review, a gated execution plan, a list of explicit approvals, and a saved context package that explains why the work was allowed to proceed.

Prompt Samples

Run These In Kendr

Prompt 01 · Risk Review
Review this requested change before any execution happens.

I need:
- impacted systems, files, or stakeholders
- likely risks and failure modes
- rollback or recovery considerations
- where human approval should be mandatory
- what evidence is still missing before safe execution

Do not execute anything. Focus on review.
Prompt 02 · Gated Plan
Turn the requested change into a gated execution plan.

Break it into:
- preconditions
- read-only review steps
- approval checkpoints
- execution steps that should stay serialized
- post-change verification and rollback actions

Make the approval boundaries explicit.
Prompt 03 · Approval Context
Save the review context for this sensitive change.

Summarize:
- what was requested
- why it is sensitive
- what approvals are required
- what future Kendr runs should remember before attempting related work
Example Deliverables

What The Team Gets Back

Risk assessment

Add the change-risk review from Prompt 01.

Approval-aware plan

Insert the gated plan from Prompt 02.

Mandatory checkpoints

List the exact points where the run pauses for human review.

Saved approval context

Show what Prompt 03 preserves for later runs.

Join Early Access