Orchestration & Control

The instinct that trips people up is to treat an agent like a colleague who will use common sense and stop when something feels off. An agent has no such instinct by default. It pursues the goal you gave it through the plan it made, and it will keep pursuing - stepping over a problem, taking a consequential action, spending time or money, running in a loop - unless the design tells it to stop. The autonomy that is the whole point is also the whole risk: the more of the work happens without you watching, the more depends on having decided in advance where the process must pause, what it must never do, and how it ends. Control is therefore not a constraint you add reluctantly; it is the thing that makes autonomy usable at all.

Think of it as the difference between a power tool with no guard and one designed for a human to operate safely. The capability is the same; what changes is whether the boundaries that keep it from doing harm have been engineered in. With agents, those boundaries are not physical but designed into how you set the process up: the limits you place on its tools and access (least privilege, from Lesson 2.2), the conditions under which it must halt, the points at which it must check in, and your ability to see what it is doing and stop it. An agent given a goal and a keyring and set loose with none of this is not autonomous in a good sense - it is unsupervised.

The consequences of getting this wrong scale with the agent's reach, which is why control and least privilege are two halves of one discipline. A tightly scoped, read-only research agent with no boundaries is a small problem - the worst it does is waste a run. A broadly tooled, write-capable agent with no stopping conditions and no checkpoints is a serious one - it can take many consequential actions, fast and silently, before anyone notices it went wrong. So the design effort you put into orchestration should match the stakes: light-touch for cheap, reversible, contained work; rigorous for anything autonomous that can change the world in ways that are costly to undo. And the reason ties straight back to the spine of the course - you remain accountable for what the process does, so you must retain the ability to bound it, watch it, and stop it. Oversight you cannot exercise is not oversight.

Controlling an agentic process comes down to a small set of instruments you combine to fit the stakes. Guardrails are the hard limits the agent may never cross, regardless of what its plan suggests: the tools it cannot use, the data it cannot touch, the actions it is forbidden to take, the budget of money, time or steps it cannot exceed. Guardrails are set in advance and enforced by the system, not left to the agent's discretion - the strongest ones are structural (the agent simply does not have the capability) rather than merely instructed (you asked it not to). Least privilege is the foundational guardrail; on top of it you add explicit prohibitions and hard budgets so a confused or looping agent hits a wall instead of running forever or overspending.

Stopping conditions define when the process must halt. An agent needs to know not just how to proceed but when to stop - and there are three kinds worth designing for: stop on success (the goal is met and verified against the definition of done from Lesson 2.1), stop on failure (it cannot make progress, so it should halt and report rather than thrash), and stop on limit (it has hit a budget, a step count, or a guardrail). Without deliberate stopping conditions, agents can loop, over-work a task, or grind against an obstacle indefinitely - so saying clearly what 'done' and 'stuck' look like is as much a control mechanism as it is an instruction.

Checkpoints are the designed pauses where the process reports or asks before continuing. Rather than run start-to-finish untouched, a well-orchestrated agent surfaces at chosen moments: to show a plan before executing it, to present intermediate results before building on them, and - most importantly - to get explicit human approval before any high-consequence, hard-to-undo action (send, spend, submit, overwrite, delete). This is the human gate from Lesson 2.2, generalised into the rhythm of the whole process. Checkpoints are where you convert raw autonomy into supervised autonomy: the agent does the work, but at the moments that matter it stops and hands you the decision. Placing them well is a judgement call - too many and you have destroyed the productivity by turning the agent back into a chatbot; too few and you have lost oversight where it counted. The skill is to put the checkpoints exactly where being wrong would be expensive.

The heart of control is deciding, deliberately, where the human stays in the loop - and this is a design decision about a process, not a personality trait about how cautious you are. The useful way to think about it is by consequence and reversibility. Where an agent's action is low-consequence and easily reversible - drafting, searching, proposing, producing a working file you can discard - let it run freely; interrupting there just wastes the autonomy you wanted. Where an action is high-consequence or hard to undo - anything that reaches a client or authority, spends money, changes live work, or makes a binding commitment - the human belongs in the loop before it happens, not after. Mapping your process this way, action by action, tells you exactly where to place the checkpoints and where to let go.

There is a spectrum here that Module 6 develops, from human-in-the-loop (the agent needs your approval to proceed at each significant step) through human-on-the-loop (the agent runs but you monitor and can intervene) to fuller autonomy (it runs to completion and you review after). None of these is right in the abstract; the correct level is set by the stakes of the specific process. A low-stakes internal research summary can run to completion and be reviewed after. A process that issues documents, spends money, or touches anything safety-related should keep a human firmly in the loop at the consequential moments, however capable the agent is. Choosing the level honestly - matching oversight to consequence rather than to convenience or enthusiasm - is the core professional judgement of orchestration.

Two things make intervention real rather than nominal. First, visibility: you can only intervene in what you can see, so a controllable process is one whose actions, reasoning and progress are observable - an agent working in an opaque black box cannot be meaningfully supervised, and for consequential work that opacity is itself a reason for caution (a theme that returns in Module 8). Second, the ability to stop: you need a reliable way to halt the process and take back control - a stop that actually stops, promptly. An autonomous process you cannot see into or cannot halt is not under your control no matter what the design says on paper. So build for observability and for a working brake, and treat the power to intervene as something you must be able to exercise in practice, not just claim in principle.

Put together, orchestration is the craft of setting up an agentic process so it does as much useful work autonomously as the stakes allow, and no more unsupervised than the stakes permit. The governing question for any process is simple: what is the worst thing this could do if it goes wrong, how likely am I to catch it, and how hard is it to undo? Your answer sets everything else - how tightly you scope the tools, what guardrails and budgets you impose, where you place the stopping conditions and checkpoints, and how much you keep a human in the loop. Low stakes, contained and reversible: light-touch control, let it run, review after. High stakes, consequential, hard to undo: rigorous guardrails, checkpoints at every consequential action, a human firmly in the loop, and never a black box you cannot see into or stop.

A further layer arrives when processes get complex - multiple steps chained together, or several agents working in concert (Module 6). Orchestration then also means designing the flow itself: which step feeds which, where the hand-offs are, and where a checkpoint sits between stages so a wrong result does not silently propagate down the whole pipeline. The principle is the same at every scale - bound it, watch it, gate the consequential moments, be able to stop it - but the design gets richer as the autonomy compounds. The temptation, as agents get more capable, is to remove the checkpoints because the agent 'usually gets it right'; resist it exactly where getting it wrong is expensive, because usually-right is not a defence for the one time it was confidently wrong on something that mattered.

This closes the agentic toolkit, and it closes it on the course's spine. You have learned to instruct an agent, to give it tools, to ground it in truth - and now to keep it under control. Every one of these is a way of directing an autonomous system while remaining the human who is responsible for what it does. Orchestration is where that responsibility becomes concrete: you design the boundaries, the stops, the checkpoints and the intervention points precisely because you, not the agent, answer for the outcome. Use agents boldly for the autonomous work they are genuinely good at; design the control that lets you do so safely; and keep, always, the ability to see what your agents are doing, to gate what matters, and to take back the wheel. Autonomy well bounded is a powerful instrument of practice. Autonomy unbounded is just risk with a plan.