Agents & Orchestration

1 · What an agent actually is

▶ Watch: one coordinator, two specialists · 3 min

Your client says every agent must be registered. A vendor says their product ships twelve agents. A teammate says they built an agent last night. The word is doing three different jobs in those three sentences, and this module starts by pinning it down, because everything else depends on it.

Strip away the marketing and an agent is a stack of three layers:

An agent is all three running together: a model supplying judgment, a harness supplying hands and the loop, instructions supplying the job. So when a teammate "builds an agent" by writing a markdown file, what they actually built is layer three: a configuration the harness reads. And when a vendor sells a product with its own credentials running unattended at 2am, that is all three layers deployed as a standing system. Both get called agents, and they deserve very different governance: the markdown file gets reviewed like code, through pull requests and git history, while the standing system gets registered, monitored, and given an owner, like any other production system.

Whose definition is this?

A fair question to ask of any framework, so here is the honest sourcing. No standards body has settled what "agent" means: NIST's AI Risk Management Framework governs AI systems broadly and leaves the word undefined, and every vendor defines it in the shape of their own product. The closest thing to an authoritative anchor is the definition Anthropic published in Building Effective Agents (December 2024), the engineering guide this exam draws on: agents are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." The same guide draws a line the exam also tests: a workflow follows code paths a developer predefined, while an agent decides its own next step. The three layer stack above is this course's way of unpacking Anthropic's definition into parts you can point at during an architecture review. The definition is theirs. The layer names are ours, and when you use them with a client, say so.

Where Microsoft Copilot Studio agents fit

If your client builds agents in Microsoft Copilot Studio, they picture something that feels nothing like a markdown file, and the three layers explain why. A Copilot Studio agent is the full stack, rented whole:

And Copilot Studio's familiar features map straight onto vocabulary from this course:

• Its knowledge bases do the context layer's job: curated material the agent consults, playing the role CLAUDE.md files and skills play here.
• Its connectors and actions are the tool catalog: the allowlist of what the agent can actually reach and do.
• Its channels (Teams, Word, Excel) are the surfaces where the hosted harness meets the user.

The mapping also resolves a governance puzzle before it starts. A subagent in Claude Code is layer three alone: a file riding a harness that a person is operating right now. A Copilot Studio agent is all three layers, hosted, deployed to channels, and standing, which is why it lives in an admin center from the day it exists. Same word, opposite ends of a spectrum: subagent file, then your own session, then an SDK program, then a hosted platform agent. When someone says "agent," find where on that spectrum they are pointing, and half the meeting's confusion evaporates.

2 · The agentic loop (TS 1.1)

Two terms first, restated plainly so this section stands on its own. The harness is the ordinary program wrapped around the model: the software that assembles what the model sees, and that actually reads files and runs commands when the model asks. Claude Code is a harness. The agentic loop is what that program does, over and over, from the moment you press enter to the moment you get an answer. They are two different things: the harness is the machine, and the loop is the cycle the machine runs. The exam expects the cycle's steps cold, so here is one full turn, with a name on every step:

1. User input. You give the harness a task in plain language: "fix the pagination bug in api/users.ts."
2. Context assembly. The harness bundles everything the model will be allowed to see: the system prompt, the CLAUDE.md chain, your message, and the catalog of available tools, described in text. It sends the whole bundle to the model's API.
3. Model response. The model answers with text, and the harness checks one field of that answer, called stop_reason, to learn what kind of answer it just received. Two values matter: tool_use and end_turn.
4. Tool execution. stop_reason says tool_use: the model is asking for something, like "read api/users.ts." The harness runs its checks (permissions, hooks), executes the tool itself, appends the result to the conversation, and returns to step 2. This step can repeat dozens of times inside a single task.
5. Completion. stop_reason says end_turn: the model is finished. The harness shows you the final answer and the loop stops.

Two things about this loop matter more than the rest:

• The model never touches anything. It asks; the harness acts. Every file read, every command, every write flows through the harness's checks. That is why hooks and permissions work: they sit in the harness, on the only road every action travels.
• Control flow is model driven. Nobody scripted "read the file, then edit it." The model decides each next step from what it has seen so far, which is what makes agents flexible, and also what makes stop conditions and this module's handoff contracts necessary.

3 · Subagents: separate workers, separate briefcases (TS 1.3)

