AI Learning Hub › Learn AI › Self-Paced Courses › Introduction to AI › Intermediate › Building Repeatable Workflows

Level 3 of 4 · Intermediate · Lesson 6 of 6

Building Repeatable Workflows

Moving from one-off chats to repeatable processes using reusable instructions, projects, templates, skills, and human review.

About 25 minutes

Skip to lesson

By the end of this lesson you should be able to

  • Distinguish reusable instructions, templates, projects, saved procedures, and a workflow with human checkpoints
  • Design a small workflow with authorized inputs, a named reviewer, stopping rules, and a retained record
  • Recognize the signs that a workflow needs revision

Why this matters

Once an AI-assisted task works, you will want to repeat it: the weekly digest, the reading reminder, the monthly summary. Repetition saves setup time, and it can also carry an error forward from one run to the next unless the process is built to catch it. The question for this lesson is: how do I repeat useful AI-assisted work without repeating its mistakes?

Five ways to reuse, from simplest to fullest

Reusable instructions
A saved bounded task (Lesson 1) that you paste in each time.
Templates
A fill-in structure for the inputs or the output, such as the context packet (Lesson 2) or the verification log (Lesson 4).
Projects
A space in some products that keeps files and standing instructions together for a recurring task. (Not the same as an organization’s managed workspace; see Getting Started Lesson 1.)
Saved procedures, or skills
Packaged instructions that a tool can load when a task calls for them. The Hub’s AI Skills are examples.
A workflow
A defined sequence of steps for accomplishing a task. This lesson teaches a human-reviewed kind, with named people deciding at named points; that is the design recommended here, not something every workflow has. A skill or saved procedure can encode a workflow, but saving instructions does not by itself put the reviews in place or show that they work.

How these work varies from product to product and changes often, so this lesson is about design, not setup. If you want to try a saved procedure, the Hub’s guide to installing a skill walks through it.

A portable workflow

This sequence fits most small, recurring tasks, whatever tool you use:

  1. Task: the bounded task, saved and versioned.
  2. Authorized inputs: the specific sources you are permitted to use for this task, and nothing else.
  3. Preparation: gather the inputs, check their dates, and assemble the packet.
  4. AI step: the assistant drafts, extracts, or summarizes.
  5. Review: a named person checks the output against the inputs and the criteria.
  6. Correction: fix the output, or send it back a step.
  7. Human-approved output: a named person approves it before it is released to its intended audience. Authorized reviewers can see drafts before then.
  8. Retained record: keep what is needed (which inputs, which version of the instructions, who reviewed, and what changed) in an authorized location, following any access and retention rules that apply.

Three things turn that sequence into a workflow someone else could run:

  • Who reviews what. “Someone checks it” is not a step. Name the role and what they check.
  • Stopping rules. Conditions under which the output does not go forward: an input is out of date, a required fact is missing, the draft contains something not in the inputs.
  • A record. A later editor should be able to see which sources and which instructions produced this week’s version. Record what that requires, and no more: a workflow log is not permission to keep every source indefinitely.

Keep any external action, such as sending, posting, or publishing, as a manual step taken by a person after approval. Systems that act on their own, and how to supervise them, are covered in the Advanced level.

Worked example: a weekly events digest, including the week it went wrong

A constructed example. The office, events, and dates are fictional.

Each Monday, a library staff member posts a short digest of the week’s public events. The workflow:

  • Inputs: this week’s export from the public events calendar, and the saved instruction (version 1.0). Nothing else.
  • Preparation: export the calendar and confirm the export date is today.
  • AI step: draft a digest of up to three events, using placeholders for anything missing.
  • Review: the staff member checks every date, time, and room against the live calendar.
  • Approval: the communications lead approves before the staff member posts it by hand.
  • Stopping rules: stop if the export is not from today; stop if any event lacks a date, time, or room; stop if the draft names anything not in the export.
  • Record: export date, instruction version, reviewer, approver, and changes made.

The week of October 12. The draft comes back looking finished. Review finds three problems:

  1. An outdated source. The export is dated October 5: last week’s file was reused, so the preparation check on the export date was missed or did not work. Stopping rule 1 applies at review instead. The staff member re-exports; one event on the old list had been canceled.
  2. A missing fact. The calendar lists the Research Commons open house with no start time. Stopping rule 2 applies. The staff member asks the organizer.
  3. An invented detail. The draft gave the open house a time of 12:00 p.m., which appears nowhere in the export. Stopping rule 3 applies, and the pattern matters: the instruction asked for placeholders, and the draft filled the gap anyway.

The staff member rejects the draft, gets the current export and the missing time, then rebuilds the draft and reviews it again; it does not go out until that review and the approval are done.

They also revise the saved instruction to version 1.1, adding: “If an event has no time listed, write [TIME TO CONFIRM]. Never supply a time.” A revised instruction is not evidence that the problem is fixed, so they retest it on a sample event with no time listed before relying on it, and the human release check stays in place. The record notes what went wrong and what changed. A workflow that only describes the week everything goes right is a description, not a safeguard.

Try it: design a small workflow

A constructed scenario. The seminar, reading, and rules are fictional.

