One developer has spent four to five months running a small game studio largely through AI agents, software that takes a goal, splits it into tasks and uses tools to finish them. Hand the system a large project spec and the agents work for dozens of hours across code, character art, music and quality testing. The result so far is a Spades card game submitted to Apple for App Store review. The setup was not designed as a grand system on day one. It grew from a single rule in a repository file and one coordinating agent that hands out work.
What an agentic system actually is
An agentic system here has three parts: intelligence, which is the model; rules, which are the instructions and boundaries; and tools, which are the ways the work actually gets done. The wrapper that runs these together is called a harness.
ChatGPT, Codex and Claude Code are already agentic systems. Most people simply use them under rules written by the companies that make them. Writing your own rules changes how you work:
- The habit of prompting, looking at a weak result and re-prompting is treated as last year’s workflow.
- Frontier models released since the summer appear to do better when given an objective rather than line-by-line coding instructions.
- Working by objective requires rules that spell out what the agent may do, what it must never do and how the team works.
The first rule can be tiny. A single line in an AGENTS.md or CLAUDE.md file, such as never pushing straight to production, is enough to start. More rules get added one at a time as they are needed.
Turning a real Mac app into an orchestrated project
One example of the approach is a commercial Mac menu bar app that shows how much of a Claude or OpenAI subscription allowance remains and whether current usage is on pace to run out early. One Git repository holds the Mac app, its landing page, its storefront and its distribution pipeline.
In the Claude Code desktop app, a chat session tied to that repository was told to act as an orchestrator, a lead agent that divides work and tracks progress, rather than as a coder. The instructions asked it to:
- Interpret each request and split the work across sub-agents or separate threads
- Pick a suitable model tier and reasoning effort, meaning how much thinking the model spends, for each task
- Stay free to talk with the human at all times while tasks run in the background
- Report which sub-agents are running, their status and project milestones without being asked
Claude Code accepted the role and laid out how it would assign models:
| Model | Assigned work |
|---|---|
| Haiku | Lookups, renames and mechanical edits |
| Sonnet | Standard implementation, test runs, site and export jobs |
| Opus at high effort | Critical work such as pacing, forecasts, notifications, pricing tiers, licensing and PR reviews |
It also committed to worktree isolation. When several agents edit the same files, each works in its own Git worktree, a separate checkout of the same repository, so their changes do not collide at merge time.
Rules belong in AGENTS.md, not in tool memory
At first, Claude Code saved these operating rules to its own local memory. Memory inside one tool only helps that tool, so the agent was told to move the rules into the repository. It added a nine-line “How we work” section to AGENTS.md and deleted the memory copy. Other coding tools such as Codex can now follow the same rules. When a fresh session was asked whether it was a worker or an orchestrator, the model answered right away that it was the orchestrator, citing the repository rules.
▲ Three tasks running in parallel
Three jobs at once
The orchestrator then got a three-part request: confirm that the build on sale matches the releases in the repository, run the automated test suite, and brainstorm two or three new features. It split the request into three background tasks and showed a live table of agent names, models, effort levels and status.
| Task | Model and effort | Outcome |
|---|---|---|
| Version check | Sonnet, low | Public release 2.3.0 (14) confirmed |
| Test run | Sonnet, medium | 356 tests in 43 suites passed in about 17 seconds including the build, no compiler warnings, build notarized and signed |
| Feature brainstorm | Opus, medium | Three feature proposals |
The brainstorming agent read the project history, rate limits and configuration files in its own thread, and the main chat never froze. It proposed an activity strip covering the past eight weeks of usage, an alert predicting when a session will run out before the five-hour reset, and a breakdown of the heaviest sessions by project. The human picked the activity strip and told the orchestrator to have Opus write a spec first, then hand implementation to Sonnet in an isolated worktree.
Compare that with opening several agent sessions in separate tabs. There is no single view of overall progress, and the human has to choose models and effort levels by hand every time. Opus at medium effort worked well enough for brainstorming, though higher effort seems preferable for architectural roadmaps. If the orchestrator falls back to running tasks one after another instead of in parallel, the fix is to adjust the instructions in AGENTS.md.
Scaling the idea into a game studio
Applied at company scale, the same idea becomes a set of departments, each living in its own folder:
- A department for each game, such as Spades and Cribbage
- Marketing and producer departments
- Shared kits for UI, session management, lobby and core game logic that every game can reuse
The studio also has its own dashboards. One draws the organization as circular diagrams of leads, workers, shared rules and departments. A character tool manages portraits, voice performance profiles and dialogue revisions. An audio tool catalogs music and sound effects and standardizes sample rates and bitrates; one search showed 205 music items, and the sound library holds 949 effect clips. A release dashboard tracks App Store review requirements, screenshots, legal disclosures and marketing material.
A Lab department handles long-running evaluations. It runs on local hardware but can talk to external test benches. The guiding principle is decentralization: long jobs should run on hosted infrastructure instead of depending on one laptop staying awake all day.
The Producer and the Architect
Two roles hold the studio together.
The Producer is the main point of contact for human instructions. It breaks goals into plans, assigns workers and watches the output through a four-stage cycle:
- Interpret and plan
- Staff and start
- Observe and recover
- Evaluate and integrate
On the studio’s kanban board, the Producer juggles parallel requests across design, engineering and marketing, including 14 active request cards for the Spades game, and files follow-ups as it goes.
The Architect is the internal regulator. It checks the health of every department, and when one keeps failing or needs repeated rework, it writes corrective guidance into that department’s rules. When the business grows, for example with a new game or a push into marketing videos and social posting, the Architect creates a new department with clear boundaries. It also collapses departments that are no longer needed to keep the organization lean.
Ten shared rules
Every department inherits ten shared rules: Human Intent, Ownership, Leads and Workers, Real Starts, Quality, Recovery, Durable Work, Hosts and Delivery, Learning, and Whole Scope. They keep departments writing files the same way, communicating through the same conventions and meeting the same quality bar.
The whole structure started with one goal: make a Spades game. A design folder came first, then a Spades code folder, then a separate character library. Once Cribbage and Parcheesi began sharing assets and utilities, the folders grew into the current multi-department studio.
▲ An AI game studio organized by department
Where the human stays in charge
The system is neither fully autonomous nor perfect. The human acts as creative director, putting personal taste into the games and making the decisions about features and user experience. A more common trap may run the other way: assuming AI can only handle small, single-file code snippets and missing how much of a company’s operational work it can take on.
Start with one rule and one orchestrator
There is no need to design a multi-department studio upfront. Complexity should come from real friction in real projects. A sensible starting sequence:
- Add an AGENTS.md or CLAUDE.md file to an existing repository with one prohibition.
- Tell the main chat to act as an orchestrator instead of writing code itself, and have it choose model tier and effort per task: Haiku or low-effort Sonnet for quick checks and tests, high-effort Opus for architecture and ideation.
- Require sub-agents that touch the same files to work in separate worktrees.
- Ask for status as a table showing model, effort and completion.
- Keep operating rules in version-controlled documents in the repository, not in a tool’s private memory.
- Every time an agent stalls or repeats a mistake, turn that lesson into a new rule.
As projects multiply, split shared code into its own modules and consider adding a Producer for instructions and an Architect for system health. One rule in a repository is a modest start, but it is the same start this studio grew from.