Our summary
Perplexity’s recipe sorts twelve fictional support tickets and can optionally draft investigation plans. Its own decision model, not Jev, judges whether a person needs to act, what the customer wants and how serious the impact is. Python code then labels each ticket with what should happen next.
The rules check danger first, including the probability of the most serious outcome, not only average severity. Unclear categories get a review label before low-risk tickets can qualify for automation. An optional service drafts plans for tickets marked for urgent attention; the script does not contact responders, send replies or carry out repairs.
Perplexity reports three tickets marked urgent in its twelve-ticket run, not a real-world success rate. Its example numbers determine which label a ticket gets. Test those numbers against tickets people have checked and labelled. Saved results are model predictions, not verified answers, and the whole ticket goes to Perplexity.
Key takeaways
- Check the chance of a serious outcome before uncertainty and automation; an average can hide a dangerous possibility.
- Leave room around borderline answers and test routing changes against tickets people have labelled, not model answers alone.
- Distinguish assigning an automated route from actually replying, and account separately for optional investigation calls.