I’m building AI-powered automations using independent AI triage scripts (e.g., spam check, tag determination). These currently run concurrently, which is inefficient. I need to “chain” them so, for example, the tag script only runs if the spam script doesn’t flag the content.
How can I govern and orchestrate these scripts for a more logical workflow? Specifically, how can I chain these scripts conditionally?
Custom tools already have support now for scripting so we have a great vehicle for this kind of change.
I am thinking Persona + forced tool use - then from the tool we can run the flow given we already have all the infra to do so. Just need to give custom tools the ability to trigger other llm calls, something that is reasonably simple to add.
Interestingly given custom tools have support for rest calls they can run the entire flow (and just use the discourse rest api to wire this up)
Let me have a think about this over the weekend, and will reply again next week with how I think we can swing this.
Automation chaining is also a very interesting approach here, @j.jaffeux have you thought about this problem?
Hi @Cloud_spanner I am trying to get to the bottom of this and would like to flesh out the actual flow here a bit more, can you help with some answer to questions along the way 5. ?
Which posts should be scanned?
Every new post on the forum?
Every new topic - eg post number 1 - on the forum?
What about edits? Should every edit be scanned? At what frequency? (10 minute debounce)
What about high trust users? People that already posted twice on the forum?
Intent
Should it apply to ALL topics? ALL posts?
What if an intent tag is already there?
Can a topic have more than 1 intent (is this a tag group?)
If intent can be manual, should manually tagged stuff also be scanned for “hot button”?
Is hot an invisible tag or visible tag?
Particularly, what I am thinking about here is:
Does the “workflow” contain shortcuts, where particular posts just skip steps an proceed to next
Every new topic should kick off an AI triage workflow. Edits can be ignored.
To be clear, I am using intent to illustrate the workflow so it shouldn’t be considered a hard-coded flow. The point I am trying to make is that there is no reason to kick off ‘intent’ workflow if the first triage workflow deems it unnecessary. +1 to the IFTTT workflow concept.
Intent and ‘hot’ would be invisible tags in this example visible to mods and admins only.
There should be one intent tag per post.
I think for the sake of the workflow, we can ignore manually tagged posts.
Yes.
What if a private tag was used to show that the flow has run for that topic? And then it can be ignored for any future runs.
Another thought I have is that with the increased ability for LLM “reasoning” + large context windows would it be better to allow for structured outputs in the Discourse Automation window. IFTTT logic could then just be applied to a single automation instead of chaining multiple automations together. Imagine if there were the ability to have one automation, but many “Search for text” actions.
We can then allow it a few more functions such as llm.generate and topic.close, topic.tag and so on which could be used by the tool to perform these types of workflows.
Another advantage this has is that you could even test it which would make it easier to tune it.
That sounds like a great idea. I’m still newish to the Discourse ecosystem, so I’ll dig into Custom Tools and also how feature requests make their way into production.
스팸 탐지기와 자동화(Automation) 스크립트의 실행을 오케스트레이션(조율)하지 못하는 문제를我也 겪었습니다.
좋은 소식은 Discourse가 이제 “Workflows” 핵심 플러그인을 만들었다는 것입니다. 이 플러그인은 “Automation” 플러그인과 동일한 유형의 애플리케이션을 지원하지만, 훨씬 더 강력하고 유연한 방식으로 작동합니다:
여기서 요청된 오케스트레이션은 Automation 플러그인을 통해 구현되던 시스템을 Workflows 플러그인을 사용하여 구현할 경우 달성할 수 있습니다.
제 Automation의 목적은 스팸일 가능성이 높지만 확정적이지는 않은 특정 특성을 가진 게시글에 플래그를 올리는 것이었습니다. 제가 겪은 문제는 이러한 동일한 특성들이 Discourse AI 스팸 탐지 시스템이 플래그를 올리는 스팸 게시글에도 자주 존재한다는 것이었습니다. 이로 인해 Automation이 중복된 플래그를 자주 올렸고, 이는 모더레이터에게 무의미한 추가 작업을 발생시켰습니다.
위에서 제시된 "모든 것을 하나의 Automation으로 통합한다"는 우회 방법은 제 시스템에는 적용할 수 없었습니다. 저는 두 시스템을 의도적으로 분리했기 때문입니다:
스팸 탐지 시스템의 역할은 스팸일 가능성이 높은 게시글을 탐지하는 것입니다.
제 보조 시스템의 역할은 스팸일 가능성이 있는 게시글을 모더레이터의 주의를 끌기 위한 것입니다.
Discourse AI 스팸 탐지기는 Discourse 프레임워크 내에서 특수한 구현을 가지고 있으므로(포럼 관리자에게 제공되는 Discourse AI 프레임워크만으로 작동하는 것이 아님), 저는 Automation으로 이를 대체하려는 관심이 없었습니다.
또한, 제 보조 시스템을 스팸 탐지기에 통합하는 것(프롬프트에 지침을 추가하는 것)도 적절하지 않았습니다. 스팸 시스템의 게시글을 즉시 숨기고 작성자를 무음 처리하는 동작은 높은 정확도로 작동하도록 구성된 한 적절합니다. 반면, 제 보조 시스템은 본질적으로 오탐(false positive)이 발생하기 쉬우므로, 인간의 검토 전에 해당 사용자에게 영향을 미치는 플래그를 올리지 않아야 합니다.