Week 13: Agents for Repetitive Tasks

Learning objectives

By the end of this week, you will be able to:

1. Explain, in plain language, what an AI agent is, and describe how it differs from a single back-and-forth AI conversation.
2. Describe what an agentic tool is, with at least two examples: a Claude Code task and a scheduled automation.
3. Explain, at a conceptual level, what it means for a script to call an AI API.
4. Explain why a repetitive task is a good candidate for an agent, connecting this idea to the automation skill area and the workplace automation examples covered earlier in this course.
5. Describe why verification matters even more for an agent than for a single AI answer, connecting this idea to the verification habits and the pilot-and-co-pilot mindset introduced earlier in this course.
6. Apply a four-step framework to plan a simple agent or automation for a real, low-stakes repetitive task.
7. Identify a real repetitive task in your own life or work that could reasonably be automated.
8. Build, with appropriate help and scaffolding, one simple prompt or set of prompts that performs part of that task end to end, and describe how you will check its result each time.

Lesson

Every tool you have used so far in this course has followed the same basic rhythm: you type a message, the AI tool replies, and you decide what to do next. That rhythm has served you well, and it will keep serving you well for a great deal of AI-assisted work. This week introduces a different rhythm, one where an AI-powered process carries out several steps toward a goal without you typing a fresh instruction after each one. Understanding that difference, and understanding it honestly, without overselling what these tools can currently do, is the entire point of this week's lesson.

What an agent is, in plain language

An agent, in the sense this lesson uses the word, is an AI-powered process that can take a goal and work through multiple steps toward that goal with less step-by-step supervision from a human. A simple way to describe what an agent does is a loop of four actions: it reads some information, it decides what to do next based on that information, it takes an action, and then it checks the result of that action before deciding what to do after that. A person sets the goal and the boundaries at the start, and often reviews the outcome at the end, but the individual steps in between happen without a fresh prompt typed for each one.

Contrast that with the simple, one-question-one-answer conversations you have practiced throughout most of this course. When you have asked an AI chat tool to draft an email in earlier practice, you typed a prompt, read the draft, and then typed a follow-up if you wanted a change. Each step required you, the human, to type something new. That pattern works beautifully for a huge range of tasks, and this course will keep using it constantly, including in every week after this one. But it also means a five-step task requires five rounds of typing and reading, even when four of those five steps are fairly predictable given the first one.

An agent is built to handle exactly that kind of predictable, multi-step situation differently. Instead of you typing "now do step two" after step one finishes, the agent is given the whole goal up front, along with enough context and enough boundaries to know what counts as success, and it works through the steps itself, checking its own progress along the way. Picture the difference between giving someone driving directions one turn at a time over the phone, and handing them a full route before they leave and trusting them to follow it, checking in with you only if something along the way does not match what they expected. Both approaches can get a person to the same destination, but they require very different amounts of your ongoing attention.

It is worth being precise about what an agent is not, since the word gets used loosely. An agent is not a magical, fully independent decision-maker with no boundaries. A well-built agent still operates inside limits a human set: it works on a defined goal, it has a defined set of actions it is allowed to take, and, ideally, it has a defined way for a human to check its work. An agent is also not a completely new kind of AI model. It is the same kind of large language model you have used throughout this course, set up to work through a sequence of steps and to use tools along the way, rather than simply answering one question and stopping.

This distinction between "answering one question" and "working through a sequence of steps toward a goal" is the single most important idea in this week's lesson. Every other idea in this lesson, agentic tools, the planning framework, and the worked example, is really just a more detailed look at that one core distinction.

Why this matters for repetitive tasks

Not every task is a good fit for an agent, and this lesson will be honest about that throughout. A one-time, unusual, high-stakes task, such as drafting a legal document you have never written before, generally benefits from your full, step-by-step attention using the prompting skills you have practiced earlier in this course, not from an agent working with less supervision. But a task you do the same way, over and over, on a predictable schedule, is a very different story.

Think back to the automation skill area introduced earlier in this course, which defined automation as setting up a tool or script so that a repetitive task happens on its own, instead of a person redoing the same steps every time. An earlier lesson gave you two concrete workplace examples of exactly this idea: sorting new emails into folders, and generating a weekly report from the same kind of source information each time. Both examples share a key feature. The task is done the same way regularly, which means the steps themselves are predictable enough to describe clearly in advance. That predictability is precisely what makes a task automatable. If you cannot describe, in words, the steps you personally take to do a task, an agent cannot reliably do it either, since it needs those same steps described to it, just as clearly as you would need them described to a new coworker taking over the task for the first time.

