Course lesson 29 · Building AI Workflows

Create an AI Workflow Step

One study unit · Read, recall, then practice · Original video 00:21:52

The course implements an AI destination-checking helper with a Zod output schema, the Workers AI provider, and the AI SDK’s recorded generateObject API. The helper receives extracted page text and returns an availability status plus a concise reason, and a new workflow step calls it with a restrained retry policy. Testing reveals an important limitation: a more detailed prompt still produces an unknown result when the collected page content is incomplete or unexpected.

Primary source: course video 29 · Supplied English subtitles · 00:21:52.

Understand the idea

Using body text reduces irrelevant markup in the prompt and avoids spending tokens on styling and layout.
The schema permits available, unavailable, and unknown outcomes so incomplete evidence need not force a confident answer.
Field descriptions and the main prompt explain what evidence should justify each classification.
A reason makes a classification inspectable, but the instructor’s belief that reasons improve accuracy is an empirical preference, not a guarantee.
Model/provider selection is separate from the workflow that coordinates rendering, inference, and persistence.

What the course does

Create the AI helper and define its status-and-reason output schema.
Add the AI binding, regenerate types, and configure the Workers AI provider.
Call the structured-output API with a supported model, instructions, the extracted body text, and the schema.
Add an AI workflow step with a deliberately limited retry policy.
Test an unavailable AliExpress listing: the first run reports unavailable, though its explanation is not the expected evidence.
Strengthen the prompt and rerun; the result becomes unknown, motivating storage of the actual scraped input for diagnosis.

Watch for

Recorded SDK versions and APIs need checking before copying them into a new project.
HTTP 200 did not prove the renderer received the expected product information.
Added advice: keep a small labelled evaluation set and compare changes against it; one plausible output does not establish accuracy.

Follow the final workflow correction in lesson 34 when combining these steps.

Recall before revealing

Why is the unknown result useful evidence rather than simply a failed prompt?

Reveal the explanation

It can indicate that the model was given missing or different page content; the pipeline must inspect its input before blaming the model.

Try it

Write three short page-text samples: clearly available, clearly unavailable, and missing product information. State the expected status and supporting phrase for each.

Check your result

Your expected results distinguish uncertainty from unavailability and can be used as a small repeatable evaluation set.

Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.

Rewatch only what you need

Open this lesson in your original course library and seek to the times below. Videos are not hosted on this site.

00:02:59 — Body text rather than full HTML as model input
00:04:27 — Zod output schema
00:10:24 — Workers AI binding
00:13:44 — AI step and retry budget
00:20:21 — Unknown result despite successful HTTP status

Companion primary documentation: Workflows Workers API. For recorded API names, commands, limits, and prices, check the version you use.

← Previous Next →