Inside Sprint Engine: Automating a Sprint Without Losing the Plot

The hard part of agentic coding stopped being how to start an agent a while ago. Any of us can open a terminal, paste a goal, and watch a model produce a diff. The hard part is the second week: knowing what should be worked on next, who owns it, what actually changed, what was tested, and whether the result is safe to merge.

Sprint Engine is our answer to that. It is the part of SE Studio that takes a goal and runs it like a sprint instead of a chat session: a plan, owners, dependencies, and review gates that leave evidence behind. A direct agent gives you output. Sprint Engine gives you a workflow you can inspect.

A sprint, not a session

A coding session optimizes for the next answer. A sprint optimizes for the whole run. That difference is the entire design. Real product work rarely lives in one file: a single change can touch runtime behavior, a migration, tests, packaging, and docs. The risky failure is usually not a compile error. It is that one path still uses the old behavior, one review never happened, or one agent quietly declared success without enough evidence.

So Sprint Engine splits the run into named tasks, gives each an owner and acceptance criteria, tracks the dependencies between them, and refuses to let work reach done until the gates it owes have passed.

What runs when you start a sprint

The brief comes first because most bad sprints start with a vague goal. A strategist agent interviews you, writes a brief.md, and closes its session. The architect reads that brief and produces a task graph: discrete tasks with owners, dependencies, and acceptance criteria. From there the developer roles claim ready work, and the gates do the rest.

Fully pluggable teams

Sprint Engine does not ship one fixed team. A team is configuration: a set of roles, the CLI each role runs on, and the gates a task must clear. Our built-in teams are a sensible default, but you can edit them, swap the model behind any role, or write your own from scratch.

# .multi-code/teams/dashboard.yaml
team: dashboard-squad
roles:
  - role: strategist   # interviews you, writes brief.md
    cli: codex
  - role: architect    # turns the brief into a task graph
    cli: claude code
  - role: developer
    cli: codex
  - role: reviewer
    cli: claude code
gates: [code_review, tests, security]

Because the team is just a plugin slot, the same sprint can mix runtimes: a strategist on one CLI, an architect on another, a security reviewer on a third. The workflow does not care which model is underneath. It cares about the contract: claim a task, do the work, publish evidence.

Nothing moves on vibes

The gates are the point. An implementation agent cannot silently move its own card to done. It has to publish what it changed, and the task then sits in review until its gates pass. Reviewers run in their own lanes, in parallel, so a task can be getting a code review, a test run, and a security pass at the same time.

• Task ownership: every unit of work has an owner, a status, and acceptance criteria.
• Dependency control: downstream work waits until upstream plans and implementation are ready.
• Review gates: code review, tests, security, performance, and architecture can each be a separate accountable step.
• Evidence trail: agents record touched files, commands, results, and review verdicts on the card.
• Needs-input routing: a blocker is classified and surfaced instead of stalling a terminal.

The benefit is not more agents. It is accountable handoff between agents.

Why this matters

Agent speed is useful. Agent evidence is what makes the result trustworthy. With a direct agent, the human has to remember the plan, watch for missing tests, ask for review, and decide if the output is safe to merge. Sprint Engine moves those concerns into the system, so the work is planned, claimed, reviewed, tested, and documented as part of the run.

That is the difference between agent assistance and agent operations — and it is built for the hundredth sprint, not just the first.