Continuous AI Game Production Through Governed Sprints

How a governed sprint loop lets AI agents keep making bounded, evidence-backed progress across a portfolio of Unity game repositories.

The game changer is not that an AI agent can generate a script, draft a mechanic, or fill in a checklist. Those are useful, but they are still isolated acts. The larger shift is that a repository can be structured so an AI agent can keep doing bounded production work without losing the thread.

That is the model I am using across the Unity game portfolio. Each game repository has a canonical agent entry point, source design evidence, VeritySpec records, roadmap, changelog, content validation, local tests, CI workflows, and explicit release boundaries. The agent is not asked to remember the process from chat. The process lives in the repository.

The result is a continuous production loop. The agent works one game at a time, completes one playable foundation sprint, records the evidence, leaves main clean, and moves to the next eligible repository. It keeps going until the next step is blocked by something that actually needs operator input.

The Operating Contract

Every repository starts with AGENTS.md. That file is not decoration. It tells the agent how to enter the project, which records to inspect, which checks to run, how to handle uncertainty, when to update VeritySpec, what not to publish, and when approval is required.

The workspace now has its own entry point too. When an agent works inside a repository, it reads the workspace entry point and the repository entry point together. After a commit, it refreshes by reading them again and checking the latest repository state. That matters because long-running production work is vulnerable to stale context. The refresh rule makes context renewal part of the operating loop instead of a memory trick.

VeritySpec handles the product truth. GitHub handles workflow. Unity implements the game. VerityFoundry helps rough intent become structured records. That separation is simple, but it changes the shape of AI work. Product decisions do not live only in scenes, prefabs, scripts, or a chat transcript. They become inspectable records with validation and readiness expectations.

What A Two-Week-Style Sprint Means

The sprint packet calls this a two-week-style sprint, but that phrase describes scope and shape, not a guaranteed number of elapsed calendar days. The point is to bundle a coherent production increment that could reasonably be treated as a focused sprint.

For these first portfolio passes, the sprint theme is a playable foundation slice. The agent inspects the source design package, creates or uses a GitHub issue and milestone, works on a branch, updates VeritySpec before or alongside implementation, adds deterministic content or runtime foundations, updates tests and validators, keeps the Next 20 Product Backlog full, opens a pull request, watches checks, merges cleanly, records tracker evidence, and handles the devlog/source-sync path.

That is more than code generation. It is a production unit. The code matters, but so do the contract records, issue state, validation results, CI runs, devlog status, and follow-up risks.

The Portfolio Loop

The cross-game coordination lives in the shared Unity library repository because that is the current portfolio coordination point. Its tracker lists 50 Unity game repositories in sprint order. The operating rule is deliberately narrow: work on one game repository at a time, leave it clean on main, then move to the next eligible pending game.

At the time of this writing, the tracker records 25 completed game sprints and 25 pending game sprints after the Lemonade Lane closeout. The next pending repository is loose-cargo-bumpy-roads, and the active handoff says that sprint has begun operationally even though the shared tracker still reflects the previous closeout state.

Completed rows are not vague status claims. They name issues, commits, CI run identifiers, devlog slugs, and tracker closeouts. For example, landy-ship completed issue #3 at commit 2bae89a with CI, content, VeritySpec, and CodeQL checks recorded, plus a published sprint devlog. leanns-gloom-grill-frights completed issue #3 at commit aad325b with the same kind of evidence. lemonade-lane-stand-by-stand completed issue #3 at commit 4c16d64, with CI 28587940138, Content 28587940118, VeritySpec 28587940122, CodeQL 28587939423/28587947408, and a published devlog.

The practical effect is continuity. The next agent does not have to ask, "What was I doing?" It can read the tracker, read the repository entry point, inspect the issue and records, and continue from the current evidence.

The Blocker Model

Continuous does not mean reckless. The loop continues only while the next repository is eligible, checks can be resolved, required approval gates are not being crossed, and the operator has asked the loop to keep going.

The agent stops when the operator asks or when the next step requires input it cannot safely invent. Real blockers include missing required source evidence, conflicting active work in a repository, branch-rule or check failures that cannot be fixed locally, missing approval for release or deployment actions, legal or monetization decisions, production SDK choices, external credentials, physical devices, or unavailable runners needed for required validation.

That blocker model is important because it turns stopping into a signal. The agent is not stopping because it ran out of prompt context. It is stopping because the system has reached a boundary that should be handled by a person or an external service.

Evidence Is The Engine

The strongest part of this model is the evidence path. A completed sprint is expected to have a GitHub issue or milestone, a branch and pull request, changed VeritySpec records, implementation or content changes, updated tests or validators, local validation, GitHub Actions results, a clean main, tracker closeout fields, and a devlog disposition.

The standard local checks include unit tests, content validation, VeritySpec validation, strict linting, readiness checks, graph generation, and whitespace checks. Unity edit mode, play mode, and Android build smoke checks are added when the runner is configured. The website has its own checks for content, links, Astro validation, build output, and VeritySpec records.

If CI is unavailable, the agent can record local verification evidence and the external blocker. It cannot simply claim clean completion unless the operator accepts that fallback. That distinction keeps the system honest.

Why This Changes AI Game Work

Most AI-assisted development breaks down when the process is implicit. The model works for a while, then the agent forgets a convention, skips a validation step, duplicates a pattern, or turns uncertainty into a confident claim.

This portfolio works differently because the rules are durable. The agent knows where product truth lives. It knows the next backlog should not run dry. It knows release, deployment, store submission, analytics, ads, purchases, legal publication, and shared-library rollout require approval. It knows article and devlog opportunities are proposed or published through their own source repositories. It knows reusable practices and terminology belong in canonical pattern and glossary repositories instead of being silently forked inside one game.

That makes AI less like a stateless assistant and more like a governed production participant. It can make progress because the repository tells it what safe progress looks like.

What This Does Not Claim

This does not mean all 50 games are complete. It does not mean the playable foundation slices are finished commercial products. It does not mean release readiness, store approval, legal clearance, privacy clearance, platform compliance, monetization readiness, or commercial performance has been established.

It also does not mean the shared Unity package is live across every game. Shared-library candidates are intentionally recorded without automatically forcing adoption. A consuming game should not add the shared package dependency until the package records, tag, migration notes, and rollout approval exist.

Those limits are part of the point. The loop is powerful because it keeps moving without pretending that every unresolved question has been solved.

The Compounding Effect

Each sprint moves one game forward, but the value compounds across the portfolio. A sprint can produce a playable foundation, a clearer VeritySpec record, a better validator, a shared-library candidate, a devlog, a reusable pattern, a glossary term, or a stronger backlog item.

The work is not just accumulating files. It is improving the operating system around the games. The more repositories follow the same contract, the easier it becomes for an agent to switch context, understand the next safe step, and preserve evidence.

That is the real game changer: continuous AI game production becomes practical when the project is designed for continuity. Better prompts help, but durable repository structure is what lets the work keep going.