07 Orchestration Placement Diagnosis: Where a Need Belongs, and the Cost of Getting It Wrong

June 2026 (6433 Words, 36 Minutes)

Two ways to work through these cards. This page is the full exercise — all six cards, their scenarios, and the complete instructor key for each one (placement, kind of need, deciding axis, cost ledger, the tempting wrong placement and its cost, the one-sentence final placement, and a “draft the artifact” model answer). Read it linearly to study, or use it as the instructor and group-workshop guide (worksheet, warm-up example, group activity formats, rubric, debrief, grading scale all included below). For a gated self-study version where you decide each placement yourself before seeing the key, use the interactive quiz — the same six cards as placement + need + reflection questions with the analysis revealed after you submit.

Goal

In this exercise you treat six recurring needs in an AI-assisted development workflow as objects of study. For each need you decide where in the orchestration layer it belongs and why, then predict the cost of the tempting wrong placement, reasoned in context-budget and attention terms. This is a routing exercise: it cites budget reasoning only as justification, and it deliberately does not re-run the Lecture 7 lab’s three artifacts (the context-budget calculator, the buried-instruction experiment, the single-file CLAUDE.md redesign). By the end you will:

1. Route a recurring need to the right orchestration mechanism — root CLAUDE.md, a subdirectory CLAUDE.md, a skill, memory, a tool/MCP server, a hook/CI gate, or out-of-scope;
2. Classify the kind of need behind it — influence, enforcement, capability, or human ownership — using the completed three-layer model, extended with capability;
3. Reason about placement as a shared, finite context window: the window has a fixed size, so every token an always-on block occupies is a token (and a slice of cost and latency) not available to the task — treat “budget” as window occupancy and cost, not as a single pool of attention split evenly among tokens (attention is normalised per head and per position and concentrates on what the model has learned to weigh, so this budget metaphor is a planning heuristic, not a literal attention law);
4. Predict the concrete failure of a mis-placement — wasted window cost, lost-in-the-middle, never-loaded-so-absent, probable-not-guaranteed, stale memory, or widened blast radius.

This is the Lecture 7 sibling of the Lecture 6 “Prompt Strategy Diagnosis” exercise. There, the question was which prompting strategy fits this task; here it generalises to the orchestration layer: which mechanism should host this need, and what does the wrong host cost.

Learning objectives

After this exercise, students should be able to:

1. Place a recurring need at the right point in the orchestration layer, and justify the choice on a named axis (frequency, scope, provenance, likely-vs-guaranteed, touches-the-world).
2. Distinguish the four kinds of need — influence, enforcement, capability, human — and recognise that a placement decision sits inside a kind, not instead of it.
3. Reason in budget terms about always-on standing charges vs. on-demand vs. free, treating the context window as one finite, shared resource (occupancy and cost) — every always-on token is window the task does not get, which is true regardless of how attention itself distributes.
4. Predict the cost of a wrong placement mechanistically — name the failure mode and the mechanism behind it.
5. Reject the sterner CLAUDE.md reflex — recognising that more or louder influence never substitutes for enforcement, a capability, or a better placement.
6. Answer “it depends” responsibly by naming the deciding condition rather than leaving it bare.
7. Draft the artifact — sketch the SKILL.md, hook, MCP tool spec, memory note, or subdirectory file that the placement implies.

Recommended placement in the lecture

This exercise works best after students have worked through Lecture 7 §10 (the context budget) and §11 (the completed three-layer model), and ideally after the Lecture 6 “Prompt Strategy Diagnosis” workshop, because it reuses the influence/enforcement/human vocabulary and extends it.

Recommended sequence:

1. Short recap of the four kinds of need (influence, enforcement, capability, human) and the placement menu.
2. Introduce the diagnosis worksheet.
3. Work through the warm-up example together.
4. Students work in pairs or small groups on the cards.
5. Groups present placements and the cost of the wrong placement.
6. Instructor debrief connects answers back to context-budget engineering.

Duration options

Short version: 25–30 minutes

Use 3 cards (a good set: Card 1, Card 2, Card 6 — one skill extraction, one enforcement, one split-layer).

• 5 min: explain the task and show the placement menu
• 10–15 min: group work (placement only)
• 10 min: discussion and debrief

Standard version: 45–60 minutes

Use 4–5 cards.

• 5 min: recap the four kinds of need
• 5 min: instructor warm-up example
• 20–30 min: group work (placement + cost of the wrong placement)
• 15–20 min: presentations and debrief

Extended lab version: 90 minutes

Use all six cards and require students to draft the artifact for at least two of them.

• 10 min: recap and warm-up example
• 25 min: place and cost all six cards
• 25 min: draft the artifacts (SKILL.md, hook, MCP spec, memory note, subdirectory file, hook+permission sketch)
• 20 min: compare drafts
• 10 min: debrief and takeaways

