The unified PAI Algorithm: one system that absorbs everything

The Algorithm is the only system. Everything else describes how it executes.

If you've been following the PAI project, you've seen several execution concepts emerge:

The Algorithm is a 7-phase loop (OBSERVE, THINK, PLAN, BUILD, EXECUTE, VERIFY, LEARN) that processes every request through ISC (Ideal State Criteria) verification.

ORBIT (Orbital Refinement by Iterative Testing) is an outer loop that persists state to disk and iterates the Algorithm until all ISC criteria pass. Inspired by Ralph Loops and Maestro.

Agent Swarms are Claude Code's CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS feature that lets you spawn coordinated teams of agents that communicate via SendMessage and share task lists.

Ralph Loops are the elegantly simple while :; do cat PROMPT.md | claude-code ; done pattern, where each turn gets fresh context and state lives on disk.

Four things. They look like four systems. If you try to use all four, they feel like they'll clobber each other. ORBIT wants to control iteration. Swarms want to parallelize. Ralph wants fresh context. The Algorithm wants its seven phases. Who's in charge?

Nobody, because there aren't four systems. There's one.

One system, three properties ​

The Algorithm is the only system. It always runs. Its seven phases are invariant. Nothing bypasses it.

Everything else — ORBIT, Swarms, Ralph — describes a property of how the Algorithm executes. Three orthogonal properties:

Depth, Iteration, and Parallelism compose freely across three independent axes.

These properties compose freely. A task might use FULL depth + ORBIT iteration + Swarm parallelism. Or MINIMAL depth + single-pass + single-agent. The Algorithm's PLAN phase examines the ISC criteria and selects the right configuration.

Think of it like a car. You don't choose between the engine and the transmission and the drivetrain. The engine generates power (Algorithm). The transmission selects the gear ratio (Depth). The drivetrain distributes power (Parallelism). The trip planner decides whether to stop and refuel (Iteration).

They don't compete because they're on different axes.

What fires when ​

Here's what actually happens when you send a message. Every component, every hook, every decision point.

Before you see output ​

Before the Algorithm starts, hooks inject context and enforce structure. LoadContext is the critical one — it injects the CORE spec that contains the Algorithm's phase definitions, the ISC creation rules, and the Capability Audit instructions. Without this, the Algorithm doesn't know its own structure.

Every message triggers six hooks on entry. Every tool call is security-guarded. Every session end captures learnings.

This is the invisible infrastructure that makes the Algorithm self-improving.

OBSERVE: reverse engineering ideal state ​

OBSERVE reverse-engineers what the user actually wants into granular, testable criteria.

The ISC criteria created here are the most important output of the entire system. They become the verification criteria in Phase 6. They're what ORBIT checks for exit. They're what gets partitioned across swarm workers. Everything downstream depends on these being granular, testable, and complete.

The trick is to capture what the user wishes they would have told you if they had all the intelligence, knowledge, and time in the world. That's what becomes the ISC.

THINK: assess the three execution properties ​

This is where the three properties get assessed based on the ISC criteria from OBSERVE.

Each assessment is independent. The three answers compose into an execution configuration.

DEPTH asks how complex the ISC is. ITERATION asks whether one pass is enough. PARALLELISM asks whether criteria can be worked on simultaneously.

ORBIT and Ralph are mutually exclusive — both control the iteration axis. But Swarm composes with either one because it's on a different axis entirely.

PLAN: lock in the execution strategy ​

PLAN takes the three assessed properties and selects one of five execution configurations.

Five configurations from simple direct execution to maximum firepower ORBIT + Swarm.

Config A (Direct) is by far the most common — just do the work inline, no agents, no loops. Config D (ORBIT + Swarm) is the maximum firepower configuration for complex, multi-faceted tasks. The PLAN phase declares which config it's using, visible to the user. No hidden decisions.

BUILD + EXECUTE: where capabilities run ​

This is where the selected configuration takes effect.

Config A (Direct): Just do the work. Write code, answer the question, run the skill. No special machinery.

Config B (Swarm): Partition ISC criteria across N agents via TeamCreate. Each agent works independently with its own Algorithm at assigned depth. The lead collects results.

Config C (ORBIT): Create an ORBIT.md manifest with Master ISC criteria. First pass runs FULL depth. Subsequent passes run ITERATION depth with cumulative context. Exit when all ISC pass.

State lives on disk in ORBIT.md, surviving context loss. ISC criteria track exactly how much progress has been made.

