Capstone: automate a weekly workflow

What you're building

Across this level you learned to build a custom GPT, schedule a recurring Task, and think clearly about agentic tools, supervision and security. Now you combine the first two into one small system that handles a real weekly workflow from end to end.

The goal is a pair that works together:

• a custom GPT that does the specialised, repeatable thinking, turning raw input into the output you need, in your house style, following your rules; and
• a scheduled Task that runs on a rhythm and either produces the input, prompts you at the right moment, or delivers a first draft, so the work arrives instead of waiting for you to remember it.

The point of using both is that each covers the other's weakness. A GPT is a brilliant tool that sits there until you open it; a Task is a reliable rhythm that's only as good as the instruction inside it. Together they turn "a job I do every week, badly, when I remember" into "a job that mostly does itself and lands on time."

You'll also do the thing professionals do and amateurs skip: measure it. Time yourself doing the workflow the old way once, time the automated version, and write down the difference. A capstone that ends with "it saves me about 40 minutes a week" is worth ten that end with "it works well."

The project brief

Choose one real weekly workflow you own. Good candidates share three features: it repeats weekly (or close to it), it has a fixed shape (the same kind of input becoming the same kind of output), and it currently costs you real time or reliably slips. Examples: a weekly team update built from scattered notes; triaging and drafting first replies to a recurring type of request; a Monday priorities brief pulled from last week's loose ends; a weekly summary of a dataset that lands in the same format each time.

If you don't have a suitable workflow of your own to use safely (remember the Phase 0 privacy rules: nothing confidential on a personal account), build the reference workflow below using the Fernway sample world.

The Fernway reference workflow: the weekly operations prep. Every week, Fernway's operations team holds a sync (the meeting notes show the shape of it), and prep is always a scramble: last week's half-finished actions, this week's new issues, and no consistent format. Your job is to automate the prep.

Your deliverable is a working two-part system:

1. A "Fernway ops prep" custom GPT. Instructions: take last week's notes (or a brain-dump of the week) and produce a fixed prep pack: carried-over actions with owners, new items to raise, open decisions, and two questions to push the meeting forward. It should mark unowned actions as UNASSIGNED, flag anything it's unsure about, and never invent an action or a decision that wasn't in the input. Give it a knowledge file: the Fernway project brief, so it understands the live feedback project the meeting keeps returning to.
2. A scheduled Task that runs every Monday afternoon and drafts the prep pack ahead of the Tuesday sync, using the GPT's approach, so it's ready when the team sits down, with an honest "nothing new to flag" for a quiet section rather than padding.

Then measure: how long did preparing this used to take (or would it take by hand), versus how long it takes now to review and finish the automated draft?

A suggested approach

You don't have to work this way, but this order tends to go smoothly. Set aside about 20-25 minutes.

1. Map the workflow first (5 min). Before building anything, write down the workflow as it is: what's the input, what steps turn it into the output, what's the output's exact shape, and where do your judgement and your house style come in? This map becomes your GPT's instructions. Skipping it is the main reason capstones come out vague.

2. Build the GPT (8 min). In the GPT builder, write instructions from your map: role, the fixed output shape, the rules, and, as in the Custom GPTs lesson, at least one boundary ("when the input doesn't cover something, say so; never invent it"). Attach your reference material as a knowledge file. Rough it out in the conversational builder, then tighten it by hand in Configure.

3. Test the GPT properly (4 min). Run it on a normal input, then on an awkward one: a week with a contradiction, a missing owner, an ambiguous note. Watch whether it holds its boundaries or improvises. Fix the instructions, not just the one output, and re-test. This is what makes it dependable enough to run unattended.

4. Build the scheduled Task (3 min). Create a recurring Task whose instruction carries the same approach the GPT uses (the same output shape and the same honesty guardrail) on the right day and time. Read the plain-language schedule confirmation so it isn't set to the wrong moment. Let one run happen (or trigger it) so you see a real output.

