Operator: Designing a Control Plane for Bounded AI Product Delivery

Operator started from a practical constraint: I was running several software and business projects while increasingly using AI agents for implementation. More execution capacity did not automatically make the portfolio easier to manage. Agents could rebuild stale context, duplicate investigations, stop at the first ticket, wait on overly broad blockers, or produce large amounts of internal activity without moving customer or economic evidence.

I designed the system around a different question: what infrastructure lets agents make useful progress without transferring product ownership or consequential authority to them? Operator became the portfolio control plane for that answer. Child repositories keep their own product goals, evidence, code, and delivery truth. Operator owns shared mandate, authority, allocation, scheduling, continuity, and organizational controls.

An early governance instinct was to make agents conservative by escalating ambiguous choices. The side effect was predictable: the system trained agents to treat ordinary difficulty as a reason to ask for permission. That increased founder coordination instead of reducing it.

I changed the authority model so lawful, reversible, low-risk work is decided at the lowest level capable of owning the consequence. Project Product Owners own normal project direction and authorized services. Delivery agents own implementation choices inside that scope. The system escalates the smallest consequential decision only when spending, contracts, sensitive data, material public commitments, destructive actions, or other retained boundaries are actually involved.

This is a product-design decision as much as a policy decision. The goal is not maximum agent freedom or maximum approval. It is enough autonomy for useful work to continue while important ownership remains unambiguous.

Agent conversations are temporary, and replaying large histories is expensive and brittle. I designed Operator so useful continuity should survive the particular model, provider, or session that performed the work. Canonical repositories, GitHub, CI, project databases, and provider state remain the sources of truth.

The current event-context architecture observes those sources, derives material changes, and is being rolled out as a selective context layer. The target is to give a new or resumed agent the small set of changes that affect the current Product Goal, evidence gate, blockers, and runnable work instead of reproducing another agent's transcript.

Operator Observatory is the private, read-only stakeholder surface for the portfolio. It reads project facts from the control plane and child repositories, combines them with bounded operational telemetry, and presents fleet, project, approval, gap, and efficiency views without owning the underlying product or decision data.

That read model follows an important rule: one unavailable source should not suppress healthy sources, and an unavailable value should remain unavailable rather than being inferred as zero. This matters when evaluating capacity, outcomes, blockers, or agent efficiency. The dashboard can expose uncertainty, but it is not allowed to convert missing evidence into a confident portfolio decision.

The same principle shapes product metrics. Runs, commits, tokens, and tool calls are supporting evidence, not the definition of success. Operator's current product goal is to connect work to validated customer, revenue, cost, investment, or decision evidence strongly enough to support continue, change, pause, or reallocation decisions.

• Founder-owned mandate, product architecture, and authority boundaries are explicit and versioned.
• Child repositories preserve local product ownership and delivery truth instead of being absorbed into a central workflow database.
• Agents can make bounded implementation increments through GitHub, validation, deployment, research, and operational tools.
• Observatory provides read-only portfolio visibility across repository state and bounded telemetry.
• Context, continuity, project-entry, and evidence models are being iterated through measured rollout rather than assumed complete.
• The longer-term claim that this system will repeatedly create more external economic value with materially less founder coordination is not yet proven.

Operator is a working control-plane architecture and an active product experiment, not a claim that I built a fully autonomous software company. The strongest evidence today is the operating model itself: explicit ownership, delegated authority, durable project context, bounded execution, read-only visibility, and decision gates designed to keep internal activity separate from real outcome evidence.