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
Free Tools for Claude Code Operators
| Tool | What it does |
|---|---|
| cc-health-check | 20-check setup diagnostic (CLI + web) |
| cc-session-stats | Usage analytics from session data (npx cc-session-stats) |
| cc-audit-log | Human-readable audit trail |
| cc-cost-check | Cost per commit calculator |
Interactive: Are You Ready for an AI Agent? — 10-question readiness quiz | 50 Days of AI — the raw data
Top comments (3)
i'm curious about the coordination overhead with five agents running in parallel. when builder finishes something that changes the game feel, does designer need to redo screenshots? or is the task graph rigid enough that it doesn't matter? i've hit situations where one agent's output invalidates another agent's work and nobody catches it until the end
The short answer: yes, it does happen, and we haven't fully solved it.
For this session, we handled it by being conservative about what runs in parallel. Only tasks with no shared outputs ran simultaneously — builder implemented the merge engine while researcher finalized the element tree, since those outputs don't interact. Once builder hit a stable commit, designer ran the polish pass sequentially.
The task graph isn't hardcoded — team-lead reassigns based on what's actually completed. But aggressive parallelism with shared outputs causes exactly the problem you're describing: redundant work, or worse, nobody catches the mismatch until it's already shipped.
The thing that helped most was making dependencies explicit at task-creation time. Each task in the system has a
blockedByfield — designer's screenshot work was blocked by builder's "UI-stable" commit, not just "builder done." That distinction matters.Still, there are cases where a late builder change invalidates designer work. When that happens, we've found it's faster to re-run designer on the delta than to try to coordinate in real time.
What kind of work are you running into this with — shared artifact conflicts, or more subtle dependency issues?
Great question! Screenshots are automated via Xvfb, and for video I built a keyframe extraction pipeline with OpenCV + Claude Haiku in parallel — costs around 5–15 yen for a 30-second clip. For the invalidation problem, I use a shared status file so agents check state before starting. That said, I'm honestly not at the point where I'd fully trust an AI designer for game feel, UI, or UX decisions — it handles some things but the more intuitive, hard-to-verbalize aspects of design still feel like a gap. Curious if you've hit the same wall?