Introduction

A workflow is a list of steps that run in order. Some steps fetch or read things, some ask a model to work on them, and some save the result or tell you about it. Each step can use what earlier steps produced, and you can run the whole list by hand, on a schedule, or each time a feed or a folder gets something new.

In this tutorial, you will build a workflow that watches the releases of a tool you depend on. The example uses uv, the Python package manager, because it releases often and its release notes are detailed. For every new release, the workflow reads the release notes, asks a low-cost model for a short summary, saves the summary, and sends you a desktop notification only when the release has breaking changes. You will test it safely, read what each step did, fix a step without rerunning the whole thing, and then approve it to run on its own.

You can follow along with any project on GitHub; only the feed address changes.

Key takeaways

• A workflow can start by hand, on a schedule (every day, on weekdays or every few hours), or when a new post appears in an RSS or Atom feed or a new file lands in a folder.
• Steps pass results to each other through values you insert from a menu, such as the post's link or the text a previous step produced.
• Each step that uses a model can pick its own, so routine work can go to a fast, inexpensive model.
• A Continue only if… step ends a run quietly when there is nothing worth your attention.
• Before a workflow runs on its own, it lists everything it will be allowed to do, and you approve the list. Anything more pauses the run and asks.
• Every run records what each step did, and you can rerun from any step without repeating the ones before it.
• The same workflow can be drawn as a canvas, can branch on a condition and run steps side by side, and can hand work to agents that ask before they act.

Prerequisites

To follow this tutorial, you will need:

• Conduit installed on Windows, macOS or Linux. Download the latest release from the releases page.
• A model provider set up in Conduit with your own API key. This tutorial uses GLM 5.3 Flash through OpenRouter for the summaries, but any provider works, including a local model. To set one up, follow one of the provider guides, such as Use OpenRouter in a desktop app.
• Desktop notifications allowed for Conduit in your operating system's settings, so you can see the alerts the workflow sends.
• (Optional) The address of a feed you care about. Every GitHub repository publishes its releases as an Atom feed at https://github.com/<owner>/<repo>/releases.atom.

Step 1 — Starting from a ready-made workflow

Conduit comes with ready-made workflows you can use as they are or change. In this step, you will create one that already watches a feed, and use it as the base for the release watcher.

Choose Workflows in the side rail, or press Ctrl+6 (⌘6 on macOS). If you have no workflows yet, the page lists the ready-made ones under No workflows yet; otherwise, choose New workflow to see them.

The list includes:

• Morning briefing — reads two sites and saves the top stories from each as one briefing.
• Watch a page — checks a page and only tells you when it has changed.
• Topic watch and Weekly research digest — search or research a topic and keep a digest up to date.
• Weekly numbers deck and Monthly report section — update a Slides deck or a Writing draft you choose.
• Summarize new posts and Inbox folder — run once for each new post in a feed, or each new file in a folder.
• Check notes against my docs — compares a notes file with passages from your document collections.
• Start from scratch — an empty workflow you build step by step.

Find Summarize new posts and choose Use this. Conduit creates the workflow and opens its page.

— enlarge Enlarge

The new workflow already has four steps: it fetches the post, asks the model to summarize it, saves the summary and shows a notification. Nothing runs yet; a workflow that watches a feed only starts watching once you turn on Run automatically, which you will do in Step 9. Next, you will point it at the uv releases.

Step 2 — Pointing the workflow at a releases feed

What starts a workflow is set in its Starts when section. In this step, you will change the feed this one watches from the Rust blog to uv's releases.

On the workflow's page, choose Edit. The header reads Editing followed by the workflow's name, with Edit as JSON, Cancel and Save. The steps are on the left. A side panel on the right holds Start (with the Starts when choices), then Asked each run, Helpers and Workflow settings, where you set the name, description, model provider and folder.

Make these changes:

1. In Workflow settings, change Name to uv releases.
2. Under Starts when, leave A new post appears in a feed selected and set Feed address to https://github.com/astral-sh/uv/releases.atom.
3. Set Check every to 360 minutes. A release watcher doesn't need to look every half hour; checking four times a day is plenty.

The other choices under Starts when are Only when I run it, or on a schedule, for workflows you run by hand or at set times; A new file appears in the workflow's folder, which needs a folder chosen under Workflow settings first; and Something new from a connector.

— enlarge Enlarge

The workflow now watches the right feed. Next, you will look at how its first step uses the post that started the run.

Step 3 — Fetching the release notes

Each run of a feed workflow is about one post, and the post's details are available to every step as values. In this step, you will see how the first step uses one of them to fetch the release notes.

