The AI SDLC platform for enterprise teams

Agents do the work. This is where it is declared, permitted, recorded and signed.

Any team can put agents on the work now. Almost none can say afterwards what ran, what it was allowed to touch, or who accepted the result.

View pricing Compare the category

The command center of a workspace: a portfolio briefing over thirty-one projects, a line reading that 99 of 264 recorded findings are waiting on a person, findings broken out by class, portfolio by delivery state, an assurance funnel over 145 requirements, and fourteen days of trail activity totaling 249 recorded acts. — Photographed from the running product. Every organization, program, project and person name was substituted out of the page before the shutter opened, and the capture is refused outright if one of them survives in the rendered document — real screen, real arithmetic, illustrative workspace.

The shape of it

Four questions, and the register that answers each.

The work happened in your harness. What comes back here is a record in four parts, and each part is a table with its boundary enforced in the database rather than in the screen in front of it.

Which models saw this work, and where do they run? What did the agents actually do, stage by stage? What were they held to, and what came back? Which tools could they reach, and what was refused?

One run of agent workexecuted in your harness, recorded here

Model registerwhich model, and where it runs

Tool permissionswhich doors it could reach

Operating policieswhat it was held to, sealed

Decision trailwho accepted the result

One run of agent work sits between four registers. It names the approved model it ran under; every tool it called was resolved against the permission register before the door executed; each adopted policy returned a verdict sealed against the bytes it covered; and the acceptance at the end names the person from their signed-in session, never from anything the agent sent.

SprintLoop does not run the agents. It does not execute a build, dispatch a lane or hold a model key, and it does not replace the harness your engineers already work in. Agents report in over a scoped connection: six of its eleven doors only answer questions, the other five write narration and propose test bindings, and none of them can accept, sign or disposition anything.

From a requirement to its proof

A requirement carries the strongest evidence actually attached to it.

A citation, an artifact that resolves at a pinned commit, a test that ran and a runtime observation stay distinct all the way up. A reviewer sees what supports the record rather than one word standing in for all four.

A skipped test creates no binding, and a failing one still binds. A citation that does not resolve at the pin stays visible as a classified finding until a person decides what to do about it.

A requirementin the register, with nothing attached to it yet

A citationa path, a route, or a test name

Checked at the pinagainst one recorded commit

Evidence bounda test that ran, or a runtime observation

A classified findingstale reference, unsupported claim

A citation is attached to a requirement and then checked against one recorded commit. What resolves becomes evidence bound to that requirement, with the outcome kept explicit. What does not resolve becomes a finding in a closed set of classes — it does not quietly disappear, and it does not silently pass.

The ladder, in order

Rank is carried by how much of the mark is filled, so the ladder survives a grayscale print and a color-vision deficiency. There is no tick at the top: a test that ran may have failed, and a shape promoting a failure to a success would be the exact overstatement this product refuses.

RecordedNo citation at all. This is a finding, not a gap to ignore.
CitedA citation with nothing resolved behind it yet.
Artifact resolvedA path that exists in the pinned tree. Not implemented.
Route confirmedA route in the pinned tree answers for the claim.
Test executedA test that ran, with a recorded outcome. Not compliant.
Runtime observedObserved at runtime against a live surface.

The finding classes, closed

Six classes and no seventh. Adding one is a reviewed product change, so a workspace cannot quietly redefine what a finding means, and two workspaces reading the same register cannot reach different answers about it.

Resolved referenceThe citation resolved in the pinned tree.
Stale referenceThe citation names a path that is not in the pinned tree.
Outside the boundaryThe target is outside the pinned system boundary.
Unsupported claimA claim was made with no citation behind it.
Requirement without citationA requirement carries no citation at all.
Rollup disagreementA summary row disagrees with the rows beneath it.

The agentic harness

A run is recorded stage by stage and lane by lane.

Workflows are declared with named stages, every run is recorded stage by stage, and parallel lanes declare which files they own.

A lane that declares nothing owns nothing. Usage is recorded in tokens, and money appears only where a dated price exists — never as an estimate.

01PlanWhat will be done, and what would prove it was done.
02BuildThe change itself, against the declared slice of the tree.
03ReviewWhat a second reader found, by severity.
04VerifyWhether the stated proof actually holds.
05ShipWhat was published, and the commit it was built from.

A runone workflow, one approved model, five stages

Lane onedeclares the slice of the tree it owns

Lane twodeclares its own slice, and what it waits on

Ownership comparedexact paths, and globs it will not judge

Both lanes landharness, branch, head commit, files changed

Collision namedtwo lanes, one path, before either merges