Config D (ORBIT + Swarm): The most powerful configuration. Each ORBIT iteration spawns a swarm of parallel workers. Failed criteria get retried with focused workers in subsequent iterations — the swarm naturally shrinks as more criteria pass.

Maximum firepower: ORBIT manages the loop while Swarms parallelize each iteration.

Config E (Ralph): Each iteration gets completely fresh context. State passes only through disk. Used for debugging, evals, and adversarial testing where you explicitly don't want accumulated context bias.

VERIFY: the culmination ​

Everything in phases 1-5 leads here.

VERIFY is the loop gate — it decides whether to exit, iterate, or report failure.

VERIFY is where ISC proves its worth. Without granular, testable criteria, there's nothing to check. This is the loop gate — it decides whether to exit (all ISC passed), iterate (ORBIT active, failures remain), or report failure (max iterations reached).

Evidence is required, not just claims. Test output, screenshots, file checks — actual proof that each criterion passed.

LEARN: capture and exit ​

What worked, what didn't. If ORBIT is active, update the context for the next iteration. If a Swarm was used, note which partition strategy worked. Voice announcement summarizes the result.

At session end, the StopOrchestrator fires four parallel learning captures: WorkCompletionLearning, SessionSummary, RelationshipMemory, and SoulEvolution. These persist learnings to the MEMORY directory so future sessions can build on them.

The fractal nature ​

The Algorithm isn't just the top-level loop. It appears at every level of execution, with adapted depth.

The Algorithm runs at every nesting level. Only the depth changes.

Every box is the Algorithm. The structure is the same at every level. Only the depth changes:

• FULL: All 7 phases, voice announcements, full ISC creation, capability audit
• ITERATION: Condensed — CHANGE (what's different) then VERIFY (did it work?)
• MINIMAL: Just EXECUTE then VERIFY. For leaf-level tasks where the ISC is pre-assigned.

The minimum viable Algorithm is OBSERVE, EXECUTE, VERIFY. You can compress THINK/PLAN/BUILD into implicit decisions, but you cannot skip understanding what success looks like (OBSERVE/ISC), doing the work (EXECUTE), and checking if it worked (VERIFY).

A real example end-to-end ​

Let's trace an actual request through the entire system.

User says: "Rebuild the authentication system. JWT tokens, refresh flow, password reset. Make sure it's secure."

OBSERVE reverse-engineers the request into 8 ISC criteria: JWT signing, refresh rotation, password reset flow, HTTP status codes, OWASP compliance, integration tests, session migration, and secrets management. The Capability Audit selects Swarm x 3 workers + ORBIT for iteration.

THINK assesses: FULL depth (complex, high-stakes), ORBIT iteration (security can't be gotten right in one pass), SWARM x 3 (three independent tracks: JWT/refresh, password reset, security/testing).

PLAN selects Config D: ORBIT + Swarm x 3.

BUILD + EXECUTE (Iteration 1): Three workers spawn in parallel. Worker A builds JWT middleware with refresh rotation. Worker B builds the password reset flow. Worker C waits for both, then runs security audit and writes test scaffolding.

VERIFY (Iteration 1): 5/8 ISC criteria pass. Worker C found a SQL injection in the reset query and two test failures. ORBIT iterates.

Iteration 2: Only two focused workers — one fixes the SQL injection and failing tests, one tests session migration in staging. Score: 8/8 passed. ORBIT exits.

LEARN: Three parallel tracks worked well for independent auth components. Security audit as a separate track caught issues the implementation workers missed. ORBIT needed only 2 iterations — good ISC decomposition.

How new capabilities get absorbed ​

This is the pattern that prevents fragmentation. When Anthropic ships something new — say "Claude Persistent Memory" or "Multi-Model Routing" — it doesn't become a new system. It gets absorbed.

New capabilities register within the three axes. The seven phases never change.

The process is always the same: identify which of the three axes the new capability serves, register the ISC triggers that should cause PLAN to select it, and let it execute within the Algorithm's existing phases.

The seven phases never change. The ISC remains the exit gate. New capabilities fill in HOW phases execute, not WHAT phases exist.

Summary ​

The Algorithm always runs its seven phases. During THINK/PLAN, it examines ISC criteria and selects depth (how much Algorithm), iteration strategy (direct/ORBIT/Ralph), and parallelism (single/swarm). These compose freely across three orthogonal axes. Everything executes within the Algorithm's phases. New capabilities register as options within these axes. ISC is the exit gate for everything.

ISC criteria created in OBSERVE, verified in VERIFY. The system grows more powerful without growing more complex.