sam announced built-in support for decision models in Discourse AI, a feature championed by TypeSafe.ai and also implemented by providers like CloudFlare and OpenAI. These models allow for fast, accurate, and cheap classification of text and images by answering arbitrary questions, offering a better cost/speed/accuracy profile than using standard language models for this purpose. The feature is currently available for users with Discourse Workflows enabled, providing a new “Classify” model node that can drive use cases like automatic moderation, team notifications, and tagging.
satonotdead highlighted the utility of these models for response triage and proposed using them as a gate in agent architectures. sam expressed interest in exploring this as a way to route requests to the correct sub-agent. satonotdead detailed a potential implementation where a decision model selects from existing sub-agent descriptions based on confidence thresholds, falling back to the parent LLM if confidence is low. This approach could also serve as a guard to enforce strict rules, such as blocking investment advice requests in an educational community.
Regarding access, sam noted that people hosted by CDCK get pre-configured access, while self-hosters can try the service for free at vllm-sr.ai. putty shared a practical success story, using the new workflow to reliably detect and flag unwanted auto-responses from service email addresses (e.g., ticket creation notifications), which previous LLM-based attempts struggled with due to false positives. However, putty encountered a minor bug where the integrated AI tool could not detect the hosted decision model ID, requiring manual entry. Falco acknowledged the bug and linked to the relevant GitHub pull request addressing the issue.
I am very happy to announce we now have built-in support for decision models.
Decision models were championed and first developed by TypeSafe.ai and since then have been implemented by numerous providers including CloudFlare (clef), Open AI (decisions api) and many more.
They allow you to classify text and images by answering arbitrary questions about the inputs quickly, accurately and cheaply.
The new intelligence can be used for a very large amount of workflows given it allows you to classify text (and images) using your own designed classifier.
Automatic moderation - get notified when discussions get heated
Notify particular team members when particular topics are discussed
Automatic tagging and categorization
And much more
Enjoy, and please share interesting workflows you come up with.
I find this great for response triage agents; I’m already in my first tests to see how it goes. I understand that these new models for decision-making are very precise and fast, and I’m glad we can have them in Discourse.
I wonder if there are plans and/or if it is technically possible to incorporate them into common agents as well, to develop ‘Senior Helpers’ that first classify before delegating. Or does that not make sense at all?
It’s likely that I haven’t yet fully understood their real best use case, and maybe I’m asking something out of place.
I think there are a large number of uses here, using them as a gate that finds the right agent or subagent to answer is certainly something I want to explore
a chart a member shares, reviewed against our public method
Today the parent LLM reads the subagent descriptions and picks one with spawn_agent. The gate would take that decision from it:
A gate setting on the agent, pointing to a decision model.
The choices are the subagent descriptions that already exist, plus “answer yourself”. Nothing new for admins to write.
Only the subagents the current user can access are offered.
Above a confidence threshold, the subagent runs directly. Below it, the result reaches the parent LLM as a hint and the LLM decides, as it does now.
Since decision models classify images, “member shared a chart” comes from the image itself.
The same gate, as a yes/no question, would also work as a guard before the LLM runs.
We’re an education community and we don’t give signals, price targets or investment advice, so “is this asking for a trading signal?” → fixed reply. Today that rule is a line in every prompt, and models drift from it under pressure.
If you get to it, we’d be glad to try an early version on our forum.
This is awesome! This seems to have solved a big pain point for us: sometimes users sign up with a service email address, which, when it receives an email, auto-responds, creates a ticket, etc.
This often resulted in random “your ticket has been created” posts popping up. These weren’t considered true “autoresponses” that would be blocked otherwise. I was tolerating the private message versions (gradually adding patterns to the email ignore by title settings), but the public ones were frustrating.
I tried an LLM workflow to detect these, but it had too many false positives. After doing several tests, this workflow has reliably caught and flagged them all
Super slight bug with this experience: I used the integrated AI tool to build this, but it couldn’t see the CDCK Hosted Decisions model, and there’s no way to see the ID # from the Models page (there’s no edit button to dig into it). I knowingly told it the wrong ID #, knowing I would have to update it manually.
