Introducing the AI Node in Courier Journeys

The AI node is a new step inside Courier Journeys that classifies users, branches a journey based on the result, and writes per-channel message copy, all from a single prompt. Drop it between your trigger and your sends, define an output schema, and the rest of the journey reads structured data the model returns.

This post covers what the AI node does, how to set one up, and the use cases where it actually helps.

What the AI node does

The AI node sits inside a Courier journey. It reads data from the trigger payload (an API invoke, or an event from Twilio Segment), runs a prompt against a model you choose, and returns structured output the rest of the journey reads.

Three common jobs:

• Classification. Sort a user into one of N categories and branch the journey on the result.
• Personalization. Generate subject lines, email body copy, push titles, in-app text, anything that has to vary per user.
• Summarization. Compress a noisy event payload into one or two sentences a message template can drop straight into the copy.

The whole point is to replace a thicket of conditional rules and template variants with one node and one prompt. Fewer nodes to maintain, and a journey that's easier to change later.

Setting up an AI node

You configure an AI node in four passes: write the prompt, define the output schema, pick the model, and test.

1. Write the prompt

Give the model a role, name the inputs it'll receive, and describe the task to complete. The data comes from the trigger payload, so reference fields the same way downstream nodes do (for example, {{user.email}} or {{account.arr}}).

A useful pattern is to combine roles in one prompt: an analyst that classifies, and a copywriter that writes. Describe the inputs (account attributes, usage data, qualitative notes), name the decision the model needs to make (which category to assign), and list the outputs you want back (subject lines, message bodies, push text) in concrete terms. The more specific the prompt, the more consistent the output.

2. Define the output schema

The schema tells the AI exactly what fields to return. Downstream sends read from this schema through Handlebars, so the field names you pick are the names you'll use in templates.

You can define the schema two ways:

• JSON. Full control over types and structure, paste-friendly.
• Form builder. Click-to-add fields, useful for quick iteration without hand-writing JSON.

Both produce the same structured response at runtime. Pick whichever is faster for the work in front of you.

3. Pick the model

Model choice covers the latest from Anthropic and OpenAI. Match the model to the job:

• Heavy reasoning or nuanced writing: a frontier model from either provider.
• Light classification on a tight schema: a smaller, faster model that returns quickly and costs less.

If you pick an Anthropic model, you get an extra toggle: web search. Turn it on when the prompt benefits from current information (a recent event, fresh competitive data, an external lookup). Leave it off when everything the model needs is already in the payload. It's faster and cheaper without it.

4. Test before launch

The configuration panel has a test mode. Paste in a sample payload, run the node, and inspect the output. Iterate on the prompt and schema here, before any real user touches the journey.

Wiring the output into sends

After the AI node, each send pulls its content from the output schema through Handlebars.

For an email send:

• Subject line: {{aiResult.emailSubject}}
• Body: {{aiResult.emailBody}}, dropped into a drag-and-drop template designed in Design Studio.

In-app, push, and SMS sends bind their fields the same way. Because the AI writes a version per channel, you don't hand-tune copy for one channel and lose the others.

Templates are designed in context with the journey, so you don't bounce out to a separate library to wire up the bindings.

Branching off the output

Add a branching node after the AI node and point it at the field you nominated for routing (category, for example). Each value gets its own path. Skipped branches don't fire.

This is where the AI node pays off. Instead of building a tree of conditional rules around computed scores, the model judges once and the rest of the journey acts on the result.

When to use the AI node

The AI node is most useful when:

• The decision depends on something hard to compute, like a fuzzy classification, sentiment, or the overall tone of an account
• You want personalized copy across channels without writing five variants by hand
• A clean implementation would otherwise require a half-dozen conditional nodes and template variants to do the same job

It's less useful when the rule is simple, like if plan == 'free' and trialEndsIn < 3. Use a regular condition node for that. AI nodes add latency and cost; they're worth using when the work isn't easily expressed in code.

What to build next

Spin up a journey, drop in an AI node, give it a prompt and an output schema, and run a test invoke. The whole loop takes a few minutes to set up, and the result is easier to maintain than nested conditions and a wall of template variants.

For product or growth teams that want personalized messages at scale without maintaining a tree of rules, this is the node to reach for.

Read the Journeys docs or start building a journey.