Process Reward Model (PRM) and Escalation

Relevant source files

The following files were used as context for generating this wiki page:

• src/agents/architect.ts
• src/agents/critic.ts
• src/hooks/system-enhancer.ts
• src/agents/reviewer.ts
• src/agents/coder.ts

The Process Reward Model (PRM) in the OpenCode Swarm is implemented as a distributed quality-control mechanism that evaluates intermediate steps of the development lifecycle rather than just the final output. It utilizes a combination of automated tool gates and specialized agent reviews (Critic, Reviewer, and Test Engineer) to provide continuous feedback loops. When these feedback loops detect an impasse or repeated failure, the Escalation Discipline takes effect, transitioning from autonomous self-correction to structured expert consultation and, ultimately, human intervention.

This system ensures that the Swarm maintains high standards for technical accuracy, security, and architectural integrity while preventing logic loops or autonomous "hallucinations" from persisting in the codebase. Sources: src/agents/architect.ts:64-165, src/agents/critic.ts:130-150

The Escalation Discipline

The Swarm follows a mandatory three-tier escalation protocol designed to resolve ambiguity and technical blockers with minimal human interruption. The Architect must exhaust lower tiers before proceeding to the next level.

Escalation Tiers

Tier	Name	Description
Tier 1	Self-Resolve	The Architect attempts to resolve the issue using internal context (.swarm/context.md, .swarm/plan.md, .swarm/spec.md) and tries at least two distinct approaches.
Tier 2	Critic Consultation	If Tier 1 fails, the Architect invokes the critic_sounding_board. The Critic provides senior-level pushback or resolves the query directly.
Tier 3	User Escalation	Only permitted after a Tier 2 consultation returns an APPROVED verdict for escalation. Includes a full history of attempts and the Critic's reasoning.

Sources: src/agents/architect.ts:316-324, src/agents/critic.ts:400-420

Escalation Flow Logic

The following diagram illustrates the decision path taken when the Architect encounters a roadblock or logic loop.

Sounding Board Protocol

The critic_sounding_board acts as a pre-escalation filter. It prevents the Architect from bothering the user with technical questions that can be solved through better reasoning or existing project documentation. Sources: src/agents/critic.ts:360-385

Verdict Types

The Critic evaluates the Architect's reasoning and provides one of four specific verdicts:

1. UNNECESSARY: The Architect already has enough context in the plan or spec to answer the question.
2. REPHRASE: The question is valid but poorly formed or lacks specific context.
3. RESOLVE: The Critic can answer the question directly from its own knowledge of the codebase and technical principles.
4. APPROVED: The question is genuinely a product/business decision that requires human input.

Sources: src/agents/critic.ts:31-36, src/agents/critic.ts:413-424

Process Feedback and Reward Gates

The "Reward" in the PRM is the advancement to the next task, which is only granted upon successful passage through tiered QA gates.

Tiered QA Pipeline

Changes are classified into tiers (Tier 0 to Tier 3) based on their impact. Each tier defines a mandatory sequence of rewards (passes).

• Stage A (Automated Tools): Includes syntax_check, secretscan, lint, and build_check. These must return gates_passed: true before any agent review begins.
• Stage B (Agent Review): Mandatory parallel review by the reviewer and test_engineer. The reviewer provides a VERDICT (APPROVED/REJECTED) and a RISK assessment.

Sources: src/agents/architect.ts:371-400, src/agents/reviewer.ts:250-270

Retry Circuit Breaker

If a coder task is rejected three times, a circuit breaker triggers:

1. The Architect invokes the critic_sounding_board with the full rejection history.
2. The approach is reassessed, usually favoring simplification over more complex logic.
3. The task spec is either rewritten or delegated to a Subject Matter Expert (SME).

Sources: src/agents/architect.ts:326-332

Retrospective and Learning

The PRM system captures "lessons learned" through the write_retro tool at the end of every phase. These retrospectives are injected back into the Architect's context for future phases to prevent repeating previous mistakes.

Retrospective Metrics

The Architect tracks the following metrics for the PRM:

• Total tool calls and coder revisions.
• Reviewer rejections and test failures.
• Security findings and integration issues.
• Lessons Learned: A maximum of 5 actionable points per phase.

Sources: src/agents/architect.ts:468-472, src/hooks/system-enhancer.ts:180-195

Summary

The Process Reward Model (PRM) and Escalation system provide a robust framework for autonomous development. By enforcing a tiered QA pipeline, the Swarm ensures that every code change is validated by both tools and specialized agents. The Escalation Discipline acts as a safety valve, using the Critic as a senior advisor to filter technical challenges and ensure that human intervention is reserved for high-level decision-making. This combination of rigorous gating and structured escalation minimizes technical drift and maintains a consistent standard of quality across the project lifecycle. Sources: src/agents/architect.ts:316-350, src/agents/critic.ts:380-430