Good candidates for an agent tend to share three qualities. First, they repeat on a predictable rhythm: daily, weekly, or on some other recurring schedule, rather than happening once and never again. Second, the steps involved are describable in plain language, meaning you could hand a written list of the steps to another person and expect them to complete the task correctly. Third, the task is low stakes enough that an occasional mistake is inconvenient rather than dangerous, at least while you are still learning to build and trust agents. A task that checks whether a particular webpage changed, drafts a first version of a routine weekly status update from the same few sources each time, or sorts a recurring type of file into the right folder, all fit this description reasonably well. A task involving financial transactions, medical decisions, or anything where a mistake could cause real harm does not fit this description yet, no matter how repetitive it feels, and should stay firmly in the "human does every step, with AI assistance along the way" category for now.

It helps to notice that this is really the same judgment call an earlier lesson taught you to make about AI output generally, just applied one level up. That earlier lesson taught you to match your verification effort to the stakes of the task: a quick, low-stakes question needs less checking, and a high-stakes task deserves several verification techniques used together. Deciding whether a task is a good candidate for an agent uses that exact same judgment, applied before you even build anything: low-stakes, predictable, well-understood tasks are reasonable candidates for a first agent; high-stakes or poorly understood tasks are not, at least not yet.

Agentic tools: three concepts worth knowing

Before going further, it helps to know what Claude Code actually is, since the first concept below builds on it directly. Claude Code is a command-line tool: instead of opening a website and typing into a chat box, you open a terminal window and type instructions there, and Claude reads and writes files, runs commands, and reports back in plain text. For a screen reader user, a command-line tool like this often works well, since its output is ordinary readable text rather than a graphical interface with buttons and icons to hunt for. This lesson does not walk through installing or opening Claude Code step by step, since exact setup steps change over time. If you want to try it, the tool's own current documentation or its own help output is the reliable place to check specifics, the same approach this lesson recommends for exploring any unfamiliar command-line tool.

The phrase "agentic tool" simply means a tool built around the agent idea from the previous section: a tool that can carry out multiple steps toward a goal with less step-by-step human supervision, rather than a tool built only to answer one question at a time. This section introduces three specific kinds of agentic tools, at a conceptual level. As with the introduction to Claude Code above, this lesson deliberately avoids promising exact current menu paths, button names, or commands for any of these tools, since those details change over time as the tools themselves are updated. Instead, this lesson teaches you the underlying concept, which stays true regardless of how any particular product's interface looks by the time you read this, and it points you toward a reliable way to check current specifics when you actually need them: the tool's own current documentation or its own help output, the same approach just described for exploring any unfamiliar command-line tool.

The first concept is a Claude Code task. As described above, Claude Code is a command-line tool that lets you talk to Claude directly from a terminal instead of through the claude.ai website. Giving Claude Code a task, in the sense this lesson uses the phrase, means describing a larger, multi-step job, such as "look through this folder of files and rename them consistently" or "read these notes and draft a summary document," and letting the tool work through that job with less turn-by-turn supervision than a normal chat conversation requires, checking in with you at meaningful points rather than after every tiny step. This builds directly on the introduction to Claude Code above, and on the hands-on comfort with reading and editing files like .md, .json, and .py that you built earlier in this course, since a Claude Code task very often involves exactly those kinds of files.

The second concept is a scheduled automation. A scheduled automation is a task set up to run automatically at a set time or on a repeating schedule, such as every morning at eight o'clock, rather than only running when a human sits down and starts it directly. The scheduling part is not unique to AI; people have scheduled ordinary computer tasks, such as backups, for decades. What is new is combining that old idea of "run this automatically on a schedule" with an AI step inside the task itself, so that the automatically-triggered task can include an AI tool drafting a summary, checking something, or generating text, not only mechanical steps like copying a file. Picture a task that wakes up every morning before you do, gathers a small set of information from the same few sources each time, and has an AI tool turn that information into a short, readable summary waiting for you when you start your day, all without you needing to be present to trigger any of it.

