The Self-Deterministic Agent Loop
The canonical overview. How Plan Forge's deterministic slice executor, the Phase-25 reflective layer, and the Phase-26 competitive layer compose into a single self-deterministic agent loop.
- Deterministic part, the slice executor. No random model picking, no hidden retries that change the result. You can re-run a plan and get the same answer.
- Self-learning part, the “inner loop” (reflection on what worked) and “competitive loop” (multiple models racing) feed lessons back into the next slice or plan.
- Safety, every learning signal is opt-in or advisory. Nothing silently changes a run you've already started.
What "self-deterministic" means
Plan Forge's slice executor is deterministic: same plan, same config, same model routing, same outcome. On top of that spine, the Phase-25 and Phase-26 subsystems let the loop observe itself and feed what it learns back into the next slice, the next plan, or a sibling project. The execution contract stays deterministic; the loop's context gets progressively better-informed. That combination is what we mean by self-deterministic:
- Determinism at the execution boundary, no randomized control flow, no hidden model selection.
- Reflective feedback at the learning boundary, trajectories, postmortems, auto-skills, and advisory signals.
- Every signal is opt-in or advisory by default; nothing silently changes a deterministic plan run.
Diagram A — System-wide state flow
The outer pipeline is the same one Plan Forge has always had. The inner loop adds callback arrows that let later stages feed earlier stages without breaking the forward progression.
Two things to notice: first, every backward arrow from Execute, Sweep, and Review is opt-in or advisory by default, the forward pipeline stays honest. Second, the arrow from Execute back to Harden crosses a plan boundary: a postmortem written at the end of this run is read by the hardener at the start of the next one.
Diagram B — Inner-loop callback graph
Zooming into a single slice, here is what happens at the slice boundary and how each Phase-25 and Phase-26 subsystem feeds something downstream, the next slice, the next plan's hardener, or a Dashboard promotion surface.
The Phase-25 subsystems are labeled L1–L8 in the capabilities surface (forge_capabilities → innerLoop); the Phase-26 subsystems, C1 competitive, C2 auto-fix, C3 cost-anomaly, extend the same surface. Every node in the diagram corresponds to one entry in INNER_LOOP_SURFACE.subsystems.
Subsystem roll-call
Every subsystem, the stage at which it fires, and where its output shows up. See the companion chapters for mechanics and configuration.
| Subsystem | Fires at | Output lands in | Default posture |
|---|---|---|---|
| Reflexion (L7) | Gate fail → retry | Next attempt's prompt | Always on |
| Trajectory (L8) | Slice pass | .forge/trajectories/ | Always on |
| Auto-skill library (L2) | Slice pass → next slice | .forge/auto-skills/ | Always on |
| Adaptive gate synthesis (L6) | Pre-flight | Stdout + Dashboard promotion surface | Suggest (never mutates plans) |
| Postmortem (L5) | Run end | .forge/plans/<basename>/postmortem-*.json | Always on (retention 10) |
| Federation (L4-lite) | Brain miss → cross-repo read | In-memory recall | Off (opt-in, absolute local paths) |
| Reviewer (L4) | Gate-check | Gate-check response, Dashboard | Off, advisory-only |
| Competitive (C1) | Slice start (marked competitive) | Winner's worktree → tree | Off (opt-in) |
| Auto-fix (C2) | Gate fail + small diff | .forge/proposed-fixes/ | Advisory (never auto-apply) |
| Cost-anomaly (C3) | Every slice | .forge/cost-anomalies.jsonl, Dashboard | Advisory (detection only) |
Why this matters
The individual subsystems are useful on their own. The mesh is what turns a slice runner into a self-deterministic loop: a trajectory written today becomes part of tomorrow's planning context; a cost anomaly noticed this run becomes the reason next run's hardener picks a cheaper model for that slice; a gate command accepted three times graduates into the validation template for that domain. None of this changes the deterministic execution contract, it only changes the information the deterministic executor runs with.