Required prior concepts

Students should already be familiar with:

• CLAUDE.md / AGENTS.md and how they become tokens (§4) — the always-on rule (rule one) and the on-demand subdirectory splice (rule two)
• skills as context on demand (§7)
• the illusion of memory (§5) and CLAUDE.md vs MEMORY.md (§5.2)
• the tool-call loop (§8) and MCP, the standard interface (§9)
• the context budget (§10) — everything competes for one finite window
• the completed three-layer model — influence / enforcement / human (§11)

Placement menu reference sheet

Give students this compact reference before the exercise. The right-hand column is the single question that routes most needs.

A dating caveat. The mechanism names and paths above are mid-2026 Claude Code specifics; .claude/skills/, MEMORY.md, and the exact loader rules will date. The concepts — always-on vs. on-demand, influence vs. enforcement vs. capability, one shared budget — transfer to every orchestration layer. Keep the out-of-scope option live throughout: not every need deserves a permanent home.

The two cuts, restated

Every card is diagnosed twice.

• First cut — what kind of need is it? Extend Lecture 6’s three layers with a fourth:
  • Influence — text that enters the context and biases the distribution (CLAUDE.md, skills, memory, prompts, tool results).
  • Enforcement — a deterministic guarantee outside the model (hooks, CI, schema validation, scoped permissions).
  • Capability — the system must touch the world; only a tool can (§9.3: what an AI system can do is determined by its tool surface, not its intelligence).
  • Human judgment / ownership — what no automated layer can encode; the human owns the wrapper.
• Second cut — which concrete L7 mechanism hosts it? Use the placement menu above.

Throughout, treat “best solved by a sterner / better-worded CLAUDE.md” as a decoy. It is the reflex Lecture 7 is built to break: louder influence never becomes enforcement, never becomes a capability, and never fixes a placement.

Student worksheet

For each card, students fill out the following row.

Instructor warm-up example

Warm-up need: “Use British spelling in prose” — but for a need that is genuinely always-on, to contrast with Card 4.

Imagine a documentation repository where every file is prose and the whole team must use British spelling, enforced informally by review but not by any linter. Where does that belong?

The six cards

Each card is a recurring need. Decide where it belongs and why, then predict the cost of the tempting wrong placement. The cards vary: some have one clean home, one is a genuine “depends,” and one splits across two layers.

Card 1: The always-on rule that is really a one-task rule

The need. A 25-line quiz-formatting block — the <details markdown="1"> rule, the two-trailing-spaces rule, the quiz front-matter rules — currently lives in this repo’s root CLAUDE.md, and is therefore loaded into every session, including the hundreds of lecture-writing and slide-building sessions that never touch a quiz. We want the block reliably present whenever someone authors a quiz, without charging its tokens to every other conversation. (This repo has no .claude/skills/ directory yet — this would be a genuine first extraction.)

Student task. Place the need on both cuts, name the deciding axis, work the cost ledger, identify the tempting wrong placement and its cost, then draft the artifact.

.claude/skills/quiz-format/SKILL.md

---
name: quiz-format
description: Use when authoring or editing an interactive quiz under _quizzes/ — the Jekyll/Marp formatting rules a quiz file must follow.
---

When writing a quiz file, follow these formatting rules:

- Every <details> block must be written `<details markdown="1">`, or markdown
  inside it (bold, lists) renders as raw HTML.
- Each answer option line (A) … D)) must end with TWO trailing spaces, or the
  options collapse into one paragraph.
- Front matter must declare: layout: quiz, title, date, tags, lang, permalink,
  and a quiz: map (id, version, passingScore, allowRetry, showFeedbackImmediately).

[one short worked example of a correctly formatted question + answer block]

Card 2: “Always run add-anchors before committing a lecture”

The need. Lecture anchors must be regenerated by scripts/add_anchors.py whenever headings change, and the CI job check-anchors.yml already fails the PR if the committed anchors are stale. A teammate, tired of CI failures, proposes adding a strongly-worded paragraph to root CLAUDE.md: “ALWAYS run uv run add-anchors after editing a lecture. NEVER commit stale anchors.”

Student task. Place the need on both cuts, name the deciding axis, work the cost ledger, identify the tempting wrong placement and its cost, then draft the artifact.

Trigger:  pre-commit (and the existing check-anchors.yml on every PR)
Command:  uv run add-anchors --check   # regenerate, diff against committed files
Pass:     no diff — committed anchors already match the regenerated output → commit proceeds
Fail:     diff present — anchors are stale → abort the commit, print the offending files,
          tell the author to run `uv run add-anchors` and re-stage

Card 3: “Let the agent read and file tickets in our tracker”