The agents/ folder has been sitting empty in the repo since the day it was scaffolded. Here is its full explanation.

A subagent is defined by one markdown file in .claude/agents/. This is a complete, real one, built in this module's closing demo:

---
name: researcher
description: Reads background material and produces short, source-cited
  summaries. Use for any task that means reading many files and reporting
  back, so the main session stays clean.
tools: Read, Grep, Glob
---

You are a research specialist. When given a question and a folder:

1. Find and read every relevant file. Be thorough.
2. Produce a summary of one page or less.
3. Cite the source file for every claim, like (research/2026-07-14-notes.md).
4. End with a "Gaps" line listing what you could not determine and why.
Your reply is your entire report. Anything you leave out is lost.

The frontmatter is the ID card: a name, a description (which works exactly like a skill's description: it is how the main session decides when to delegate), and a tools list. That tools line is quiet but important: this researcher can read, search, and match filenames, and nothing else. It cannot write files or run commands. Scoping tools per agent is least privilege for AI workers, and it is the first thing an enterprise reviewer will praise in your setup.

Below the frontmatter sits the agent's own system prompt: who it is, how it works, what its report must contain.

The part that makes subagents powerful: the separate window. When the main session delegates to the researcher, the harness spins up a fresh context window for it. The researcher reads forty files in there, fills its own briefcase to the brim, writes its one page report, and then that window is thrown away. Only the report crosses back. Know this boundary precisely, because the exam tests it:

Read those tables twice, because both directions bite. A subagent does not know what you and Claude discussed for an hour unless the task prompt says it. And you will never see what the researcher read unless its report says it. The boundary is the feature, and the boundary is also the failure mode.

4 · Orchestration patterns (TS 1.2)

One worker is delegation. Several workers need a shape, and four shapes cover nearly everything real:

The pattern to internalize first is hub and spoke, because the others are variations of it. The coordinator (usually your main session) owns three jobs: hold the goal, write clear task prompts for the specialists, and synthesize what comes back. The specialists own one job each, and their mess stays in their own windows. What makes the whole thing work is an unglamorous skill: the coordinator writing task prompts that contain everything the worker needs, because the worker starts with an empty window and knows only what the briefing says.

The adversarial review pattern deserves one extra note for your world: it is the cheapest quality control available. The reviewer agent's prompt says "find what is wrong with this," and an agent instructed to attack finds problems an agent instructed to summarize never mentions. The closing demo runs exactly this pair.

5 · Decomposition and handoffs (TS 1.6, 1.4)

Orchestration lives or dies at two moments: when you slice the work, and when the pieces pass between hands.

Slicing the work (TS 1.6)

Three rules cover most cases:

• Cut along independence. The best boundaries are where pieces need nothing from each other. Eight folders of meeting notes decompose beautifully (one researcher each, fan out). One tangled 400 line function does not decompose at all; forcing a split there costs more coordination than it saves.
• Every piece gets a deliverable. Not "look into the notes" but "produce a one page summary of decisions made, with a source citation per decision." A worker with a vague assignment returns a vague report, and vague reports poison the synthesis.
• Match the piece to the window. Each subtask should comfortably fit one worker's context. If a single slice needs 200 files, slice it again.

The handoff (TS 1.4)

Every delegation is a game of telephone: whatever the researcher fails to write in its report, the reviewer will never know, and the error compounds silently downstream. The defenses are contracts and checks:

• Report contracts. A well built worker's instructions end with requirements about the report itself: a citation for every claim, and a "Gaps" line admitting what it could not determine. That is a contract: the report must carry its own evidence and confess its own holes. Contracts turn handoffs from vibes into documents.
• Enforced sequence. In multi-step workflows, the coordinator verifies each step before starting the next: the draft exists before review begins, the review passed before anything is marked final. For hard enforcement, the hook machinery extends here: a SubagentStop hook fires when a subagent finishes and can run a deterministic check on what it produced.
• Escalate what you cannot complete. A worker that cannot complete its assignment should say so in its report, per the contract, and the coordinator decides what happens next. Workers that quietly improvise around gaps produce the worst class of errors: confident ones.

6 · Case study: the forty file Friday

The setup

The five consultant team at the regional health plan, one more time. The engagement partner asks for a current-state assessment of the client's AI governance: what has actually been decided across six months of steering committee meetings, working sessions, and workshops. The raw material: forty two meeting summaries sitting in the second brain's research/ folder. Due Monday.

The first attempt: one heroic session

A consultant opens one session Friday morning and starts feeding it meeting notes. By early afternoon:

• The context window is nearly full. Compaction kicks in and summarizes the morning, and details from the early files quietly blur.
• Asked to reconcile two meetings that disagreed about a decision, the session confidently cites the wrong one. The original wording is no longer in the window.
• The consultant is now re-reading files themselves to check the assistant's memory, which is the job the assistant was supposed to do.

Nothing is broken. The tool is being used against its own physics: one briefcase, forty two files, no chance.

The second attempt: decompose and orchestrate

Another consultant, who has read this module, structures it instead:

• Slice: the forty two files group naturally into six workstreams. Six research assignments, one per workstream. Independent slices, so they fan out in parallel.
• Contract: each researcher gets the same report shape: decisions made, open questions, contradictions found, one page, a citation per claim, a Gaps line.
• Synthesize: the main session, still clean, receives six one page reports and drafts the assessment from them.
• Attack: a reviewer agent gets the draft plus the six reports, with one instruction: find unsupported claims and contradictions. It flags two, including the disagreement that fooled the heroic session, visible now precisely because two researchers' reports contradicted each other and the contradiction had citations.

What changed

The assessment went out Sunday night. The main session's window held six pages of reports and one draft, never forty two raw files. Every claim in the final document traces to a source file, because the contract demanded citations at every handoff. And the two consultants did the same amount of directing; only one of them fought the physics.

The governance question this raises

The researcher is a markdown file in a git repo, reviewed like code. Now imagine the team likes it so much they schedule it: every Friday at 6pm, unattended, with standing credentials, filing reports nobody asked for that week. Same file. At what point did it become a system the client's registry should know about? Here is the working answer, in one sentence you can use in a steering committee: govern agent files like code (peer review before merge, git history as the record) until an agent gains standing access and runs without a person watching, and from that point treat it like any other production system: registered, monitored, owned. The moment of crossing is the moment to register, and everything before it is version control doing its job.

7 · Demo: watch the agents get built, then build yours

▶ Watch the demo: building your first agent team · 4 min

The prompt pack: every demo prompt, cleaned and explained

The demo applies this chapter prompt by prompt in the practice repo: the researcher agent built with read only tools and a report contract, the reviewer built to attack, a real delegation run against research notes, and then the isolation tests that prove the boundary is real in both directions. The closing beat asks the researcher to fix a file and watches it decline, because its tools list has no Write.

Then run the pack in your own repo. The prompt pack linked above holds every prompt from the demo, cleaned up and explained. Copied as is or rephrased in your own words, check what the demo checked as you go:

• A fresh session lists both agents when asked what agents exist. Discovery works.
• A research request produces a cited, one page report, and your main window never contains the raw files. Delegation and isolation work.
• Ask the main session for a detail that only exists inside one raw file. It does not know, because only the report crossed back. The boundary is real, in both directions.
• The reviewer, given the summary, returns specific criticisms with citations. Adversarial instructions produce adversarial reading.
• Ask the researcher to fix a file. It cannot: its tools list has no Write. Least privilege, working.

8 · Wrap-up: what you should be able to do cold

• Explain the three layers (model, harness, instructions) and place any "agent" someone mentions into them
• Walk the agentic loop from prompt to end_turn, including both stop_reason values and who executes tools
• Write a subagent file from memory: frontmatter (name, description, tools) and a system prompt with a report contract
• State precisely what crosses a subagent boundary in each direction, and what does not
• Choose among hub and spoke, fan out, pipeline, and adversarial review for a given task, and say why
• Decompose a real piece of work along independence lines, with a deliverable per slice
• Explain the telephone game failure and the three defenses: contracts, enforced sequence, escalation

Readings

Anthropic's Building Effective Agents (anthropic.com/news, December 2024) for the definition and the workflow versus agent distinction; Claude Code docs on Subagents (code.claude.com/docs); the Agent SDK documentation for the loop and stop_reason mechanics.

Take the Module 04 quiz →  then hit the Study App for Domain 1, lessons 1.1 through 1.6. This domain is 27% of the exam; drill it heaviest.