AI-A03 — Multi-Agent and Agentic AI Workflows

Course Code: AI-A03  |  School: School of Artificial Intelligence  |  Cluster: Level 5 — Advanced Systems & Innovation

Level: Advanced  |  Duration: 6 weeks · 24–30 learning hours  |  Language: English  |  Certificate: Professional Certificate (non-degree)  |  Format: Self-paced with AI support under human supervision

Overview

An agentic system is not simply a language model with extra features. It is a machine that has been given a goal, a set of tools and permission to decide for itself which tool to reach for next. That shift, from answering a question to pursuing an objective across many steps, changes the engineering problem and it changes the institutional problem. The engineering question becomes how to keep a long chain of probabilistic decisions from drifting; the institutional question becomes who is accountable when a system that nobody watched in real time produces an outcome nobody intended.

This course treats those two questions as one. It begins with the classical account of an agent as a perceive–decide–act loop and shows how contemporary tool-using models fit that account and where they depart from it. It then works through the practical architecture of multi-agent systems: how work is decomposed, how roles are assigned, how state is carried between steps, how agents communicate without corrupting each other, and how a supervising process detects that an agent has begun to fail. The final third of the course is devoted to control — evaluation harnesses, bounded permissions, cost and latency budgets, audit trails and the design of the human checkpoint.

The course is deliberately sceptical. A recurring theme is that most problems presented as requiring an agent swarm are better solved by a deterministic pipeline with one model call inside it. Learners are asked, at every design stage, to justify why autonomy is warranted, and are assessed as much on the restraint of their architecture as on its ambition. What is produced by the end is a working multi-agent workflow, an evaluation suite that can detect its failure modes, and a governance annex that a risk committee could actually read.

Learning outcomes

On completion, a successful learner will be able to:

1. Define an agentic system in terms of goal, tool set, state, termination condition and permission boundary, and distinguish it from a fixed pipeline that merely contains a model call.
2. Decompose an institutional objective into a task graph, and justify for each node whether it should be deterministic code, a single model call, or a delegated agent.
3. Design role, memory and message-passing structures for a multi-agent workflow, including how state is persisted, summarised and prevented from accumulating error across steps.
4. Implement a working multi-step agentic workflow with tool calls, structured outputs, retry logic, loop limits and explicit termination conditions.
5. Build an evaluation harness containing golden tasks, adversarial cases and regression checks, and report agent performance with a defensible measure rather than an anecdote.
6. Identify the characteristic failure modes of autonomous systems — objective drift, tool misuse, silent partial failure, runaway cost, compounding hallucination and unsafe delegation — and specify a control for each.
7. Write a governance annex defining permission scope, escalation triggers, logging requirements, cost ceilings and the named human accountable for the system in production.

Who this course is for

The course is written for practitioners who have already built something with language models and have run into the ceiling of single-prompt work: research and analysis leads automating multi-stage investigation, knowledge and operations managers designing systems that touch institutional records, technical staff in universities, ministries, think tanks and NGOs who are being asked to deploy agents without a clear account of the risk, and consultants who must advise on whether an agentic architecture is justified at all. It is equally suitable for a policy or governance officer who will never write the code but must be able to interrogate the design.

Prerequisites

Completion of AI-A02, or demonstrable equivalent experience: comfort with APIs and structured data formats, prior use of a retrieval or orchestration framework, and familiarity with basic prompt design. Programming ability in Python is helpful but not required; all build work can be completed in a low-code orchestration environment. No background in formal multi-agent theory or reinforcement learning is assumed.

Syllabus

Module 1 — What an agent is, and when you do not need one

The module opens with the classical definition of a rational agent and the environment properties that make agency necessary: partial observability, dynamism, and a task horizon longer than a single decision. Against this it sets the contemporary tool-using model, and asks in what respects the analogy holds. The distinction that carries through the whole course is introduced here — between a workflow, where the control flow is fixed by the designer, and an agent, where the control flow is decided at runtime by the model.

Lessons. 1.1 Agents, environments and the perceive–decide–act loop. 1.2 Workflow versus agent: who owns the control flow. 1.3 The autonomy ladder, from suggestion to unsupervised action. 1.4 A decision test for when autonomy is warranted.

The module closes with a critical exercise: learners take three automation proposals from their own institution and argue, in writing, which of them genuinely require runtime decision-making. In most cohorts the honest answer is none, and that finding is treated as a successful outcome rather than a failure.

Deliverable. Autonomy justification memo (one page) for a real institutional task, stating the required autonomy level and the evidence for it.

Module 2 — Task decomposition and the design of a task graph

Before any agent is built, the work must be described. This module covers decomposition of an objective into a directed task graph: nodes, dependencies, inputs and outputs, and the acceptance condition attached to each node. It introduces the practice of annotating every node with its determinism class — fixed code, single model call, or delegated agent — and with the cost of getting it wrong.

Lessons. 2.1 From objective to task graph. 2.2 Acceptance conditions and node contracts. 2.3 Determinism classes and where probabilistic steps are tolerable. 2.4 Estimating error propagation along a chain.

Particular attention is given to error propagation. Learners compute the compounded reliability of a chain of steps and confront the arithmetic that a ten-step workflow with ninety-five per cent per-step accuracy succeeds barely six times in ten. This calculation reshapes most initial designs.

Deliverable. Annotated task graph with determinism classes and a compounded reliability estimate.

Module 3 — Roles, memory and message passing

This module builds the internal architecture of a multi-agent system. It examines the common role patterns — planner and executor, generator and critic, supervisor with specialised workers, and blackboard-style shared workspaces — and evaluates each against the criteria of traceability and cost. It then addresses state: what an agent must remember, what should be summarised, what must be written to durable storage, and how context is prevented from silently truncating.