A teaching assistant sends a short weekly reminder to a seminar: this week’s reading, where to find the discussion question, and the response-paper deadline. The TA wants an assistant to draft it each week. The materials:

  • Syllabus, Weeks 6–7: “Week 6: Reading 6 (all parts). Week 7: Reading 7. Response papers are due Tuesdays at 9:00 a.m.”
  • The instructor’s note for Week 6: “For Week 6, read only Parts I and II of Reading 6. The discussion question is posted on the course site. Response papers are still due Tuesday at 9:00 a.m.”
  • The instructor’s rules for the TA: the TA may not change readings or deadlines. The instructor must approve any reminder that differs from the syllabus. Reminders are sent by the TA through the course site.

Fill in the template below for this workflow.

One-page workflow template

PURPOSE: [What the output is for, and who receives it]
INPUTS: [The specific sources to use, with how to confirm they are current]
PERMISSIONS: [What information may be used, in which tool, and what must not be included]
STEPS: [Preparation -> AI step -> review -> correction -> approval -> manual send or post -> record]
OUTPUT REQUIREMENTS: [Content, length, placeholders for unknowns]
REVIEWER AND APPROVER: [Who checks what; who approves]
STOPPING RULES: [When the output must not go forward]
VERSION AND REVIEW NOTES: [Instruction version; what to record each time]
SIGNS THE WORKFLOW NEEDS REVISION: [What would tell you to change it]
A model workflow and discussion

One reasonable version. Yours may differ in wording and detail; what matters is that each line settles who decides and what stops the output.

  • Purpose: a weekly reminder for seminar students with the reading, where to find the discussion question, and the paper deadline.
  • Inputs: the syllabus entry for the week and the instructor’s note for that week, if there is one. Confirm the note is for the current week.
  • Permissions: first confirm with the instructor that AI-assisted drafting is allowed for these reminders, and which service and account to use; the rules about sending do not settle that. Then: course schedule information only, with no student names, grades, or individual information in the tool or the reminder.
  • Steps: gather both inputs; draft with the assistant, telling it that the instructor’s note controls where it differs from the syllabus; the TA checks the draft against both; if the reminder differs from the syllabus, send it to the instructor for approval; the TA sends it through the course site; record it.
  • Output requirements: under 100 words; reading with its parts, the question’s location, the deadline with day and time; a placeholder for anything not in the inputs.
  • Reviewer and approver: the TA reviews every week. The instructor approves any reminder that differs from the syllabus, as Week 6 does.
  • Stopping rules: no instructor note and no syllabus entry for the week; the note and the syllabus conflict in a way the note does not resolve; the draft changes a reading or deadline that the instructor did not change, or adds anything not in the inputs; a reminder that differs from the syllabus has not been approved. (A change the instructor supplied, like Week 6’s, is not a stopping condition; it goes through the approval step.)
  • Version and review notes: instruction version, the inputs used and their dates, who reviewed and approved, and what was changed.
  • Signs it needs revision: the same correction is needed two weeks running; students ask about something the reminder should have said; the course site or the instructor’s process changes.

For Week 6 specifically, the reminder must say Parts I and II only, and because that differs from the syllabus, it needs the instructor’s approval before the TA sends it.

Build the failure path first. Before you reuse a process, write down who checks the output, what makes it stop, and what you will record. If those are missing, an error in one run can pass into the next without anyone noticing.

Level check: putting the Intermediate lessons together

A light self-check across the level, not a graded test.

A constructed scenario. The schools and their policies are fictional.

A faculty member asks a research assistant for a one-page comparison of how three peer schools’ course AI policies treat exams, to be updated each semester. The research assistant has each school’s current policy page, an older version of one school’s policy, and a news article from two years ago.

  1. What must be clear before the research assistant asks an assistant for a draft? (Lesson 1)
  2. What goes into the context packet, and how is it labeled? (Lesson 2)
  3. One school’s policy page never mentions exams explicitly. What should the comparison say? (Lesson 3)
  4. The draft says, “All three schools require written instructor permission for AI use on exams.” What next? (Lesson 4)
  5. The comparison is a table. What must it preserve? (Lesson 5)
  6. What makes next semester’s update repeatable? (Lesson 6)
Discussion
  1. The goal and reader (a faculty member comparing exam rules), the evidence (the three current policy pages only), the output form (a one-page table), and acceptance criteria, such as every cell traceable to a quoted passage and gaps marked as gaps.
  2. The three current pages, each labeled with school, date checked, and address. The older version is left out, or included only if the faculty member wants the history, labeled as superseded. The news article is left out as a source of rules.
  3. First check whether the page’s general provisions reach exams: its scope, definitions, exceptions, and any requirements it incorporates by reference. The scenario does not supply the policy text, so that check cannot be done here. If the page still does not resolve exam use, record it as unresolved: “not identified in the sources reviewed.” Do not record that the school has no exam rule, and do not borrow a rule from another school.
  4. Split it into three claims and check each against its school’s page. If question 3’s check leaves one school unresolved, the sentence cannot stand as written; either way, each school’s part needs its own supporting passage.
  5. For each cell, the school and the location of the passage; the difference between “not addressed” and “prohibited”; and the date each page was checked.
  6. A saved task and packet template, a stopping rule for pages that have changed or cannot be reached, a named reviewer (the faculty member), and a record of which page versions and instructions were used.

Further practice