The need. Instructors want Claude Code to look up open issues and open new ones from inside a session, instead of copy-pasting between the chat and the tracker.

• Realization A: connect a Jira/GitHub MCP server so the capability is available in every session.
• Realization B: when a session needs ticket text, paste the issue that one time and leave the tracker unwired.

The need arises about twice a week. Which wins?

Student task. Resolve the A/B — but only with a named condition. Place the need on both cuts, name the deciding axes, work the cost ledger, identify the tempting wrong placements and their costs, then draft the artifact.

Server:  github-issues (an MCP server wrapping the tracker)
Tools exposed (each: name, description, input/output schema):

  list_open_issues
    description: List open issues, optionally filtered by label or assignee.
    input:  { repo: string, label?: string, assignee?: string }
    output: [ { number: int, title: string, url: string, state: string } ]
    permission: read-only

  create_issue
    description: Open a new issue. Requires title; body optional.
    input:  { repo: string, title: string, body?: string, labels?: [string] }
    output: { number: int, url: string }
    permission: write — scoped to the course's repo only; human-confirm before create

Budget note: every tool's description above is paid in EVERY session once the
server is wired — justify the standing charge with real frequency before wiring.

Card 4: “Remember that I prefer British spelling and terse commit messages”

The need. This preference is genuinely personal (yours, not the team’s), genuinely recurring (most sessions), low-stakes, and verified by nothing — no test checks it, no convention enforces it.

• A: write it to the model-authored MEMORY.md.
• B: commit a “Preferences” block to the version-controlled root CLAUDE.md.

Student task. Place the need on both cuts, name the deciding axis, work the cost ledger, identify the tempting wrong placement and its cost, then draft the artifact. This is the rare card whose best home really is memory — and the card whose inverse lesson matters most.

~/.claude/projects/<project-id>/memory/preferences.md

# User preferences (soft — verify nothing against this)
- Prose: British spelling (colour, behaviour, optimise).
- Commit messages: terse — imperative subject line, no body unless non-obvious.

(These are personal and low-stakes. Do NOT store load-bearing technical facts here —
ports, endpoints, schema details — those go stale and are never verified; check the
repo for those instead.)

Card 5: A tests-only convention in a monorepo

The need. A convention applies only inside tests/: fixtures go in conftest.py, and tests must be parametrized rather than looped. This is a large repo; most sessions never touch tests. A colleague put the rule in root CLAUDE.md “to be safe.”

Student task. Place the need on both cuts, name the deciding axis, work the cost ledger, identify the tempting wrong placement and its cost, then draft the artifact.

tests/CLAUDE.md

# Conventions for this test suite
- Put all fixtures in `conftest.py`; do not define fixtures inline in test modules.
- Tests must be parametrized with `@pytest.mark.parametrize`, not written as loops
  over cases inside a single test function.
- One behaviour per test; name tests `test_<unit>_<condition>_<expected>`.

Card 6: A hard “no-secrets-in-logs / no-prod-deploy” rule that keeps slipping

The need. The assistant must never write code that logs secrets and must never run a production deploy. The team keeps adding sterner CLAUDE.md wording — “NEVER log credentials, this is CRITICAL” — and it still occasionally slips, especially after the model reads a web page or issue that contains an injected instruction.

Student task. Place the need on both cuts — note this one splits across two kinds of need — name the deciding axis, work the cost ledger, identify the tempting wrong placement and its cost, then draft the artifact.

1. Secret-scanning hook (pre-commit + CI)
   Command: run a secret/credential scanner over the diff (e.g. a gitleaks-style rule)
   Pass:    no credential-shaped strings, no logging of secret-typed values → proceed
   Fail:    block the commit/PR, report file+line — deterministic, not advisory

