You need to get across the city.
A train runs on rails. Same route every trip — stop A, stop B, stop C — no matter what. It never decides anything. It's predictable and repeatable, and if the track is laid right it just works, a thousand times the same. But it can't reroute. If your stop isn't on the line, the train can't help you.
A car with a driver gets a destination — "take me to the airport" — and the driver decides the route. Highway jammed? Side streets. Road closed? Another way. They handle a goal, not a script.
A GitHub Actions workflow is the train. An agent is the car. And the part people miss: the car still drives the same roads, stops at the same red lights, parks in the same lot. The agent doesn't tear up the rails — it joins the system and plays by its rules.
The idea, in plain English
A workflow (a GitHub Actions YAML file, from lessons 0.6–0.7) is a fixed script. You write the steps in order — on: push → run tests → build → deploy — and it runs those exact steps, in that exact order, every time it's triggered. You decided the steps in advance. The workflow just obeys.
An agent is given a goal, not a script. "Fix the failing test." It then decides the next step itself: read the error, find the file, try a change, run the tests, look at the result — and if it still fails, try something different. That deciding-and-looping is the Plan → Act → Evaluate loop (the repeating cycle: decide a step → do it → check the result → repeat — full lesson in 1.4). The steps aren't written ahead of time; the agent picks them as it goes.
A workflow runs pre-written steps in a fixed order — you decide the path in advance. An agent interprets a goal and decides the next step at run time, adapting to what it finds.
Side by side
| Workflow (YAML) | Agent | |
|---|---|---|
| Who picks the steps? | You, in advance | The agent, at run time |
| Same every run? | Yes — deterministic (same input always gives the same output — predictable) | No — adapts to what it finds |
| Handles surprises? | No — fails or skips | Yes — re-plans |
| Best when… | the steps are known + fixed | the path depends on what's found |
The agent uses workflows. When it finishes a change it opens a pull request, which triggers your CI workflow (tests, scans). The agent rides the rails you already built. GH-600 line to memorize: an agent joins the workflow as a contributor — it does not replace it.
When to use which (this is the decision the exam tests)
Don't reach for an agent just because you can. Use the green-light / red-light test:
🟢 Green light — an agent fits when:
- Inputs and outputs are clear ("update this dependency", "add tests for this file").
- Work is scoped to a repo, branch, issue, or PR.
- The result is reviewable through a diff, log, or check.
- Tests or scans can validate the output.
- It can run with least-privilege tools (given only the minimum access it needs, nothing more).
🔴 Red light — use a plain workflow or a human instead when:
- Success criteria are unclear or fuzzy.
- The task is irreversible or production-sensitive (e.g. a deploy).
- It would need broad secrets or broad external write access.
- The agent would end up approving its own work.
- Human judgment is required — policy, legal, security, product.
"Deploy on every push to main" → a workflow (fixed, repeatable, no judgment). "The deploy keeps failing intermittently — figure out why and fix it" → an agent (the path depends on what it finds). Fixed + known → workflow. Open-ended + investigative → agent.
The cert-language version
Agentic systems interpret goals, propose solutions, and take action — beyond simple automation. They operate a Plan → Act → Evaluate loop rather than a single fixed pass, and they join the GitHub workflow as a contributor (branches, PRs, checks) rather than replacing it. Each agent should be bound to a specific SDLC (Software Development Life Cycle — the whole path from idea to coding to testing to shipped software) stage with a defined, bounded scope.
Our summary · grounded in MS Learn — Foundations of Agentic AI (units 2–3) + Designing Agent Architecture & SDLC Integration (units 1–2, 9) · fetched 2026-05-31
Common confusions (read these or get them wrong on the exam)
- "Automation = an agent." No. A scheduled script that runs the same steps every time is a workflow. No goal-interpretation, no deciding the next step = not an agent.
- "Agents replace workflows." No. The agent joins the existing system — it opens PRs that trigger your CI. Rails stay; the agent rides them.
- "Give the agent the whole pipeline." No. Bind each agent to a specific, bounded SDLC stage. Unrestricted lifecycle access is an anti-pattern (lesson 1.5).
- "If you can use an agent, you should." No. Red-light tasks (irreversible, fuzzy criteria, broad secrets, self-approval) belong to a workflow or a human.
Ticks this lesson done on the home roadmap. Saved in this browser.