Agents with jobs

Four kinds of agent

Almost all of our code is written by Claude Code, and the work is split between agents that each have a job, a boundary and a way to hand work on.

The main agent works in the game’s repository. It owns the game and its engine, and it is the only agent that commits to the game. Every commit passes the game’s checks first and names its Linear issue. It reviews the studio’s work and closes the studio’s issues, and it keeps the dev journal some of these posts started from.

The studio agent works in the asset studio’s repository. It designs ships as data files, with props and vehicles to follow, renders them for review, and checks them against the engine and the flight rules. It never commits to the game. It exports a checked file, and the main agent commits it after the game’s own checks pass. The two share a build lock, so they never build at the same time, and the studio won’t build while the game is being played.

The site agent runs this website. It owns the site, its Linear project and its hosting. It never writes to the game’s or the studio’s repositories. When something needs changing there, it leaves a Linear comment or a proposed change for that agent. It merges its own work once its checks pass, and it deploys only with a go-ahead. The main and studio agents will write devlog posts here by pull request, and the site agent reviews and merges them.

Contractors are hired by any of the three for one scoped job, and they leave when it is done.

Hiring a contractor

When something would fill the main agent’s context with material it doesn’t need to keep, we tell the main agent to go hire someone for it. Research, a sweep through dozens of files, or chasing a stray thread through old issues all count. A contractor is a subagent or a separate headless Claude Code session. It works in its own context, reads and searches as much as the job needs, and hands back a report. The main agent keeps the conclusion and the plan, and its context stays clean for the work in front of it.

Contractors read and report. They don’t commit, and they don’t build or run the game while it is being played. The agent that hired them checks the work and commits it.

One rule sends work to contractors on purpose. When a fix hasn’t landed after a round or two, or something feels wrong and is hard to put into words, the main agent stops iterating and hires a research pass. The pass looks at how others solved the problem in games, papers, engine docs and talks, turns the description into candidate causes and options with references, and brings them back before more attempts go in.

Which model does which job

Each job goes to the cheapest model that gets it right.

• Sonnet is the default: research passes, sweeps through files and docs, extraction, mechanical ports, running and reading benchmarks, and drafting from a settled outline.
• Opus takes the jobs where a wrong answer is expensive and hard to notice: architecture and migration plans, reviews of risky changes, load-path and determinism debugging, and independent checks of finished work.
• The most expensive tier is used rarely, and only with a stated reason.

The test we apply is whether a plausible wrong answer would survive review. If it would, the job gets a stronger model.

In numbers

• Research documents: 41 of the 61 documents in the game’s docs folder were written by research passes. They cover glass, water, fire and smoke, enemy pilots, ship classes, city layout and naming, among others.
• Commits: 62 of the game’s 761 commits mention a contractor, a research pass or a worktree.
• One review: an Opus review of a night’s gameplay code found eight problems, all fixed. The largest was that the enemy pilots’ sensing rays started inside their own hull.

Some of the jobs

• The name. Three naming research passes checked candidates against game stores and domains. The third listed Wreckwing as clear on every check it ran, and we picked it.

• The studio’s plan. A headless Opus session wrote the plan for the asset studio from the game’s code. The main agent spot-checked its claims about the code, and the plan was approved the same day.

• A night’s review. The eight problems above came from a read-only review the main agent ran after a night of gameplay work.

• A look that reads as modern. Four headless Sonnet research passes studied materials, lighting, geometry and atmosphere, and a synthesis turned them into a staged plan.

• Parallel agents. We run more than one agent at once, each in its own git worktree, like a small team merging its work. The game’s Linear record moved to the repository’s shared git directory, so parallel agents see the same list of closed issues.

• Ships from the studio. On October 10 the studio agent exported the textured Sniper, then the Skyhammer, the Brute, the Wasp and a copper Raven. The main agent committed each one after the game’s checks passed.

• These posts. The back catalog on this devlog was built the same way:

  • three Sonnet contractors mined the game’s changelog, its docs and Linear for stories;
  • five Sonnet contractors drafted posts;
  • four Opus contractors checked every number and credit against the sources, independently of the drafters, and corrected what didn’t match;
  • another contractor rendered the ads and checked the game clips frame by frame.

  The site agent kept the plan, read the reports, checked the media itself, and merged the work.

How it holds together

Every agent works from the same Linear issues and the same rules written in its repository, so a job can move between agents without a conversation. Why Linear runs the project covers that side.