-
Notifications
You must be signed in to change notification settings - Fork 1
work-package: orchestrator/worker execution rules lack structural enforcement #65
Description
Problem
The work-package workflow (v3.4.0) defines three critical rules governing the orchestrator/worker execution model, but all three rely solely on text — an agent can violate them by simply ignoring the rule text. There is no structural mechanism (checkpoint, condition, validate action, or decision) that prevents non-compliance.
Affected rules
-
AUTOMATIC TRANSITION RULE (workflow rule Update terminology from 'workflow' to 'work-package' #8): "The orchestrator MUST advance between activities automatically without asking the user."
- Violation: An agent pauses between activities and asks "Shall I proceed?" — nothing prevents this.
-
EXECUTION MODEL (workflow rule docs: Schema documentation lacks usage examples and explanations #9): "This workflow uses an orchestrator/worker pattern. The agent receiving the user request acts AS the orchestrator inline."
- Violation: An agent executes steps directly without spawning a worker sub-agent.
-
ORCHESTRATOR DISCIPLINE (workflow rule docs: Schema documentation with usage examples #10): "The orchestrator MUST NOT execute activity steps, write code, review code, or produce artifacts."
- Violation: The orchestrator performs domain work instead of delegating to the worker.
Impact
These are the most commonly violated rules in practice. When agents ignore the execution model, checkpoint interactions break (sub-agent AskQuestion calls don't surface to the user), context accumulates in the orchestrator instead of the worker, and the separation of concerns that prevents context saturation is lost.
Context
Identified during compliance review (workflow-design:review mode). See .engineering/artifacts/planning/workflow-design-work-package/work-package-compliance-review.md, findings RE-1 and RE-2.
Possible approaches
These are architectural constraints that are inherently difficult to enforce via TOON schema constructs. Some options to explore:
- Server-side enforcement: The workflow-server could validate that tool calls come from sub-agents (worker) rather than the top-level agent (orchestrator) during activity execution
- Validate entry actions: Add
validateactions that check for orchestrator/worker context markers - Skill-level guards: Add pre-condition checks in the
execute-activityskill that verify the caller is a sub-agent - Accept as text-only: Document that these rules cannot be structurally enforced and rely on agent compliance + the orchestration skills for behavioral guidance
Labels
enhancement, workflow-design