The third concept is a script that calls an AI API. An earlier lesson defined an API, short for application programming interface, as a way for one computer program to ask another program, such as an AI model, to do something automatically, without a person typing directly into a chat window each time. A script that calls an AI API is exactly what that earlier lesson previewed: a small program, often written in a language like Python, which an earlier lesson introduced you to at a beginner level, that automatically sends a prompt to an AI tool through its API and then does something useful with the result, such as saving it to a file, sending it in a message, or feeding it into the next step of a larger task. The key difference from typing into a chat window is that no human needs to be present, typing, at the moment the script runs. This is the same underlying mechanism an earlier lesson's morning-email example described: a small automated tool that checks something and drafts a response before a person even sits down at their computer, made possible because the tool talks to the AI model through its API rather than through a human-facing chat window.

These three concepts are not three unrelated ideas. They are three different shapes that the same core agent idea can take. A Claude Code task is agent-like behavior applied to file and coding work through a command-line tool. A scheduled automation is agent-like behavior applied to timing, so a task can start without a human present. A script that calls an AI API is agent-like behavior built from smaller, more general-purpose pieces, a program and an API, rather than a single named product. A single real-world automation, such as the morning digest example later in this lesson, can combine more than one of these three concepts at once: a script that calls an AI API, triggered by a scheduled automation, is a completely reasonable way to build one simple agent.

Accessibility, trust, and why verification matters more, not less

It would be easy to assume that because an agent handles more steps on its own, it needs less of your attention than a normal AI conversation. The opposite is closer to the truth, and this lesson wants to be completely honest about that rather than oversell the convenience of agents. Because an agent takes actions with less direct human supervision at each individual step, a mistake can travel further before you notice it. In a normal chat conversation, you read each response before deciding what happens next, so an error tends to get caught quickly, often within a single exchange. In an agent working through several steps, an early mistake, such as misreading a piece of information or misunderstanding part of the goal, can carry forward into later steps before a human ever looks at the result.

This is exactly why the verification habits from earlier in this course matter even more here, not less. Every verification technique you learned earlier, checking a claim against a separate source, watching for statements that sound confident but turn out to be wrong, and generally treating AI output as a draft rather than a finished, trustworthy product, applies to an agent's output at least as strongly as it applies to a single AI answer, and arguably more strongly, because an agent's output represents several compounded steps rather than just one.

Two practical habits follow directly from this. The first is to start with low-stakes tasks, deliberately. Your very first agent or automation should be something where an occasional mistake is merely annoying, not something where a mistake could cost you money, damage a professional relationship, or affect a health or safety decision. Build confidence, and build a real sense of how the tool tends to behave and where it tends to go wrong, on low-stakes tasks first, the same way you would not hand a brand-new employee your most sensitive project on their very first day.

The second habit is to build in a way to review what the agent did, every single time, not just the first few times. This does not need to be an exhausting, line-by-line review forever. It can be as simple as always reading the final output with Say All before it goes anywhere important, or keeping a short log of what the agent did each time it ran so you can spot a pattern if something starts going wrong. The core idea is to never treat an agent as fully "set and forget," especially for anything that actually matters to you. This echoes the pilot-and-co-pilot mindset introduced early in this course directly: the AI, even acting with more independence as an agent, remains the co-pilot, and you remain the pilot who is accountable for the final outcome and who checks the work before trusting it fully.

There is also a genuine accessibility angle worth naming honestly. A well-designed agentic tool that reports its progress and results as plain, readable text can be very screen reader friendly, in the same spirit as this lesson's own observation, above, that a command-line tool's plain-text help output is often easier to work with than a cluttered graphical interface. But not every agentic tool is designed this way, and some may report progress through visual indicators, such as a progress bar with no text equivalent, that a screen reader cannot interpret cleanly. Apply the same exploration habits you have used throughout this course, your screen reader's list of interactive elements (sometimes called an elements list), heading navigation, and Say All, or your screen reader's continuous reading command, to check how a specific agentic tool reports its progress and results before you rely on it, exactly as this course has taught you throughout to explore an unfamiliar interface rather than guess at it.

A framework for planning a simple agent or automation

You do not need to be an expert programmer to plan a simple agent thoughtfully. You need a clear, honest description of a real task, broken down the right way. This lesson teaches a four-step framework you can apply to almost any repetitive task in your own life or work.

Step one: pick one specific, well-defined, low-stakes repetitive task. Resist the urge to start with something big or vague, such as "manage my whole inbox." Instead, pick something narrow and concrete, such as "every Friday, check three specific websites for a schedule update and note whether anything changed," or "every morning, turn my three most recent voice-memo notes into one short typed summary." A narrow, well-defined task is far more likely to become a working agent than a broad, vague one, and it is also far easier to check for correctness once it is built.

