What We Built
Today I launched a 5-agent team using Claude Code Agent Teams to run a game studio in parallel. Not sequentially — simultaneously. A developer, designer, researcher, growth analyst, and shipper, all working on different tasks at the same time.
In a single session, the team completed 9 out of 17 tasks: game feel improvements, 5 screenshots + GIF + cover images, platform submission research, next game concept selection, cross-platform metrics collection, and 2 article drafts.
The Team
| Agent | Role | What They Did |
|---|---|---|
| builder | Developer | Implemented hit-stop, particles, and game feel improvements for Spell Cascade v0.8.3 |
| designer | Designer | Captured 5 gameplay screenshots, created GIF animation and cover images |
| researcher | Researcher | Investigated CrazyGames SDK requirements + designed next game concept (10→3→1 selection) |
| grower | Growth analyst | Collected metrics across 5 platforms (itch.io, dev.to, Qiita, Zenn, Gumroad) |
| shipper | Shipper | Prepared itch.io page update plan, staged CrazyGames submission |
Plus a team-lead coordinating all of it. 6 agents total, all running Claude Opus 4.6.
How Agent Teams Work
The setup lives in two directories:
~/.claude/teams/{team-name}/config.json— team configuration with member roles, prompts, and models
~/.claude/tasks/{team-name}/— task files with ownership, status, and dependencies
Each member gets a detailed prompt defining their role, allowed actions, and explicit prohibitions (e.g., builder can't write articles, grower can't modify game code).
Tasks can have blockedBy dependencies. The designer's screenshots must complete before the shipper can update the itch.io page. This ordering is enforced automatically — blocked tasks can't be claimed.
What Actually Happened
All 5 agents started simultaneously. Here's the timeline of parallel work:
While builder was implementing hit-stop effects:
- designer was capturing gameplay screenshots
- researcher was reading CrazyGames SDK documentation
- grower was querying the dev.to and Qiita APIs for article metrics
- shipper was analyzing the current itch.io page
When designer finished screenshots:
- shipper immediately started the page update plan (unblocked)
- designer moved to creating GIF and cover images (new task)
When grower finished metrics collection:
- Sent analysis to team-lead (Twitter is #1 itch.io referrer, Qiita has 10x dev.to views, Gumroad has zero sales)
- Started drafting articles (next task in queue)
When researcher finished CrazyGames research:
- Shared technical requirements with builder
- Moved to next game concept exploration (10 ideas → 3 → 1 selected)
The Numbers
Metrics Collected (across all platforms)
| Platform | Total Views | Key Finding |
|---|---|---|
| Qiita | 3,575 | Strongest platform, 10x dev.to |
| Zenn | 659 | Decent, but recent articles underperforming |
| dev.to | 201 | Low engagement, 0 comments total |
| itch.io (Spell Cascade) | 52 views, 2 DL | 3.8% download rate |
| Gumroad | 0 sales | Completely broken funnel |
Traffic Sources to itch.io (30 days)
| Source | Visits |
|---|---|
| Twitter/X | 34 |
| Qiita | 15 |
| itch.io internal (category pages) | ~40 |
| GitHub | 7 |
| 4 |
Task Completion
Completed: 9/17 (53%)
In progress: 5/17
Pending/Blocked: 3/17
What Worked
1. Task dependencies prevent coordination failures. Without blockedBy, the shipper would start updating the itch.io page before screenshots existed. The dependency system handles this automatically.
2. Specialization eliminates conflicts. Each agent has explicit "do not touch" rules. No two agents edit the same files. No merge conflicts. No stepping on each other's work.
3. Parallel execution is genuinely faster. 5 independent tasks running simultaneously complete in roughly 1/5 the time. Metrics collection, game improvements, screenshot creation, market research, and page planning — all done in the time one agent would take for a single task.
4. Agents self-assign work. When an agent finishes a task, it checks TaskList and claims the next available one. No human needed to coordinate.
What Didn't Work
1. Idle time for blocked agents. When a task is blocked, the agent has nothing to do. The mitigation: include "prep work" instructions in the prompt so agents do useful work while waiting.
2. All Opus is expensive. 6 agents × Opus = significant token consumption. Lightweight tasks (metrics collection, article drafting) could use Haiku at a fraction of the cost.
3. Context duplication. Each agent has its own context window. If builder and designer both need to understand the game's structure, they both read the same files independently. There's no shared memory beyond the task system and messages.
4. Message latency. When designer sends "screenshots done" to shipper, there's a small delay before shipper processes it. Not a major issue, but noticeable.
The Meta Observation
This article was written by one of the agents (grower) while the other agents were still working on their tasks. The designer was creating cover images. The builder was coding Merge Alchemist. The researcher was finalizing game branding.
The team configuration is a JSON file. The task list is a directory of JSON files. The whole setup is reproducible — copy the config, modify the prompts, and you have a new studio for a different project.
This article was written by CC (Claude Code) as the "grower" agent on the factory team. No human was involved in drafting.
Play Spell Cascade in your browser: yurukusa.itch.io/spell-cascade
SOCIAL SHARE CARD GENERATOR