You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 validate actions that check for orchestrator/worker context markers
Skill-level guards: Add pre-condition checks in the execute-activity skill 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
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."
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."
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."
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:
validateactions that check for orchestrator/worker context markersexecute-activityskill that verify the caller is a sub-agentLabels
enhancement, workflow-design