Team-Status System

Parallel work needed one decision-maker — and no human as the router. I designed an operating system that removes the founder from routine status relay while keeping a single person for anything ambiguous, risky, or irreversible.

Role: Founder · process design
Client: OurnAI
Year: 2026

Sanitized Team Status document on a dark field, showing Purpose, Core principle, and Collaborator A, B, and C blocks with placeholder content.

The problem

The failure mode of parallel engineering is obvious once you have lived it: without a shared source of truth, one person becomes the router. Every status update, every “is this actually done,” every merge conflict and stalled thread has to pass through that person, relaying context between conversations that cannot see each other. The work is fast. The founder is not.

In this case the parallel work was three AI coding collaborators in independent sessions — not one assistant switching contexts, but three agents, each holding its own thread, each able to open pull requests and make judgment calls in its lane. That made the router problem acute, and it is what the system had to solve.

The fix was not a better meeting cadence. It was removing the founder from the loop as the carrier of routine status, while keeping him as the one decision-maker for anything that is actually ambiguous, risky, or irreversible.

How it came about

The system was not designed up front. It was pulled into existence by a specific failure: all three collaborators were editing shared sections of one status file, and their edits kept colliding — three merge conflicts in a single week. The constraint that ended the conflicts was structural: each collaborator owns a named block, and no one edits another’s block, ever. Git cannot conflict on lines that only one author ever touches.

A second experiment ran in parallel: for one day, two collaborators had standing authority to merge their own verified pull requests, to see whether that sped things up without raising risk. It was used once, on a docs-only change, and expired on schedule. The standing rule since: collaborators open and fully verify their own pull requests; the founder reviews and merges.

How it works

The system is two documents with deliberately different jobs, plus a small set of standing rules that tell collaborators when they can act alone and when they must stop.

A live dashboard

One file, one section per collaborator, each holding exactly three bullets: what I’m doing right now, what I need a decision on, and what’s ready for review. It is overwritten, not appended, so it stays readable in under a minute. The founder reads it at set check-in points rather than continuously.

An append-only record

Every finding, decision, and incident gets a permanent, timestamped entry: what was found, what was decided, and why. The dashboard says what is true right now. This file says how it got that way. Nothing is deleted from it.

Standing permissions, scoped tightly

Collaborators may trigger routine deploys on their own judgment, and may contact a vendor’s support line when genuinely stuck — with a disclosure requirement every time, and hard boundaries: no public-facing communication, nothing that commits to cost, nothing beyond a one-day experiment without renewal. Default to visibility, not permission.

One true escalation rule

Anything a collaborator cannot resolve goes under its own “needs a decision” bullet, and work continues on everything else in that queue. The only thing that interrupts the founder directly, outside the check-in cadence, is active, ongoing harm — a live security exposure or data loss, not a routine blocker.

Document snapshot

The live files contain open findings, private pull-request numbers, and account detail that do not belong in a public portfolio. What follows is the same structure with that detail replaced by placeholders — the mechanism, not a map of the live codebase.

Sanitized Team Status document on a dark field, showing Purpose, Core principle, Collaborator A, B, and C blocks with placeholder tasks, and Conventions. Live repository detail is omitted. — Same visual shape as the live operating file, with generic collaborator labels and placeholder content. This is a rendering of the sanitized snapshot — not a screenshot of the repository.

Readable structure of the sanitized snapshot

Purpose: A single, shared, current-state view for all AI engineering collaborators — so status doesn’t have to be manually relayed between sessions. Update this file directly as part of your normal workflow.

Core principle: if you hit something you can’t resolve yourself, flag it under “Needs a decision” in your own block and keep working on anything else in your queue. Don’t stop and wait. Only interrupt directly for something genuinely urgent.

In Progress Right Now

Each collaborator owns one block. Edit only your own three bullets — never another collaborator’s heading, bullets, or the blank line between blocks.

Collaborator A

Now: [current task, one line]

Needs a decision: none

Awaiting review: none

Collaborator B

Now: [current task, one line]

Needs a decision: [specific, answerable question — not a vague status check]

Awaiting review: [PR reference]

Collaborator C

Now: [current task, one line]

Needs a decision: none

Awaiting review: none

Conventions

Edit only the three bullets under your own heading.
Keep it current, not comprehensive — overwrite “Now” when you start or finish something; don’t append a history.
PR descriptions and the followups log remain the real record of why something was done — this file is only what’s true right now.

The companion followups log is simpler in shape: one dated, append-only entry per finding or decision, each stating what was found, what was decided, and why — never edited after the fact, only added to.

What it has caught in practice

Reported “merged” did not mean “live.”

A change landed on the main branch and was marked done, but a separate deploy step failed silently because of an expired credential. Because the followups record exists, the gap between merged and deployed was caught and logged rather than assumed away.

An outside reviewer’s findings were reconciled, not just filed.

When an external engineer independently audited the codebase, the list was logged as an input, checked item-by-item against what was already fixed versus still open, and only then turned into tasks with an owner and a recorded decision.

A credential-rotation pattern got noticed instead of re-explained.

When two collaborators hit expired tokens on the same day in back-to-back weeks, that was flagged as a pattern worth investigating — not treated as two unrelated annoyances.

Risky one-day exceptions stayed one-day.

Because the current rule is explicit and dated, a temporary loosening of process did not quietly become the new normal.

Why this is worth showing

This is not a story about AI writing code. It is a story about designing the operating system that lets multiple autonomous agents work in parallel without a human becoming the bottleneck — and about the judgment calls that process required: when to let agents act without asking, when to force a stop, how to keep a record that survives tool turnover, and how to recover when a convention turned out to be wrong.

That is a product-management and engineering-leadership skill, not a coding one. It shows process written as a spec rather than a memo — the file is the enforcement mechanism — plus reversible experimentation, a bias toward keeping people moving, and a clean split between what is true now and why it is true. For anyone evaluating whether someone can run point on a multi-agent or multi-contractor engineering effort, this is direct evidence, not a claim.