Scroll to Steps. Each step is a card titled with its number and type, such as 1. Fetch pages, with a short id beside it, here fetch. The id is how later steps refer to this one.

The Page 1 field of the fetch step holds a chip for the post's link. Values like this are inserted with the Insert value… menu next to each field, which lists what is available at that point in the workflow:

• From the trigger — the post's title, link, summary, date and id.
• Earlier steps — what the steps above produced, such as fetch · text of the first page.
• Asked each run — values you fill in when you run the workflow, if you add any.

Leave the fetch step as it is. For uv, each post's link is the GitHub page for that release, so the step fetches the release notes. A fetch step reads up to ten pages, keeps up to 50,000 characters of each, and only fetches public https addresses.

Notice the If it fails, try again setting on the card: a fetch is retried twice by default, which rides out a brief network problem. Every step also has Keep going if this step fails. Leave it off here; without the release notes there is nothing to summarize.

The workflow can now read each new release. Next, you will tell the model what to do with it.

Step 4 — Writing the summary step and choosing its model

An Ask the model step sends one instruction and some text to a model and keeps the answer. In this step, you will write an instruction that suits release notes, and pick an inexpensive model for this step alone.

Find step 2, Ask the model, with the id summary. Replace its Instruction with the following:

Summarize these release notes for a developer who uses this tool every day.
List new features and fixes in at most five bullet points.
Then add a section titled "Breaking changes" that lists anything that could break
an existing project, such as removed options, changed defaults or new minimum versions.
If there are none, write exactly: No breaking changes.

The Text to work on field already holds the post's title followed by the fetched text, so the model knows which release it is reading. Leave it as it is.

The last line of the instruction matters. In Step 6, you will use that exact sentence to decide whether to notify you, so the model is asked to write it the same way every time.

Now choose the model. Under Model for this step, the default is Use the workflow's model, and the workflow's own Model setting at the top of the editor defaults to Follow the chat model, whichever model you last picked in a chat. For a routine summary, choose a fast, low-cost model instead. This tutorial uses GLM 5.3 Flash through OpenRouter.

— enlarge Enlarge

The workflow now produces a summary with a predictable last section. Next, you will make sure every summary is kept.

Step 5 — Saving every summary

A Save a document step stores text as a document you can open later. In this step, you will set it to keep one document per release.

Find step 3, Save a document, and set:

• Title — uv followed by the Post title chip, so each document is named after its release.
• Content — leave the summary chip and the Source: line with the post's link.
• Save as — Document.
• Each run — Adds a new document.

The other choice for Each run, Replaces the same document, keeps one document with the latest result, which suits a page watch or a daily briefing. For a release history, you want one document per release.

The save comes before the check you will add next, on purpose: every release is recorded, even the ones that don't need your attention today.

Next, you will add the step that decides whether to notify you.

Step 6 — Notifying only about breaking changes

A Continue only if… step checks a value and ends the run quietly when the check fails. In this step, you will add one between the save and the notification, so you are only notified about releases with breaking changes.

At the bottom of Steps, open Add a step… and choose Continue only if…. The new step is added at the end, so use its ↑ button to move it above Show a notification. Then set:

• Value to check — insert summary · text from Earlier steps.
• Continue only if it — doesn't contain.
• Text — No breaking changes.

The comparison ignores capital letters and extra spaces. The other tests are has changed since the last run, isn't empty, is empty, contains and is; the first one is what the Watch a page starter uses to tell you only when a page changes.

Finally, update step 5, Show a notification. Set Title to Breaking changes in uv and Message to the Post title chip.

If the model ever forgets the exact sentence, the check lets the notification through, so the worst case is one notification you didn't need, never a breaking change you missed.

Choose Save. If anything doesn't add up, such as a step reading a value that doesn't exist yet, the editor lists it under Fix these before saving: and keeps Save disabled until it is fixed. After saving, the workflow's page lists the five steps in plain words.

— enlarge Enlarge

The workflow is complete. Before you let it run on its own, you will test it.

Step 7 — Testing the workflow with Run now

A test run shows you exactly what the workflow will do, using real data. In this step, you will run it once by hand.

On the workflow's page, choose Run now. For a workflow that watches a feed, a run by hand uses the newest post in the feed as a test, so you don't have to wait for the next release. The button changes to Running…, a Stop button appears, and the run shows up under Recent runs as Test run: followed by the release name.

Almost all of the run's time is the model step. With GLM 5.3 Flash, the test run shown here took under a minute. When it finishes, its status reads Finished if the release had breaking changes and you got a notification, or Nothing new if the check ended the run after saving the summary. Either way, Saved: links to the summary it saved.

