What Counts as an AI Workflow (Not a Chat)

When an unstructured customer support email arrives, it may be tempting to send it directly to an AI assistant and use the generated reply, but this approach does not inherently provide a repeatable or auditable decision process. Reliable automation requires explicit routing, auditability, and logging rather than ad hoc prompting. In this lesson, we will explore five core parts of a verifiable AI workflow: triggers, processing steps, routing, side effects, and logging. You will also learn how to transform raw support text into a structured JSON triage object.

A support email arrives with a short subject line and an unstructured body. It mentions a billing issue, includes an order number, requests a refund, and reports an app crash. One approach is to send the text to a chat assistant and use the generated response directly. The response may be fluent, but it does not necessarily produce a structured decision that another system can execute.

A different way is to run the same message through a repeatable process that returns a compact decision object, for example, a JSON-shaped output with fields like category, priority, route_to, needs_human, and draft_reply. That object can be routed, audited, and logged as a record of what happened. The end state of this path is the ability to design, build, and operate AI-powered automations that are repeatable and inspectable rather than prompt and hope. For this chapter, the specific target is turning support text into a triage decision object that stays reusable later.

What makes it a workflow

With that contrast in mind, the key question is not whether the assistant produces a fluent response. The key difference is whether the workflow has explicit stages with defined, repeatable behavior and produces artifacts that another engineer can inspect and verify. In this course, an AI workflow is a system that transforms an input event into an output artifact through five explicit, inspectable stages.

Those five parts correspond directly to the support inbox triage workflow used throughout the course:

• Trigger means the condition that starts a run, such as a new message landing in the support inbox or a teammate manually selecting a thread to triage.

• Steps means the ordered actions that transform the input into intermediate and final outputs, such as extracting order identifiers, classifying the issue, and drafting a reply.

• Routing means the rules that send the case to the next place, such as choosing route_to=Billing or setting needs_human=true for escalations.

• Side effects mean the actions that change something outside the workflow output, such as creating a ticket, sending a reply, or assigning an on-call rotation.

• Logging means the record of inputs, outputs, and key decisions, such as saving the original message text, the returned triage JSON, and the route that was taken.

When these parts are defined explicitly, the same support message can be reprocessed, compared across runs, and reviewed against the recorded decision path. A standalone chat response usually does not provide those guarantees because it may not record the triggering event, enforce a structured output schema, or produce an audit log that captures the decision, inputs, and relevant execution context.

Rule: If we cannot name the trigger, the output, and the log entry for a run, we do not have a workflow yet.

The example triage output as a real, runnable JSON snippet:

What this chapter will produce and what it will not

With the workflow parts defined, it is important to clarify the scope and limitations of this chapter. No coding is required in this chapter, and the workflow described here should not be treated as production-ready. All external text, including email content, is treated as untrusted input. This matters because message bodies may contain irrelevant content, misleading claims, or instructions that should not influence routing. The workflow therefore needs explicit routing rules that remain separate from instructions contained in the message.

Inspectable means each run can be reviewed using a consistent set of recorded inputs, outputs, and decision context. Another reviewer should be able to inspect the exact input message, inspect the output decision object, and verify whether it conforms to the workflow rules without inferring unrecorded intermediate behavior. The two required artifacts for this chapter are a one-page workflow specification and a JSON-shaped triage output.

The key engineering questions are what events trigger triage, which fields the decision object must contain to support routing, which conditions trigger escalation, and which log entries are required so another teammate can audit a completed run.

We have established the defining characteristics of an AI workflow. A repeatable process requires a clear trigger, structured steps, defined routing, controlled side effects, and an inspectable log. By moving from free-form responses to structured JSON decision objects, we have established the basis for more reliable automation. The next step is to define the rules and one-page workflow specification that govern how the system processes untrusted input.