Two Agents. Independent Review.

• 0 Sprint tasks completed
• 0 Pipeline stage gates passed
• 0 Matching test scenarios verified
• 0 Self-approved cards

/ pulse-brownfield-feature-demo

Loading board snapshot…

Read-only snapshot — no credentials, no live connection back to the original board.

Implementation and validation run task by task, not stage by stage — a submission that comes back with changes requested doesn’t move forward until it’s genuinely cleared.

1. STEP01

   Ground it in what already exists

   The team records what the codebase already does as a Pulse Decision, so both agents start from the same ground truth.

   Decision recorded before the Sprint opens
2. STEP02

   Foundation task clears first

   The sprint’s first task has no dependencies — everything else waits for it to clear review.

   okto_pulse_get_task_context
3. STEP03

   Independent tasks run in parallel

   Once the foundation task clears, two independent tasks open and move through started → in_progress → validation.

   okto_pulse_move_card (gate: builder != validator)
4. STEP04

   Independent review checks

   The Validator checks confidence, completeness, and drift from spec — short on any one, and it goes back with a specific reason.

   okto_pulse_submit_task_validation
5. STEP05

   Verify test execution evidence

   Three test tasks must actually run their scenario — a result marked passed isn’t accepted without evidence.

   okto_pulse_submit_task_validation
6. STEP06

   Close-out sprint & spec

   Once all 6 tasks are approved, the Validator closes the sprint — the spec is marked complete only after that.

   okto_pulse_submit_sprint_evaluation

Builder

Executor

• Implements each task end to end against the real codebase
• Submits a completeness estimate and any deviation from spec
• Moves cards: started → in_progress → validation
• Cannot submit task validation or self-approve cards

Validator

Reviewer

• Never implements or modifies code
• Reviews every submission independently for confidence, completeness, and drift
• Submits validated test evidence to the board
• Moves cards: validation → done

Builder runs on the Executor preset, Validator on the Validator preset — both enforced structurally on the board, not by instruction either agent could ignore.

{
  "mcpServers": {
    // Builder's identity — can implement and move cards,
    // cannot submit a validation or move a card to done.
    "okto-pulse-executor": {
      "url": "http://localhost:8101/mcp",
      "headers": { "Authorization": "Bearer <executor-token>" }
    },
    // Validator's identity — a separate MCP connection,
    // separate credentials, not the same agent switching roles.
    "okto-pulse-validator": {
      "url": "http://localhost:8101/mcp",
      "headers": { "Authorization": "Bearer <validator-token>" }
    }
  }
}

Both agents work through the same MCP surface — Pulse exposes 312 core MCP tools over okto-pulse serve. A sample of what this workflow actually calls: