Workflows

A workflow decides what happens to a piece of content after your policies score it: auto-action, route to a human queue, escalate, or clear.

Workflows are how Musubi orchestrates multi-policy decisions in production. If you only run a single policy, you may not need one. If you combine multiple policies, route by risk score, or want different actions for different categories of violation, you need a workflow.

⚠️ Workflows are a power-user surface. There's no UI yet, and they're complex enough that we recommend building your first few together with the Musubi team. Reach out in your shared Slack channel before you start.

What's in a workflow

Every workflow has:

• A name (lowercase letters, digits, and hyphens; unique in your org: e.g. spam-triage)
• An optional description
• One or more versions, each carrying the workflow's source code

Editing a workflow creates a new version; older versions stay available for audit and rollback.

Sending content to a workflow

You can send content to a workflow two ways. Ask the Musubi Agent to run a review (more on that in the next section), or send a request to the review API endpoint from your own system. Both take the same payload, and both let you choose the workflow by name.

We recommend keeping two workflows: one for testing and one for live content. For example spam-triage-dev and spam-triage-prod. This allows you to make workflow changes on the test (dev) workflow first. Once the results look correct, then make the same changes to your live (prod) workflow via the Agent or Musubi team.

Each workflow defines the input it accepts. Ask the Agent what your workflow expects, or open the workflow in the app to see its input

Building a workflow with the Musubi Agent

The Agent can draft, test, and propose new versions of workflows for you. It's the fastest path today, and the one we recommend while there's no UI.

A typical session looks like this:

1. You describe the logic in plain language: which policies to call, thresholds on risk score or labels, and what should happen at each branch.

   Here’s an example prompt:

   *Build a workflow for user-generated comments. Input is a single text field called content.

   1. First, run the comment through the spam-detection policy, version 3. If the label is Spam or Scam, stop immediately and return the decision REMOVE with reason "spam" and the risk score. Don't call anything else; there's no point paying for a second check on spam.
   2. If it clears spam, run it through the harassment policy, version 5, and the hate-speech policy, version 2, in one batched call.
   3. Branch on the results: ◦ If either policy returns a risk score of 9 or higher, return REMOVE with the reason set to whichever label fired. ◦ If either is flagged with a risk score between 6 and 8, send it to human review with the trigger reason "elevated risk, needs a second look", and return ESCALATE along with the highest risk score. ◦ If either is flagged but the risk score is 5 or below, return APPROVE_WITH_NOTE and include the label, so we can track soft flags without actioning them. ◦ If nothing is flagged, return APPROVE. The output should always include: decision (one of REMOVE, ESCALATE, APPROVE_WITH_NOTE, APPROVE), reason (a string), and score (the highest risk score across the policies that ran)*

   Here’s what that flow looks like. (Fun fact: the Musubi Agent created this. You can ask it to create a visual flowchart for you as well, if you want to see what your workflow is like, or share with others).