PLAYGRND has a public web product, a backend, mobile clients, AI workflows, competition data, design work, operations, content, commercial questions and a growing list of decisions that have to remain consistent.

Putting all of that into one long AI conversation sounds efficient. In practice, it creates a new bottleneck: every task carries every other task’s history, ownership becomes unclear and a useful answer can still collide with work happening elsewhere.

We currently organise the project through 12 persistent Codex threads. Each thread holds the context for one role. A separate PM thread orchestrates their order and dependencies.

These are not twelve employees and they are not twelve autonomous systems making unsupervised product decisions. They are supervised workspaces with different responsibilities, working against the same repository, product documentation and acceptance process. HILLS Lab remains responsible for priorities, review and release decisions.

The twelve roles

The split follows durable ownership rather than individual features.

  • PM maintains the current product picture, orders work, resolves dependencies and decides which specialist should receive the next bounded task.
  • Dev owns core implementation across the backend, database and server-rendered web product.
  • Design refines the public and signed-in experience on desktop and mobile without silently changing product rules.
  • AI owns assistant behaviour, deterministic actions, evaluation and the boundary between a generated proposal and an accepted change.
  • Mobile protects the iOS and Android contract, release compatibility and device-specific behaviour.
  • Termini handles schedule and competition-onboarding work where source quality, dates and canonical records matter.
  • Social turns verified product material into public content without inventing features or results.
  • Sales works on offers, qualification and the commercial path around what the product can actually deliver.
  • Audit independently tests risky assumptions, failure modes and acceptance evidence before a release is called safe.
  • Legal identifies privacy, claims, permissions and contractual questions that require careful product treatment or qualified legal review.
  • Competitors studies public products and market movement to sharpen positioning, without copying proprietary code, data or design.
  • Pitch maintains a coherent external narrative based on shipped facts and clearly labelled product direction.

The value of the split is not that every role is busy all the time. Most should be idle until their context is useful. A permanent role is a prepared lane, not a target for maximum activity.

The PM thread plays midfield

The PM thread is the control tower, but football gives us the better metaphor: it plays midfield.

It sees enough of the whole pitch to choose the next pass. It does not take every shot.

A normal orchestration loop looks like this:

  1. Read the current repository state, open product decisions and specialist handovers.
  2. Separate what is live from what is planned and what is still waiting for human QA.
  3. Select the smallest valuable slice and assign one clear owner.
  4. Keep other build work paused if it would collide with the same files, schema or release.
  5. Route specialist findings back to the owner. An Audit finding, for example, becomes a Dev acceptance condition rather than a second implementation.
  6. Require tests, a clean source state and production evidence before calling the slice shipped.
  7. Return the final product and QA decision to a person.

This distinction matters. An orchestrator that implements every task eventually becomes another oversized thread. Our PM thread coordinates ownership; it does not absorb specialist queues.

One repository still needs one truth

Parallel AI work does not remove the ordinary constraints of software engineering. Two capable threads can still edit the same file, assume different schema states or describe an unfinished feature as live.

We therefore treat the repository as the canonical technical state. Before a new slice starts, the PM checks which work is active, which changes belong to another role and whether a separate worktree is still in use. Existing uncommitted work is preserved, not cleaned away for convenience.

The same discipline applies after implementation. A commit is evidence that code exists. It is not evidence that a deployment completed, a migration ran correctly or the public route behaves as expected. Those claims need their own checks.

This sounds procedural until two workstreams meet in the same migration or release. Then it is the difference between parallelism and a race condition.

Handovers are part of the architecture

Long-running threads accumulate decisions, failed paths, tool output and old assumptions. Eventually the useful context becomes harder to retrieve than the total context is to store.

We handle that with episodes. When a role thread becomes too dense, it writes a compact handover containing:

  • the current verified state;
  • work that is still in progress;
  • decisions that must not be reopened without new evidence;
  • files or product boundaries owned by another stream;
  • the smallest safe next step.

A fresh episode starts from that handover and the live repository. The full history remains available, but it no longer has to sit in the active working set.

This is context engineering in a practical form. The goal is not to preserve every sentence in the prompt. It is to preserve the decisions and evidence required for the next correct action.

A snapshot, without invented token maths

In one exact health snapshot across the 12 current role threads, we counted 45 API-level turns, 1,141 recorded history items and 16 context compactions. Seven threads were in the low-load range, four in medium, one in high and none in extreme.

Those numbers describe workflow shape, not productivity. One short Audit turn can prevent days of repair. A long Design thread may simply be ready for a clean handover.

We do not publish an estimated token total because compacted and truncated histories do not provide a trustworthy billing-token reconstruction. A precise-looking guess would be less useful than the counts we can verify.

For this work we use a 20x Codex subscription tier. The additional capacity is useful because specialised contexts can remain available while bounded work runs frequently. It does not provide the orchestration. More capacity without ownership, sequencing and release gates would only produce conflicts faster.

Where the human judgment stays

The system deliberately keeps several decisions outside automatic execution:

  • which problem is worth solving now;
  • whether a product trade-off is acceptable;
  • whether legal or privacy questions need qualified review;
  • whether evidence is strong enough to describe a feature as shipped;
  • whether the result is good enough for users.

Legal and competitive research threads are support functions, not shortcuts around professional advice, licences or source boundaries. Audit can expose a risk; it cannot redefine the company’s risk tolerance. PM can propose the next slice; it does not own the final product call.

That boundary makes the workflow more useful, not less automated. Codex handles a larger share of reading, comparison, drafting, implementation and verification. People spend more time on priority, judgment and acceptance.

What this demonstrates for HILLS Lab

The interesting unit is not the prompt or the individual thread. It is the operating system around them:

  • durable ownership instead of one universal chat;
  • compact, evidence-based handovers;
  • a canonical repository and explicit worktree hygiene;
  • independent risk review;
  • a clear distinction between shipped facts and roadmap intent;
  • human gates where consequences exceed the confidence of the automation.

PLAYGRND gives us a demanding place to test that model because code, data, product, design and operations regularly meet in the same release.

For software teams, the lesson is simple: adding more AI capacity is easy. Designing a workflow in which several AI contexts can contribute without losing accountability is the engineering work.

If your team is reaching the limits of one long AI conversation, we can help design the role boundaries, handovers and verification loop around the product you already have. Talk to HILLS Lab.