— enlarge Enlarge

Expect a model to judge borderline releases differently from run to run. uv 0.12.24 was mostly bug fixes, a few of which make uv stricter, such as checking supplied hashes even when hash checking is turned off. In two test runs on that release, GLM 5.3 Flash once listed those fixes as breaking changes and once wrote No breaking changes. If you want to hear about changes like these, say so in the instruction, for example: Count bug fixes that make uv stricter as breaking changes.

Choose a model that answers directly for steps like this one. A model that reasons at length before it answers can take many minutes over a long page, and a run stops when it reaches its 30-minute limit.

Next, you will open the run and see what each step did.

Step 8 — Reading a run and rerunning a step

Every run keeps a record of each step: what went in, what came out, which model it used and how long it took. In this step, you will read that record, change the summary, and rerun only the steps that need it.

Choose the test run under Recent runs. The section What this run did lists the steps, each with a status: Finished, Failed, Skipped or Reused. If the check ended the run, it says Nothing new — stopped at followed by the step's id, here check.

Expand the summary step. A line beginning Used names the model and provider it ran on, and below it are the step's Input and Output. Under Saved:, choose the document's name to open the summary itself.

Suppose the summary is longer than you want. Choose Edit, change at most five bullet points to at most three bullet points, and save. Then open the test run again, find the summary step and choose Rerun from this step.

The new run marks the fetch step as Reused: it takes the release notes from the previous run instead of fetching them again, and runs the summary, the save, the check and the notification with your new instruction. In the run shown below, the rerun took 10 seconds, against 16 for the full run, because the page wasn't fetched again. On a longer workflow, this saves both time and model calls.

— enlarge Enlarge

If a run fails, the same view shows which step failed and why, in plain words. Fix that step, then rerun from it.

The workflow does what you want. Next, you will let it run on its own.

Step 9 — Turning on automatic runs

A workflow that runs on its own must be approved first. In this step, you will review what the release watcher is allowed to do and turn it on.

On the workflow's page, choose the Starts chip under the description, which reads Starts · A new post in a feed (in Canvas view, select the Start step instead). The Start panel opens with a Schedule section; tick Run automatically. (← Back in the panel returns to the workflow.) Conduit shows a panel titled Let it run on its own?, which lists everything the workflow will be allowed to do without asking. For the release watcher, the list is:

• Read pages on github.com — to read the feed.
• Read pages at the addresses step “fetch” gets when it runs — the fetch step's address comes from the feed, so Conduit can't name the site in advance.
• Send text to OpenRouter, online — for the summary step.
• Save documents.

Notifications and the check need no approval. Choose Allow and turn on. The section now shows Watching github.com every 360 min, and a line beginning When it runs on its own, it may: keeps the approved list in view.

— enlarge Enlarge

If you later edit the workflow so that it needs something more, such as a new site or another provider, the page shows It needs your OK for more with an Approve button. Until you approve, an automatic run that reaches that step stops and asks. You get a notification, the run shows Waiting for you, and Home lists it under Needs you. You can choose Allow once, Always allow or Don't allow; if nobody answers within a day, the step doesn't go ahead.

The first time you turn on automatic runs, Conduit also offers to Keep running in the tray. Automatic runs only happen while Conduit is running, so accept if you close the window often. You can change this later in the same section, along with Start Conduit in the tray when I sign in.

— enlarge Enlarge

The release watcher is now running on its own. In the last step, you will see a faster way to start the next one.

Step 10 — Describing a workflow instead of building it

You don't have to build every workflow step by step. In this step, you will have Conduit draft one from a sentence.

On the Workflows page, choose New workflow. In Describe a workflow, type:

Every weekday at 9:00, read the Hacker News front page and the Lobsters front page, and save one list of the stories about Rust or Python.

Choose Draft it. The chat model writes a workflow, Conduit checks it the same way it checks a workflow you save, and sends any problems back to the model to fix. The draft opens in the editor unsaved: nothing is saved or scheduled until you choose Save and turn it on yourself.

The model never chooses things only you can choose, such as a folder, a deck or a document collection, and it doesn't turn on schedules. When a draft needs any of these, the editor shows Still to fill in before you save with a short list. For the description above, the list reads Turn on the schedule: every weekday at 9:00., a reminder to set the schedule on the workflow's page after you save it.

— enlarge Enlarge

There are two other ways to start a workflow from words:

• From Home. Type what you want in the ask box and choose the Automate chip; Conduit opens Workflows and drafts it.
• From a chat. After doing something by hand in a chat, open the command palette with Ctrl+K (⌘K on macOS) and choose Save chat as workflow…. The draft is based on what you asked and which tools were used; the model doesn't see the pages or documents themselves.