Where a run fans out, each lane records the brief it was given, the slice of the tree it claims, the lanes it waits on, which harness executed it and the commit it landed. Ownership is compared as exact paths and globs; a pattern the check cannot judge is reported as a collision rather than waved through, because the failure a reader can see beats the one they cannot.

supabase/migrations/20260820020000_agentic_harness.sql
src/lib/harness/model.ts

The AI control plane

Where a model runs decides what it may be shown.

Every approval carries a hosting posture — the organization's own hardware, a tenant-isolated private cloud under contract, or a vendor's public API — and the posture is what decides what the model may be shown. A workspace holds several credentials at once, each with its own boundary and its own ceiling, and a retired one stays listed with the date and the person, because the runs that happened under it did happen.

Whether work carrying regulated or member-identifying content may reach a model is a second decision, recorded separately from the hosting posture and defaulting to no. An approval is narrow until a named person widens it.

Work to be sentcarrying regulated or member-identifying content

The approvala posture, and a separate yes or no

A model that may see itwith the address it answers at, recorded

Outside the boundaryapproved for de-identified work only

The posture is the permission. Work carrying regulated content reaches only a model whose approval says in writing that it may process it; every other approved model stays available for de-identified work and is simply outside the boundary for this piece of work. On premises and private cloud approvals must record the address the model answers at, because a posture nobody can check is an assertion rather than a control.

On premisesRuns on hardware this organization controls. Prompts do not leave the network.
Private cloudA tenant-isolated deployment under contract. Handling is governed by that agreement rather than public terms.
Vendor hostedA public API. Work sent here leaves the organization's boundary.

The register never holds a key — only where one lives, in words. Key-shaped text is refused at write by the database, not by a form.

supabase/migrations/20260820100000_provider_credentials.sql
supabase/migrations/20260820200000_ai_credential_repair.sql
src/lib/harness/model.ts

Three columns of the model register, ordered by distance from the network. On premises holds two of five approvals, both marked regulated content permitted, each with the address it runs at. Private cloud holds two, both de-identified work only. Vendor hosted holds one, de-identified work only, with no endpoint recorded. — The three postures side by side, each carrying the standing rule for work sent there and the approvals under it today.

The register of approvals

An approval is a person’s decision with the reason attached.

Approving a model is an act by a named person, stamped from their session rather than from anything a form sends. The basis is written in their own words and an approval without one fails the write, because an approval nobody had to justify is a checkbox.

Withdrawing an approval records the withdrawal beside it rather than removing the row. The runs that happened under it did happen, and a register that deleted the approval would make them unexplainable.

The model register: five standing approvals, two of which may process regulated content, shown as three posture columns above a table of every approval recorded — model, posture, whether regulated content is permitted, the date approved, the approver's stated basis, and whether it still stands. — Standing and withdrawn approvals in one table, newest first, each with the basis its approver stated. The heading counts carry their denominators, here and everywhere else in the product.

Where the key livesThe register records the location in words — the environment variable, the vault entry. A constraint refuses key-shaped text at write, so a paste accident is a failed write rather than a secret sitting in the database a reviewer is pointed at.
What a run costUsage is recorded in tokens. Money appears only where a dated price exists for that model; where none does, the register says the price is unrecorded rather than showing a zero.
Several at onceA workspace holds more than one credential, each with its own boundary and its own ceiling, so a team is not forced to run everything through the loosest one it has.

Tool permissions

A tool call is authorized before the door executes.

The catalog of tools an agent can call is derived from the server that publishes them, and anything that writes is denied until a named person grants it.

A refusal names the tool, never the payload. An agent cannot grant itself a tool: every grant is a named person's act.

6 / 11doors only answer5 / 11write, and propose

An agentholding a workspace credential

The endpoint/api/mcp

Tool standingresolved in the database, before anything runs

The door executesa read, or a write a person granted

Refusal recordedthe tool, the reason, and whether it was stopped

The check runs before the door, not beside it — a check that runs in parallel with the work it authorizes has authorized nothing. The answer comes from the same database function the workspace console reads, so a reviewer cannot be shown a control the endpoint does not apply. A refusal is written by the database, and it records whether the call was actually stopped or only watched, because a control a workspace deliberately made advisory is not a control it is protected by.

The machine surface, in the catalog’s own words

These are the exact names a model receives from the endpoint, and the phrase beside each is the description the model itself is given. Read or write is derived from that description rather than from a second list somebody has to remember to update. A door that writes is denied until a named person grants it.

