Agentic AI Needed a Producer. It Got One by Accident.
The Q→O→D→D→A protocol in Claude Code Game Studios is the governance layer the industry keeps forgetting to build
Claude Code Game Studios encodes a five-step collaboration protocol into every agent interaction: Question, Options, Decision, Draft, Approval
This is not a code safety mechanism. It is a production discipline, and the distinction matters more than the repo’s 16,000 stars suggest
The producer agent in the system is explicitly forbidden from making decisions. Its job is to quantify scope and surface trade-offs. That is textbook producer behaviour
Producers have been running this protocol by hand for thirty years. The question is why it took this long for someone to write it into an AI system
A few days ago I wrote about Claude Code Game Studios, a GitHub repo that appeared last week with 49 specialised AI subagents, 73 workflow skills, and a studio hierarchy that mirrors real game development. I spent most of that piece on where the architecture falls short: the context window, the false independence of parallel reviewers, the markdown-as-institutional-memory problem. All of that stands.
What I didn’t have room to say is that the repo accidentally got something right that almost nobody in agentic AI is getting right. And the reason it got it right is that it was thinking like a producer without knowing that’s what it was doing.
The protocol
Buried in the repo’s docs/COLLABORATIVE-DESIGN-PRINCIPLE.md is a five-step workflow that every agent must follow on every interaction:
Question. Options. Decision. Draft. Approval.
The agent asks clarifying questions before proposing anything. It presents two to four options with reasoning and trade-offs. The human decides. The agent drafts based on that decision. Nothing goes to file without explicit sign-off.
It is worth noting the structural similarity to John Boyd's OODA loop, the decision framework developed for fighter pilots: Observe, Orient, Decide, Act. The parallel is real, but the difference is the point. OODA assumes the observer and the decision-maker are the same person, moving fast under pressure. Q→O→D→D→A splits them deliberately. The agent observes, researches, and generates options. The human decides. That separation is not a limitation of the system. It is the system. Boyd was designing for a solo pilot in a cockpit. This protocol is designed for a producer with a team.
The README makes the principle explicit: “you still make every decision.” The CLAUDE.md configuration reinforces it: “Agents MUST ask ‘May I write this to [filepath]?’ before using Write/Edit tools.” This is not a suggestion. It is a constitutional constraint baked into every agent definition in the system.
Most people reading the repo are treating this as a cautious engineering choice. It is not. The repo has plenty of those: automated checks that run on every commit, rules that block dangerous commands, validation scripts that fire whenever an asset gets changed. Those are developer instincts applied to agent behaviour, and they are sensible. The Q→O→D→D→A protocol is doing something different. It is not preventing bad code. It is preventing bad decisions from being made by the wrong party.
That is a production instinct.
The tell
The producer agent in the CCGS system has a specific, hard-coded constraint that reveals everything about where this thinking came from.
It is forbidden from making design decisions. It is forbidden from making technical decisions. Its job, as written in the agent spec, is to “quantify the production impact in concrete terms” and “surface the conflict to the user with the scope implications clearly stated.” When the creative director and technical director disagree, the producer does not pick a side. It calculates how many sprints the disagreement will cost and puts the trade-off in front of the human.
The producer does not resolve conflicts. It prices them.
If you have worked in production, that sentence will land immediately. If you have not, it might read as a limitation. It is the opposite. The moment a producer starts resolving creative or technical conflicts instead of surfacing them, they have stopped being a producer and started being a bottleneck with a title. The CCGS producer agent is correct about its own role in a way that most descriptions of the producer role get wrong.
A developer who worried about AI agents going off-script would build automated validation. CCGS has that too, and it is clearly developer-authored. But a developer worried about AI agents going off-script would not think to write a rule that says “do not make the decision, price the decision and give it back to the human.” That is thirty years of production instinct encoded in a markdown file.
What happens when you skip it
I follow something close to Q→O→D→D→A in my own Claude Code work, mostly by habit. I ask before I let it write. I push for options before I commit to a direction. I approve file writes explicitly.
I did not always do this, and I have paid for the gaps.
The worst version of skipping the protocol is not an agent that writes the wrong file. It is an agent that confidently continues from stale context. In one session, old data crept in without my noticing. The agent had picked up assumptions from an earlier state of the project and started elaborating on them. By the time I caught it, those assumptions had propagated through several connected decisions. The cost was not just undoing the work. It was unpicking the scope implications, identifying everything the stale assumption had touched, and re-running the reasoning from the point where the corruption entered.
That is a familiar failure mode for any producer. It is what happens when a decision gets made in the wrong room, or by the wrong person, and nobody catches it until three sprints later when the dependencies start complaining. The Q→O→D→D→A protocol exists precisely to stop that from happening. The Question phase is the checkpoint where stale assumptions get caught. Skip it, and you are running without gates.
The question phase is the checkpoint where stale assumptions get caught. Skip it, and you are running without gates.
The autonomy narrative in agentic AI treats human checkpoints as friction to be eliminated. More speed, fewer interruptions, less oversight. The problem is that the checkpoints are not slowing the work down. They are the mechanism by which the work stays aligned with what the human actually wants. Remove them, and you get faster output and worse decisions.
Why this is a producer problem
The industry arrived at agentic AI from the developer side. When everything looks like a nail, the hammer is autonomy: how much can the agent do without asking, how far can it run before it needs a human. The Q→O→D→D→A protocol comes from a different trade entirely. The question it is answering is not how to reduce human input. It is how to protect the decisions that matter while still letting the agent handle the execution.
Producers have been thinking about that question since before AI was in the room. The whole job is managing the boundary between what the team executes and what the human with authority over the product decides. A producer who can answer the question “who approved this?” at any point in production is doing their job. A producer who cannot is not.
CCGS encodes that accountability in its agent architecture. Every write requires approval. Every direction change goes through a decision step. The --review solo flag that turns off director gates for a game jam is the production equivalent of “we’re in crunch, skip the full review, get it done.” The review intensity modes, full versus lean versus solo, are a recognition that the overhead of governance scales with the stakes of the work. That is not a developer’s model. Developers tend to want consistent standards regardless of context. Producers live in the trade-off space.
The implication is uncomfortable for a field that has mostly thought of producers as project managers with Jira access. If the most sophisticated agentic AI system currently available for game development had to solve its core governance problem by reaching for production thinking, then production thinking is not a soft skill adjacent to the real work. It is the architecture.
What this means now
The CCGS repo has over 16,000 stars. The discussion in its wake, on GitHub, on LinkedIn, in the AI newsletters that picked it up, is almost entirely about the technical achievement: 49 agents, 73 skills, three engine specialist sets. The Q→O→D→D→A protocol gets mentioned as a feature of the collaboration model. It is not a feature. It is the load-bearing wall.
Remove the protocol, and what you have is a collection of well-named agents that will confidently produce output based on whatever they last understood about your project. That is a faster way to build the wrong thing. The protocol is what makes the structure meaningful rather than decorative.
For producers moving into agentic AI workflows, the lesson is not that CCGS is the right system to use. I went into the structural limitations of the current implementation in detail in a recent piece. The lesson is that the governance layer, the thing that determines who decides what and when, is not secondary to the agent design. It is the agent design. The engineers will build the capability. The producers are the ones who know how to build the constraint.
That combination is what the current moment actually needs.
This is basically the missing operating system for agentic AI