Build a support-routing sandbox before connecting a channel

Extract the task from the demo

Mckay Wrigley’s archived post describes a quick support agent that routes tickets to Slack channels. Its build-time and code-generation claims are not reliability evidence, and the video was not reviewed. Slack’s current message documentation makes channel identity and permissions explicit. That gives a concrete boundary for a sandbox task: selecting a destination is different from being allowed to send there.

Create a fictional ticket table

Write six short requests: an ordinary question, two topics in one message, an unknown product, a request containing sensitive-looking dummy data, a duplicate and a request for a restricted destination. Give each a human-written expected route or escalation decision. Include a reason and the smallest information the recipient needs. Start by asking the system to return a proposal without sending anything.

Evaluate the complete decision

Check destination, unnecessary disclosure, duplicate handling and whether uncertainty produces a human handoff. A wrong route is not fixed by a friendly acknowledgement. If the workflow is later connected under authorization, verify the actual returned channel and message record as well. This is an original sandbox protocol, not a tested support system, adoption result or instruction to contact real users.

Put it to work.

• Use fictional tickets.
• Label routes and escalation.
• Keep proposal and send separate.
• Check duplicates and disclosure.

Go to the source.

Original material, with its own scope and publication date. This note is an explanation, not a CooScope performance test.

1. @mckaywrigley — archived X post (2024-09-09)
2. Slack — chat.postMessage referenceLink / source review: 2026-10-15