Skip to content

work-package: orchestrator/worker execution rules lack structural enforcement #65

@m2ux

Description

@m2ux

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

  1. 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.
  2. 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.
  3. 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 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

Labels

enhancement, workflow-design

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions