AI
AI Use Cases
The concrete tasks an AI Agent can perform — classify, summarise, draft replies, spot anomalies. Use cases are the building blocks of every agent.
Updated May 18, 2026
Configuration · AI · 8.2
An AI Use Case is a bounded task an agent can perform: classify, summarise, propose, detect. Use cases are the building blocks — an agent links one or more use cases with a specific system context and target object. Here you configure what AI does; in AI Agents (8.1) you decide who.
Why this matters to the business
"AI does too much or too little"
Use case choice bounds the action — Classify is not the same as Answer.
"Reuse across agents"
One use case "Classify Ticket" can be used by multiple agents (generic + IT-specific).
"Results measurable"
Per use case: accuracy measurement (correct vs overridden by handler).
"Not everything fits AI"
Use cases set clear boundaries — some tasks are trivial (categorisation), others too complex (legal decision).
Common use case types
| Type | What it does | Best suited for |
|---|---|---|
| Classify | Assign category/priority/workgroup based on content | Tickets, reports, requests |
| Summarize | Summarise long threads, ticket history or conversations | Handler handover, manager overview |
| Draft response | Drafts first reply based on KB | End-user questions, FAQ-level |
| Suggest action | Suggests next step (escalation, routing, closer to resolution) | Complex tickets |
| Detect anomaly | Spots deviations from the pattern (ticket spike, unusual booking) | Major incidents, fraud signals |
| Extract data | Pulls structured info out of free text (serial, date, location) | Conversations → ticket fields |
| Match | Links an item to the best match in a set (question → KB article, ticket → asset) | KB suggestions |
| Predict | Predicts outcome (no-show probability, ticket lead time, defect risk) | Preventive action |
What do you configure per use case?
| Field | What it's for |
|---|---|
| Name & description | What it does, in end-user language. |
| Type | One of the above (Classify, Summarize, etc.). |
| Inputs | Which fields we read (title, description, classification, KB)? |
| Outputs | Which fields it fills (category, priority, suggestion text)? |
| Confidence threshold | From what certainty is the suggestion shown / applied? |
| Fallback | What to do on low confidence — nothing, default value, ask a human? |
Which decisions will you make?
Which use cases do you prioritise?
Start with "Classify" (low risk, high impact). "Draft response" only after a strong KB.
Confidence strategy
High (only confident suggestions) = fewer but better; low = always show something but more noise.
Reuse across agents
One generic "Classify ticket" + service variations, or separate per service from the start?
Measurement strategy
How do you measure accuracy per use case? Decide upfront which "handler correction" counts as a miss.