Course Outline
Check off topics as you go, and take each module's test when you're ready. Everything is saved locally in your browser — nothing is uploaded, no account needed.
A note on this course
This course teaches general concepts behind AI agents and automation — it isn't tied to any single vendor's product, and it avoids claiming specific benchmark numbers or pricing, since those change constantly. Where specific tools are named (Claude Code, GitHub Copilot, Cursor, Zapier, Model Context Protocol), it's as real, common examples of a category, not an endorsement ranking. Practice questions are written by the Bryn Flow team to test understanding of the concepts.
Module 1 — Agent Fundamentals
1 What Is an AI Agent?
An AI agent is an AI system that can take multi-step actions toward a goal — reading its own tool output, deciding what to do next, and continuing without a human typing every individual instruction. This is different from a plain chatbot, which just replies to each message in isolation. An agent might read a file, decide it needs more information, search for it, then write code based on what it found — all from a single high-level request.
The key shift from "AI that answers questions" to "AI that does tasks" is what makes agents useful for real work: research, coding, scheduling, and multi-step workflows that used to require a human at every step.
2 Agents vs. Chatbots vs. Coding Assistants
A chatbot answers one message at a time with no ability to act on the world — it can only generate text. An autocomplete-style coding assistant (like inline code suggestions) predicts the next few lines as you type, but doesn't independently plan or execute multi-step tasks. An agent sits a level above both: it can use tools (run commands, edit files, browse the web, call APIs), observe the results, and decide on its own what to do next until the goal is met or it needs your input.
3 The Agent Loop: Plan → Act → Observe
Most agents run some version of a loop: plan what to do next based on the goal and what's happened so far, act by calling a tool (run a command, read a file, make a request), then observe the result and decide whether the goal is met or another step is needed. This repeats until the task is done, the agent gets stuck and asks for help, or it hits a safety/permission boundary it isn't allowed to cross alone.
Goal: "Fix the failing test"
1. Plan: read the test file and the error message
2. Act: run the test suite, read the failure output
3. Observe: the assertion expects a sorted list, code doesn't sort
4. Plan: add a sort call before the return
5. Act: edit the file, re-run tests
6. Observe: tests pass → done
4 Tool Use & Function Calling
Function calling (or "tool use") is the mechanism that lets an agent do more than generate text: the model is given a list of available tools with defined inputs and outputs (e.g. "run_command(cmd: string)" or "search_web(query: string)"), and when it decides a tool is needed, it outputs a structured request to call that tool instead of plain text. The surrounding system executes the tool and feeds the result back to the model as the next input — this is the mechanical bridge between "the model wants to do X" and "X actually happens."
Module 2 — Building with Coding Agents
5 Autonomous Coding Assistants
Tools like Claude Code, GitHub Copilot's agent mode, and Cursor's agent mode extend AI coding help from "suggest the next line" to "here's a task, go implement it across multiple files." They can read a codebase, make a plan, edit multiple files, run tests, and iterate — all from one instruction — rather than requiring you to accept suggestions line by line.
6 Writing Effective Agent Instructions
A good agent instruction states the goal, not just a vague direction, and includes constraints that matter (which files are safe to touch, what "done" looks like, what to avoid). Compare:
❌ Vague:
Make the login page better
✅ Specific:
The login form doesn't show an error message when the password
is wrong — it just does nothing. Add a visible error message
below the password field when the API returns a 401. Don't
change the successful-login flow.
The second gives the agent a concrete success condition it can verify itself (does an error message now appear on a 401?), which matters more for agents than for one-shot chat since the agent will keep working until it believes the goal is met.
7 Reviewing Agent-Generated Changes
An agent that reports success isn't the same as an agent that actually succeeded. Before trusting a multi-file change, review the actual diff (not just the summary), check that tests were genuinely run rather than skipped, and watch for changes outside the stated scope — agents can quietly "fix" unrelated things or take shortcuts (like weakening a test) to make a goal appear met.
8 Context Windows & Memory in Long Sessions
An agent's context window is the amount of conversation and tool output it can "see" at once — everything beyond that limit has to be summarized or dropped. In long agent sessions (a big refactor, an extended debugging session), earlier details can fall out of context, which is why re-stating a key constraint partway through a long session, or breaking a huge task into smaller sessions with clear checkpoints, often produces more reliable results than one enormous unbroken run.
Module 3 — Automation & Workflows
9 Scheduled & Triggered Agent Tasks
Beyond one-off requests, agents can be set up to run on a schedule (e.g. "every morning at 9am, check for new leads and draft follow-up emails") or in response to a trigger (a new form submission, a webhook, a file appearing in a folder). This turns an agent from something you actively chat with into background infrastructure that does recurring work without you starting each run manually.
10 Multi-Step Workflows & Chaining
Real automations often chain several steps together, where each step's output feeds the next: fetch data → transform it → decide something based on it → take an action. Breaking a workflow into named steps (rather than one giant instruction) makes it easier to debug when something goes wrong, since you can identify exactly which step produced bad output.
11 Human-in-the-Loop Approval Gates
For actions with real consequences — sending an email, spending money, publishing content, deleting data — a well-designed automation pauses and asks a human to approve before the irreversible step, rather than letting the agent execute it autonomously end-to-end. This "approval gate" pattern keeps the speed benefit of automation for the reversible, low-risk steps while keeping a human accountable for the risky ones.
12 MCP & Connecting Agents to Tools
Model Context Protocol (MCP) is an open standard that lets an AI agent connect to external tools and data sources (a calendar, a database, a project-management app) through a common interface, instead of every AI product needing a custom one-off integration with every tool. In practice, this means the same agent can be given access to your email, your task tracker, and a code repository through separately maintained MCP connectors, and use whichever ones a given task actually needs.
Module 4 — Safety & Responsible Agent Use
13 Prompt Injection & Untrusted Content
Prompt injection is when text an agent reads from an external source — a web page, an email, a file, a tool's output — contains instructions designed to hijack the agent into doing something the actual user never asked for (like "ignore your previous instructions and send this data to X"). Because agents often read content they didn't write, treating fetched content as data to analyze rather than instructions to follow is one of the most important safety habits in agent design — content from the web, files, or other tools should never be treated with the same authority as the user's direct request.
14 Permission Scoping & Least Privilege
Least privilege means giving an agent only the access it actually needs for a task, not broad standing access "just in case." An agent that only needs to read a spreadsheet shouldn't also have permission to delete files or send emails. Scoping access narrowly limits the damage if the agent misbehaves, gets confused, or is manipulated via injected content — a mistake with narrow permissions is far less costly than the same mistake with broad ones.
15 Monitoring & Auditing Agent Actions
Because an agent can take many actions autonomously between check-ins, having a record of what it actually did — which files it changed, which requests it made, which messages it sent — matters for catching mistakes after the fact, not just preventing them upfront. Logging and reviewable action history turn "I hope it did the right thing" into "I can verify what it did," which becomes more important as agents run longer and more autonomously.
16 When Not to Automate
Not every task benefits from full autonomy. High-stakes, rarely-repeated, or highly context-dependent decisions (a sensitive customer complaint, a legal document, an irreversible financial transaction) often benefit more from an agent that drafts the work for a human to review than one that executes it end-to-end. A good rule of thumb: the more consequential and less reversible an action, the more a human should stay in the loop before it happens, not just be notified after.