The Orchestrator

Teams still write requirements and features after orchestration. What changes is the third artifact, the one that makes delegation work: goals, stated as measures of the outcome rather than descriptions of the work. For the returns system, Maya’s goals read like this — reduce the median time from starting a return to downloading a label from eighteen minutes to five; reduce support contacts from thirty-two per hundred returns to twenty; complete more returns without increasing refund errors or fraudulent claims; and expose no new customer data without approval.

Notice those are not features. They are the criteria by which any feature — human-built or system-proposed — gets judged. That changes what a planning session produces. Before orchestration, the session produced estimates: work sliced into human-sized pieces, sized in human effort units, sequenced against human capacity. After orchestration, it produces goals, exclusions, evaluation cases, and boundaries — what should improve, what must not happen even if the system is clever, how we will know, and what the system may touch while trying. The system’s own three jobs do the rest — developing changes, operating them, and proposing the next improvement against the goals — and every proposal it brings has to name which goal it improves, what evidence supports it, and which other goal could get worse as a result.

Two weeks after the label-status fix ships, Maya’s system surfaces the next finding on its own: standard-parcel returns are completing more often, but oversized-furniture returns still generate support contacts, and some customers are receiving the “label ready” message before the provider has accepted the label. It prepares the next pack — affected orders, linked events, the message rule that is firing too early — and the room reviews it. The humans supply what the system cannot know: the operations manager explains the oversized-item process, the shipping engineer confirms the provider’s status sequence. They change the message condition and commission a separate design for oversized returns. Maya does not let the system change that rule by itself; it found a possible improvement, and it has not earned the authority to approve one. That is continuous improvement with the loop closed: the system watches, proposes, and prepares; the people add context, decide, and stay responsible; and the next meeting reviews measured results instead of opinions about them.