2. Deploy tool: scoped + schema-validated + gated
   - The deploy tool the model can call is wired ONLY to non-prod by default
     (scoped credentials: prod credentials are not present in the model's tool surface).
   - Input schema validated before execution: { environment: enum[dev, staging] } —
     "prod" is not a legal value the model can pass.
   - Any prod deploy requires a human approval gate at the interface (the orchestration
     layer holds the call and asks a human), never an automatic tool call.

3. Optional, kept SHORT: one CLAUDE.md line nudging "never log credentials" —
   influence that helps a little, but is NOT the guarantee.

Group activity formats

Option A: Placement only

Each group receives two cards.

For each card:

1. Name how often the need arises.
2. First cut: which kind of need (influence / enforcement / capability / human)?
3. Second cut: which L7 mechanism?
4. Name the deciding axis.
5. Name the tempting wrong placement and its concrete cost.

Each group presents one card in 2 minutes — and must say the cost of the wrong placement, not just the right answer.

Option B: Placement plus draft

Each group receives one card and must also draft the artifact — the SKILL.md skeleton, hook spec, MCP tool spec, memory note, subdirectory snippet, or hook+permission sketch the placement implies. The draft forces the placement from a label into something runnable.

Option C: Placement review

Treat an existing root CLAUDE.md as a code artifact under review. Students “review” it line by line and tag each block with a placement verdict:

• Genuinely always-on — keep in root
• One-task-type — extract to a skill
• Subtree-only — move to a subdirectory CLAUDE.md
• Personal soft preference — move to memory
• Needs a guarantee — replace with a hook/CI
• Needs to touch the world — this is a tool, not a rule
• Rarely needed — out-of-scope
• Sterner wording proposed where placement is the real fix — reject

Debrief questions

1. Which needs looked like CLAUDE.md material at first but belonged somewhere cheaper?
2. Where did “to be safe” (Card 5) or “be thorough” turn out to be a budget mistake?
3. Card 3: what exactly was the condition that decided A vs. B — and why is a bare “it depends” not an answer?
4. Card 4 is the only card whose home is memory. What made it the exception, and what would have made it the trap instead?
5. Where did someone want to prompt a capability into existence (Card 3, option C)? Why can’t influence grant a capability?
6. Card 6 split across two layers. Why is “enforcement only” closer to right than “influence only,” and why must the sterner CLAUDE.md box stay unchecked?
7. For each card, state the cost of the wrong placement in one phrase (wasted window cost / lost-in-the-middle / never-loaded / probable-not-guaranteed / stale memory / widened blast radius).
8. Which placements were free in budget terms — and why is “free” almost always the enforcement layer?

Assessment rubric

Use this rubric if the exercise is graded. Weight the cost-ledger and mis-placement-cost dimensions heavily — naming the right home is the easy half; reasoning about the cost of the wrong home is where the learning is.

Suggested grading scale

For a short in-class activity (per card):

• 2 points: correct placement (both cuts)
• 2 points: deciding axis named
• 3 points: cost ledger (always-on / on-demand / free)
• 3 points: mis-placement cost named with its mechanism

Total: 10 points per card.

For a larger homework assignment:

• 15% placement accuracy (both cuts)
• 15% deciding axis
• 25% cost-ledger reasoning
• 25% mis-placement-cost analysis
• 20% artifact drafts

The 50% weight on cost-ledger + mis-placement is deliberate: a student who routes every card correctly but cannot say why the wrong route is expensive has memorised a lookup table, not learned context engineering.

Instructor notes

Common student mistakes

1. Pattern-matching keywords without cost reasoning. “Security → enforcement, done” — without saying what the sterner-rule alternative actually costs. The cost is the lesson; the label is not.
2. Forcing every need into a mechanism. Not everything deserves a permanent home — keep the out-of-scope option live (and remember Card 4’s home is memory, not a mechanism at all in the CLAUDE.md/skill sense).
3. Treating split-layer answers as wrong. Card 6 is genuinely influence and enforcement; mark “enforcement only” as essentially correct and do not penalise a student who keeps a short influence line alongside the enforcement. The only failure is selecting the sterner CLAUDE.md decoy or relying on influence instead of enforcement.
4. Bare “it depends.” On Card 3, “it depends” with no named condition earns nothing. The whole skill is naming the hinge (frequency) — a conditional answer is excellent only when the condition is explicit.
5. Pattern-matching the topic. Card 4 (“British spelling”) routes to memory; the warm-up’s near-identical “British spelling” routes to root CLAUDE.md. Students who route by topic instead of by axis will get exactly one of them wrong.
6. Treating tokens as free. “Just put it in CLAUDE.md to be safe” (Card 5) is the most common and most expensive instinct — every always-on token is a token denied to the work.

Instructor emphasis

Repeat this sentence several times:

The right question is not “Where can this rule live?” but “How often is it needed, what does it guarantee, does it touch the world — and what does the wrong home cost in the one budget every tenant shares?”

And the standing reminder, since the paths will date:

The mechanism names are mid-2026 Claude Code specifics and will change. The axes — always-on vs. on-demand, influence vs. enforcement vs. capability, one finite shared window (occupancy and cost) — will not.

Final takeaway slide

Use this as the final slide of the exercise.

Orchestration placement diagnosis

A good AI-supported developer does not merely write CLAUDE.md.

A good AI-supported developer can:

1. Name how often a need arises, and what it must guarantee.
2. Decide its kind — influence, enforcement, capability, or human ownership.
3. Route it to the right mechanism — root file, subdirectory file, skill, memory, tool, or hook.
4. Reason about every candidate against one shared, finite window — its occupancy and cost.
5. Predict the concrete cost of the tempting wrong home.
6. Refuse to fix a placement problem by wording a file more sternly.

Placement is context engineering. The window is finite, so a token an always-on block occupies is a token of window (and a slice of cost) the task does not get.