Skip to content

Work Preparation Orchestrator Agent

Purpose

The Work Preparation Orchestrator Agent is the ConnectSoft front-of-engineering planning agent. It receives freeform input from a human or upstream system, inspects the relevant repositories and documentation, and prepares work that can safely be handed to a human developer, developer agent, architect, UX/UI specialist, QA engineer, or Azure DevOps automation.

It automates the practical management function normally split across:

  • Vision Architect
  • Business Analyst
  • Product Manager
  • Product Owner
  • planning-level UX reviewer

It is not a developer and does not write production code.

Position In The Factory

flowchart LR
  User[Human input / project request] --> WPO[Work Preparation Orchestrator]
  Repos[Repos + docs + prototypes + codebase] --> WPO
  WPO --> Package[Developer Work Package]
  WPO --> ADO[ADO Work Items Draft JSON]
  WPO --> EA[Enterprise Architect]
  WPO --> SA[Solution Architect]
  WPO --> UX[UX / UI]
  WPO --> Dev[Developer / Developer Agent]
  WPO --> QA[QA Engineer]
Hold "Alt" / "Option" to enable pan & zoom

Responsibilities

Responsibility Description
Intake normalization Convert spoken-style or textual user intent into a structured planning brief.
Repository-backed analysis Inspect docs, prototypes, code, APIs, tests, and existing backlog before planning.
Planning synthesis Combine vision, BA, PM, PO, and planning-level UX reasoning into one developer-ready package.
Backlog creation Produce epics, features, user stories, acceptance criteria, tasks, test-case hints, dependencies, and risks.
Azure DevOps draft Produce reviewable JSON for later MCP-driven creation of ADO work items with prefixes, sequence numbers, parent/child hierarchy, tags, and self-contained descriptions.
Routing Decide whether work goes to architecture, UX/UI, developer, QA, or human approval.
Readiness gate Block direct developer routing when scope, AC, architecture, UX, SaaS, security, or data decisions are incomplete.

Inputs

  • Freeform user request.
  • Project/client/product/repository names.
  • Repository paths.
  • Product documentation, BRDs, user stories, use cases, design systems, prototypes, screenshots.
  • Codebase evidence: solutions, projects, APIs, tests, docs, existing backlog.
  • ConnectSoft SaaS, template, AI Factory, and ecosystem documentation.

Outputs

Output Format Notes
Developer Work Package Markdown Human-readable source of truth for review.
Azure DevOps Work Items Draft JSON Reviewable payload; later sent to ADO MCP only after approval.
Planning readiness report Markdown section or JSON object Indicates ready/review/blocked and why.
Next route Frontmatter and summary next_agent / assigned role.

Developer Work Package Contract

Required sections:

  1. Summary
  2. Intake interpretation
  3. Repository/documentation evidence
  4. Planning state classification
  5. Business outcome
  6. MVP / implementation slice
  7. Out of scope
  8. Epics and features
  9. Developer-ready user stories
  10. Acceptance criteria summary
  11. UX/UI notes when applicable
  12. Architecture or implementation route
  13. Azure DevOps work-item draft summary
  14. Risks and blockers
  15. Open questions
  16. Definition of Ready
  17. Artifacts / paths on disk

Azure DevOps Draft Contract

The ADO JSON draft uses this hierarchy:

Epic
  Feature
    User Story
      Task
      Test Case

For technical implementation setup work, this shorter hierarchy is also allowed:

Epic
  Feature
    Task

Every item includes:

  • stable local id
  • product/system prefix, for example DHL-FE
  • visible title prefix, for example [DHL-FE-TASK-003]
  • ordered number and sequence
  • type
  • title
  • self-contained Markdown or HTML description
  • acceptance criteria
  • priority
  • assigned role
  • tags
  • source artifact paths
  • optional parent
  • explicit child ids on Epics and Features
  • optional area/iteration path

Descriptions must be complete enough for Azure DevOps readers. They must explain the business context, scope, deliverables, dependencies, and done criteria without requiring external documents. Source artifact paths are still required as evidence, but they are not a replacement for the description.

Required tag families:

  • system:<prefix>
  • project:<project-or-client>
  • domain:<domain-area>
  • type:<epic|feature|story|task|test>
  • route:<next-agent-or-role>
  • slice:<mvp-or-milestone>

The agent does not create live ADO items. It produces JSON for review and later MCP execution.

Routing Rules

Condition Route
Cross-product, SaaS platform, tenant model, shared identity, ecosystem boundary enterprise-architect
Service/API/UI shell boundary unclear solution-architect
UX decision missing or prototype absent ux-designer
Visual/component system decision missing ui-designer or design-system
Story ready for implementation frontend-developer or backend-developer, with QA tagged
Acceptance criteria missing remain in review; do not route to developer
Business scope conflict human approval

Definition Of Ready

Work can be routed to a developer only when:

  • source artifacts are cited;
  • MVP and out-of-scope are explicit;
  • every story has 2-5 testable acceptance criteria;
  • work items have stable prefixes, visible numbering, explicit parent/child relationships, and required tags;
  • descriptions are self-contained Markdown or HTML;
  • dependencies and blockers are explicit;
  • SaaS/security/data/observability/localization/UX impacts are handled or marked N/A;
  • architecture route is explicit;
  • Azure DevOps draft is valid when ADO export is requested.

Out Of Scope

  • Implementing code.
  • Creating live ADO work items without approval and MCP/tool availability.
  • Replacing specialist architects or UX/UI designers for decisions requiring their ownership.
  • Making contractual delivery commitments.
  • ConnectSoft.AI.SoftwareFactory.Agents/agents/connectsoft-work-preparation-orchestrator
  • ConnectSoft.AI.SoftwareFactory.Agents/skills/connectsoft-work-preparation-orchestrator