Build the Triage Workflow with an LLM API

With the primitives and near-neighbor distinctions from the last lesson in hand, it's time to put them to work. A minimal triage workflow only needs three steps to prove the integration works: a trigger that emits one sample support message payload, an action step that sends the message text to an LLM API over HTTP, and a final step that stores and displays what came back so it can be inspected later. Along the way, we'll wire the HTTP request itself, decide what to store for debugging, and verify the whole run using evidence rather than guesswork.

The key is visibility after a run. The run must show the exact request body that was sent, the HTTP status code that came back, and the full response JSON so the location of the model output text can be verified, since it varies by provider and even by API method.

Once the first run succeeds, keep the raw response even if the next step parses JSON out of it. When parsing fails later, the raw response is the only evidence that distinguishes a retrieval miss from an authorization error or a formatting issue.

Rule: Store raw_response on every run before attempting to extract triage_json.

We build this in the Support Inbox Triage workflow from the last lesson. The finished version has four nodes. The fourth, a small mapping step, is the data mapping primitive made visible: it gives the sample message stable field names before anything else reads it.

• Trigger: New Support Message, A Manual Trigger. It starts one run each time we click Execute workflow. In an upcoming lesson, we will swap it for a webhook or a polling trigger without changing anything after it. ...