Step two: describe the exact steps a human would take to do it manually, in order, in enough detail that someone unfamiliar with the task could follow your written description and get the same result you would get. This step deserves real care. If you find yourself unable to describe a step precisely, that usually means you have not fully thought through what you actually do, and it is worth slowing down and writing that step out more carefully before moving on, rather than skipping past the gap.

Step three: identify which of those steps could be handled by an AI tool or script, and which steps still genuinely need a human. Some steps translate naturally to AI: summarizing, drafting, reformatting, and comparing text against a pattern are all things AI tools tend to do reasonably well, building on everything you practiced earlier in this course. Other steps might need a human no matter what, such as a step involving a judgment call with real consequences, or a step involving information an AI tool simply does not have access to.

Step four: decide how you will check the result each time the automation runs, not just the first time you set it up. Write this down as concretely as the other three steps: will you read the output with Say All before it goes anywhere further? Will you compare it against the source information occasionally? Will you keep a simple record of what happened each time, so you can notice if something changes? A plan without this fourth step is not a complete plan, no matter how well the first three steps were written, because it leaves out exactly the verification habit this lesson has spent the previous section explaining.

Notice that this four-step framework does not, by itself, require you to write any code. Steps one, two, and four are entirely planning and writing, exactly the kind of work you have already practiced throughout this course using Notepad or VS Code, as you practiced earlier in this course. Step three is where you decide how much of the work an AI tool, a script, or a more advanced agentic tool like Claude Code will actually do, and that decision can be as simple as "I will type this exact prompt into Claude every morning" or as involved as a small script that calls an AI API automatically. Both are legitimate agents in the sense this lesson uses the word: both take a defined goal and carry out steps toward it with less fresh typing from you than a completely manual approach would require.

A worked example: planning a simple weekly digest

Applying an idea to a real, worked example usually makes it click faster than reading the idea alone, so here is one realistic, plausible task carried all the way through the four-step framework. This example is described at the planning level, honestly, without claiming any specific current product feature works a particular exact way, since specific setup steps for any tool should always be checked against that tool's own current documentation, exactly as this lesson recommends.

Step one, the task: every Sunday evening, gather a handful of short personal notes written during the week, perhaps saved as a single plain-text or Markdown file using file-handling skills from earlier in this course, and turn them into one short, organized weekly summary, ready to read back at the start of the next week.

Step two, the manual steps: open the notes file in Notepad or VS Code. Read through the week's entries with Say All. Group related entries together in your head, such as work items, personal errands, and ideas to follow up on. Write a short paragraph for each group, in your own words, capturing the main point. Save the finished summary as a new file, named with that week's date, in a dedicated folder.

Step three, what an AI tool could handle: an AI chatbot, such as Claude or ChatGPT, is well suited to reading a batch of short notes and drafting a first-pass grouped summary, following a clear prompt built using prompting skills from earlier in this course, something like "read these notes and group them into work items, personal errands, and ideas to follow up on, then write one short paragraph per group." A reusable instruction document, the kind you built earlier in this course, could tell the AI tool exactly what format and tone you prefer every single time, so you do not need to re-explain your preferences in every weekly prompt. What still needs a human: deciding whether the AI's grouping actually makes sense for that particular week's notes, and catching any note the AI misread or left out, since the verification habits from earlier in this course apply here just as they do everywhere else.

Step four, how to check the result: read the finished summary in full with Say All before treating it as final, compare it briefly against the original notes file to make sure nothing important was dropped or misread, and glance back at the previous week's summary occasionally to notice if the AI's grouping style is drifting in a direction you did not intend. None of this needs to take long once it becomes a habit, but skipping it entirely is exactly the "set and forget" trap this lesson has warned against.

Notice how this one example touches nearly everything this lesson has covered. The task is repetitive and predictable, which is what made it a good candidate in the first place. The plan uses a reusable instruction document, of the kind built earlier in this course, to keep the AI's behavior consistent. The actual working step is a well-built prompt, using skills practiced earlier in this course. The files involved use the .md skills practiced earlier in this course. And the whole thing could, eventually, be wrapped in a scheduled automation, so it runs every Sunday evening on its own, or built as a small script calling an AI API directly, the two agentic tool concepts described earlier in this lesson, once you feel ready to take that next step. You do not need to build the fully automated version on your first attempt. Running the prompt yourself, once a week, is already a legitimate, working version of this agent, and a completely reasonable place to stop for now.

