Expert Risk Bot

An autonomous agent that identifies and manages risks across projects, products, and operations — performing risk assessments, quantifying impact, designing mitigation strategies, and maintaining risk registers with continuous monitoring.

When to Use This Agent

Choose Expert Risk Bot when:

• You need to assess risks for a new project, product launch, or initiative
• You want to quantify risk exposure with probability and impact analysis
• You need to design mitigation strategies and contingency plans
• You want ongoing risk monitoring with early warning indicators

Consider alternatives when:

• You need security-specific vulnerability assessment (use a security auditor agent)
• You need financial risk modeling (use a financial analyst)
• You need compliance-specific risk assessment (use a legal advisor agent)

Quick Start

Copy
# .claude/agents/risk-bot.yml
name: expert-risk-bot
description: Identify, assess, and manage risks
agent_prompt: |
  You are a Risk Management Expert. Help teams manage risk:

  1. Identify risks across categories (technical, operational, market)
  2. Assess probability and impact using quantitative methods
  3. Prioritize risks using risk exposure scoring
  4. Design mitigation strategies (avoid, reduce, transfer, accept)
  5. Create contingency plans for high-impact risks
  6. Establish monitoring triggers and early warning indicators

  Risk principles:
  - Unknown risks are more dangerous than known risks
  - Mitigation costs should be proportional to risk exposure
  - Accept risks deliberately, not by default
  - Monitor risk indicators continuously, not periodically

Core Concepts

Risk Assessment Framework

Category	Examples	Assessment Method
Technical	System failures, performance, security	Failure mode analysis
Operational	Process failures, key person dependency	Process mapping
Market	Competition, demand changes, regulation	Scenario planning
Financial	Budget overrun, revenue shortfall	Monte Carlo simulation
Schedule	Delays, dependency chains	Critical path analysis

Risk Scoring Matrix

Risk Exposure = Probability × Impact × Detectability

Scoring Guide:
  Probability: 1 (rare) → 5 (almost certain)
  Impact:      1 (negligible) → 5 (catastrophic)
  Detectability: 1 (easy to detect) → 5 (undetectable until too late)

Risk Register:
  ID   Risk                    Prob  Impact  Detect  Score  Status
  R01  Database migration      4     5       2       40     MITIGATE
       fails in production
  R02  Key engineer leaves     2     4       3       24     MONITOR
       before launch
  R03  API rate limits hit     3     3       4       36     MITIGATE
       during peak traffic
  R04  Competitor launches     3     2       1       6      ACCEPT
       similar feature

Mitigation Strategy Selection

Strategy Selection Guide:
  Risk Score > 30:  MITIGATE or AVOID
    → Reduce probability or impact with specific actions
    → Example: Run migration on staging first with rollback plan

  Risk Score 15-30: TRANSFER or MONITOR
    → Insurance, contracts, SLAs, or active monitoring
    → Example: Add monitoring alerts for key person workload

  Risk Score < 15:  ACCEPT
    → Document and move on; not worth mitigation cost
    → Example: Competitor feature launch — continue as planned

Configuration

Option	Type	Default	Description
riskCategories	string[]	["technical", "operational", "market"]	Risk categories to assess
scoringMethod	string	"exposure"	Method: exposure, qualitative, monte-carlo
mitigationThreshold	number	30	Score threshold requiring mitigation
monitoringFrequency	string	"weekly"	How often to review risk register
includeContingency	boolean	true	Create contingency plans for high risks
reportFormat	string	"register"	Output: register, heatmap, narrative

Best Practices

1. Identify risks proactively, not reactively — Schedule risk identification sessions at project kickoff and at every major milestone. The cheapest time to address a risk is before it materializes. Use pre-mortem analysis: "Imagine the project has failed. What went wrong?" This mental shift surfaces risks that optimism bias hides.

2. Quantify risks with numbers, not adjectives — "High risk" is subjective and unmeasurable. "70% probability of 2-week delay costing $50K in engineering time" is actionable. Quantified risks enable cost-benefit analysis of mitigation strategies and make it clear which risks deserve investment.

3. Assign an owner to every risk — Unowned risks are unmanaged risks. Every risk in the register should have a named owner responsible for monitoring the risk indicators and executing the mitigation plan if triggered. Without an owner, the risk is documented but not managed.

4. Design mitigation proportional to exposure — Spending $100K to mitigate a risk with $50K exposure is over-engineering. Spending $1K to mitigate a risk with $500K exposure is negligent. Calculate the expected cost of the risk (probability × impact in dollars) and ensure mitigation cost is a reasonable fraction.

5. Use leading indicators, not lagging indicators — "The project is 2 weeks late" is a lagging indicator — the risk has already materialized. "Sprint velocity has dropped 30% over 3 sprints" is a leading indicator — it warns of future delay. Design monitoring triggers around leading indicators to enable proactive response.

Common Issues

Risk register becomes a checkbox exercise nobody reads — The register is updated monthly to satisfy process requirements but does not influence decisions. Make the risk register a living document that is reviewed in weekly standups. Highlight the top 3 risks and their current status. If the register does not change decisions, it is not being used correctly.

Risks are identified but mitigation plans are not executed — The team agrees on mitigation strategies but returns to feature work without implementing them. Treat mitigation tasks as sprint work items with the same priority as features. If a risk scores above the mitigation threshold, its mitigation task should be in the next sprint.

New risks emerge faster than old ones are resolved — The risk register grows indefinitely because resolved risks are not removed and new ones are constantly added. Review and close risks that are no longer relevant (the event window has passed, the condition has changed). A register with 50 active risks is unmanageable — prioritize the top 10 and accept the rest.