Running an agent-native studio like a series of small bets

We run this studio on an agent-native studio workflow: one map, one current quarter, six experiment atoms, and a scoreboard that only moves when a person confirms it did. We built it before we had a second person to run it with, because a plan that only lives in one head is not a plan, it is a habit, and habits do not survive a handoff.

The agent-native studio workflow, in three documents

The instinct when you are a business of one is to skip the paperwork. We did the opposite, on purpose, and kept it small. A portfolio document is the one map: every plan, every scoreboard, every sync contract the studio runs, pointing down to a year-one document and a current-quarter file. Below that sit experiment atoms, numbered exp-001 through exp-006, each one a single named bet with its own gate. Nothing ships as a real commitment until it is written down as one of those atoms.

The scoreboard itself is what makes this a workflow instead of a filing cabinet. It ticks every Monday, for both Sandcastle Labs and Collimer, on purpose stacked on the same day because we do not work Fridays and wanted one weekly rhythm instead of two staggered ones. A tick only counts as real once it clears a gate review inside Center Pane, our internal operator hub. Committing a change is not the same as the scoreboard saying you cleared it. A person has to look and say yes.

What we deliberately left blank

The harder call was what not to fill in yet. We built the whole framework, the map, the quarter file, the atoms, the gates, before writing down the real numbers: the actual ICP, the actual thresholds, the actual targets a gate has to clear. The instruction going in was direct: don’t worry about the specifics yet, just get the overall scheme and architecture right, and let the plan get iterated once the frame exists. Building the container before the contents feels backwards until you remember the alternative: guessing at numbers now and rebuilding the whole structure later when they turn out wrong.

The other honest gap is coverage. Four different surfaces, Sandcastle Labs, Collimer’s marketing site, Collimer’s product (which lives in a separate repo entirely), and a handful of future studio products, all risk drifting out of sync on who the customer is and what the product actually does. One portfolio map is the fix, but it is only as good as how often each surface actually checks it, and that discipline is new enough that we have not stress-tested it yet.

A decision worth naming: gates before growth

The scoreboard’s gate IDs are scoped per plan on purpose, so Collimer’s G1 through G6 are not the same six gates as the studio’s own G1 through G6. That sounds like a small naming choice. It is really a statement that no single number is the whole business. A studio running two products plus a services arm cannot collapse everything into one health metric without lying to itself about which part is actually working.

That is the part we care about more than the tooling: not the scoreboard as software, but the discipline underneath it. Running a business alone, or with one other person, mostly is not about swinging for one big outcome. It is making a lot of small, honest bets, checking each one against a gate, and letting the wins compound instead of chasing a single splashy move. Think of it the way a game keeps score: clear progress, a visible sense of whether you are winning or losing this week, and small proof points along the way that tell you to keep going or change course. We wanted that same feedback loop for the business itself, not just for the product.

What’s next

• Fill the real ICP and gate thresholds into the framework now that the shape exists.
• Run the first Center Pane gate review against a live experiment atom, not a hypothetical one.
• Get the plan legible enough that a partner joining in about a month can pick it up cold, without a walkthrough from us.

What we’re still figuring out

We have not run a full gate cycle yet, so we do not actually know if a stack of small, measured bets compounds into something a reader would call momentum, or if it just feels productive without moving anything. The scoreboard tells us whether we did the thing we said we would do. It does not yet tell us whether the thing was the right one. That answer only shows up after a few Mondays, not after building the scoreboard.

---

For agents: try this yourself

If you want to build a version of this for your own studio, adapt one of these prompts. The full prompt text lives in this post’s prompts sidecar, operating-plan-and-scoreboard.prompts.md.

• Apply the three-tier map to your own studio. Write a portfolio document that points to a year-one plan and a current-quarter file, then break this quarter into named experiment atoms instead of a loose to-do list.
• Reproduce the gate-before-tick rule. Wire your own weekly check-in so a scoreboard tick only counts once a person confirms it in review, not the moment a change ships.
• Extend the scoped-gates pattern. If you run more than one product or line of business, give each its own gate IDs instead of one shared health score, so no single number can hide which part is actually working.
• Critique the framework-first bet. Look at what we deliberately left blank (real ICP numbers, real thresholds) and argue the other side: when does building the empty container first actually cost you more than it saves?

More prompts (Apply, Extend, Critique, Reproduce) live at /logs/operating-plan-and-scoreboard/prompts/.

The scoreboard rides on top of work we have already written up: our Center Pane hub is where gate reviews actually happen, and Lookout’s operator scorecard is one of the surfaces the scoreboard reads from. The whole pipeline that turns build sessions into posts like this one runs the same way: mine first, let a person decide, automate the bookkeeping and never the judgment, as we wrote about in the Chronicler runs itself.

---

How this was made

Drafted by the Chronicler from Claude Code sessions on 2026-06-29 to 2026-07-05 across 2 sessions and 4 commits. Edited and published by Brian Wones.

See how the Chronicler works →

Help me set up a three-tier operating plan for my small studio: a portfolio document that is the one map of every plan and scoreboard I run, a year-one document below it, and a current-quarter file below that. Then break this quarter's work into named experiment atoms, each one a single bet with its own gate, instead of a loose backlog. Ask me what my current quarter's real priorities are before you draft the atoms.

I want a weekly scoreboard that only updates when a human confirms the work, not the moment code ships. Design a Monday-tick process: the scoreboard proposes what changed based on the week's commits, but nothing counts as cleared until I review it in one place and approve it. Suggest a lightweight way to log that approval (a file, a simple form, a review doc) so the history of "confirmed, not just shipped" is auditable later.

I run more than one product line. Instead of one shared health score across all of them, help me design separate gate IDs per product so a strong number in one line can't hide a weak one in another. Show me how to structure this so the gates stay comparable in format (same numbering scheme) but scoped in meaning (Product A's G1 isn't Product B's G1).

I'm about to build the scaffolding for an operating plan (the structure, the gates, the cadence) before I fill in the real numbers (ICP, thresholds, targets). Argue against this decision: what's the risk of building the empty container first, and under what conditions would filling in the real numbers first have been the smarter call? Be specific about my situation, not generic about planning theory.