Work

Work strategies route Work — not just leads or orders — to whoever (or whatever) should do it: humans, teams, queues, AI agents, or service accounts. This is the routing surface that treats every kind of Worker alike. The point of the design is that work routing does not fork the strategy system: a person, a queue, and an AI agent are candidates in the same pkg/strategy substrate that routes everything else, so eligibility, capacity, fairness, shadow, and certification all apply unchanged. The worker registry names all of them as one identity, over that same shared candidate substrate.

The work-assignment bridge

application/workassignment/ converts a domain/workassignment request and its candidate set into a strategy SelectRequest (candidates + feature snapshot), runs the resolved strategy from the shared registry, and maps the response back into a WorkAssignmentDecision. It deliberately depends only on domain/workassignment and pkg/strategy, so the same bridge is reused by the case service, workflow actions, preview, shadow, scenario, and certification flows without import cycles.

RegisterWorkAssignment registers the work-specific strategies and their contracts into the same strategy.Registry the routing engine uses, then validates that every work recipe resolves to a discoverable contract — the usual descriptor + contract rule.

Work recipes

Recipes use the dotted work. namespace and map onto registered strategy names. Several reuse the shared built-ins; a few are work-specific strategies registered by the bridge.

Because these register into the shared registry, a work-assignment strategy gets its own certification and scenario runner for free — the bridge ships a receipt contract harness (receipt_contract_harness.go) and scenario support (scenario.go) so a work-assignment policy is certified and shadow-evaluated the same way any routing strategy is.

AI-triage split

The work.ai_triage_split recipe routes routine, high-confidence work to AI agents and escalates complex or edge-case work to human experts, with an explicit work.human_fallback on AI failure, refusal, or escalation. That explicit fallback is what makes it safe to put AI on the front line: work is never dropped when the AI can't or won't handle it. Structurally it is a filter → select → fallback pipeline exposed as one named recipe.

Case-management assignment

application/casemgmt/ is a second, narrower assignment substrate for case queues. It defines its own AssignmentStrategy interface (Select(SelectParams) → QueueMember) and an AssignmentStrategyRegistry, with three built-ins wired by NewDefaultRegistry: manual, round-robin, and least-loaded. It also carries AI assignment, escalation workers, and due-at handling for case work specifically.

Tie-in to workflows

Work assignment is how a DAG hands a step to a person or agent. The human_loop workflow step routes to a human (or AI) assignee through this substrate and waits for the result before the workflow continues — see the DAG workflow model. Because the assignee is chosen by an ordinary strategy over the shared registry, the same eligibility, capacity, and fairness rules that govern lead routing govern who picks up the task.

Related