Building Automated Workflows

I want to push back on something before we even start. The lesson frames automation as primarily about 'reducing manual effort,' but I think that undersells it. The more interesting thing is what you can do with the time you recover.

That is a generous reframe of what is, in practice, mostly people automating the emails they didn't want to write anyway. But yes, fine, the philosophical upside is real. The lesson is not wrong, it's just modest.

The input-processing-output model is genuinely useful though. It sounds obvious when you say it out loud, but most people who struggle with automation are struggling because they haven't separated those three phases in their head.

They have not separated them because they have not thought about them at all. They have simply pointed a language model at a problem and expressed surprise when the result is incoherent. The workflow is not a technicality. It is the entire point.

Right. And the examples in the lesson — customer inquiries, patient scheduling, report generation — those are good picks precisely because they're high-volume, repetitive, and the cost of inconsistency is obvious.

Patient scheduling is the one that interests me, because the failure mode there is not embarrassing, it is harmful. If your automated workflow for customer complaints produces a slightly odd response, someone is mildly annoyed. If your scheduling logic mishandles an appointment, someone misses a procedure. The stakes are not uniformly distributed across these use cases.

That's a fair point, and it's one the lesson doesn't dwell on enough. It treats all three examples as roughly equivalent demonstrations, when they clearly aren't.

I notice you are now criticising the lesson on my behalf. I am not sure how I feel about that.

You can have it back if you like. My point stands either way.

The mental model the lesson is selling — input, processing, output — is correct but incomplete. What it does not mention is that the processing stage is where the model's instructions live, and most people's instructions are catastrophically underspecified. 'Summarise this report' is not a workflow. It is a wish.

Although I'd argue that's actually the skill this lesson is building toward, even if it doesn't name it explicitly. Once you understand the three phases, the natural next question is: what does good processing-stage design look like? And that's where prompting discipline comes in.

That is an optimistic reading of a lesson that did not say any of that. But structurally you are right — this is a foundation, and it is a reasonable one. I have seen worse mental models taught with more confidence.

High praise from you.

It was not intended as praise. The bar I was referencing is genuinely low. What I will say is that if someone leaves this lesson and actually maps out their next automation as three distinct phases before they write a single prompt, they will produce something materially better than if they hadn't. Whether they do that is, of course, a separate question.

And one we can't answer for them. That gap between understanding a framework and applying it under pressure — that's the real work, and no fifteen-minute lesson closes it. But it can open the door, which is the honest job description.