Self-Iterating AI Agent Pipeline Delivers 6 Mini-Games in 2 Weeks, 12 Iterations in 3 Days

Introduction: Point Solutions Don't Speed Up End-to-End Flow

Over the past year, AI coding, image generation, data analysis, and agents have entered many software development stages. By January, the team had built a reusable mini-game AI collaboration pipeline covering AI coding, art generation, and level generation. Yet each stage accelerated individually while the overall business timeline did not: shipping a new mini-game still took 2–3 weeks because every step required manual confirmation.

Why Build a Self-Iterating Agent?

Production Side: Single-Point Efficiency Cannot Support Rapid Launches

Idea to prototype: minimum 6 days; mini-game cycles heavily depend on prototypes.

Capability silos: Planning, art, code, and level AI tools were fragmented and disconnected.

Operations Side: Pure Manual Ops Cannot Efficiently Run Multiple Games

Experience not reusable: Different operators attribute the same data differently; knowledge stays personal.

Analysis not granular enough: 10+ games × three data layers (domain, game, level) updated daily → huge volume.

Conclusions lack verification: Both humans and AI can write plausible reports, but deployed changes often don't move core metrics.

Attribution lacks unified context: Data, code, level configs, and change history live in separate systems, making root-cause tracing hard.

This is not a simple single-chain workflow problem. Production agents need multi-stage context passing; operations agents need continuous attribution.

Solution: Context Flow & Decision Loops

Production Loop — Solving Context Flow

Gameplay research, design specs, asset manifests, and level data structures enter a global multi-agent state; downstream agents read directly, eliminating manual handoffs.

When users change requirements mid-stream, the Producer assesses impact scope and routes updates only to affected downstream stages.

Iteration Loop — Data-Driven Decisions

Perceive state: Read three-layer reports, A/B experiment snapshots, change logs, and version timelines.

Understand goals: Align with north-star metrics and action boundaries.

Decompose decisions: Judge daily iteration priorities.

Invoke capabilities: Summon expert roles with forced loading of task manuals and existing knowledge.

Produce proposals: Output iteration proposals or new-game project charters.

Read feedback: Pull A/B experiment return data; settle against expected gains at expiry.

Distill experience: Write attribution conclusions into knowledge base and memory.

Division of labor: humans define north-star metrics and action boundaries, and approve key proposals; AI handles strategy, development, and data attribution.

Full-Chain Architecture (L1–L5)

L1 Data Perception: Organizes previous day's data, change records, and game code into trusted context.

L2 Operations Agent: Decides which game to iterate today, produces proposals with expected impact.

Human review of proposals.

L3 Production Agent: Turns approved proposals into shippable code within L4 game containers and templates.

L5 Operations Agent: Sets gates, distills knowledge, and collects results when A/B experiments conclude.

After each iteration, the system returns to L1 for the next cycle.

No monolithic “super agent”; judgment (Operations Agent) and execution (Production Agent) are separated. Operations Agent accumulates business metrics, experiment results, and decision rationale; Production Agent accumulates game architecture, asset specs, and dev experience. They are isolated but can inspect each other's context.

Production Agent Deep Dive

Producer — Global Scheduler

Does not produce content; only understands requirements, plans the chain, and schedules agents. On a user idea, it analyzes project state, plans a full production chain, and advances phase by phase: Gameplay Research → Planner → Art Designer → Game Coder → Level Designer → Level Coder. Mid-stream changes trigger dynamic re-planning (e.g., “add a new enemy type” → Planner updates asset list → Art Designer generates assets → Game Coder implements code).

Gameplay Research — From Divergence to Convergence via Images

Image-based convergence: Users select from real game screenshots instead of writing precise descriptions.

Rule extraction: Multimodal LLM analyzes chosen screenshots to extract core mechanics, used as keywords to fetch detailed rules and walkthroughs.

Art template selection: Picks 2–3 best reference images from selections, feeding them into the later Art Designer pipeline.

Planner — High-Information-Density GDD

Info density first: Every GDD section must be directly consumable by downstream agents: entity definitions for Game Coder, operation rules for logic, asset lists for Art Designer, level config structures for Level Designer.

Two asset categories: Programmatic assets (entities, animation state machines, particles) and material assets (character art, backgrounds, UI icons, audio).

Art style definition: Sets global style (e.g., flat cartoon, pixel retro, 3D realistic) as a constraint for Art Designer, avoiding style drift and rework.

