Locus — A Product Operating System for the AI Era

Overview

When AI is a consistent collaborator — not an occasional tool — the operating model has to change. There is no PM holding context between sessions. No engineering lead remembering why a tradeoff was made last week. No standup syncing what happened yesterday. If the reasoning behind a decision is not captured in a place the system can reach, it is gone the next time work resumes.

Locus is the operating system I built to solve that problem. It captures the thinking behind product decisions — not just the conclusions — and structures it so that any collaborator, human or AI, can pick up the thread and keep building without starting over.

This is not a framework I designed and handed off. It is a system I built, used on real projects, and evolved based on what broke.

Role

Creator, designer, and systems architect

• Defined the core thesis: captured context as the infrastructure that holds AI-native product work together
• Designed the information architecture — the working surfaces, the relationships between them, and the rules that govern how work flows through the system
• Built collaboration rules that let AI contribute consistently without losing context, quality, or decision clarity
• Used Locus on live projects to pressure-test the system and evolve it through real use
• Reworked the architecture when the first model broke — replacing an early abstraction that created more friction than clarity

The problem

Product thinking is fragile. In a team environment, useful context travels through conversations, standups, and the ambient awareness that comes from working in the same room or the same Slack channel. Decisions get made, and the people who were there carry the reasoning forward — even if it is never written down.

Solo, that ambient layer does not exist. And when AI is the collaborator, it is worse: every session starts with a blank slate. The AI does not remember what was decided yesterday, what alternatives were considered, or why the current direction was chosen. Without a system to hold that context, every session begins by re-deriving decisions that have already been made.

Most AI workflow tools focus on accelerating output — write faster, build faster, ship faster. But speed does not help if the thinking behind the work is not captured along the way. The bottleneck is not production. It is continuity.

Three design principles that shaped the system

1. Context is infrastructure, not documentation

Most product documentation is written after the fact — a summary for stakeholders. In Locus, documentation is embedded in the workflow itself. The surfaces where decisions are recorded are the same surfaces where decisions are made. The handoff layer that keeps the next session productive is not a status update — it is a structural part of how work moves through the system.

When documentation is part of the operating model rather than appended to it, it stops feeling like overhead.

2. Separate what changes from what stays

An early version of Locus used a model that coupled too many concerns together. It worked well enough to get started, but as the system matured, the coupling created friction — the same abstraction was carrying workflow logic, decision authority, and output ownership. When I needed to change one, I had to work around the others.

The redesign separated those concerns into independent layers. Each layer has a clear job, and changing one does not force changes to the rest. That separation is what makes the system composable — it can adapt to different project shapes without being restructured from scratch.

3. Solo work needs more structure than team work, not less

On a team, alignment happens naturally through conversation and shared context. Solo, you have to build that alignment into the system. Locus includes explicit rules for what level of decision requires what level of review, how existing work is protected when the product evolves, and when to pause execution for concentrated evaluation. These are the same functions a healthy team performs — Locus just makes them structural instead of conversational.

Proof: Canary

The clearest proof of Locus is the work it produced. Canary — an AI-powered monitoring tool I built solo from zero — was the first project built entirely inside the system.

What the system had to handle: a 17-epic roadmap, a major product pivot midstream, and continuous AI collaboration across sessions where context loss was the default risk. The strategic framework that sequenced the roadmap survived the pivot intact — because the reasoning behind it was captured in the system, not just the conclusion. The specs were detailed enough that an AI collaborator could execute them without making product decisions, because those decisions had already been made upstream.

Canary shipped as a working MVP and evolved through the pivot — all without a team. A second project (this portfolio site) followed the same pattern. The system is consistent: raw signal enters, gets structured into working surfaces, generates executable specs, and preserves the reasoning so it is available the next time anyone — or any AI — picks up the work.

Outcomes

• Built a working operating system for end-to-end product development with AI as a consistent collaborator
• Used the system to ship Canary (17+ epics, major model pivot, solo build) and structure a second project end-to-end
• Created a durable context layer that eliminated the re-derivation problem across AI sessions
• Evolved the architecture based on real friction — replacing an early model that coupled too many concerns with a composable alternative
• Established collaboration rules that let AI contribute consistently without losing quality or decision clarity

How this transfers

These patterns are not solo-builder tools. Decision authority structures, change control rules, durable context layers, and separated concerns are the same things teams need when AI agents participate in product work at scale. The difference is that Locus was designed around the operating model question — what changes when AI is a consistent collaborator from the start — rather than bolting AI onto an existing process.

I am happy to walk through the system's architecture, the specific design decisions, and what I would change in more detail — that is a better conversation than a case study.

How I work

The system improved not because I defined the perfect model up front, but because I used it seriously enough to see where the abstractions broke and then redesigned them. That is the pattern I trust: build, use, notice what is wrong, and fix the structure.