Give agents a job.
Make the work inspectable.

Decide what is worth doing next.

A company can keep producing work without learning whether it helped. OM5 is my approach to organizing that work: choose an outcome, decide who or what should act, then check the result. It builds on OM4, which organized software delivery. OM5 asks a broader product question: what should a company do next, and what evidence would show it worked? Sometimes the next move is code. Sometimes it is research, a positioning change or a distribution experiment. The operating loop is discover, decide, build, distribute, measure and learn.

Start with an objective contract.

Each objective describes the outcome, deadline, budget, allowed channels and stop conditions. Work is assigned to the smallest adequate mechanism: a prompt, skill, agent, script, scheduled job or person. The design makes responsibility and limits explicit before execution.

The builder never judges its own output.

Separate reviewers examine evidence, content and code. Autonomy is earned by role and channel through evaluation and incident history. Money, brand and trust remain subject to explicit controls.

Five planes keep the system understandable.

The control plane holds objectives, a work ledger, risk tiers, budgets, permissions and kill controls. The intelligence plane reasons about the work. The action plane connects tools. The data and memory plane preserves context and provenance in durable files. The audit and evaluation plane checks results independently.

File-based checkpoints let work resume after context resets. Repeated failures become guards or tests. For external content, claims, brand and platform-policy reviews examine the same artifact before an action can proceed.

The June 2026 build

My June 2026 build had a 31-role operating model, 17 invokable agents, 14 ephemeral prompts, 16 deterministic services, 23 schemas and 602 control-plane tests. These are owner-reported engineering artifacts from that build, not customer adoption or revenue metrics.

At that point, the system was in A0 shadow mode: measure and observe. External connectors still required setup, and the external action tier was dormant. Later levels progress through human-approved drafts, owned-channel publishing, campaigns, lifecycle work and a closed loop. Those levels describe the design, not permissions already granted.

The operating model keeps evolving.

The later implementation adds a command-line interface (CLI), adapters for different model providers, JSON Schema contracts that check data formats, and memory split into established facts, working checkpoints, retrieval and summaries. Provider routing spans Anthropic, OpenAI, Codex and local Ollama. The implementation has evolved since June. Those test totals and the A0 status describe that earlier build, not a current deployment inventory.

The product lesson

Adding agents is easy to count. Making work resumable, reviewable and bounded is the harder product decision. OM5 is my independent implementation of that operating discipline; it is separate from deployed customer systems.