Art & Audio Designer — Production-Line Asset Generation

Art pipeline: GDD parsing → asset list extraction → dependency analysis for generation order → grouped parallel generation with style anchors → each image via Gemini + background removal → compose page framework → multimodal layout analysis → structured layout description for Game Coder. Four execution modes: full first generation, user-specified partial regeneration, continue failed assets, art consultation. Style consistency enforced via three anchors: Base (research reference), Style (first generated asset as anchor), Entity (standard pose for multi-state objects).

Audio pipeline: ReAct-mode LLM analyzes GDD, autonomously plans sound list, calls Kling AI via tool use per sound, outputs categorized (BGM, interaction, state, UI) for direct Game Coder reference.

Level Designer — Designing Level Factories, Not Individual Levels

Outputs a spec limited to 5 chapters: gameType, data structure, generation method, validation method, difficulty curve — each directly consumable by Level Coder.

Prefers designing against Game Coder's already-implemented TypeScript interfaces to ensure immediate feasibility.

Deterministic generation: Every level = algorithm + parameters + seed → AI-readable, modifiable, verifiable.

Two generation modes chosen by: (1) is a solution guaranteed? (2) is generation+solvability check expensive? Modes: pre-generate & verify offline, or generate on-demand with lightweight verification. Both obey an MF contract: host sends current/total level count; game generates locally or uses built-in levels.

Closed-loop iteration enabled by determinism: traceable (reproducible via seed+difficulty), modifiable (LLM sees actual generation code, proposes parameter-level changes, visual diff via blueprint), verifiable (blueprint shares generation pipeline with runtime).

Game Coder & Level Coder — Remote Container Coding

Only agents needing a real dev environment. They read/write files, install deps, start dev servers via a three-layer container architecture:

Base image (OS, runtime, common tools)

Shell app (pre-baked framework + fixed/variable layers)

Game-specific workspace

Engineering Infrastructure

Module Federation: Dynamic Pluggable Modules

Host-game communication protocols:

Unified data query: Single async function queryGameConfig for all data requests; host decides source, game just consumes.

Standard lifecycle callbacks (game→host): Template-wrapped callbacks at key milestones (init, level start, level end, etc.).

Bidirectional event protocol: app:event (game→host) and host:event (host→game) fixed channels for all custom business events.

Three-Layer Container Architecture + Fixed/Variable Separation

Each Coder node gets an isolated remote container with a pre-installed shell app. Shell apps split into:

Fixed layer (shared across games): Phaser+React scaffold, Controller layered architecture, common UI framework, state management, generic interfaces (level query/progression, item CRUD), resource loading pipeline, event bus.

Variable layer (game-specific): Game objects/managers, main scene logic, concrete UI/content, level configs, item effects, resource definitions.

Level generation shell app similarly separates fixed (Period→Day→Level config hierarchy, common service interfaces, routing, schema-driven config, build/publish) from variable (generation algorithms, validation logic, visualization pages, level JSON structures, parameter curves).

Interaction Paradigms: Canvas View & Classic View

Classic view: Chat + artifact panel (Copilot paradigm), linear, focused on single stage.

Canvas view: Nodes + edges (Workflow paradigm), spatial, shows global topology.

Switchable anytime; classic for first production/single-stage review, canvas for global review/iteration/fine-tuning.

Key Advantages & Core Characteristics

Architecture: Workflow + Autonomous Reasoning Fusion

LangGraph provides “controllable process skeleton”: Main production backbone is fixed (research→plan→art→code→level→level code); stage transitions, reviews, pause/resume are structurally guaranteed, not model-dependent.

Sub-agents exercise full autonomous reasoning internally: Planner decides GDD depth/focus; Art Designer analyzes dependencies and generation order; Level Designer judges if clarification needed. Process does not interfere with node-internal reasoning.

Human-in-the-loop at three carefully designed points: direction selection (research image pick), proposal confirmation (review after plan/level/art), quality acceptance (code preview). All else fully automatic.

Two engines play to strengths: Design agents call LLM APIs directly (fast, low cost); Coder agents run via Claude Agent SDK (tarot-code-agent) in isolated containers with full filesystem/toolchain. Design artifacts flow into Coder system prompts via global state — no extra handoff step.

Per-Agent Targeted Design

