From strategy to proof.

The portfolio a PMO runs on, and the record of the agent work underneath it.

Many agents, one record.

Every run recorded stage by stage—plan, build, review, verify, ship—with the commit each parallel lane landed.

One control plane over the AI.

Which models this workspace approved and where each one runs, which may see regulated content, what an agent is allowed to reach, and who accepted the result.

AI ships the work. Your PMO still owns the outcome.

Reporting and visibility

Walk into the review with the picture already made.

Illustrative workspace · not a customer's data
The command center of an illustrative workspace: a portfolio briefing over an average handle time measure, findings grouped by class, and the portfolio counted by delivery state.
  1. Portfolio briefing
  2. Assurance funnel
  3. Early warning
  4. The register

AI-native teams deliver at a speed no reporting cycle can follow.

Agents draft plans, open pull requests, and run test suites between one stand-up and the next. The register that governs them still updates on a weekly rhythm, assembled by hand—so the portfolio spends most of its life describing work that has already moved.

SprintLoop closes that gap at the one point where it matters: the moment a change enters the plan. An agent proposes the whole change—scope, assumptions, and every work item it would create. A named person accepts or rejects it. The decision, the evidence behind it, and the person who made it are recorded together.

The fair objection is that governance is what takes the speed back, and most of the time it does. A control that asks a person to re-read everything a model produced returns exactly the hours the model bought. So the review boundary sits at one place rather than everywhere: the moment a change enters the plan. Everything before it runs at machine speed.

Recording is the half that has to happen everywhere, and it costs almost nothing at the time. It costs a great deal later, when a regulator asks which model saw member data in March and the person who watched that work has left. What the registers below hold is the answer to that question, written while the work was happening rather than reconstructed after it.

See what the registers hold

Built on and connected to

The systems SprintLoop runs on.

Model providers

Drafting and review run on Claude models from Anthropic. A workspace can point SprintLoop at OpenAI, Google Gemini, or Azure OpenAI instead, using its own key and its own spending ceiling.

Work and evidence sources

A claim is pinned to the commit that carries it, in GitHub, GitLab, or Bitbucket, and test outcomes arrive as JUnit results. Jira Cloud connects read-only, and anything it proposes waits for a named person.

Hosting and data location

A customer register stays in the United States: PostgreSQL in AWS us-east-1, the application served from us-east-2. Stripe takes card details on its own page; Resend carries invitations.

AnthropicOpenAIGoogle GeminiMicrosoft AzureGitHubGitLabBitbucketJira CloudJUnitNext.jsReactTypeScriptNode.jsNetlifyAmazon Web ServicesSupabasePostgreSQLStripeResend

Each name above is the trademark of its owner, and appears here as a system SprintLoop runs on or connects to.

The second register

Your portfolio is one record. What the agents did is the other.

Agentic delivery stalls at a security review more often than it stalls at a benchmark, and the question that stalls it is a narrow one: which model saw this work, was it allowed to, and who accepted what came back. Four registers answer it. Every table the product’s own data lives in carries forced row-level security, and a check that raises rather than reports runs at the end of every migration.

  1. Model register

    /engineering/models

    Which models this workspace approved, and where each one physically runs: on hardware the organization controls, in a tenant-isolated deployment under contract, or behind a public API. Every approval carries a separate decision about whether work containing regulated or member-identifying content may reach that model, and it starts at no.

    The approver states the basis in their own words and the database refuses an approval that states none. Withdrawing one records the withdrawal instead of deleting the row, so a run that happened under an approval stays explainable after the approval ends. The register holds where the credential lives, in words. A constraint refuses key-shaped text at write, so a paste accident fails the write rather than leaving a secret in the database an estate points its auditors at.

  2. Run record

    /engineering/runs/<id>

    What a run was asked to do, which approved model it ran under, and what happened at each stage: plan, build, review, verify, ship. Where the work fanned out across parallel lanes, each lane records the slice of the tree it owned, the lanes it waited on, the harness that ran it, and the commit it landed.

    Two lanes claiming the same path becomes something the register states before the merge rather than something a reviewer discovers after it. Tokens are counted and money is not, because cost is a join against a dated price and a run with no price behind it should say so.

  3. Operating policies

    /engineering/policies

    Nine written policies, IL-01 through IL-09, each with a statement and the reasoning behind it. An agent may not grant itself authority. A result is a proposal until a person accepts it. Regulated content stays inside its approved boundary. A waiver names a person. A workspace adopts the ones it will hold its runs to and sets each one advisory or blocking.

    What a policy returned for a run — pass, fail or waived — is sealed with a digest over the bytes it was about, and the table carries no update path at all. Nobody holding a token can rewrite a sealed verdict; a correction is a new run. A policy with no verdict against a run reads as not evaluated, never as passed.

  4. The agent connection

    /api/mcp

    Agents reach the workspace over a scoped connection that reads the registers and narrates its own session back. Six of its eight doors are reads: projects, requirements, work items, risks, control gates, and the standing counts with their denominators, so an agent cites a requirement key the register actually holds instead of inventing one. The other two write narration and propose test bindings.

    There is no door on it to accept, sign or disposition anything. Who accepted comes from a signed-in person’s session, and a connection does not have one — the database refuses the act rather than the application declining to offer it.

None of this runs the agents. SprintLoop 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. It is the register those tools report into, and the desk where a named person accepts what they produced.

One operating view

Know where the portfolio stands—and what should happen next.

Most PPM tools answer “how is the portfolio doing?” with a color. SprintLoop answers it with the counts, the decisions and the evidence they were drawn from. See the sourced comparison

01

See the whole portfolio move.

Connect outcomes, funding, projects, milestones, and risks without flattening them into one vague score.

02

Turn decisions into momentum.

Give every proposal a clear owner, a review point, and an attributable decision before work changes.

03

Reach evidence in one step.

Move from a portfolio claim to its requirement, code pin, test result, and acceptance without a scavenger hunt.

Traceability that travels

From intent to evidence, without the scavenger hunt.

Each stage stays connected, so a portfolio claim can be examined instead of merely repeated.

  1. 01

    Intent

    Outcomes and investment choices

  2. 02

    Plan

    Requirements and delivery scope

  3. 03

    Evidence

    Pinned tests and traceable results

  4. 04

    Acceptance

    Named, attributable decisions

SprintLoop

Make the next decision visible

Run the portfolio with clarity from the first plan to final proof.