windags-architect

license	BSL-1.1
name	windags-architect
description	Build WinDAGs — the orchestration platform where AI agents accumulate genuine expertise through DAGs of skillful agents. Covers DAG design, execution engines, meta-DAG architecture, skill selection, dynamic mutation, visualization, and deployment. Activate on "windags", "agent DAG", "DAG of agents", "workflow orchestration", "agent pipeline", "dynamic DAG", "meta-DAG", "build windags", "implement windags". NOT for understanding WHY decisions were made (use windags-avatar), creating individual skills (use skill-architect), or managing skill libraries (use windags-librarian).
allowed-tools	Read,Write,Edit,Bash,Grep,Glob
argument-hint	[problem-description] [mode: local|web|embedded]
metadata	{"tags":["windags","architect","agent-dag","dag-of-agents"]}
category	Agent & Orchestration
tags	["windags","architecture","system-design","platform","meta"]

WinDAGs Architect — V3

Build WinDAGs: directed acyclic graphs of skillful agents that accumulate genuine expertise. Each node is an agent with curated skills; each edge is a typed dependency. The system builds DAGs, executes them in waves, mutates them at runtime, evaluates quality across four layers, and crystallizes reusable skills from execution data.

DECISION POINTS

1. Execution Mode Selection

Problem type assessment:
├── Simple task (< 5 nodes, single domain)
│   ├── If user has CLI access → Use local mode
│   └── If web interface needed → Use embedded mode
├── Medium task (5-20 nodes, 2-3 domains)
│   ├── If team collaboration needed → Use web mode
│   ├── If execution history important → Use web mode
│   └── If isolated/private → Use local mode
└── Complex task (20+ nodes, multiple domains)
    ├── If distributed execution needed → Use web mode
    ├── If real-time monitoring required → Use web mode
    └── If cost optimization critical → Use web mode with smart routing

See references/execution-engines.md for implementation details on each execution model (asyncio vs. multiprocess vs. Docker isolation).

2. DAG Architecture Pattern Selection

Problem complexity:
├── Sequential chain (A→B→C)
│   ├── If error-prone steps → Add approval gates between nodes
│   └── If simple pipeline → Use basic data-flow edges
├── Fan-out pattern (A→[B,C,D]→E)
│   ├── If independent work streams → Use parallel execution
│   ├── If failure domains overlap → Isolate to separate waves
│   └── If results must merge → Add aggregator node
├── Iterative refinement (A→B→C→B)
│   ├── If quality improvement loop → Use loop_back mutation
│   ├── If human oversight needed → Add approval gates
│   └── If automatic iteration → Use quality threshold triggers
└── Multi-stage validation (parallel checks)
    ├── If binary validation → Use Floor/Wall evaluation only
    ├── If process quality matters → Enable Ceiling evaluation
    └── If stress testing needed → Monitor Envelope metrics

3. Node Commitment Level Assignment

Task certainty assessment:
├── COMMITTED (implementation clear)
│   ├── If skill signature known → Direct skill assignment
│   ├── If template available → Use template with parameters
│   └── If standard pattern → Apply seed template
├── TENTATIVE (approach unclear)
│   ├── If 2-3 viable approaches → Create parallel exploration nodes
│   ├── If dependency on prior results → Mark as vague node
│   └── If expert consultation needed → Add human approval gate
└── EXPLORATORY (research needed)
    ├── If domain expertise required → Use research-synthesis template
    ├── If multiple unknowns → Break into sub-DAG
    └── If high uncertainty → Add PreMortem analysis

See references/progressive-revelation.md for the full vague-node resolution machinery, including domain meta-skills and cross-wave context management.