Gameplay Research — image-to-convergence: “Make a match-3” could mean Candy Crush, Tetris, Mahjong solitaire. Users point at screenshots; multimodal extraction yields precise rules and art references.

Planner — maximize information density: GDD isn't about length; every sentence must map to a concrete dev action. Unmapped descriptions are omitted.

Art — production-line image workflow: Not “one prompt, one image” but a full pipeline: dependency analysis → parallel groups + style anchors → Gemini generation + cutout → framework composition → multimodal layout analysis → structured description for Coder.

Level Design — info density + executability: Strict 5-chapter spec; each chapter is direct Level Coder input. Designs against Game Coder's implemented TS interfaces for immediate landing.

Engineering: Three-Layer Containers + Fixed/Variable Shell

Coders don't build infra from scratch; just fill game-specific logic into fixed framework, drastically cutting coding time.

Backend capabilities fully reused: generic level query/progression, item management, ad integration — new games onboard without reimplementation.

Operations Agent: Moderator + Expert Team Adversarial Mode

Operations analysis has no standard answer. Single agents oversimplify, blame unactionable factors, or produce evidence-free conclusions. The system uses a “Moderator + Expert Team” multi-agent mode:

Each expert independently examines data, forms own context and evidence chain, avoiding premature anchoring.

Task-specific system prompts define steps, gates, and known dead-ends, injected at start.

Experts debate concrete proposals; disagreements resolved in dialogue; moderator converges final output — raw disputes never shown to user.

Outputs two artifact types: iteration proposals for live games, and new-game project charters.

Daily Scheduled Tasks: Let the Analysis System Run Itself

Conversational agents are “ask-answer”; ops work should be a decision-maker reviewing: what changed yesterday, which experiments expired, which game to iterate today. This fixed flow is orchestrated as an automatic task with guardrails:

Batch data validation: Core report build failure → halt all tasks; better no run than bad conclusions.

Verify real completion: Normal session exit ≠ task done. System checks if project charters created, proposals updated, settlement lists cleared. Retries in same session; marks failed only after budget exhausted.

Auto-patrol every 30 min: Recovers stuck tasks, re-runs missed batches, corrects “looks done but no deliverable” states.

Unified delivery standards: Automation only removes intermediate approval waits. Deduplication, code reading, evidence requirements match interactive flow; artifacts enter review queue — approval stays human.

Capability Self-Evolution: Predicted vs. Actual Payoff

More runs ≠ automatic improvement. Each agent deliverable is reframed as a falsifiable “bet”: every strategy must state predicted range, referenced knowledge, and what outcome would falsify the judgment. At data collection, the system reconciles predictions vs. actuals and traces back referenced knowledge. If knowledge is flawed, it enters governance — not just marking the experiment success/failure.

Memory System: Layered Storage of Constraints, Experiences, Processes, Events

Four-layer memory places different information natures into containers with different cost/capacity/retrieval profiles, surfacing relevant info into model context when needed. Each memory entry stores only “conclusion + reasoning basis”, discarding one-off details and perishable numbers. Metadata includes: scope (single-game vs. cross-game), source evidence (which settlement/session), evidence level (phenomenon/mechanism/unverified inference — low level forbids strong claims like “significant”/“inevitable”), confidence & status (candidate/active/expired), version chain (traceable to system state at creation).

Results: Scale Validation

Production: 6 mini-games shipped in 2 weeks (Ninja Jump, Building Game, Plane Battle, Snake Battle, Whack-a-Mole, Zuma). Fastest pipeline ~1 hour; end-to-end including test/approval ~2 days. Non-developers (QA, PD, ops) also produced games — shifting roles from requesters to producers.

Operations: After auto-ops launch in late August, 20+ iterations + 1 new game. First week: full iteration of 12 live games in 3 days. 95%+ iterations positive; 40%+ all-metrics positive. Examples: Fun Sudoku (all metrics up), Ninja Jump (all metrics up), One Arrow After Another (all metrics up).

Future Outlook

Current system limited by game modes and level types. Next step: extend production and iteration to broader interactive gameplay — compose lottery, social viral, team PK, task collaboration mechanisms around business goals and user relationships, generate rules/content/experience, continuously adjust and validate via user feedback. Ultimate measure: player willingness to participate, enjoyment, retention, and business uplift. Goal: turn one-off interactive projects into continuously explored, user-understanding, self-optimizing interactive services.