portfolio_standingThe workspace's current standingReads
list_requirementsThe requirement registerReads
list_projectsThe portfolio registerReads
list_work_itemsThe delivery backlogReads
list_risksThe risk registerReads
list_gatesThe control gates instantiated on each projectReads
log_agent_activityNarrate this agent session into the workspace's session recordWrites
report_test_runReport a test run against one pinned commitWrites
open_workflow_runOpen one execution of a workflow a person already defined. The caller supplies a stable idempotency key, agent name and intent; exact retries return the same run. Optionally name the pod under whose delegation this run executesWrites
record_workflow_runRecord 1–50 stage, lane, token-usage or sealed policy-verdict events against an open workflow run. Event ids make exact retries no-ops. This write door cannot create, edit, accept or disposition any delivery-register row, waive policy or accept evidence.Writes
close_workflow_runClose one workflow run as complete, failed or abandoned. Exact retries return the first result and a terminal outcome cannot change. This write door cannot create, edit, accept or disposition any delivery-register row.Writes

supabase/migrations/20260820190000_tool_permission.sql
src/app/api/mcp/route.ts
src/lib/tool-permission/gate.ts

Operating policies

Nine policies ship with the product, each adopted by a named person.

A run may not widen its own permissions, may not pipe fetched bytes straight into an interpreter, may not carry regulated content past its approved boundary, and may not accept its own output. Seven are blocking and two report without stopping the work, and which is which is recorded rather than assumed.

What a policy returned for a run is sealed with a digest over the bytes it covered, and the table has no update path, so a sealed verdict cannot be rewritten after a ship — a correction is a new run. A policy with no verdict against a run reads as not evaluated, never as passed, and a waiver names a person or the database refuses to record it.

7 / 9ship as blocking

IL-01An agent may not grant itself authorityBlocking
IL-02A result is a proposal until a person accepts itBlocking
IL-03No opaque executionBlocking
IL-04Regulated content stays inside its approved boundaryBlocking
IL-05A gate seals before a deployBlocking
IL-06Every run names the model it ran underAdvisory
IL-07A waiver names a personBlocking
IL-08A run narrates what it didAdvisory
IL-09Secrets are located, never storedBlocking

supabase/migrations/20260820020000_agentic_harness.sql

The gated AI SDLC

Thirteen blocking control gates, in four bands.

The bands are intake and design assurance, build and runtime security, access and data and operations, and final risk acceptance — architecture review, threat modeling, dynamic testing, penetration testing, identity and data protection reviews among them. One further check runs continuously after deploy and reports without withholding a release.

There is no gate percentage and no gate health score anywhere in the product. A gate is signed by a named person holding the owning role, waived with a recorded reason, or it is open.

Where a release is held

Intake and design assuranceInitiation · Architecture review · Threat modeling · Secure design validation4 / 13gates
Build and runtime securityCode and build security · Infrastructure security · Dynamic testing · Penetration testing4 / 13gates
Access, data and operationsIdentity and access review · Data protection review · Logging and monitoring · Incident response readiness4 / 13gates
Final risk acceptanceFinal risk assessment, signed by the release authority1 / 13gates

What kind of control it is

A control declares when it acts, and the set is closed — the ingest door refuses anything outside it. The distinction is authority, not lifecycle: a check that runs after a release can never withhold one, so it is never counted among the thirteen.

PreventiveBefore generation. The agent cannot.Halts
InlineDuring generation. Blocks and returns a correction signal.Halts
GateBefore release. Withholds release.Halts
ContinuousAfter release. Never a control. It earns its keep by feeding a gate and a person.Detects only

supabase/migrations/20260814000000_methodology_gates.sql
src/lib/gates.ts

Evidence that leaves the building

The receipt carries the signed record and checks without us.

Deck and trail exports carry an Ed25519 receipt over canonical bytes, and the public key travels inside the receipt.

A claim whose count exceeds its own denominator is not rounded: the receipt is not issued. There is no partial receipt.

SprintLoop authority receipt

Executive delivery brief

Illustrative receipt · fields and verifier behavior mirror the current format

ReceiptSL–E7A4–91C2

Subject: Quarterly delivery deck
Source: Portfolio register
Pinned commit: 8f4c91a

Evidence contract Complete
Claim	Present	Required	Standing
Bound requirements	42	42	Complete
Blocking gates	13	13	Complete
Named acceptances	3	3	Complete

The signed receipt can travel alongside an export. A recipient can re-derive its canonical body and verify the signature with the embedded public key, without calling SprintLoop. It attests to the claims it contains; it does not hash the separate deck file.

Verify a receipt View pricing

src/lib/evidence/receipt.ts
src/lib/evidence/canonical.ts
src/app/verify/page.tsx