Five lessons, just over an hour. Treat an AI tool like a junior assistant who is fast, tireless, occasionally brilliant, and cannot be trusted with anything unchecked or anything confidential. This module is what to hand it, how to brief it so the first draft is usable, how to check work you didn't do yourself, which automations actually save hours, and the one line you never cross regardless of how much time it would save.
An AI tool can draft the first version of Adaeze's newsletter, summarise a long article for module 6's research, or turn rough meeting notes into a clean paragraph in ten seconds. It can also, if you paste the wrong thing into it, put a client's name, a diagnosis-adjacent detail, or a supplier's contract terms into a system you don't control and can't take back. The skill in this lesson is telling those two situations apart before you paste anything, not after.
Treat every AI tool as a very capable stranger you've just met. Useful for plenty. Told nothing it couldn't repeat.
A rough working test, before every paste: would you be comfortable saying this sentence out loud in Adaeze's waiting room, where any client might overhear it? A newsletter draft about general wellness tips — yes, obviously. "Summarise this session note about Chinelo's anxiety symptoms" — no, and pasting it into a general-purpose AI tool is exactly as exposing as saying it out loud, even though it feels more private because no one's in the room.
Swapping "Chinelo" for "the client" is the easy part. The harder part is the detail that identifies someone even without a name attached — a very specific combination of profession, location, and situation can be enough to be recognisable to someone who knows the practice, even to a machine that never sees the name. When in doubt, generalise further than feels necessary, or don't de-identify at all — keep the task inside the client's own systems instead.
"Summarise this note: Chinelo Okafor, 34, presenting with anxiety related to a custody dispute, third session, discussed coping strategies for court dates in October."
"Rewrite this general paragraph on anxiety coping strategies for a client-facing newsletter, keeping the tone warm and non-clinical: [your own paragraph, containing no client details at all]."
Ask, or default to the stricter category. The cost of treating a borderline task too cautiously is a few extra minutes doing it by hand. The cost of guessing wrong the other way is not reversible once it's pasted into a tool you don't control — there is no version of "undo" for information that's already left the client's systems.
Adaeze's clients trust her with things they don't tell most people. That trust is the entire asset her practice runs on. An assistant who pastes the wrong thing into the wrong tool once, even accidentally, once even out of genuine helpfulness, is risking something that took years to build and cannot be quickly rebuilt.
List five tasks you might hand to an AI tool for Adaeze's practice this month. Sort each into one of the three categories from this lesson, out loud if it helps, before you do anything else with the list.
"Write a newsletter" produces something generic enough to belong to any wellness practice in the world, because that instruction told the tool nothing that distinguishes this one. The skill here is not learning to use an AI tool — it's the same skill from module 5's meeting agendas, redirected: turning a vague ask into a specific brief before the work starts, except now you're briefing a tireless junior instead of running a meeting.
A vague prompt gets a generic answer. The gap between generic and genuinely useful is almost entirely the brief, not the tool.
Thin prompt: "Write a newsletter for a therapy practice."
Full brief: "Write a monthly newsletter update for existing clients of a solo therapy practice in Lagos. Purpose: reassure clients the practice is stable and remind them gently that rebooking is easy — not a sales pitch, and not aimed at new clients. Under 300 words. Warm, direct, no clinical jargon, no mention of pricing. Here's an excerpt from a past one that landed well: [paste example]. Should read like it was written by the therapist herself, not a marketing team."
Notice the full brief doesn't ask for anything technically difficult — every constraint in it is something a competent human writer would also need to know before starting. That's the whole insight: briefing an AI tool well is briefing anyone well. The skill transfers directly from every other briefing moment in this course.
When a first draft misses, the instinct is to ask for a rewrite — "make it warmer," "shorter." That works, but it's slower than fixing the brief itself for next time: if tone keeps coming back wrong, the brief is probably missing the example that would have fixed it in one pass. Treat a bad first draft as information about what the brief left out, not just a draft to patch.
Even a well-briefed output is a starting point, not a finished piece — this lesson is about getting to a usable first draft, not a final one. Lesson 7.3 covers what checking it properly actually involves, and it applies to every output, however good the brief was.
Take the thin prompt from the worked example above — or write your own one-liner for a real task — and expand it into a full four-part brief. Notice how much of it you already knew and simply hadn't written down.
An AI-drafted summary of a supplier contract states the notice period is 30 days. You didn't read the original contract yourself — the draft looked clean, confident, well-formatted, entirely plausible. It is also, on this point, wrong: the actual clause says 60 days. Confident and wrong look identical from the outside, which is exactly why checking AI output needs a specific discipline, not just a read-through.
Fluent is not the same as correct. A well-written wrong answer is more dangerous than a badly-written one, because it doesn't look like it needs checking.
AI-drafted summary: "The contract requires 30 days' written notice to terminate."
Source check: Opened the original contract, found the termination clause. It actually says 60 days. The summary was wrong.
Why it likely happened: Many commercial contracts use a 30-day standard, and the tool may have defaulted toward the common pattern rather than this specific document's actual clause.
What changes: Corrected the summary, and now treat every specific number in future AI-drafted summaries as needing this same source check, not just the ones that feel surprising.
The unsettling part of this example is that 30 days was entirely plausible — it's a completely normal notice period, which is exactly why it didn't trigger suspicion on a read-through. Plausible and wrong is the failure mode a source check catches that a read-through alone never will.
It's tempting to check casually on the tasks that matter most, because they took the most effort to draft and feel the most "done." Do the opposite: the three-way check should scale up with stakes, not down. A social media caption with a wrong fact in it is embarrassing. A client-facing summary of a legal or financial document with a wrong fact in it can cost real money or trust — and the second one is exactly what got less scrutiny in the example above, because it read as authoritative.
Whatever went into producing a draft, once you send it, edit it, or hand it to Adaeze without flagging a concern, it is your work in every way that matters. "The AI said so" is not a defence a client will accept, and it shouldn't be — checking is the actual job, and drafting is increasingly the easy part.
Take any AI-drafted output you have access to — yours or an example. Pick three specific factual claims in it and try to trace each back to a real source. Note how many you actually could.
Booking reminders that fire automatically 24 hours before each session, from module 4's handover file, are a no-code automation already doing real work in Adaeze's practice. A tool like this connects two systems — the booking calendar and an email or SMS sender — with a trigger ("a session is booked") and an action ("send a reminder"), no custom software required. Set up well, automations like this buy back hours every single week. Set up carelessly, they fail silently and nobody notices until a client misses an appointment and asks why no reminder came.
A good automation saves time forever. A bad one saves time until the day it silently stops working, and costs far more than it ever saved.
Not everything repetitive should be automated. A task is a good candidate when it's frequent, the steps are genuinely identical every time, and the cost of it going unnoticed if it breaks is low enough that occasional spot-checking is enough of a safety net. A task that's frequent but varies in subtle ways each time — like drafting a truly personalised reply — is usually a worse fit; automating it either produces something generic or requires so many exceptions that the automation becomes more fragile than doing it by hand.
Once a month, deliberately trigger every live automation and confirm the whole chain actually completed — not just that something happened, but that every step happened. This is a direct echo of module 4's process-library discipline: a system nobody is responsible for checking is a system slowly drifting toward failure, unnoticed, until the day it matters.
Booked a test session for a fake client on the 1st of the month. Confirmed: reminder email sent 24 hours before (yes) — calendar note logged (yes) — internal tracker updated with the new booking (no — this step had silently failed for the last three weeks, since the tracker's spreadsheet was renamed). Fixed the broken link, re-ran, confirmed all three steps completed. Logged the fix in the process library page for booking reminders.
Every live automation deserves its own process-library page, in the format from module 4.4: what triggers it, what it does step by step, what to watch for, and when to ask Adaeze rather than fix it alone. This isn't extra work on top of the automation — it's what makes the time-saving durable rather than something that quietly stops paying off the moment you're unavailable to notice it's broken.
The best first automation to build is something that runs often and where an occasional miss is annoying, not costly — booking reminders, not anything touching money or clinical information. Build confidence in the discipline of monitoring before automating anything where a silent failure would be expensive.
List every repetitive task you currently do by hand, weekly or more often. Circle the one that's most frequent and lowest-stakes if it briefly goes wrong. That's your first automation candidate — not necessarily the one that would save the most time.
Every lesson in this module has circled this point without quite landing on it directly, so this lesson says it plainly: there is one line in this entire course that doesn't bend for convenience, deadline pressure, or good intentions, and it's this one. Client confidentiality is not a best practice to weigh against speed. It's the floor everything else in this role stands on.
Every other rule in this course has an exception for a good enough reason. This one does not.
Most of this course has been about judgement — when to escalate, how firmly to chase, what counts as good enough. Confidentiality isn't a judgement call in the same sense, because the harm from a breach is often irreversible in a way a late invoice or a clumsy email isn't. A missed deadline can be apologised for and fixed. A client's private information, once it's left the systems it was meant to stay inside, cannot be put back — the exposure already happened, permanently, regardless of what happens next.
Tell Adaeze immediately, plainly, with exactly what happened and where — not after trying to quietly undo it yourself, and not with the details softened to make it sound less serious than it was. A fast, honest disclosure that starts the right response early is recoverable in ways that will make the relationship stronger, not weaker, if handled this way. A mistake discovered later, or one you tried to hide, damages trust far beyond the original error — because now the concern isn't just what happened, but what else might have happened that was never disclosed.
That instinct works fine for small, reversible calls — trying a new template, sending a slightly informal message. It fails completely here, because the harm from a confidentiality breach happens at the moment of exposure, not at the moment someone finds out about it. Asking first is the only version of this that actually prevents the harm rather than just managing the fallout afterward.
Write, in your own words, the one sentence you'd want to be able to say honestly about how you've handled every piece of client information this month. If any part of that sentence would be uncomfortable to say to Adaeze directly, that's worth addressing before it becomes a habit.
Pick one genuinely repetitive task from your own life or work — not a hypothetical, something real you actually do more than once a week. Build a working automation or AI-assisted workflow for it end to end, using the disciplines from this whole module.
Whether you can hand real work to a fast, tireless, occasionally wrong junior — and still be the reason the work is trustworthy. Every module's drill has tested judgement under a different kind of mess. This one tests it under speed: the tools in this module make it easy to move fast, and the discipline is making sure fast doesn't mean careless.
You should now have: a working, tested automation with real documentation, and a clear-eyed paragraph on your own value in an AI-assisted role. Module 8 turns to communication and discretion — the messages that get a decision instead of a conversation, and the judgement calls about what you say, to whom, and what you never repeat.