Get started

The fastest way to understand SprintLoop is to push a small change through it. This page takes you from a cold workspace to a merged pull request authored by an agent in a lane you signed off on. Plan for fifteen minutes; budget thirty if your CI is slow.

You’ll need: a GitHub repo you can push to, a workstation with git, and an Anthropic, OpenAI, or Google AI API key for whichever harness you want to race first. Bringing all three at once is fine — the racing surface gets more interesting with two or more.

1. Sign up and create a workspace

Open https://app.sprintloop.ai/signup and sign in with Google, Microsoft, or email. The first sign-up creates a personal workspace with a single seat — you’ll be able to upgrade to an org workspace later without losing history.

Once you’re in, hit Cmd+K to open the command palette and run Workspace settings → Identity. Set a workspace handle (lowercase, alphanumeric, like acme) — this is what shows up in lane titles, audit exports, and federation receipts. You can rename the human-facing display name freely; the handle is immutable to keep the audit trail stable.

2. Connect a repo

Settings → Integrations → GitHub → Install the GitHub App. Choose the org or personal account that owns the repo and grant access to the specific repos you want SprintLoop to dispatch lanes against. The app needs contents: write, pull_requests: write, checks: read, and members: read. It does not request access to secrets, packages, or admin endpoints.

When the install completes you’ll be back in SprintLoop with a green status row for each connected repo. Pick one and click Open lane. The workspace prepares an empty lane scoped to the repo’s main branch and waits for a brief.

For the rest of this walkthrough, use a sandbox repo or a feature branch. The lane will open a real PR.

3. Bring a model key

Settings → Models → Add provider. Paste an Anthropic, OpenAI, Google, or Mistral key. Keys are stored encrypted at rest and never logged. The workspace verifies the key with a one-token request to confirm it’s valid before saving — this charges you a fraction of a cent and surfaces obvious errors (revoked keys, wrong region) before you dispatch a real lane.

You can add more than one provider. The harness picker on the dispatch screen will only show harnesses whose keys are present.

4. Dispatch your first lane

Hit Cmd+N to open the dispatch dialog, or click + Lane in the left sidebar. Pick the connected repo, give the lane a title ("Add a /healthz endpoint that returns commit SHA" is a good first task), and choose a harness — Claude Code, Codex, Cursor Compose, Aider, or Devin. If you have multiple keys, Race is enabled: pick two or three harnesses and SprintLoop runs the same brief through each in parallel and compares the diffs.

Before you click Dispatch, scope the lane: which paths in the repo is the agent allowed to touch? Default is the whole repo, but for a first lane it’s worth narrowing — apps/api/healthz/** and package.json is plenty for a healthz endpoint. The agent will be denied at the storage layer if it tries to write outside the scope.

Click Dispatch. You’ll be on the lane page within a second.

5. Watch the lane run

The lane page shows three streams:

• Tool log — every read, write, shell command, and model call the harness makes. Each entry is signed before it’s appended; the page shows the signature heads ticking up.
• Live diff — what the agent has changed in the working tree, refreshed every few seconds.
• Sign-off — the slot at the bottom where you (or an approver) accept or reject the lane.

A first-lane healthz task usually completes in 60–90 seconds. When the harness signals it’s done, the Review Committee (Architect, Security, QA) renders verdicts in the right rail. They’ll either say Looks good, Has questions, or Block. Block means at least one reviewer found something serious enough that the merge button is disabled until you override.

6. Sign off and merge

Click Approve in the sign-off slot. The workspace asks for an inline confirmation (you’re attesting that you reviewed the diff). On approve, SprintLoop:

1. Pushes the branch to your GitHub remote with the lane’s signed commit message.
2. Opens a pull request, populating the body with the brief, the harness used, the model versions called, and a link to the lane’s audit page.
3. Stamps the lane’s chain head into the federation root and writes the receipt to your workspace’s evidence/ bucket.
4. Closes the lane.

GitHub sends the PR through your normal CI. When CI passes, merge as you would any other PR. If you have branch protection requiring approvals, SprintLoop’s sign-off does not substitute for a human reviewer on the GitHub side — it’s an internal attestation, not a GitHub review.

What just happened

You dispatched an agent into a bounded execution context with cryptographic provenance. Every action it took was logged and signed. A panel of reviewer agents read the diff before you did. The merge produced a PR your team can audit six months from now.

That’s the whole loop. Everything else in the docs — racing, the Context Engine, MCP, the Review Committee tuning — makes that loop tighter.

Where to go next

• Lanes — the primitive you just used. Worth ten minutes.
• Harness racing — how to dispatch the same brief to two or three harnesses at once.
• API reference — if you want to script lane dispatch from your own systems.

If something didn’t work, the most common first-lane snag is a wrong-scope claim (agent tries to touch a file outside its scope and stalls). Widen the scope and re-dispatch — the workspace remembers your previous brief.