Lessons. 3.1 Role patterns and their trade-offs. 3.2 Short-term context, working memory and durable state. 3.3 Message schemas and structured hand-offs. 3.4 Preventing echo, collusion and shared-error amplification between agents.

A central caution is developed here: agents that critique each other can converge on a shared error and report high confidence in it. The module treats inter-agent agreement as weak evidence and requires that at least one verification step draw on a source outside the agent population.

Deliverable. Architecture specification: roles, message schema, memory policy and hand-off contracts.

Module 4 — Building it: tools, structured outputs and control flow

The build module implements the specification. It covers tool definition and description, argument validation, structured output enforcement, retry and backoff behaviour, loop and depth limits, timeouts, and explicit termination conditions. It also covers the unglamorous engineering that determines whether a system survives contact with production: idempotent tool design, safe handling of partial writes, and logging that captures the reasoning trace alongside the action taken.

Lessons. 4.1 Tool interfaces and description quality. 4.2 Structured output and schema validation. 4.3 Retries, loop limits and termination. 4.4 Trace logging for later audit.

Learners build a working system of at least three cooperating roles that completes a genuine multi-stage task drawn from their own institution, and keep a build log recording every failure encountered and the change made in response.

Deliverable. Working multi-agent workflow with trace logs and an annotated build log.

Module 5 — Evaluation, failure modes and adversarial testing

An agentic system cannot be assessed by looking at one good run. This module builds an evaluation harness: a fixed set of golden tasks with known correct outcomes, a set of adversarial and edge cases, and a regression suite run after every change. It covers the choice of metric — task completion, step-level accuracy, cost per successful outcome, latency, and rate of silent failure — and the reporting of results with uncertainty rather than as a single headline figure.

Lessons. 5.1 Golden tasks and how to construct them honestly. 5.2 Adversarial cases: ambiguous instructions, hostile inputs, missing tools. 5.3 Prompt injection and tool-boundary attacks. 5.4 Metrics, cost accounting and reporting uncertainty.

Prompt injection through retrieved or tool-returned content is treated as a first-class security concern rather than a curiosity, since an agent with write permissions and a poisoned input is a materially different risk from a chatbot that says something wrong.

Deliverable. Evaluation harness with results table covering golden, adversarial and regression cases.

Module 6 — Governance, permission and the accountable human

The final module places the system inside an institution. It covers the scoping of permissions to the minimum necessary, the design of escalation triggers and approval gates, cost ceilings and circuit breakers, retention and auditability of traces, and the allocation of named accountability. It reviews how the NIST AI Risk Management Framework and the management-system requirements of ISO/IEC 42001 translate into concrete controls for an autonomous workflow, and how to present those controls to a committee that is not technical.

Lessons. 6.1 Least-privilege permission design. 6.2 Escalation triggers and human approval gates. 6.3 Cost ceilings, circuit breakers and kill switches. 6.4 Accountability, audit and the decommissioning plan.

The course closes with the decision brief: a two-page document recommending deployment, restricted pilot or abandonment, with the evidence for the recommendation and an explicit statement of residual risk.

Deliverable. Final project: architecture specification, working system, evaluation report, governance annex and two-page decision brief.

Assessment

Pass mark 70 per cent. All assessed components must be attempted. Every mark in this course is issued by a human assessor; no assessment outcome is generated automatically.

Rubric criteria

Each assessed artefact is marked against four criteria at four levels (distinction, pass with merit, pass, fail).

1. Architectural justification. Whether the level of autonomy, the number of agents and the division of roles are argued from the properties of the task rather than adopted by fashion, and whether simpler alternatives were considered and rejected on stated grounds.
2. Technical execution. Whether the system runs end to end, handles error and termination correctly, enforces structured outputs, respects its permission boundary, and produces traces sufficient for another engineer to reconstruct a run.
3. Evidential rigour. Whether performance claims rest on a documented evaluation with adversarial and regression coverage, whether metrics are appropriate to the task, and whether uncertainty and failure are reported honestly.
4. Institutional judgement. Whether the governance annex identifies real failure modes with proportionate controls, allocates named accountability, and communicates residual risk in language a non-technical decision-maker can act on.

Reading list

Core. Michael Wooldridge, An Introduction to MultiAgent Systems, 2nd edition (Chichester: John Wiley & Sons, 2009).

Stuart Russell & Peter Norvig, Artificial Intelligence: A Modern Approach, 4th edition (Harlow: Pearson, 2021), chapters on intelligent agents and multiagent decision making.

Yoav Shoham & Kevin Leyton-Brown, Multiagent Systems: Algorithmic, Game-Theoretic, and Logical Foundations (Cambridge: Cambridge University Press, 2009).

National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (Gaithersburg: NIST, 2023).

International Organization for Standardization, ISO/IEC 42001:2023 — Information technology, Artificial intelligence, Management system (Geneva: ISO, 2023).

Dario Amodei, Chris Olah, Jacob Steinhardt, Paul Christiano, John Schulman & Dan Mané, ‘Concrete Problems in AI Safety’, arXiv:1606.06565 (2016).

Academic integrity and use of AI

Learners are expected to use AI systems throughout this course; the subject of study is, after all, the delegation of work to machines. What is assessed is judgement, not keystrokes. Submissions must therefore include a short use-of-AI statement identifying which models and tools were used, for which components, and what the learner changed after reviewing the output. Undisclosed use, or submission of generated material that the learner cannot explain and defend in discussion, is treated as a breach of academic integrity.

All factual claims and citations in submitted work must be verified against the primary source. Fabricated references, invented benchmark figures and unverifiable performance claims are treated as serious breaches regardless of whether a model produced them. Institutional data used in the build must be anonymised or synthetic unless the learner holds documented permission, and no personal data may be placed in a tool call without a lawful basis.