Skip to content

Autonomy Levels

RaiSE doesn't start autonomous. It starts manual, builds trust through transparency, and earns autonomy through demonstrated reliability. This is deliberate — it mirrors how humans learn and how teams build trust.

Legacy runbook commands such as /rai-story-run, /rai-bugfix-run, and /rai-epic-run are deprecated. The Level 2 discussion below refers to the guided orchestration pattern, not to those commands as a recommended public interface.

The Problem with "Just Automate It"

Most AI-assisted development tools start with full automation and add guardrails after things break. This is backwards. An AI that runs autonomously without the human understanding why each step matters produces:

  • Fragile automation — it works until it doesn't, and nobody knows how to fix it
  • Cargo cult compliance — gates pass but nobody understands what they validate
  • Trust deficit — the team doesn't trust the output because they never saw the process

RaiSE inverts this. You start by doing every step yourself, with the AI as partner. You see every decision, every gate, every artifact. Only after you understand the process — and the AI has demonstrated reliability — do you progressively hand over control.

Three Levels of Autonomy

Level 1: Skills (Manual)         → Human drives, AI assists
Level 2: Runbooks (Guided)       → AI drives, human approves
Level 3: Pipeline Engine (Auto)  → Engine drives, human reviews

These aren't modes you "configure" — they're stages you grow through. A new developer starts at Level 1. A team that's shipped 20 stories together graduates to Level 3. The system remembers your journey.

Level 1: Individual Skills (Shu — Follow the Form)

At Level 1, you invoke each skill manually:

