At some point, PLAYGRND stopped feeling like a side project and started behaving like a small software company.
There was the main web product, a Go API, PostgreSQL, a mobile app, AI features, design work, social content, sales material, legal questions, competitor research, a pitch site, production infrastructure, and a growing list of ideas that all looked important for different reasons.
Trying to carry all of that inside one long AI conversation produced a predictable result.
The context became huge. Product decisions mixed with implementation details. Design feedback disappeared under database work. A task that began with a button could end with deployment logs, a legal question, and half a roadmap attached to it.
So I stopped treating Codex as one very large assistant.
I split PLAYGRND into twelve specialist threads and put a Product Manager thread in charge of orchestration.
That sentence sounds more futuristic than the reality. These are not twelve employees. They do not wake up, understand the whole company, or carry responsibility when something goes wrong.
They are twelve carefully bounded working contexts.
The interesting part is not the number of agents. It is the organization around them.
Why one giant thread stopped working
A long AI thread feels productive because it remembers everything.
Until it remembers too much.
Every additional topic adds context that the next decision has to compete with. Old assumptions remain nearby even after the product changes. A coding task carries weeks of irrelevant product discussion. A design review inherits implementation details it does not need. Eventually the thread spends more effort locating the current truth than doing the work.
This is the same problem I wrote about in I Think in Compressed Models. A useful working model must remove information. The difficult part is deciding which information belongs together.
My first improvement was not a better prompt.
It was an org chart.
The twelve PLAYGRND threads
Each thread owns one recurring type of work. The borders are not perfect, but they are explicit enough that a task has a natural home.
- PM: the control tower. It turns ideas into outcomes, orders the work, assigns ownership, defines acceptance criteria, checks dependencies, and decides when another specialist should start. It does not quietly become the developer, designer, or lawyer.
- Dev: the main product builder. API contracts, database changes, server-rendered pages, tests, deployment, and the unglamorous work required to make a feature survive production live here.
- Design: visual hierarchy, interaction quality, responsive behavior, shared components, and screenshot-led QA. Keeping it separate prevents design from becoming the final ten minutes of an engineering task.
- AI: intent routing, model behavior, deterministic executors, evaluations, fallbacks, cost controls, and the boundary between probabilistic output and reliable product behavior. AI needs a different definition of "working" than a normal endpoint.
- Mobile: the iOS and Android product surface. It shares a product with the web app, but device permissions, deep links, signed builds, stores, push notifications, and physical-device testing create a separate delivery reality.
- Termini: a focused product stream for organizing recurring football sessions. It has its own users, pilot feedback, attendance logic, and operational questions, so treating it as one random feature inside Dev would erase useful context.
- Social: public content, visual assets, captions, campaign manifests, and publishing checks. Its output is not code, but it still needs ownership, review, versioning, and an explicit public-action gate.
- Sales: organizer conversations, pilots, offers, and the path from interest to an actual customer. This thread keeps commercial assumptions visible instead of hiding them inside the product roadmap.
- Audit: the deliberately difficult colleague. It reviews risky work, searches for missing failure modes, and is allowed to return a clean NO-GO. It does not earn points for being agreeable.
- Legal: privacy, consent, retention, data ownership, terms, and regulatory boundaries. Legal questions are separated because a developer should not accidentally convert a convenient implementation into a compliance decision.
- Competitors: market and product reality checks. It looks at alternatives, patterns, and positioning without turning the roadmap into a copy of somebody else's product.
- Pitch: the external narrative. Investor and organizer materials, verified product proof, PDFs, web presentations, and claim discipline live here. The product can move daily; the pitch must never quietly turn an old estimate into a current fact.
Twelve threads may sound excessive for one person building one product.
For me, it is the opposite. The separation reduces how much of the product I need to hold in active memory at once.
The PM thread is not the boss
The PM thread does not make the final product decisions.
I do.
Its job is to make the current state legible enough that I can make those decisions without rereading twelve histories.
It watches the specialist streams, separates shipped facts from roadmap ideas, sees which work is waiting for my QA, and recommends one next slice. When I throw five new ideas into the conversation, it does not immediately dispatch five builders. It turns the ideas into product contracts, challenges ambiguous parts, places them behind current priorities, and tells me what should happen first.
The PM thread also protects ownership.
If Design owns an active interface change, PM does not stage its files or ask Dev to "just finish it." If AI is validating a model-backed result, PM does not describe the feature as shipped because a commit exists. If Social has uncommitted source assets, another thread is not allowed to clean them up because the repository looks untidy.
Coordination is mostly the work of preventing helpful agents from helping in the wrong place.
One build slot, one adversarial reviewer
A recent PLAYGRND cycle is a good example of how the system now works.
Design was finishing a small product surface. PM let it complete the slice, validate it, deploy it, and write a handover before opening the main build slot.
Only then did Dev begin a live match operations feature.
Audit started in parallel, but as a read-only risk gate rather than a second developer. Its job was to attack the contract while Dev built it. It looked at authorization, interrupted connectivity, concurrent actions, recovery, and the gap between a successful demo and a system somebody can safely operate during a real match.
The first Audit result was NO-GO.
That was not a failed orchestration cycle. That was the system working.
The review found classes of failure that are easy to miss when the same context invents, implements, and approves the solution. Dev received bounded findings, fixed the underlying protocol, and had to produce evidence before production could become an option.
Meanwhile, PM kept the next attractive feature behind the current one. More available AI capacity did not create permission to run every idea at once.
Handovers are the API between contexts
Long-running specialist threads eventually become heavy too.
I rotate them into episodes.
A Design thread may become Design E08, then E09. Dev has its own sequence. AI, PM, Mobile, Pitch, and the other roles keep independent histories because their context grows at different speeds.
Before a thread rotates, it writes a structured handover containing:
- the current product and repository state;
- what is actually shipped and what is only planned;
- important decisions that must not regress;
- tests and production evidence that were really observed;
- unfinished work and known failure modes;
- one recommended next small step;
- a clean starting prompt for the next episode.
I think of the handover as an API between contexts.
It should be small enough to consume, strict enough to preserve the contract, and honest about what it does not know.
Git hygiene became an organizational rule
Parallel AI work becomes much less impressive when two threads edit the same file and one of them commits the other's unfinished work.
I learned to treat repository hygiene as part of orchestration, not cleanup after the real work.
Every modified path needs an owner. Every temporary worktree needs a reason to exist and a condition for removal. Before a task hands work back, its scope must be committed, safely removed, or deliberately classified as reproducible local output. One role cannot delete another role's files just to produce an empty status.
This sounds boring because it is boring.
It is also what makes parallel work trustworthy.
The queue, the repository, and reality
The setup has several different sources of truth because they answer different questions.
- The shared queue says who owns the current work and whether it is active, waiting for review, or complete.
- The repository and product documents say what the system is intended to do and what code currently exists.
- Deployment evidence says what actually reached production.
- The public product says what a user can really experience.
- I remain the final product and QA gate.
A commit is not a deploy. A deploy is not user acceptance. A document is not a feature. An AI thread saying "done" is not proof that anything is done.
The PM thread is valuable because it keeps those states separate.
What the numbers look like
I recently ran a health audit across all twelve PLAYGRND role threads.
At that snapshot they contained 45 top-level turns, 1,141 transcript and tool items, and 16 explicit context compactions. None had reached the extreme zone. One Design episode was considered context-heavy and was rotated after its active slice. Four threads were in a medium range. The remaining seven were still light.
Those are not lifetime token numbers. I do not have one trustworthy, comparable token total across the whole setup, so I will not invent one for a better headline.
I did move to the 20x Codex subscription.
The useful part is not making one agent think twenty times harder. It is having enough capacity to keep several bounded specialists available without treating every prompt like a scarce resource.
But the subscription only provides throughput.
Without ownership, sequencing, handovers, review gates, and clean repository state, twenty times more capacity can create twenty times more confusion.
This is not a twelve-person company
It would be dishonest to describe these threads as twelve employees.
They do not build relationships with league organizers. They do not stand beside me during a real pilot. They do not carry taste, responsibility, or the consequences of a bad decision. They can preserve context and challenge assumptions, but I still have to decide what matters.
What they change is the surface area one person can seriously explore.
I can move from product strategy to a database contract, ask an adversarial reviewer to attack it, refine the mobile implications, prepare a public explanation, and keep each conversation focused enough to remain useful.
That is more than autocomplete.
It is an operating layer around my attention.
The real scaling trick is boundaries
I started this because PLAYGRND had too many different kinds of work for one thread.
I expected the main benefit to be parallel execution.
The bigger benefit is better disagreement.
Design can protect the interface from engineering convenience. Audit can stop a feature that looks finished. Legal can keep a product shortcut from becoming a silent policy. Sales can expose whether an elegant roadmap has any path to a customer. PM can say that a good idea is still not the next idea.
The AI does not become more useful because I gave it more freedom.
It becomes more useful because I gave each context a smaller job, a clear exit, and another context allowed to question it.
That is how I currently run PLAYGRND: twelve threads, one orchestrator, one shared product, and one human who still has to own the result.