Either way, review the draft, test it with Run now, and only then turn on Run automatically.

Going further: canvas, branches and agents

The release watcher is a straight line, but a workflow doesn't have to be. Four things build on what you have just done.

• The canvas. Switch Canvas on in the steps view to see the start, each step, loops and the lines between them. During a run, each step shows whether it is running, finished, failed, skipped or waiting for you, and selecting a step shows its input and output. In the editor you can add steps from a palette, drag them to reorder, and drag a wire from one step to another to choose which output goes into which field, instead of typing it.
• Branches and side-by-side steps. An If… otherwise step sends the run down a Yes or No path; the path not taken is recorded as Not taken. A step can wait for several earlier steps, so steps that don't depend on each other run side by side, up to four at once, and a later step can join them. Replacing the Continue only if… step in the release watcher with a branch, for example, could notify on one path and only save on the other.
• Results. Everything a finished run saved is kept with a preview. Open a workflow's Results tab, or the Results list in the Workflows sidebar for every workflow, and use Open to read it.
• Agents. A Let the model use tools step can use up to ten connector tools and hand tasks to helpers you define, each with its own instructions, model and token limit. A connector tool that sends, posts or edits something pauses the run and asks, and the Inbox collects everything your workflows are waiting on. With Settings → Computer turned on, an agent can also run commands and change files in a folder you name, and every command asks first unless a rule you allowed covers it. The Workflows documentation lists the limits.

Every step type at a glance

The release watcher uses five kinds of step. Here are all of them, as they appear in the Add a step… menu:

A workflow can hold up to 50 steps. Every text field in every step can include inserted values, and the whole definition can be edited by hand with Edit as JSON in the editor. In that view, inserted values are written as {{steps.summary.text}} or {{trigger.link}}; to write the braces themselves, put a backslash before them: \{{.

For reference, this is the release watcher you built, as the JSON view shows it:

{
  "steps": [
    {
      "id": "fetch",
      "type": "fetch_page",
      "urls": [
        "{{trigger.link}}"
      ]
    },
    {
      "id": "summary",
      "input": "{{trigger.title}}\n\n{{steps.fetch.text}}",
      "model": {
        "model": "z-ai/glm-5.3-flash",
        "provider": "openrouter"
      },
      "prompt": "Summarize these release notes for a developer who uses this tool every day.\n…",
      "type": "summarize"
    },
    {
      "content": "{{steps.summary.text}}\n\nSource: {{trigger.link}}",
      "id": "save",
      "mode": "create",
      "title": "uv {{trigger.title}}",
      "type": "save_artifact"
    },
    {
      "id": "check",
      "is": "not_contains",
      "text": "No breaking changes",
      "type": "condition",
      "value": "{{steps.summary.text}}"
    },
    {
      "body": "{{trigger.title}}",
      "id": "notify",
      "title": "Breaking changes in uv",
      "type": "notify"
    }
  ],
  "trigger": {
    "everyMinutes": 360,
    "kind": "feed",
    "url": "https://github.com/astral-sh/uv/releases.atom"
  }
}

Questions

Conclusion

In this tutorial, you built a workflow that watches uv's releases: it fetches the notes for each new release, summarizes them with a low-cost model, saves every summary, and notifies you only about breaking changes. You tested it with a real release, read what each step did, reran it from the step you changed, and approved exactly what it may do on its own.

The same pattern of fetching something, asking the model about it, keeping the result and only alerting you when it matters fits many routines. Try pointing a copy at the releases of every tool your project depends on, use Watch a page on a pricing or status page, or let Inbox folder summarize each file you drop into a folder. To go further, explore these guides:

• The Workflows documentation, for every setting and limit.
• How to do deep research with Conduit and Exa, to learn the Research runs a workflow's Research a topic step uses.
• The provider guides, to choose and set up the models your workflows use.

Download Conduit

Conduit details match the latest release and are checkable in the documentation and the source. Found an error? Tell us and we will fix it.

Related

• How to do deep research with Conduit and Exa — Turn on Exa search, write a research brief and read a cited report in Conduit, with solar cell research as the worked example. No Exa key needed.
• API pricing vs a monthly subscription — How many messages a day before pay-per-token beats a $20 subscription? A calculator, plus why conversation length moves the answer more than volume does.
• How to demo an MCP server to a customer — Hosting an MCP server is not a customer demo. Compare a hosted chat, Claude Desktop with an extension, and your own client — and what you can ship today.