Pramaan Loop · governed delivery lifecycle

From approved intent
to observed outcome.

Loop is the control system for building with agents: it freezes the contract, bounds execution, evaluates exact candidates, coordinates release, and keeps watching after production.

What Loop owns

The application-delivery record.

Brief, PRD, user journey, technical design, phases, candidates, delivery evidence, release decisions, and the observed outcome.

What it does not own

The Pramaan kernel's authority.

Capability mutations, request context, idempotency, metering, postconditions, and platform evidence stay in the kernel. Loop and the kernel exchange immutable receipts.

The application loop

A build begins before code and ends after learning.

Every transition has a required input, an accountable decision, and evidence. A prompt cannot skip a lifecycle state.

RequirementUser journeyAcceptance criterionPhase taskGate receipt
  1. 01DefineBrief + PRD
  2. 02DesignJourney + architecture
  3. 03PlanPhases + envelope
  4. 04BuildCandidates + gates
  5. 05ReleaseDeploy + rollback
  6. 06LearnObserve outcome

Clear ownership

No agent edits the truth.

The architecture separates decisions, state transitions, effects, and proposals. That is what makes pause, resume, retry, and lost-response recovery honest.

01Decides

Controller

Selects the next permitted phase, candidate, gate, approval, or recovery action.

02Commits

Runtime

Sole writer of run state and sole owner of external effects and reconciliation.

03Accepts

Protocol

Evaluates events against lifecycle invariants, budgets, revisions, and terminal rules.

04Propose

Agents

Return plans, patches, reviews, and evidence without owning the authoritative state.

Execution

The harness is replaceable. The receipts are not.

Loop can drive different agent harnesses and skill sets through one adapter boundary. Workers operate on isolated candidates and return structured results to the runtime.

Under the product

Sisyphus-style skills and agent harnesses help agents persist, plan, test, and review. They are implementation tools beneath Loop—not competing public products or sources of truth.

Pramaan execution plane architecture
Intent
01Human authorityObjective · policy · budget
02Pramaan LoopLifecycle controller
bounded work order
Ephemeral workerisolated
01Checkout exact SHA
02Inspect + patch
03Test + review
04Return evidence
HarnessSkillsCost meter
proposal + receipts
Delivery
03RepositoryPR · CI · approval
04Customer releaseCanary · observe · rollback

Customer cost

Reserve first. Settle from receipts.

Loop budgets tokens, tool calls, duration, infrastructure, and Pramaan capability usage by run and phase. Actual cost is derived from provider receipts against versioned pricing—not a number invented before the work exists.

Phase 03 · Buildwithin envelope
Agent tokenssettled
Tool runtimesettled
Capability callssettled
Pricing versionpv_2026_07
In active development

The protocol is strong. The full product journey is not finished.

  • Lifecycle contracts, templates, budgets, candidates, and evidence model exist.
  • A durable production-shaped Pramaan exchange and joint acceptance suite exist locally.
  • Guided authoring, operator workbench, live deployment, and customer validation remain.
See the exact status

Prepare a run

Start with a contract an agent can actually execute.

Create a Loop brief