Agents & Cognition · 06.10
Demand Routing & Responsibility
How a subdomain of work gets deterministically mapped to the specialist accountable for it, with every hand-off recorded and auditable.
Two different questions: who's accountable, and who's best
Two related but distinct routing problems exist side by side. Responsibility resolution answers "who owns this work" with a strict, deterministic precedence: a workflow pinned directly to a specialist wins first; failing that, the manager of the subdomain or domain the workflow belongs to; failing that, the owner of the App the workflow belongs to; then that App's domain manager; then the top-level domain's manager as the final fallback. The result also reports how it resolved — direct ownership versus a manager stepping in — so dispatch logic can tell a genuine specialist assignment from a manager merely covering a gap.
Demand routing scores candidates, it doesn't just pick the owner
When a task needs a specialist matched to it rather than routed to a pre-assigned owner, the demand router scores every candidate role across seven weighted factors: domain match, ability match, Mind relevance, tool affordance match, historical quality, freshness, and an estimated cost penalty — then returns the winning role, an explanation, and one of six cooperation topologies (direct, supervisor, sequential, swarm, hierarchical, shadow). Either way, the conversation "theater" records the hand-off — workflow to specialist — on every execution path, so collaboration stays auditable no matter which loop actually ran the task.
Continue
Curated facts, preferences, rules, and vision-derived design patterns distilled into retrievable atoms the engine injects at dispatch.
Fan a task out to worker sessions, each in its own worktree, then merge — the two cooperation shapes and when to reach for each.