One insight from the lesson that stuck with me: what we call an AI "agent" is usually not a single autonomous entity. It's a series of prompts orchestrated by traditional code. The model itself—when you call it—is just a function: prompt in, text out. The orchestration layer (the regular software wrapping those calls) is what evaluates the output and decides what prompt to send next based on human-defined conditions. This matters because it changes how we think about responsibility, testing, and what's actually "happening" in the system. When I understand that the model isn't choosing the next step, I see the control differently. It shifts where I'd look to audit or improve the system. What does this distinction change for you?

I just finished watching the AI Animation lesson, and I had one major takeaway. I keep seeing this pattern: before you have any output, you have to have thoroughly strict lines for Claude to work within. Very similar to what was said in the video, constraints make the output better. Throughout all the courses, I see this theme pop up, so going forward, I am going to make sure that the blueprint I build when making all these Markdown files has very clear and defined lines, letting the AI know what I want and do not want.

After watching lesson 2.4, I understand how these concepts relate to the context.md and the resource.md files we made earlier. Using the lesson's ladder framework along with the prior lessons really makes me think specifically of patterns I see when working with EDR tools and how helpful it could be.

I just applied the five-part framework to a prompt I needed, and here's how I structured it: You are acting as an IT Technician working with residential customers who are not technical experts. Please read over my technical notes on how I troubleshot these specific issues, whether it be hardware failure, network issues, or software configuration. Afterwards, please use abstraction to summarize these notes in a way someone who knows nothing about technical terms or concepts can understand. Do not assume that they understand technical abbreviations, and do not explain all parts of my troubleshooting. The prompt should explain "I troubleshot <Issue> and resolved it via <solution> Make the email no more than two paragraphs for this closure email. Include a professional and friendly tone. I added Identity/Task/Constraints/Output because I wanted a very deliberate and structured prompt that I could reuse across multiple tickets The structured version got me a much friendlier and customer-facing email that also explained technical terms in an understandable manner. The framework made me think through what I actually needed.

I created my first three-file folder system for troubleshooting technical issues in IT. My CLAUDE.md included my position as a level one technician. My CONTEXT.md explained how exactly I want the output to be formatted so I can read it quickly. My REFERENCES.md provided Claude with the MSP tools we have and use. When I asked Claude to troubleshoot a printer issue as an example, the response was different because it gave me brief titles with bullet points underneath so I can read them quickly and execute as fast as possible. Before, I had to explain the exact format I wanted every time. Now Claude already has that information. Key takeaway: I shouldn't be explaining how I want my output to look.