STUDY COMMITMENT6–8 hours / week24–30 hours in total
YOUR ACHIEVEMENTCommunity certificateOn successful completion
THE BIG PICTURE
From a clever demo to a dependable agent.
An agent is more than a model in a loop. It needs a defined task, tools it can trust, a stopping rule, and a way to recognize failure. Build these pieces around one practical project, then measure whether the system actually helps.
What you will be able to do
↗Choose between a deterministic workflow and an autonomous agent.
↗Write tool contracts with validated inputs and explicit permissions.
↗Manage state, short-term memory, and retrieved context.
↗Introduce approvals before sensitive or irreversible actions.
↗Evaluate task success, cost, latency, and failure modes.
↗Deliver an agent with a runbook and a repeatable evaluation suite.
Who this is for
Developers ready to move beyond single-prompt applications.
Technical builders who want to automate a bounded business workflow.
Engineers evaluating when agents are worth the complexity.
Before you begin
Comfort with basic Python or JavaScript, functions, and HTTP APIs.
Familiarity with Git and running a small local application.
A laptop and access to a language-model API for practical exercises.
THE METHOD, EXPLAINED
What actually makes a system agentic?
An agent is a system that is given a goal rather than a procedure, chooses its own next action, acts on the world through tools, and decides when it is finished. Everything else is a workflow with a language model in it — which is frequently the better design.
The useful distinction is not how clever the model is but who holds the control flow. In a workflow, you wrote the steps and the model fills in the judgment at fixed points. In an agent, the model chooses the steps and you constrain the space it may choose within. The second is more capable and strictly harder to operate: every additional degree of freedom is an additional failure mode you now own.
That is why this course treats autonomy as a dial rather than a destination. Most production systems that are described as agents are, correctly, mostly deterministic workflows with one or two genuinely agentic segments. Knowing where to place those segments — and where to refuse them — is the engineering skill.
The parts that make an agent dependable are unglamorous: tool contracts with validated inputs and least-privilege permissions, explicit stop conditions, approval gates in front of irreversible actions, traces you can read after the fact, and an evaluation set that tells you whether last week’s change helped. Demos skip all five. Systems cannot.
The agent loop with its control points. Every box outside the model is something you own and can constrain.
The principles this course is built on
01
Earn the autonomy
Start from the deterministic workflow that solves the task and introduce autonomy only where the branching genuinely cannot be enumerated.
02
Tools are APIs, not conveniences
Every tool gets a schema, validation, a permission scope, a timeout, and an idempotency story. The model will call it in ways you did not anticipate.
03
Bound the loop
Step limits, budget limits, wall-clock limits and explicit stop conditions. An agent without a stopping rule is an outage with good intentions.
04
Gate the irreversible
Reads are cheap to get wrong. Writes, payments, deletions and outbound messages get a human approval boundary until the evidence says otherwise.
05
Treat tool output as untrusted input
Retrieved documents and API responses are an injection surface. Content that arrives through a tool must never be able to escalate what the agent is allowed to do.
06
Measure tasks, not transcripts
A good-sounding answer is not a completed task. Score against task outcomes, cost, latency and failure class, on a fixed evaluation set, against a baseline.
When an agent is the right shape — and when it is not
✓ Worth the effort when
The path through the task genuinely varies and cannot be enumerated in advance.
The task needs to gather evidence before it can decide what to do.
Partial progress is useful and a human can take over mid-task.
Failure is visible, recoverable and cheap relative to the value of success.
× Probably not when
The steps are known — write the workflow; it is cheaper, faster and testable.
The action is irreversible and the cost of a wrong call is severe.
You cannot yet describe what a successful run looks like.
You have no way to observe what the system did after it did it.
Objections worth taking seriously
“More autonomy means more capability.”
More autonomy means more variance. Capability comes from good tools, good context and a well-scoped task; autonomy just decides who sequences them.
“The agent can check its own work.”
Self-critique catches some classes of error and is systematically blind to others — particularly ones that follow from a misunderstanding it is still holding. Independent checks earn their keep.
“Evaluation can wait until it works.”
Without a fixed evaluation set you cannot tell improvement from luck, and every prompt change becomes an unfalsifiable opinion.
“Multi-agent solves hard problems.”
Splitting a task across agents multiplies coordination cost and failure surface. It helps when the sub-tasks are genuinely independent, and hurts otherwise.
INSIDE THE COURSE
A curriculum with real depth.
7 modules · 24–30 hours · Learning objectives, key concepts and an applied exercise in every module
01Week 1 · ≈4 hoursA useful task before an agent+
Define the job, success criteria, and the smallest useful workflow — then decide, on evidence, whether an agent is the right shape at all.
By the end you can
Distinguish tasks that need an agent from tasks that need a workflow.
Write a task definition with measurable success criteria.
Establish a non-agent baseline to measure any later improvement against.
What is covered
Agents versus scripts, workflows, and chat interfaces
The autonomy ladder: where control is traded for capability
Task decomposition and operating boundaries
Failure budgets and a baseline without an agent
Cost, latency and variance as first-class design constraints
Key concepts introduced
Control flow ownership
Whether the sequence of steps was written by you or chosen by the model — the only definition of “agentic” that survives contact with production.
Failure budget
The rate and severity of wrong answers the task can absorb before the system stops being worth running.
Baseline
The simplest solution that works, measured, so that any added autonomy has something to prove itself against.
PUT IT INTO PRACTICE
Write a one-page agent brief with five acceptance criteria.
YOU PRODUCE Agent brief, baseline measurement, and an explicit autonomy-level decision with its justification.
02Week 1 · ≈4 hoursThe agent loop+
Connect model decisions to tools without losing control of execution.
By the end you can
Implement a bounded decide–act–observe loop.
Express tool selection as structured output rather than parsed prose.
Define stop conditions, step budgets and fallback behaviour before the first run.
What is covered
Messages, structured outputs, and tool selection
Input schemas, result handling, and explicit state
Step limits, token budgets, wall-clock limits and stop conditions
Deterministic fallbacks when the loop cannot converge
Reading a trace: what the agent decided and why
Key concepts introduced
Stop condition
The explicit rule that ends the loop. An agent without one is an outage with good intentions.
Structured output
A schema-constrained response that names the action and its arguments, removing prose parsing from the critical path.
Trace
The recorded sequence of decisions, tool calls, costs and timings for one run — the only way to debug after the fact.
PUT IT INTO PRACTICE
Build a bounded loop with two tools and a hard execution limit.
YOU PRODUCE A running loop with budgets configured and a readable trace for one successful and one abandoned run.
03Week 2 · ≈5 hoursTools that are safe to use+
Treat every tool as a small API with a clear contract and a hostile client.
By the end you can
Write a tool contract covering schema, permissions, timeouts and error semantics.
Make write operations idempotent and safe to retry.
Place approval gates where they are justified, and nowhere else.
What is covered
Validation that rejects rather than coerces
Permissions, least privilege and blast radius
Timeouts, retries, idempotency, and duplicate actions
Typed errors the model can act on
Human approval gates for external writes
Key concepts introduced
Idempotency key
A caller-supplied identifier that makes a repeated write produce one effect — the control that prevents the second charge.
Least privilege
Each tool is scoped more narrowly than the agent, so a redirected agent still cannot reach beyond the union of its tools.
Fail closed
When permission or state is uncertain, the safe default is refusal plus escalation, never optimistic action.
PUT IT INTO PRACTICE
Add validation and an approval boundary to a write-capable tool.
YOU PRODUCE A hardened tool contract, plus a short written justification for each approval gate you added or declined to add.
04Week 2 · ≈4 hoursContext, retrieval, and memory+
Give the agent relevant evidence without accumulating noise.
By the end you can
Separate session state, task state and persistent memory deliberately.
Attribute answers to retrieved sources.
Manage a context budget and resolve conflicting evidence.
What is covered
Session state versus persistent memory
Retrieval, source attribution, and freshness
Chunking, ranking and the cost of irrelevant context
Context budgets and handling conflicting evidence
When memory becomes a liability rather than a feature
Key concepts introduced
Context budget
A deliberate allocation of the window across instructions, task state and evidence — decided, not accumulated.
Source attribution
Binding each claim to the retrieved passage that supports it, which makes hallucination visible instead of plausible.
Staleness
Retrieved evidence that was true once. Freshness is a property the retrieval layer must assert, not assume.
PUT IT INTO PRACTICE
Add a small knowledge source and cite the evidence behind an answer.
YOU PRODUCE A retrieval-backed answer with attributions, plus a documented policy for conflicting and stale sources.
05Week 3 · ≈5 hoursReliability under pressure+
Explore what happens when the happy path ends — deliberately, before production does it for you.
By the end you can
Design so that a fully persuaded agent still cannot exceed its permissions.
Distinguish failure from unknown outcome and handle each correctly.
Make partial completion visible rather than narrated away.
What is covered
Prompt injection through tool results and documents
Instruction/data separation as a design property, not a prompt trick
Unavailable services, timeouts and partial completion
Uncertainty, escalation, and meaningful error messages
Running a structured failure drill
Key concepts introduced
Prompt injection
Instructions smuggled into content the agent reads, attempting to redirect its behaviour from inside the data.
Unknown outcome
A timeout is not a failure. Querying state before retrying is the difference between one refund and two.
Silent partial completion
Three of five steps succeeded and the summary says “done”. Success must be asserted by the system, not narrated by the model.
PUT IT INTO PRACTICE
Run a failure drill with malicious input and an unavailable tool.
YOU PRODUCE A failure-drill report: what broke, what held, and which control you added in response to each.
06Week 3 · ≈4 hoursEvaluation and observability+
Measure performance on tasks, not impressive-looking responses.
By the end you can
Build a fixed evaluation set including ambiguous, adversarial and budget-limited cases.
Score outcomes with a written rubric rather than an impression.
Compare a change against a baseline and report the result honestly.
What is covered
Test datasets, expected behaviors, and regression checks
Designing cases that can actually fail
Tracing decisions, tool calls, cost, and latency
Rubrics, inter-rater agreement and scoring drift
Comparing improvements against the baseline
Key concepts introduced
Evaluation set
A fixed collection of tasks with expected outcomes, used to compare versions of the system rather than impressions of it.
Regression case
A test added the day a bug was found, so the same failure cannot return unnoticed.
Rubric
The written scoring rule that makes two reviewers reach the same verdict on the same run.
PUT IT INTO PRACTICE
Create a ten-case evaluation set with a written scoring rubric.
YOU PRODUCE An evaluation suite with a baseline result and a before-and-after comparison for one deliberate change.
07Week 4 · ≈5 hoursA system someone else can run+
Package the project and make its limitations explicit.
By the end you can
Document scope, boundaries and known limitations in operator language.
Provide monitoring, a kill switch and a rollback path.
Hand over a system a colleague can operate without you.
What is covered
Configuration, secrets, and deployment boundaries
Monitoring, alerting thresholds and cost controls
Rollback, kill switches and operational ownership
A clear runbook and human escalation procedure
Writing down what the system must never do
Key concepts introduced
Runbook
The document that lets someone who was not there diagnose and stop the system on a Monday morning.
Kill switch
A single, tested control that halts the agent — and a named person permitted to use it.
Operational ownership
The named team accountable for the system’s behaviour once it is no longer a project.
PUT IT INTO PRACTICE
Complete the capstone, evaluation report, and operator guide.
YOU PRODUCE Capstone system, evaluation report, runbook and handover notes.
The vocabulary you will be using
Agent loop
The cycle of model decision, tool call, observation and re-decision, bounded by explicit stop conditions.
Tool contract
The schema, permissions, timeout and error semantics of a single action the agent may take.
Approval gate
A mandatory human decision inserted before an irreversible or externally visible action.
Prompt injection
Instructions smuggled into content the agent reads — a retrieved document, a web page, an API response — attempting to redirect its behaviour.
Evaluation set
A fixed collection of tasks with expected outcomes, used to compare versions of the system rather than impressions of it.
Trace
The recorded sequence of decisions, tool calls, costs and timings for a single run — the only way to debug behaviour after the fact.
SEE IT BEFORE YOU BUY IT
A real session, start to finish.
A representative lecture from the middle of the course. It separates agents from workflows, walks the control points that make a loop operable, and works through the failure modes that appear the first week a system meets real input.
The sample is genuine teaching material from this course, condensed for the web. Full sessions include live walkthroughs, the handout, and the exercise review.
LEARNING THROUGH DOING
Make the work your own.
Three applied assignments build toward a capstone. Each asks you to explain your decisions and show the evidence behind your result.
01
Agent brief
A task definition, scope boundaries, and acceptance criteria.
02
Working agent
A bounded tool-using workflow with validation and approval gates.
03
Failure & evaluation report
Ten test cases, failure analysis, and before-and-after measurements.
THE CAPSTONE PROJECT
Build a research-to-action assistant
Create an assistant that consults a supplied knowledge base, drafts a proposed action, and waits for approval before executing it. Submit the code, tool contracts, evaluation cases, and a concise runbook.
DEFINEBUILDVERIFYEXPLAIN
One final exam. Clear expectations.
A 60-minute scenario exam: choose an architecture, identify unsafe tool behavior, diagnose a failed run, and explain your evaluation strategy.
70%Minimum exam score3 + 1Assignments + capstone1Final exam per course
Certificate requirements: submit all three assignments, meet the capstone acceptance criteria, and score at least 70% in the final exam. Assessment focuses on correctness, reasoning, verification, and clear communication.
THE COURSE PERSPECTIVE
Meet Mira.
Mira Voss
Agent systems & evaluation
Mira is the teaching persona for Agentic Systems. Her course perspective brings together bounded autonomy, reliable tools, and practical evaluation.
“Build a small system you can explain, measure it, and improve it one decision at a time.”
Fictional teaching persona · AI-generated portrait. This profile does not represent a real person's credentials or employment history.
RECOGNITION FOR YOUR WORK
A certificate. Backed by practice.
Successfully complete the course requirements to earn your AI Pioneers Community certificate.
A/ AI PioneersSAMPLE · NOT ISSUED
Community certificate of completion
Alex Morgan
has successfully completed the assignments and final assessment in
Agentic Systems
AI PioneersAI Pioneers Community
A/
November 2026Illustrative completion date
Illustrative sample with a fictional learner name. Your certificate is issued after assessment, not at registration. This is a community certificate of completion, not an accredited degree or professional license.
Take a useful toolkit with you
↳Agent task brief
↳Tool-contract checklist
↳Evaluation scorecard
↳Operational runbook
BEFORE YOU REGISTER
A few good questions.
When does the course start?
This course begins on 12 October 2026. Registration closes on 6 October 2026 at 23:59 UTC. Plan for 6–8 hours / week over 4 weeks.
Can I see the teaching material before registering?
Yes. The sample session is a condensed version of a real lecture from this course, including the diagrams used in class and the instructor's notes.
Is this the course classroom?
After confirmed payment, your welcome email provides account access. Your My learning dashboard contains the published lessons and resources. Assignment and examination arrangements are provided by your instructor.
Do I need a particular AI subscription?
The curriculum is organized around engineering practices rather than a single vendor. You need access to the tools listed in the prerequisites. Any third-party AI subscriptions or API usage are separate from the course fee.
How much of this is theory?
Every module ends with an applied exercise and a concrete deliverable. The concepts exist to make the practice repeatable, not the other way around. Roughly a third of your time is reading and discussion; the rest is building, reviewing and verifying.
How do I earn the certificate?
Submit the three assignments, complete the capstone against its acceptance criteria, and pass the final exam with a score of at least 70%. Simply purchasing the course does not earn a certificate.
What happens when payment is paused?
You can still explore the entire curriculum. Registration through checkout becomes available when the course administrator enables payment, provided the registration deadline has not passed.
Course teaching personaMira Voss ↗