The work loop

WilsonOS is not eight things. It is one loop with eight stations, and every piece of work — a Pinterest post, a book launch, a weekly ads review — passes through the same stations in the same order. Each station is a place work passes through, has machinery behind it, and answers exactly one question.

How it works in 5 steps explains how people use WilsonOS. The loop explains how the system carries an outcome. They are complementary views of the same work; this is the engineering one.

flowchart TB
  T["1 · Trigger — What starts work?"] --> C["2 · Context — What is relevant and permitted?"]
  C --> K["3 · Capability — Which skill or flow fits?"]
  K --> E["4 · Execution — Who acts, and what happened?"]
  E --> A["5 · Artifact — Where is the result and its version?"]
  A --> R["6 · Review — Does it meet the criteria?"]
  R --> L["7 · Learn — What should change?"]
  L --> M["8 · Measure — Did it move the business?"]
  M -. results and feedback .-> T

The eight stations

#	Station	The question it answers	What sits behind it
1	Trigger	What starts work, and who is in the loop?	Chat with an agent, scheduled automation, and signals from connected channels
2	Context	What does the agent know before it acts, and what is it permitted to see?	Memory, brand canon, the agent’s boot contract
3	Capability	How does it do the work well?	Skills and flows — atomic mastery and multi-step orchestration
4	Execution	Who does it, and what gets made?	Agents working in scoped environments; media and content generation through one gateway
5	Artifact	Where does the output live, and which version is current?	A registry that owns identity; storage that holds bytes; explicit versions
6	Review	Is it good, and who decides?	The Workbench: tasks, deliverables, comments, ratings, approval
7	Learn	Does the system get sharper?	Skill attribution, evaluation against explicit criteria, distillation of what was decided
8	Measure	Did it move the business?	Source data → conformed records → synthesis, with freshness and attribution limits visible

Results and feedback from Measure inform the next Trigger, the next Context, and the next Capability choice. That is why it is a loop and not a pipeline.

Not a wizard

Work can revisit a station. A review can send work back to Execution; a measurement can reopen Capability choice. The loop is the shape of the system, not a mandatory eight-step form.

Why a loop and not a list

Earlier descriptions of WilsonOS listed subsystems — chat, memory, skills, agents, workbench, and so on. A list of parts fails three tests that the loop passes:

1. A non-technical person can follow it. “What starts work? What does it know? How does it do it? Who does it? Where does it land? Is it good? Did we learn? Did it work?” is a story. A list of subsystems is not.
2. Each station is a clean seam. A separate engineer can own one station and know exactly what enters and what leaves.
3. Every station names what it improves. Each station maps to one or more of the WilsonOS Five, so every architectural change can say which promise it lifts.

Two of the old “subsystems” were not subsystems at all: the Workbench is a surface that reads tasks and artifacts (it belongs to Review), and goals/projects/tasks are Review’s data model. Meanwhile three things running in production — channel signals, the artifact registry, and measurement — appeared nowhere in the old list. The loop makes room for all of them.

Three foundations under every station

The stations are not the whole picture. Three cross-cutting planes sit underneath all eight — identity and access, data governance, and connections. They are not stations; they are what every station stands on. See Foundations.

How to use this page

When you read any other page in these docs, ask which station it belongs to. Agents are Execution (and Trigger, when a schedule fires them). Memory is Context. Skills and flows are Capability. Artifacts, the Workbench, measurement and learning each have their own station. If a page does not fit one station or one foundation, that is a sign the page is describing a surface rather than a mechanism.

live The loop is the agreed shape of the system and the organising principle of its architecture documents. Whether a particular capability at a station is live is stated on that capability’s page, never assumed from the loop.

Related

FoundationsIdentity & access, data governance, and connections — the three planes under every station.

How it works in 5 stepsThe user-facing view of the same loop.

What you get — the WilsonOS FiveThe five measurable promises every station is built to lift.

Example: create and launch a productFollow one outcome around the whole loop.