# How matching works

Fivexer continuously matches **tasks** to **workers** based on tags, skills, priority, and business rules. Unlike queue-based routers, there are no static queues — matching is declarative and reruns every time something changes.

## Core entities

- **Task** — a unit of work (ticket, case, job). It carries `tags`, an optional `priority`, geo constraints, and rich data (context, comments, attachments).
- **Worker** — an agent or automaton that can accept tasks. Workers carry `tags`, skills with proficiency, availability status, and a tentative queue of matched tasks.
- **Decision** — the platform's explainable match record: who was considered, who won, and why.

## Matching lifecycle

1. A task is created with `POST /tasks`. Its status is `queued`.
2. The matcher evaluates every available worker against the task's tags and constraints.
3. The best worker(s) receive the task in their **tentative queue** (`GET /workers/{id}/queue`).
4. The platform emits a `task.matched` webhook.
5. The worker (or an operator) calls `POST /tasks/{id}/accept` to move it to `accepted`, or `reject` to requeue it.
6. When done, `POST /tasks/{id}/complete` finishes the task.

## What decides the winner

- **Tag overlap** — task tags must be satisfied by the worker's tags/skills.
- **Priority** — higher-priority tasks are matched first.
- **Hard vetoes** — rules you define can forbid a match regardless of score (e.g., "agent_1 cannot take billing tasks on Fridays").
- **Fairness mode** — choose whether to prefer first-come, best-match, balanced load, or spread-work.
- **Learning layer** — optional feedback-driven weights that retune themselves from real outcomes.

To see the exact reasoning for any task, call `GET /decisions?taskId=...`.