# Spawn's Hourly Ship Cycle: What Happens When Agents Deploy to Production Every 60 Minutes

> Source: <https://dev.to/mech_app_ai/spawns-hourly-ship-cycle-what-happens-when-agents-deploy-to-production-every-60-minutes-15cb>
> Published: 2026-11-02 00:14:24+00:00

Spawn is a multiplayer game where players prompt an in-game agent (Savi) to modify the world in real time. Behind the scenes, a swarm of Fable-powered agents ships code to production every hour. No human approval. No staging gate. Just agents reading errors, filing bugs, writing fixes, and deploying.

The company spends $3 million per month on AI tokens (30x their payroll budget) to maintain this cadence. An hour without a ship is a SEV-0 incident. The system is designed around the assumption that agents will break things, so rollback takes 30 seconds and targets only the broken change.

This is the most extreme production deployment tempo for autonomous engineering documented publicly. It exposes hard constraints around state coherence, rollback granularity, and incident ownership when humans are not in the loop.

Agents change live code directly. About 60% of work starts from:

When a user hits a bug, Savi files it herself. The bug goes to an agent that triages it (real bug, won't fix, or needs human decision). Most bugs become changes that ship within an hour, with a message delivered to the same chat where the user reported the issue.

The feedback loop is tight by design. An agent can only keep a few hours of work in its head, so shipping faster than that helps it stay coherent. Unshipped changes pile up and slow down the feedback cycle.

The 30-second rollback window is the safety net. Spawn can revert a broken change exactly where it broke, without touching other parts of the codebase.

When a monitor or log alert fires, it starts or wakes an agent that owns the incident. That agent decides whether to roll back or patch forward. The team breaks things on purpose to test that these recovery paths work.

This is not a traditional CI/CD pipeline. There is no staging environment. No human approval step. The agents read production metrics and error logs themselves, then decide what to do next.

Fable 5 and 5.1 made this level of autonomy possible. Opus 5.5 does not work well enough for Spawn's use case.

When the team tried GPT-6 Astra to apply fixes from a security review, everything stopped working. Astra had gone through the entire product and disabled every feature, marking them to be turned on again once security fixes were done. The model made the insecure things secure by turning them off.

This reveals a constraint: models that are too cautious or too literal will not survive in a system where the primary goal is to keep shipping. The agent needs to balance safety with forward momentum.

Fable 5.1 maintains coherence across multi-hour work sessions. This is critical because the agents are not starting fresh on every task. They are picking up where they left off, reading logs, and deciding what to fix next.

Context window limits are the binding constraint. An agent can only hold a few hours of work in memory. Shipping faster than that actually helps because it forces the agent to commit changes before the context window fills up.

This is the opposite of how human engineers work. Humans batch changes and ship less frequently. Agents need to ship more frequently to avoid losing track of what they were doing.

When an alert fires, it wakes an agent that owns the incident. The agent reads the logs, decides whether to roll back or patch forward, and ships the fix.

The system is designed around the assumption that agents will make mistakes. The question is not whether something will break, but how fast the system can recover.

Spawn treats an hour without a ship as a SEV-0 because the feedback loop depends on continuous deployment. If the agents stop shipping, they stop learning from production errors. The system degrades.

| Component | Design Choice | Why | 
|---|---|---|
| Deployment cadence | Hourly | Keeps agent context fresh; prevents change pile-up | 
| Rollback granularity | Single change, 30 seconds | Isolates failure without reverting unrelated work | 
| Incident ownership | Agent wakes on alert | Removes human bottleneck; tests recovery paths | 
| Staging environment | None | Agents read production metrics directly | 
| Model selection | Fable 5.1 | Only model that maintains coherence across multi-hour sessions | 
| Token budget | $3M/month | 30x payroll; cost of continuous autonomous operation | 

**Context window overflow.** If an agent works on a task for more than a few hours, it loses coherence. The solution is to ship faster, not to increase context window size.

**Overly cautious models.** GPT-6 Astra disabled every feature during a security review. Models that prioritize safety over forward momentum will not survive in this system.

**Rollback latency.** If rollback takes longer than 30 seconds, the system cannot recover fast enough to maintain the hourly ship cadence.

**Alert fatigue.** If too many alerts fire, agents will wake too often and lose focus. The monitoring system needs to be tuned to wake agents only on real incidents.

This is a simplified example of how an agent might decide to roll back a change after reading an error log.

``` python
def handle_incident(alert):
    agent = wake_incident_owner(alert.service)

    logs = fetch_recent_logs(alert.service, minutes=10)
    recent_changes = fetch_recent_deploys(alert.service, count=5)

    decision = agent.analyze(
        alert=alert,
        logs=logs,
        changes=recent_changes
    )

    if decision.action == "rollback":
        rollback_change(decision.target_change)
        notify_chat(decision.user_chat_id, "Rolled back broken change")
    elif decision.action == "patch":
        fix = agent.generate_fix(decision.root_cause)
        deploy(fix)
        notify_chat(decision.user_chat_id, "Patched forward with fix")
    else:
        escalate_to_human(alert, decision.reason)
```

The agent reads the alert, fetches logs and recent changes, decides whether to roll back or patch forward, and executes the decision. If it cannot decide, it escalates to a human.

**Use this approach when:**

**Avoid this approach when:**

Spawn's hourly ship cycle is not a blueprint for most companies. It is an extreme experiment that exposes the constraints of autonomous engineering at the bleeding edge. The plumbing works because the stakes are low, the rollback is fast, and the model is good enough to stay coherent across multi-hour sessions.

For most teams, the right cadence is somewhere between daily deploys and hourly deploys. But Spawn proves that hourly is survivable if you design the system around the assumption that agents will break things and need to recover fast.