5. Measure and finish (3 min). Time yourself doing the workflow by hand once for the baseline, and time reviewing-and-finishing the automated version. Write down both, and the difference. Then do the human part that never automates: read the output critically, verify the load-bearing specifics, and finish it.

A note on how the two pieces relate in practice: the GPT is your reusable engine, the Task is the timer that fires the same job weekly. Some weeks you'll open the GPT directly for an ad-hoc run; the Task is what handles the routine week without you lifting a finger. Both encode the same rules, so the output is consistent however it's triggered.

Self-assessment rubric

Mark your own work honestly against this. The aim isn't a perfect score; it's knowing exactly where your system stands and what you'd improve next.

Basic: it runs

• The custom GPT exists, has real instructions and a knowledge file, and produces the right kind of output for a normal input.
• A scheduled Task is set up on a sensible schedule and has produced at least one run.
• You can describe the workflow the pair is meant to handle.
• Where most basic attempts fall short: the GPT has no boundaries so it invents things on odd inputs; the Task instruction is vague, so its output is generic; and there's no measurement, so you can't say whether it actually helps.

Good: it's reliable and useful

• The GPT's instructions include explicit boundaries, and you've tested it on awkward inputs and seen it hold them (asking rather than inventing).
• The Task produces a useful output (one you'd read, not skim past) and handles a quiet week honestly rather than padding.
• The two pieces share the same rules and output shape, so the result is consistent however it's triggered.
• You've measured the time saved with a real before-and-after, and you can state the number.
• You verified the load-bearing specifics of one real output (names, dates, figures) against the source before treating it as done.

Excellent: it's a system you trust and others could use

• Your testing was adversarial: you actively tried to make the GPT misbehave (contradictions, out-of-scope demands, missing data) and tightened the instructions until it handled them gracefully.
• The workflow is truly reusable and handoverable: a colleague could use the GPT, or you could hand over the Task, and it would still produce good, consistent output without you explaining it.
• You've thought about the security and privacy of the whole thing: what data it touches, whether that's appropriate for the account it's on, and (if you connected anything) whether that access is scoped and trusted.
• You can articulate the limits: where the system still needs a human, which parts you'd never let it finalise unsupervised, and why. You treat the polished weekly output as a draft to check, not an answer to trust.
• The time saving is real, measured, and you can explain what you now do with the time instead.

The jump from good to excellent is mostly judgement, not build quality: adversarial testing, an honest grasp of the limits, and treating the automated output with appropriate scepticism. That judgement is the whole point of reaching Power User.

Common mistakes

• Automating a workflow that isn't actually repeatable. If the job is different every week, a fixed GPT and a scheduled Task fight it rather than help. Pick something with a consistent shape; that's what makes automation pay.
• A GPT with no boundaries feeding a Task with no guardrail. Unattended automation multiplies a weak instruction: the GPT invents on an odd input, the Task ships it on schedule, and no one was watching. Boundaries and honesty rules matter more here than in a live chat, not less.
• Never measuring it. Without a before-and-after you have a demo, not a result. The number is what turns "I built a thing" into evidence of impact, and sometimes measuring reveals it saves less than you thought, which is worth knowing too.
• Trusting the weekly output because the system feels rigorous (over-trust). This is the trap the whole level has been circling, and the capstone concentrates it. A custom GPT following careful instructions, fired by a reliable Task, producing a polished pack every Monday: the machinery feels so professional that you stop reading the output critically. But the system doesn't verify anything; it applies your rules to whatever input it got, and it will state a mis-carried action or a half-remembered decision with exactly the same confidence as a correct one. The automation makes the work arrive; it does not make it true. Every week, read the output as a draft and check the specifics that matter before it goes near a real decision. The person who built the system is still the person accountable for what it says.

Keeping current

Custom GPTs, scheduled Tasks and how they can be combined are all evolving, so parts of this build may look different over time. For the current details, see OpenAI's help articles on Creating and editing GPTs and Tasks in ChatGPT, plus the ChatGPT release notes. Accurate as of 13 July 2026.