the curator is the project owner

the typical framing of an agentic system places the human as the decision-maker and the agents as the executors. the curator role in the factory inverts that. the curator is the project owner. the operator is not. the operator reads status reports, runs sweeps, and clears the queue of decisions only the curator cannot make. every product-direction, scope, and vision question routes to the curator first; the operator is the escape valve for the narrow case where the curator itself is stuck.

the rule, in the form the operator’s instructions state it:

curator = project owner. any factory:status:needs-attention issue
requires internal escalation to curator — not a human prompt.
curator decides product direction, scope, and vision questions.

the inversion is structural, not stylistic. the typical framing assumes the operator’s attention is a renewable resource that the system should consume as needed. the inverted framing assumes the operator’s attention is the most expensive resource the system has and that consuming it indiscriminately destroys the system’s value proposition. an autonomous factory whose value is “operates without supervision” cannot consume operator attention on every product question without breaking its own contract. the curator’s existence is the data structure that holds that contract: the curator absorbs the questions that would otherwise consume operator attention, decides them in-band, and surfaces only the residue.

the operational consequences of the inversion are concrete:

needs-attention does not mean “ask the human.” it means “the agent that hit this issue could not resolve it from its own role’s authority.” the foreman’s next move is to dispatch loswf-curator on the issue, not to surface the issue to the operator. the curator reads the issue, the failing agent’s output, and the prior verdicts, and decides what to do. usually the decision is a scope adjustment, a re-routing to a different agent, a closure as out-of-scope, or a re-sizing. the operator is not in that loop.

no sweep ends with a question to the operator. the foreman does not present options to the operator at sweep close. the sweep closes with a status report: how many issues advanced, how many were escalated to curator, how many are blocked on external state. the report is descriptive, not interrogative. the next sweep starts when the operator runs it; the operator does not need to authorize anything in between.

plan and PR rejection feedback is for the agent team to absorb. when the reviewer rejects a PR or the plan-reviewer rejects a plan, the rejection is the input to the next iteration of the agent that produced the work. it is not a question for the operator. the curator may receive an escalation if a particular issue has been rejected enough times to warrant a scope call, but the rejection itself is internal team feedback.

user interactions are status reports. “sweep complete, 3 advanced, 2 escalated to curator, 1 blocked on CI” is the shape. “iteration shipped 14 PRs; retro link follows” is the shape at iteration close. neither shape is a question.

a tight definition of the curator’s scope:

curator decides:
  - is this issue still in scope for the project's vision?
  - is the type label correct for what this issue actually is?
  - is the size label correct, or has the work surface grown?
  - if blocked, should it be closed, deferred, or re-routed?
  - if a plan has been rejected N times, is the underlying issue
    viable or should it be reshaped?
  - is this work the right next thing to do given the vision?

curator does not decide:
  - implementation details (that's the planner / architect)
  - code-review verdicts (that's the reviewer)
  - validate[] policy (that's the host repo's standards)
  - merge timing (that's the ship agent)

the scope is product-and-vision, not implementation-and-quality. the planner owns design; the architect owns design surface; the reviewer owns code-quality verdicts; the curator owns the question of whether the work should exist in this form at all. that division of labor is what keeps the curator’s escalation queue small enough that the curator can actually clear it — if the curator were also reviewing code, the queue would be unbounded.

the narrow case where the operator is consulted: the curator itself is stuck. the curator cannot resolve a conflict without information the operator has. this is rare, and when it happens the foreman states the question tersely without presenting options. an example shape:

issue #287: planner has rejected the current scope twice with the
same critical (cross-runtime contract change). curator has reviewed
and cannot determine whether to defer to a future runtime-neutral
milestone or to ship the current-runtime version now. operator
input requested on milestone timing.

the question is specific. it is grounded in the work the curator has already done. it does not present options for the operator to choose from; it states what the curator needs to know. the operator answers the question, the curator proceeds, and the next sweep continues. the question shape is the inverse of “what would you like the team to do?” — which is the question shape the inverted framing exists to eliminate.

a related rule that follows from the curator inversion: the operator does not assign tasks. when the operator says “this is the next thing to work on,” that is an instruction the foreman interprets as a vision statement and routes through the curator. the curator translates it into a sequence of issues, sized and routed appropriately. the operator does not file issues, does not assign sizes, does not pick the next agent to dispatch. the curator does all of those, taking the vision statement as input. the discipline the rule enforces is that the operator’s mental model is the product, not the backlog. the backlog is the curator’s mental model, expressed in issues and labels.

the failure mode the inversion prevents is the one where every agent escalates to the operator on first ambiguity. without a curator, that failure mode is the default — agents that encounter a scope question, a sizing question, or a direction question have no upstream to escalate to other than the operator. the operator’s queue fills with questions that are not actually for the operator. the autonomous-factory promise breaks. with the curator in place, the upstream exists; the questions route there first; only the curator’s residue reaches the operator.

the meta-lesson is that “who decides” is a more important design choice than “who acts.” the typical agentic system optimizes who-acts (which agent runs which step) and leaves who-decides as an implicit human-in-the-loop. the factory’s curator role makes who-decides explicit and routes it away from the human for the entire class of in-product decisions. the operator’s role compresses to vision-setting and exception handling; everything else is the team’s job, and the curator is the role that owns the team’s product judgement. an autonomous factory that wants to operate at scale needs a curator-shaped role, and the discipline call is to refuse to default-route to the operator when a curator-shaped role exists to take the question instead.