# Work (/docs/strategies/work)



Work strategies route <Term name="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
<Term name="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 [#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](/docs/strategies/contracts) rule.

### Work recipes [#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.

| Recipe                      | Runs                                    |
| --------------------------- | --------------------------------------- |
| `work.manual_hold`          | work-specific manual-hold strategy      |
| `work.round_robin`          | `smooth_weighted_round_robin`           |
| `work.least_loaded`         | `least_loaded`                          |
| `work.skill_match`          | work-specific skill-match strategy      |
| `work.skill_match_weighted` | work-specific skill-match-then-weighted |
| `work.availability_first`   | `availability_first`                    |
| `work.sla_rescue`           | `sla_deadline`                          |
| `work.fair_catchup`         | `fair_catchup`                          |
| `work.ai_triage_split`      | work-specific AI-triage split           |
| `work.human_fallback`       | work-specific human fallback            |
| `work.channel_aware`        | work-specific channel-aware strategy    |

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 [#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*&#x2A;, with an
explicit &#x2A;*`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](/docs/strategies/pipelines) exposed as one
named recipe.

```mermaid
flowchart TD
  W["Work item"] --> Q{"Routine, high-confidence?"}
  Q -->|yes| AI["AI agent"]
  Q -->|no| H["Human expert"]
  AI -->|failure, refusal, escalation| HF["work.human_fallback"]
```

## Case-management assignment [#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 [#tie-in-to-workflows]

Work assignment is how a DAG hands a step to a person or agent. The
&#x2A;*`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](/docs/concepts/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 [#related]

<Cards>
  <Card title="Eligibility" href="/docs/strategies/eligibility">
    Skill, license, and trait matching for choosing the right assignee.
  </Card>

  <Card title="Pipelines" href="/docs/strategies/pipelines">
    The filter → select → fallback composition behind AI-triage split.
  </Card>

  <Card title="DAG workflow model" href="/docs/concepts/dag-workflow-model">
    The human\_loop step that routes work to a person or agent.
  </Card>

  <Card title="Governance" href="/docs/strategies/governance">
    Shadow-evaluate and certify a work-assignment policy before it goes live.
  </Card>
</Cards>