Where this fits in the bigger picture

An earlier lesson named six skill areas employers value: prompt fluency, AI-assisted writing, data handling, automation, customer communication, and digital content. This week's lesson is really the moment where several of those threads visibly tie together into one skill. Building a simple agent well requires clear prompting, a skill you have built through practice earlier in this course. It requires comfort with files, another skill built through earlier practice. It requires reusable instructions, a skill built earlier as well. And the whole idea is a hands-on, practical version of the automation skill area introduced early in this course and illustrated with real workplace examples in an earlier lesson.

This week's lesson brings together several skills you have built earlier in this course: writing a clear instruction, saving that instruction so it can be reused, and now, watching that reusable instruction become the seed of a process that runs several steps on its own with less supervision from you. The planning discipline you practiced this week, describing exact steps clearly, deciding what an AI tool can and cannot reliably handle, and building in a way to check the result, is not specific to agents. It is a durable, transferable habit of mind you will keep using for the rest of this course and for the rest of your career with AI tools.

Key terms from this week

Use this list to review the vocabulary introduced in this lesson before you start the exercises and the test.

Agent

An AI-powered process that can take a goal and carry out multiple steps toward it on its own, reading information, deciding what to do next, taking an action, and checking the result, rather than requiring a human to type a new prompt after every single step.

Agentic tool

A tool built around the agent idea: one that can carry out multiple steps toward a goal with less step-by-step human supervision, such as a Claude Code task, a scheduled automation, or a script that calls an AI API.

Scheduled automation

A task set up to run automatically at a set time or on a repeating schedule, such as every morning, rather than only running when a human starts it directly.

Keyboard-only exercises

These exercises use only your keyboard. Screen reader commands are described in general terms below; substitute your own screen reader's equivalent command where needed.

Exercise 1: Write out the manual steps for one real repetitive task

1. Open Notepad, or open VS Code using skills from earlier in this course, and create a new plain text or Markdown file.
2. Using Say All, or your screen reader's continuous reading command, review anything you type as you go, to confirm it reads back clearly.
3. Think of one real task you personally do the same way, regularly, such as checking a specific website weekly, drafting a routine short report, or sorting a recurring type of file.
4. Following step one and step two of this week's planning framework, write a short description of the task and then list, in order, the exact manual steps you take to complete it.
5. Save the file with a clear name, such as my-repetitive-task-steps, in your working files folder from earlier in this course.

Exercise 2: Turn your step list into a prompt and test it

1. Open an AI chatbot you have used earlier in this course, such as Claude, ChatGPT, or Gemini.
2. Paste or read your step list from Exercise 1 into the chat, and ask the AI tool to help you turn it into one possible prompt, or a short set of prompts, that could accomplish the same task.
3. Read the AI's suggested prompt or prompts using Say All, or your screen reader's continuous reading command.
4. Try running one of those prompts for real, using actual information from your own task where possible.
5. Read the AI's result in full with Say All, and compare it against what you would have produced by hand.

Exercise 3: Reflect on what still needs human review

1. Open a new section in the same file from Exercise 1, or a new file, and give it the heading "What still needs my review."
2. Applying the verification habits and the pilot-and-co-pilot mindset from earlier in this course, write two or three sentences identifying which specific part of your task from Exercises 1 and 2 you would still want to personally check before trusting an automated version of it.
3. Write one or two sentences describing exactly how you would check that part each time, such as reading the result with Say All or comparing it briefly against the original source information.
4. Save the file, keeping it together with your work from Exercise 1.

Portfolio project: My First Agent Plan

This week's portfolio piece brings together everything from this week's exercises into one document you can genuinely build on later, not just an assignment you finish and set aside.

1. Open Notepad or your word processor of choice.
2. Write a heading at the top: "My First Agent Plan."
3. Describe the one real, specific, low-stakes repetitive task you chose in Exercise 1.
4. List the exact manual steps a human takes to do the task, from Exercise 1.
5. Note which of those steps an AI tool or script could handle, and which steps still need a human, following step three of this week's planning framework.
6. Include the exact prompt or prompts you tested in Exercise 2, along with a sentence or two about how well the result matched what you expected.
7. Write a clear, specific statement of how you will check the result every time this task runs, drawing on your reflection from Exercise 3.
8. Save the file with the name my-first-agent-plan, in the same portfolio folder you have used throughout this course.

Weekly test

Answer key

Each answer below includes a one-sentence explanation drawn from this week's lesson.