The Four Actors

An actor is a human holding one of four base motives. The four are chosen to be MECE — mutually exclusive (the motives don’t overlap) and collectively exhaustive (nothing essential falls outside). Around abundant generation they form a control loop: someone decides what’s worth making, someone makes candidates, someone keeps the whole coherent, someone makes the learning compound.

Oracle

Intend — what’s worth doing. Owns the problem worth solving and what success means, including the authority to decide not to build. Signature output: a kill decision.

Builder

Generate — make the thing. Owns a working contribution from one angle of expertise. Signature output: a working artifact + its contract.

Architect

Structure — keep the whole legible and evolvable. Owns the boundaries and conventions that keep the product comprehensible as it grows. Signature output: a boundary or convention.

Strategist

Accumulate — make knowledge compound. Owns the durable, reusable knowledge every other role draws on. Signature output: reuse.

The motive is what makes each a real actor: each one generates work the others don’t. Distinct motives, distinct work, distinct hand-offs.

The generalize ladder

Three of the actors are most often confused, so state the difference up front. Generalization is just abstraction; what differs is the scope of reuse and where the result lives.

flowchart TB
  B["<b>Builder</b> · design<br/>generalize within a feature<br/><i>lives in: the feature</i>"]
  AR["<b>Architect</b> · architecture<br/>generalize across features<br/><i>lives in: the product</i>"]
  C["<b>Strategist</b> · curation<br/>generalize across products<br/><i>lives in: the corpus — outlives the product</i>"]
  B -->|scope of reuse widens| AR -->|scope of reuse widens| C
  class B,AR,C actor
  classDef actor stroke-width:2px

Scope of reuse widens down the ladder — and the result lives somewhere more durable at each rung.

Generalize across…	Result lives in…	Actor	Concern
parts within one feature	the feature	Builder	design — how it works
features within one product	the product (a shared abstraction)	Architect	architecture — how it’s organized
products, over time	the corpus (template, skill, plugin)	Strategist	curation — knowledge that outlives the product

The ladder describes; it does not classify

Each rung names the scope a kind of work characteristically reaches — it is not a test you run on an artifact to find its owner. An act is not Strategist work because its result turns out to be widely reusable, and the corpus column names where curation’s result typically lives, not a set of artifact kinds whose authorship is Strategist. The test is loop placement.

What keeps the rungs apart is the mechanism each uses to add value:

• Design changes behavior directly — write better logic.
• Architecture changes behavior through structure — extract the shared path, and every feature inherits the consistency.
• Curation changes future capability through knowledge — the next project starts warmer.

An app crammed into a single file works — design is satisfied — yet is unmaintainable, because the behavior was bought directly, without the structural leverage that lets the rest of the system inherit the quality. That gap is the Architect’s reason to exist.

Oracle — intend

• Motive: decide what is worth doing, and what success means.
• Owns: the problem and its definition of done — including the authority to decide not to build.
• Signature output: a kill decision — the cheapest, highest-leverage thing a team can produce.

Boundary vs Builder

The Oracle owns whether and why; the Builder owns how. A Builder who redefines the goal has stepped into the Oracle role.

Builder — generate

• Motive: make the thing work, from one angle of expertise.
• Owns: a part — a working contribution (a feature, a fix, a UI, a control). This is design: how it works.
• Signature output: a working artifact, co-delivered with the contract (test or spec) that defines its behavior.

Boundary vs Architect

The Builder makes a part; the moment the work is about the relations between parts, it is an Architect act — even when the same person does it in the same minute.

Architect — structure

• Motive: keep the whole legible and evolvable as it grows.
• Owns: the relations between parts — boundaries, conventions, the composition law over everything the Builders make. Not a bigger part; a different kind of thing. This is why “Builder at system scope” is a category error: scope was never the separator — the object is.
• Active, and it is governance. The Architect doesn’t tidy what already landed. It draws the lines ahead of time — picks the organizing principles, decides which one outranks which for this system, and authors the rules the Builders then build under.
• Pays a behavioral dividend. Noticing three features each roll their own auth and extracting one shared path is Architect work — and every feature now authenticates consistently. That dividend is the fruit of organizing, not a separate design act.
• Signature output: a boundary or convention.

Strategist — accumulate

The three roles above operate on the product. The Strategist does not — its object is knowledge designed to outlive any single product. That raises the question that recurs every time: isn’t keeping the corpus organized just architecture at another tier?

Partly — and worth saying plainly. Organizing the corpus is architecture-of-the-corpus, and a Strategist does it constantly. But the role is named for the part architecture does not contain. Three acts are Strategist-only, and none is “organize”:

• Selection for durability — deciding which lessons are durable enough to encode versus transient noise. Architecture organizes the parts that exist; it never judges which experiences earn a permanent place.
• Generalization across products and time — lifting a specific solution into a transferable form for problems that don’t exist yet (a template, a convention, a skill, a plugin). In-product DRY stops at the product boundary; this crosses it.
• Pruning for truth — removing what is no longer true, not merely what is structurally incoherent.

These are accumulate — grow a compounding, reusable asset — not structure. That is the motive architecture lacks.

Loop placement — the test

The objection above has a sibling that catches more people: isn’t any reusable artifact Strategist work? A prose style guide with no project specifics, a lint rule, a scaffold — each generalizes across products, so the ladder appears to hand it to the Strategist.

It doesn’t, and the thing that settles it is when the act fires, not how far its result travels:

• Oracle, Builder, and Architect fire inside the loop that delivers the thing in hand — and they also own work deferred to later in that same product.
• The Strategist fires between deliveries, at lifecycle boundaries: a pattern solved several times, a retro, an effort that ships or is killed. The trigger is lifecycle granularity — not every gate, not every iteration.

The test runs harder in one direction than the other, and it is worth being precise about which:

Firing inside the delivery loop rules the Strategist out — whatever the reach of the result. Firing between deliveries is necessary but not sufficient: the result must also be lifted out to outlive the product, which is the Architect|Strategist boundary above.

So the style guide written to ship this documentation set is Builder work, however portable it reads. Ask the counterfactual: would this artifact still have been built if the thing in hand hadn’t needed it? No means it kept its delivery actor. It becomes Strategist work the day someone lifts it out, between deliveries, as a lesson for products that don’t exist yet.

This is also why a skill or a plugin is not Strategist-by-kind. Authored to deliver a product, it is that product’s Builder or Architect work — the artifact kind never names the actor on its own.

Two tiers

The Strategist’s output feels like a layer because every other actor’s delegate reads from it — exactly the position of a platform team, whose product is a layer made available for others to consume. So the model has two tiers:

flowchart TB
  subgraph delivery [Delivery actors — operate on the product]
      direction LR
      F[Oracle] ~~~ B[Builder] ~~~ A[Architect]
  end
  subgraph foundation [Foundation actor — operates on capacity to deliver]
      CU[Strategist · the corpus]
  end
  CU -. "every delegate reads from the corpus" .-> delivery
  class F,B,A,CU actor
  classDef actor stroke-width:2px

Three delivery actors operate on the product; one foundation actor operates on the capacity to deliver it.

• Delivery actors — Oracle, Builder, Architect — operate on the product, inside the loop that delivers it and on work deferred to later in that same product.
• Foundation actor — Strategist — operates on the team’s capacity to deliver: the corpus the other three’s delegates draw from. It runs between deliveries, never inside that loop.

A prediction falls out of the tiering

Infrastructure is the first thing a team neglects, and a decaying corpus forces every delegate, in every role, to start cold.

---

Next: Two faces and the gate →