/rai-story-start RAISE-123
  ↓ (you review the scope, decide what's next)
/rai-story-design RAISE-123
  ↓ (you review the design, adjust approach)
/rai-story-plan RAISE-123
  ↓ (you review tasks, reorder if needed)
/rai-story-implement RAISE-123
  ↓ (you review code after each task)
/rai-story-review RAISE-123
  ↓ (you extract learnings, reinforce patterns)
/rai-story-close RAISE-123

What you gain:

  • Deep understanding — you see every artifact, every gate, every decision
  • Process muscle memory — the sequence becomes instinctive
  • Trust calibration — you learn where the AI excels and where it needs correction
  • Pattern library — each review builds a corpus of team patterns

When to use: First 5-10 stories with a new codebase or a new team member. Always for high-risk or novel work.

What the AI does at this level:

  • Follows the SKILL.md steps exactly
  • Queries the knowledge graph for context (via MCP tools)
  • Presents verification gates and waits for approval
  • Produces artifacts at each step
  • Transitions backlog items (via MCP tools)

Level 2: Runbooks (Ha — Break the Form)

Once you understand the process, you don't need to invoke each skill separately. Runbooks (/rai-story-run, /rai-bugfix-run, /rai-epic-run) chain the skills together automatically, pausing at fixed HITL (Human-in-the-Loop) gates.

/rai-story-run RAISE-123

  start → design → [GATE: scope approval] → plan → implement
    → [GATE: code review] → review → close

What changes:

  • AI sequences the skills automatically — you don't manage the flow
  • Fixed HITL gates pause for your judgment at critical decisions
  • Phase detection auto-resumes from the last completed artifact
  • Context flows between phases — decisions from design inform implementation

What stays the same:

  • Every artifact is still produced
  • Every gate still requires human approval
  • You can reject at any gate and the pipeline stops

When to use: After 5-10 stories at Level 1. The team knows the process, trusts the output, and wants to move faster without skipping rigor.

The three runbook gates:

Gate After What you decide
Scope start + triage/design Is this the right problem with the right approach?
Code implementation Does the fix look correct? Tests pass?
Review retrospective Are the learnings captured? Patterns reinforced?

These gates exist because they catch the highest-value errors — wrong problem definition, incorrect implementation, and missed learning opportunities.

Level 3: Pipeline Engine (Ri — Transcend the Form)

The pipeline engine goes further. When you run /rai-story-run, the runbook skill uses MCP tools (pipeline_start, pipeline_advance) to orchestrate a YAML-defined pipeline that:

  • Sequences phases from a declarative pipeline definition
  • Injects knowledge graph context at each phase (patterns, modules, decisions)
  • Evaluates quality gates automatically (tests, types, lint)
  • Pauses at HITL gates based on your delegation level
  • Persists state — survives session restarts, context compaction
# story.yaml — 8-phase pipeline
phases:
  - id: start
    skill: rai-story-start
  - id: design
    skill: rai-story-design
    gate:
      type: hitl
      prompt: "Approve design?"
  - id: plan
    skill: rai-story-plan
  - id: implement
    skill: rai-story-implement
    gate:
      type: hitl
      prompt: "Approve implementation?"
  # ...

What changes from Level 2:

  • Pipeline definition is data (YAML), not code — customizable per project
  • MCP tools provide structured context at each phase (not stdout parsing)
  • State persists across sessions — pause today, resume tomorrow
  • Delegation levels control how much the engine does autonomously

When to use: After the team has completed an epic at Level 2 and wants to standardize their process. The pipeline encodes the team's proven workflow.

How Trust Grows

The progression isn't arbitrary. Each level builds trust through specific mechanisms:

Level 1 (Skills)
  ├── Human sees every step → builds understanding
  ├── Human corrects mistakes → builds accuracy
  └── Patterns captured → builds memory
       ↓
Level 2 (Runbooks)
  ├── Fixed gates catch errors → validates trust
  ├── Phase detection recovers → proves reliability
  └── Context flows between phases → demonstrates coherence
       ↓
Level 3 (Pipeline)
  ├── YAML is auditable → governance satisfied
  ├── MCP tools provide data → reduces latency
  └── Delegation levels tune autonomy → human stays in control

Key insight: trust is not binary. A developer might use Level 3 for routine stories but drop to Level 1 for a complex refactoring. The levels coexist — they're tools in a toolkit, not a one-way upgrade.

ShuHaRi: The Learning Philosophy

RaiSE's autonomy levels map directly to ShuHaRi, the Japanese martial arts concept of mastery:

Stage Meaning RaiSE Level Behavior
Shu (守) Protect/obey Level 1: Skills Follow every step exactly. No shortcuts. Build muscle memory.
Ha (破) Break/detach Level 2: Runbooks Understand why each step exists. Skip what's irrelevant, deepen what matters.
Ri (離) Transcend Level 3: Pipeline Create your own workflows. Customize pipelines. Trust the system.

Every skill in RaiSE declares its mastery levels. At Shu, the AI explains everything. At Ha, it explains only what's new. At Ri, it gives you the result and moves on.

Your developer profile tracks your level, and skills adapt their verbosity accordingly. A senior developer who's shipped 50 stories doesn't need the same explanation as someone on day one.

The Developer Journey

A concrete example of how a developer (let's call them Alex) progresses:

Week 1-2: Shu (Skills) Alex joins the team. They run /rai-story-start, /rai-story-design, etc. manually. Each skill explains what it does and why. Alex learns the codebase conventions, the testing patterns, the gate requirements. The AI queries the knowledge graph and presents relevant patterns.

Week 3-4: Ha (Runbooks) Alex is comfortable with the process. They switch to /rai-story-run RAISE-456. The AI chains the skills, but Alex still approves at every gate. Alex starts adjusting — spending more time on design gates, less on implementation gates (because TDD catches most issues).

Month 2+: Ri (Pipeline) Alex's team customizes their pipeline YAML. They add a security review phase, remove the scope gate (they trust their PM's tickets), and set delegation to auto for test-only stories. The pipeline runs, HITL gates fire only when something unexpected happens.

Key: Alex didn't skip any stage. The understanding from Shu makes Ha productive. The experience from Ha makes Ri safe.

MCP Tools: The Connective Tissue

At every level, skills consume MCP tools for structured operations:

Operation MCP Tool What it does
Query patterns raise_graph_query Search knowledge graph for relevant patterns
Load context raise_session_context Load governance, coaching, deadlines
Check gates raise_gate_check Run quality gates (tests, types, lint)
Track work raise_backlog_transition Move Jira issues between states
Persist learning raise_pattern_add Save new patterns from retrospectives
Score patterns raise_pattern_reinforce Vote on pattern effectiveness (+1/0/-1)

At Level 1, you see these tool calls happen (the AI shows its work). At Level 3, they happen transparently inside the pipeline. Same tools, same data, different visibility.

When MCP tools aren't available (no server running), every skill falls back to CLI commands. Nothing breaks — it's just slower and less structured.

Getting Started

If you're new to RaiSE:

  1. Start with a story — run /rai-story-start on a real ticket and follow the process
  2. Do 3-5 stories manually — build understanding of each phase
  3. Try a runbook — run /rai-story-run on a routine story
  4. Customize your pipeline — edit .raise/pipelines/story.yaml for your team's workflow

The system meets you where you are. Start simple, earn complexity.