Agentic Engineering: A Post-Doctoral Curriculum from Intermediate to Expert Level

Prepared for Datacraft | Revised 23 October 2026 (v2)

0. Scope, assumptions, and epistemic discipline

0.1 Assumptions

The learner is assumed to have:

1. Working command of probability, optimisation, and Markov decision processes.
2. Working knowledge of transformer language models and of at least one production programming language.
3. Prior experience calling LLM APIs and building at least one retrieval-augmented or tool-using prototype.

Part 0 (the Mathematical Prelude) is the bridging course. It is designed to be completed before Part I, but it is also a reference that learners will return to throughout. If the learner already commands all of Part 0, the two-week compressed path through §0.4 (evaluation statistics), §0.5 (verification theory), and §0.9 (cost models) is the minimum.

0.2 Currency and evidence tiers

• Tier A: peer-reviewed or arXiv-indexed works, forming the stable spine.
• Tier B: vendor engineering publications and specifications.
• Tier C: secondary aggregators and leaderboards, used only to locate candidates.

0.3 Reproduction-status discipline (new in v2)

Every core reading carries a reproduction status:

The curriculum applies to its own citations the standard it asks learners to apply to vendor benchmarks. In particular:

• arXiv:2609.00006 (eleven-system study): S — source-code analysis, non-peer-reviewed, but inspectable and the 90-line scaffold is released.
• arXiv:2604.25850 (AHE): P — single-lab; the Terminal-Bench 2 pass@1 improvement (69.7% → 77.0%) is unreplicated.
• arXiv:2605.10325 (VPR) and arXiv:2607.07435 (RLVP): P — theoretical hook (benefit depends on verifier reliability) is sound; empirical claims await replication.
• arXiv:2608.05179 (autonomous research survey): P — useful for problem framing; the “38% release execution traces” and “no externally validated in-loop oracle” claims are survey-derived and should be treated as hypotheses.
• arXiv:2503.14499 (METR time horizon): S with strong caveats (see §1.4 of v1 critique; now formalised in Module 5).

Vendor-reported benchmark numbers, especially for open-weight releases, must be reproduced in the learner’s own harness before reliance. Module 5 and Module 12 teach this explicitly.

PART 0: MATHEMATICAL PRELUDE (Bridging Course, Weeks 0a–0d, ~4 weeks part-time)

Purpose. Provide the derivations, results, and formal objects that the rest of the curriculum assumes. Each section ends with a derivation to reproduce by hand and a concept check. The cheat sheet in §0.10 is the consolidated reference.

0.1 Probability, concentration, and resampling

Objects. Random variables, filtrations, martingales; sub-Gaussian and sub-exponential tails; Hoeffding, Bernstein, and McDiarmid inequalities; the empirical bootstrap and its consistency; the paired bootstrap.

Key results.

• Hoeffding: for bounded $X_i \in [a,b]$, $\Pr(|\bar X - \mathbb{E}X| \ge t) \le 2\exp(-2nt^2/(b-a)^2)$.
• Bernstein: variance-adaptive tail bound; the right tool when success probabilities are near 0 or 1 (as in agent evaluation).
• McDiarmid: bounded differences inequality; underpins stability arguments for harness edits.
• Bootstrap consistency: $\sup_t |\hat F_n^*(t) - \hat F_n(t)| \to 0$ a.s.; the paired bootstrap for $\Delta = \mu_A - \mu_B$ resamples pairs $(x_i^A, x_i^B)$, preserving dependence.

Derivation to reproduce. Show that the paired bootstrap variance estimator is $\widehat{\mathrm{Var}}^*(\bar\Delta) = \frac{1}{B}\sum_b (\bar\Delta^{*b} - \bar\Delta^*)^2$ and explain why pairing reduces variance when $A$ and $B$ are positively correlated (as they are when evaluated on the same tasks).

Concept check. Why is an unpaired bootstrap anti-conservative when the same task set is used for both harnesses?

0.2 POMDPs, belief states, and the agent-as-policy formalism

Objects. POMDP $(\mathcal{S}, \mathcal{A}, \mathcal{T}, \mathcal{O}, \mathcal{Z}, R, \gamma)$; belief $b_t(s) = \Pr(s_t = s \mid h_t)$; belief update $b_{t+1} = \tau(b_t, a_t, o_{t+1})$; policy $\pi(a \mid b)$; value $V^\pi(b)$; Bellman backup for beliefs.

Key results.

• Belief MDP equivalence: a POMDP is an MDP over the belief simplex; optimal policies exist and are deterministic in beliefs.
• The context window is an implicit, lossy, non-Bayesian belief state: it is not a sufficient statistic for $b_t$, and its update is not the Bayes filter. This is the formal content of “context engineering.”
• Partial observability sources for LLM agents: (i) unobserved environment state (filesystem, network, external services); (ii) unobserved tool stochasticity (latency, transient errors); (iii) unobserved model state (sampling, temperature, hidden reasoning).

Derivation to reproduce. For a two-state POMDP with a binary observation, write the belief update explicitly and show that the belief is a one-dimensional sufficient statistic. Then show that a finite context window with truncation is not a sufficient statistic by constructing a history whose truncation loses the information needed to distinguish the two states.

Concept check. In what sense is “compaction” a lossy belief-state projection, and what is the analogue of the projection error?

0.3 Information theory for context and tool interfaces

Objects. Entropy $H(X)$; conditional entropy; mutual information $I(X;Y)$; KL divergence $D_{\mathrm{KL}}(p|q)$; cross-entropy; channel capacity; data-processing inequality.

Key results.

• Chain rule: $H(X_1,\dots,X_n) = \sum_i H(X_i \mid X_{<i})$.
• Data-processing: if $X \to Y \to Z$ is a Markov chain, $I(X;Z) \le I(X;Y)$. Consequence for harnesses: any lossy summarisation or compaction step cannot increase the information about the task available downstream.
• KL decomposition for policy regularisation: $D_{\mathrm{KL}}(\pi_\theta | \pi_{\mathrm{ref}}) = \mathbb{E}_{\pi_\theta}[\log \pi_\theta - \log \pi_{\mathrm{ref}}]$; this is the term that anchors RLHF/GRPO to a reference policy.
• Tool-interface information: a tool schema is a code; its expected description length under the task distribution is a lower bound on the tokens it consumes. Coarse tools have lower schema cost but higher per-call ambiguity; fine-grained tools invert the trade-off.

Derivation to reproduce. Show that the expected token cost of a tool-selection policy is bounded below by the conditional entropy of the correct tool given the context, $H(\text{tool} \mid \text{context})$, plus the schema description length. Interpret the gap as “interface inefficiency.”

Concept check. Why does the data-processing inequality imply that no amount of post-hoc prompting can recover information destroyed by an aggressive compaction step?

0.4 Evaluation statistics for agents

Objects. Estimands (mean success, pass^k, cost-per-success); estimators; sampling variance; paired and unpaired designs; factorial designs; variance decomposition; multiple-comparison control (Holm, Benjamini–Hochberg); power analysis; pre-registration.

Key results.

• pass^k reliability. If per-trial success is $p$ and trials are independent, $\Pr(\text{all } k \text{ succeed}) = p^k$ and $\Pr(\text{at least one succeeds}) = 1-(1-p)^k$. Under positive intra-task correlation $\rho$, the effective $p^k$ is higher than $p^k$ (tasks that are easy stay easy); under negative correlation it is lower. Report $\rho$ or use a mixed-effects model.
• Two-way factorial with interaction. For model $i$, harness $j$, replicate $k$:

The interaction term $(\alpha\beta)_{ij}$ is the harness-confounded comparison term: a significant interaction means the model ranking depends on the harness. This is the formal version of “rankings flip under harness changes.”

• Variance decomposition. $\mathrm{Var}(y) = \mathrm{Var}_\text{model} + \mathrm{Var}_\text{harness} + \mathrm{Var}_\text{interaction} + \mathrm{Var}_\text{residual}$. Report the proportion of variance attributable to each factor; this is the quantitative answer to “is the harness load-bearing?”
• Paired bootstrap for $\Delta$. Resample tasks with replacement; recompute $\Delta^{*b}$; report the percentile interval. Use BCa when the task distribution is skewed.
• Multiple comparisons. With $m$ harness edits tested, control family-wise error at $\alpha$ via Holm, or false-discovery rate via Benjamini–Hochberg. Report both the raw and adjusted p-values.
• Power. For a two-arm comparison with per-task success $p$, the number of tasks needed to detect $\Delta$ at power $1-\beta$ scales as $n \propto (z_{1-\alpha/2}+z_{1-\beta})^2 \cdot 2p(1-p)/\Delta^2$. Compute this before running the experiment.

Derivation to reproduce. Derive the non-centrality parameter for the two-sample proportion test, and show that detecting a 3-percentage-point improvement from a 60% baseline at 80% power requires roughly 2,700 tasks per arm. Discuss the implication for benchmark sizes.

Concept check. A vendor reports “+5 points on Terminal-Bench 2.” What four questions must you ask before believing it? (Answer: harness fixed? seeds? pass^k or best-of-k? multiple comparisons across the suite?)

0.5 Verification theory and the autonomy–reliability trade-off

This is the formal core of the curriculum. Every autonomy decision is a verification decision.

Objects. A verifier $V: \mathcal{Y} \to {0,1}$ (accept/reject) applied to an agent output $y$. Ground-truth correctness $C \in {0,1}$. Sensitivity (true-positive rate) $\mathrm{TPR} = \Pr(V=1 \mid C=1)$; specificity $1-\mathrm{FPR} = \Pr(V=0 \mid C=0)$; base rate $\pi = \Pr(C=1)$; precision $\Pr(C=1 \mid V=1)$.

Key results.

• Precision–recall from ROC. $\mathrm{Precision} = \frac{\mathrm{TPR}\cdot\pi}{\mathrm{TPR}\cdot\pi + \mathrm{FPR}\cdot(1-\pi)}$. Precision collapses as $\pi \to 0$ even for a good verifier: a 99%/1% verifier at $\pi = 0.05$ yields precision $\approx 0.84$; at $\pi = 0.01$, precision $\approx 0.50$.
• Autonomy condition. If the cost of an undetected failure is $C_f$ and the cost of human review is $C_h$, autonomous release is rational iff

i.e. the expected cost of missed failures is below the review cost. This is the autonomy threshold.

• Verification budget. Expected cost per successfully completed and verified task:

where $C_g$ is generation cost and $C_v$ is verification cost. The denominator is the probability that a released output is correct. Minimise over the verifier’s operating point (ROC curve) and over the amount of compute spent generating candidates.

• Sequential verification (SPRT). For a verifier with log-likelihood ratio increments, stop and accept when $\Lambda_n \ge \log\frac{1-\beta}{\alpha}$, stop and reject when $\Lambda_n \le \log\frac{\beta}{1-\alpha}$. SPRT minimises expected sample size among tests with the same error rates (Wald–Wolfowitz).
• LLM-as-judge calibration. A judge is a verifier. Calibrate it on a labelled set; report its ROC, not its accuracy. Accuracy hides the base-rate dependence.

Derivation to reproduce. Derive the autonomy threshold from the inequality above and show that it is monotone in $\mathrm{TPR}$ and in $\pi$. Then show that for fixed $\mathrm{TPR}$, lowering $\mathrm{FPR}$ is not always worth the cost—derive the marginal condition.

Concept check. A verifier has TPR = 0.95 and FPR = 0.10. The base rate of correct outputs is 0.60. What is its precision? If the cost of a missed failure is 50× the cost of review, is autonomous release rational?

0.6 Policy gradient, GRPO, and KL-regularised objectives

Objects. Trajectory $\tau = (s_0,a_0,\dots)$; return $R(\tau)$; policy $\pi_\theta$; advantage $A^\pi(s,a)$; the policy gradient theorem; REINFORCE; group-relative baselines (GRPO); KL-regularised objective.

Key results.

• Policy gradient theorem. $\nabla_\theta J(\theta) = \mathbb{E}_{\tau\sim\pi_\theta}!\left[\sum_t \nabla_\theta \log \pi_\theta(a_t\mid s_t)\, A^\pi(s_t,a_t)\right]$.
• REINFORCE. Use the empirical return $G_t$ as an unbiased estimate of $A^\pi$; variance reduction via baselines $b(s_t)$: $\nabla_\theta \log\pi_\theta(a_t\mid s_t)(G_t - b(s_t))$.
• GRPO. For a group of $G$ rollouts from the same prompt, normalise returns within the group: $\hat A_i = (r_i - \bar r)/\mathrm{std}(r)$. This removes the critic and makes the advantage scale-free, which is why it is the default for verifiable-reward agentic RL.
• KL-regularised objective. $J(\theta) = \mathbb{E}[R] - \beta\, \mathbb{E}[D_{\mathrm{KL}}(\pi_\theta|\pi_{\mathrm{ref}})]$. The gradient acquires a term $-\beta(\log\pi_\theta - \log\pi_{\mathrm{ref}} + 1)$; $\beta$ controls the entropy–reward trade-off.
• Entropy collapse. The gradient of the entropy bonus is $-\nabla H(\pi_\theta)$; when the reward dominates, the policy sharpens, $H \to 0$, exploration dies, and the agent overfits to the verifier. This is the formal mechanism behind reward hacking in agentic RL.
• Credit assignment. Sparse turn-level rewards give high-variance advantage estimates. Dense verifiable rewards (VPR, RLVP) reduce variance at the cost of verifier-reliability exposure—which is why §0.5 is a prerequisite, not an aside.

Derivation to reproduce. Derive the GRPO gradient from the policy gradient theorem with a group baseline, and show that the group mean is an unbiased baseline but the group standard deviation introduces a (small) bias. Discuss the implication for small $G$.

Concept check. Why does KL regularisation not prevent reward hacking when the verifier itself is hackable?

0.7 Control theory for harness design

Objects. Feedforward (guide) versus feedback (sensor) control; observability; controllability; stability; the internal model principle; PID as a metaphor.

Key results.

• Guides vs sensors. A linter is feedforward (prevents the error); a test suite is feedback (detects the error). The internal model principle says a controller must contain a model of the disturbances it rejects—hence the harness must model the failure modes it guards against, not just the happy path.
• Observability. A harness is observable to the extent its traces determine the agent’s internal state and decision path. AHE’s three pillars (component, experience, decision) are an observability specification: without decision observability, credit assignment for edits is impossible.
• Stability. An evolution loop that edits the harness based on noisy small-sample evaluations is a feedback loop with delay and noise; it can oscillate or diverge. The remedy is damping (held-out validation, pre-declared predictions, minimum edit size).

Derivation to reproduce. Model the harness-evolution loop as a first-order discrete system $h_{t+1} = h_t + \eta\,\widehat{\nabla}(h_t)$ with noisy gradient estimate; derive the condition on $\eta$ for stability as a function of gradient noise variance and delay. Interpret “pre-declared prediction” as a variance-reduction device.

Concept check. Why is a harness that is highly sensitive to a single noisy metric unstable by construction?

0.8 Queuing, latency, and throughput

Objects. Arrival rate $\lambda$; service time distribution; utilisation $\rho = \lambda/\mu$; Little’s law $L = \lambda W$; p95 and tail latency; burstiness.

Key results.

• Little’s law. $L = \lambda W$ for any stable system, independent of distribution.
• Kingman’s formula. For a G/G/1 queue, expected wait $\approx \frac{\rho}{1-\rho}\cdot\frac{c_a^2+c_s^2}{2}\cdot \frac{1}{\mu}$. Agentic workloads have high $c_a^2$ (bursty tool calls) and high $c_s^2$ (variable generation length), so tail latency is structurally worse than chat workloads.
• Prefix caching. For a reused prefix of length $L_p$ with cache hit rate $h$, effective cost $C = h\,C_{\text{cached}}(L_p) + (1-h)\,C_{\text{prefill}}(L_p) + C_{\text{gen}}$. Cache-aware context layout maximises $h$ for the stable prefix.

Derivation to reproduce. Derive Little’s law from first principles (flow conservation) and apply it to an agent run of $n$ tool calls with mean latency $\bar L$ and mean inter-call think time $\bar T$. Compute the throughput ceiling.

Concept check. Why does continuous batching improve throughput but not necessarily p95 latency?

0.9 Cost models and unit economics

Objects. Token cost $C_{\text{tok}} = p_{\text{in}}\cdot n_{\text{in}} + p_{\text{out}}\cdot n_{\text{out}}$; cache pricing; cost per successful task; cost per verified success; verification budget; Pareto frontier of accuracy vs cost.

Key results.

• Cost per verified success (restating §0.5): minimise over verifier operating point and candidate count.
• Routing and cascades. With a cheap model of success $p_c$ and a strong model of success $p_s > p_c$, a cascade that escalates on verifier rejection costs $C_c + (1-p_c^{\text{ver}})\,C_s$, where $p_c^{\text{ver}}$ is the probability the cheap model produces a verifier-accepted output. Escalate iff the expected saving exceeds the strong-model cost.
• FinOps invariant. $\mathbb{E}[\text{cost per task}] = \mathbb{E}[\text{tokens}]\,p_{\text{tok}} + \mathbb{E}[\text{tool calls}]\,\bar c_{\text{tool}} + \mathbb{E}[\text{verifier calls}]\,c_{\text{ver}}$. Track all three; agent cost regressions are usually tool-latency or retry-loop regressions, not token-price regressions.

Derivation to reproduce. Derive the cascade-escalation condition and show that it depends on the verifier’s TPR, not on the verifier’s accuracy. Explain why.

Concept check. A harness change reduces tokens per task by 20% but increases retries by 30%. Is it cheaper? Under what condition?

0.10 Cheat sheet: annotated terms, results, theorems, formulae

A. Probability and statistics

B. POMDP and RL

C. Information theory

D. Evaluation

E. Verification

F. Control and systems

G. Security and governance

PART I: FOUNDATIONS AND EVALUATION (Weeks 1–6)

Module 1: Build first—the minimal harness, then the formal foundations (Weeks 1–2)

Rationale (v2 change). Learners build the 90-line minimum-viable-harness scaffold before the formal POMDP treatment, then revisit the formalisation with a concrete artefact in hand.

Objectives. Implement the scaffold; formalise it as a policy over a partially observable, tool-augmented environment; distinguish workflow, single agent, and multi-agent.

Content.

• Scaffold implementation: loop, tool interface, context manager, termination. (The scaffold is described in arXiv:2609.00006, S.)
• Agents as POMDPs: textual/multimodal observation space; structured tool-call action space; environment-plus-stochastic-tool transition kernel; context window as implicit lossy belief (§0.2).
• Classical antecedents: Wooldridge and Jennings (1995); BDI; the LLM-as-policy contrast.
• Workflow vs agent: the “simplest thing that works” principle (Anthropic, Building effective agents, B).
• Decision procedure (new). A decision tree grounded in task properties: number of distinct tools; observability of intermediate state; verifiability of outcomes; cost of failure; variance in task structure. Apply it to three tasks from the learner’s own experience.
• Constitutive definition of a harness and its four necessary elements (§1 of v1; S).

Lab 1a. Implement the scaffold and run it on three tasks. Record traces. Lab 1b. Write a formal specification (no code) of the scaffold as a POMDP, naming observation, action, belief, termination, and the three largest sources of partial observability. Apply the decision tree and defend the architecture choice.

Readings. Yao et al., ReAct, arXiv:2210.03629 (R); Schick et al., Toolformer, arXiv:2302.04761 (R); arXiv:2609.00006 (S); Anthropic, Building effective agents (B).

Module 2: Tool interfaces, structured action, and protocols (Week 3)

Content.

• Function calling as constrained generation; grammar-constrained decoding; schema design as interface design.
• The ACI thesis (SWE-agent, arXiv:2405.15793, R): tool ergonomics dominate raw capability at the margin.
• MCP: transport, capability negotiation, authorisation; donated Dec 2025 to the Agentic AI Foundation (Linux Foundation). A2A v1.0 (B): agent cards, declared security schemes, and the risk that card rewriting redirects callers or injects prompts.
• Skills files as progressive disclosure; adoption 9/11 vs 8/11 for MCP (S).
• Interface-efficiency metric (new). Using §0.3: measure $\mathbb{E}[\text{tokens}]$ against the entropy lower bound for tool selection; report the gap.

Lab. Design three alternative tool surfaces (coarse, fine-grained, code-execution) and run an ablation reporting success rate, token cost, error-recovery behaviour, and interface inefficiency.

Module 3: Context engineering (Weeks 4–5)

Content.

• Positional degradation and distractor sensitivity (Liu et al., arXiv:2307.03172, R); effective vs nominal context at million-token scale.
• Compaction, summarisation, scratchpads, externalised memory (MemGPT, arXiv:2310.08560, R); evolving playbooks (Agentic Context Engineering, arXiv:2510.04618, P).
• Retrieval as an agent decision; just-in-time loading vs pre-loading.
• Compaction as lossy projection (new, formal). Use §0.3: quantify information loss by downstream task success, not summary quality. Derive the projection error bound.
• Prompt-caching economics and cache-aware layout (§0.8).
• DSPy (arXiv:2310.03714, R) as a counterpoint to hand-tuning.

Lab. Take a 200-step trajectory and engineer three compaction policies; measure information loss through downstream success, and report the projection error against a held-out oracle summary.

Module 4: Reasoning, planning, and test-time compute (Week 6)

Content.

• ReAct, Tree of Thoughts (arXiv:2305.10601, R), Reflexion (arXiv:2303.11366, R), Self-Refine (arXiv:2303.17651, R); empirical limits of self-correction without external signal.
• Process vs outcome supervision (Lightman et al., arXiv:2305.20050, R).
• Test-time scaling: best-of-n with verifiers; sequential vs parallel compute; when reasoning “thinking” helps or harms tool loops.
• METR time-horizon: a case study in metric misuse (new). Cite arXiv:2503.14499 (S, with caveats). Teach: error bars are a factor of ~2 each direction; 40–100× domain variation (software vs computer-use); 50% horizon ≠ delegable horizon (reliability-critical tasks need 98%+). Require a one-page critique of how a vendor might misuse the number and what a rigorous reviewer should ask.

Lab. Reproduce a published self-correction result with and without an external verifier; report the delta with confidence intervals. Plus: write the METR misuse critique.

Module 5: Evaluation science for agents (Week 7)

Content.

• Benchmark landscape: SWE-bench (arXiv:2310.06770, R), tau-bench (arXiv:2406.12045, R; pass^k), WebArena (arXiv:2307.13854, R), OSWorld (arXiv:2404.07972, R), AgentBench (arXiv:2308.03688, R), Terminal-Bench, BrowseComp, long-horizon suites.
• Statistical practice: variance across seeds; paired bootstrap; multiple-comparison control; pass^k vs best-of-k; report $\rho$ or use mixed-effects.
• Harness-confounded comparison (formal). Factorial design with interaction term (§0.4); variance decomposition into model/harness/interaction; pre-registered analysis.
• Contamination, leakage, reward-hackable graders; evidence tiers and reproduction status.
• Metrics that mislead under extrapolation (new). Time horizon as the primary case; second case: “average score across a suite” hides per-task variance and is sensitive to task weighting.

Lab. Build an evaluation protocol (design document + acceptance criteria) comparing two open-weight models across two harnesses, with a pre-registered analysis plan, a power calculation, and a multiple-comparison strategy.

PART II: HARNESS ENGINEERING (Weeks 8–17)

Module 6: Anatomy of a harness and component classification (Week 8)

Content.

• ETCLOVG layers mapped onto real systems; the eleven-system study’s 18 recommendations and 90-line scaffold (S).
• Anthropic’s April 2026 guidance (B): build on tools the model already knows; remove harness assumptions as capabilities improve; set UX, cost, and safety boundaries deliberately.
• Harness component classification (new, resolves the bitter-lesson tension).
  • (i) Irreducible components: verification, permission enforcement, audit logging—exist because of deployment context, not model weakness. Permanent.
  • (ii) Capability-compensating components: prompt scaffolds, few-shot exemplars, schema simplifications—should be removed as models improve. Temporary.
  • (iii) Performance-tuning components: compaction thresholds, parallelism, cache layouts—require re-tuning per model and task. Persistent but not permanent.
• Convergence and imitation (from the eleven-system study): behavioural policy migrating from prose into configuration files.

Lab. Reverse-engineer one open-source harness: component map, control-flow diagram, five model assumptions that another family might violate, and a classification of every component into (i)/(ii)/(iii) with justification.

Module 7: Execution environments, sandboxing, and verification loops (Weeks 9–10)

Content.

• Isolation primitives (containers, microVMs, gVisor-class); filesystem and network egress policy; ephemeral vs persistent state; reproducible environments.
• Verification as the core of autonomy: tests, type checkers, linters, property-based checks, differential testing, LLM-as-judge with calibration. Verifier reliability is a first-class parameter—developed fully in Module 17b.
• Permission models: allow-lists, human-in-the-loop gates, capability tokens, deterministic enforcement independent of model compliance.
• Failure recovery: idempotent tools, checkpoint/rollback, loop and stall detection.

Lab. Instrument a harness with a deterministic pre-execution policy engine; red-team it with ten adversarial tool-call sequences; report false-allow and false-deny rates with confidence intervals.

Module 8: Long-horizon state, memory, and decomposition (Weeks 11–12)

Content.

• Multi-context execution: progress files, structured handoff artefacts, initialiser vs worker patterns.
• Subagent delegation: when context isolation beats shared context; cost and coordination overhead.
• Repository knowledge: AGENTS.md and similar; progressive disclosure; instruction rot.
• Planning representations: task graphs, checklists, spec-driven development.
• Skills as reusable procedural memory (Voyager, arXiv:2305.16291, R).

Lab. Execute a task requiring more than five context windows; compare three handoff protocols on completion rate, regression rate, token cost, and information loss (using §0.3).

Module 9: Architectural constraints and entropy management (Week 13)

Content.

• OpenAI’s three-part decomposition (context engineering; architectural constraints enforced by linters/agents; entropy management via periodic clean-up agents) as a hypothesis from a single organisation’s experience (B/C); test it.
• Guides vs sensors (new, formal): feedforward vs feedback, internal model principle (§0.7).
• CI as ground truth; mutation testing as agent-robustness probe; codebase legibility.
• DORA-style baselines before/after adoption.

Lab. Retrofit a repository with a constraint layer; A/B protocol to test whether defect escape rate falls; report the stability margin of the change (§0.7).

Module 10: Automatic harness optimisation and self-evolution (Weeks 14–15)

Content.

• AHE (arXiv:2604.25850, P): component, experience, decision observability; closed evolution loop; self-declared prediction per edit, later verified.
• Self-Harness (failure-trace mining, minimal edits, regression validation) and Harness-Zero (harness distillation into student models) — read primaries, not the awesome-list summary (P).
• Evolutionary and self-improving systems: AlphaEvolve (arXiv:2506.13131, P), Darwin Gödel Machine (arXiv:2505.22954, P).
• Stability of the evolution loop (new). §0.7: step size, noise, delay; pre-declared predictions as variance reduction; held-out validation as damping.
• Overfitting the harness to the benchmark; held-out task families; credit-attribution in noisy small-sample edits.

Lab. Specify a harness-evolution loop with explicit edit log, pre-declared prediction per edit, held-out validation, and a stability analysis. Report which edits survived.

Module 11: Observability, cost, and latency engineering (Weeks 16–17)

Content.

• Trace schemas for agent runs; OpenTelemetry GenAI conventions; trajectory storage; drill-down.
• Trace schema design as a lab (new). The minimal schema supporting AHE-style decision observability: what fields must be present to support (a) failure clustering by tool-call pattern, (b) regression attribution to a harness edit, (c) cost per successful task.
• Failure taxonomies and error analysis at scale (MAST, Module 18).
• Cost models (§0.9): tokens, cache hit rates, tool latency, parallelism; Pareto frontiers; routing and cascades.
• Verification budget (new, bridge to §0.5 and Module 22). Model total cost per task = generation + verification + expected failure cost; compute optimal verification spend for a given task distribution and verifier ROC.
• Incident analysis and postmortems for non-deterministic systems.

Lab 11a. Build a trajectory-analysis workflow clustering failures from 1,000 runs; ship one harness change motivated by the largest cluster and measure its effect. Lab 11b. Design a trace schema; instrument a harness; demonstrate the three queries above.

PART III: OPEN-WEIGHT MODELS AND INFERENCE SYSTEMS (Weeks 18–23)

Module 12: Open-weight landscape and selection methodology (Week 18)

Content.

• Architecture: sparse MoE (total vs active parameters); multi-head latent attention; hybrid linear attention; long-context training recipes.
• Licence analysis: MIT, Apache 2.0, modified MIT, bespoke community licences with revenue/API thresholds; commercial-use verdicts for agent products.
• Selection protocol (replaces the v1 table). Every learner fills a dossier from primary sources:
  1. Licence text URL + one-sentence commercial-use verdict.
  2. Hardware BOM: memory bandwidth, interconnect, aggregate VRAM for weights + KV cache at target context.
  3. A reproduced benchmark number using the learner’s own harness (Module 5 discipline).
  4. Measured tool-call parse-failure rate under the learner’s harness (§0.5 precision impact).
  5. Reasoning-format and stop-token compatibility notes.
• Candidate families are named only as starting hypotheses, each requiring verification before use:
  • Moonshot Kimi K-series (note: parameter counts and licences vary by release; verify against the model card).
  • Z.ai GLM-5.x (vendor-adjacent source; reproduce before use).
  • DeepSeek V4 family (verify architecture claims against the model card, not hobbyist inference repos).
  • Qwen3.x and Gemma 4 for local/edge and subagent roles.
  • Devstral, gpt-oss-20b/120b (Apache 2.0) as fine-tuning substrates and baselines.
  • Specialists (e.g., Lean 4 proof engineering) for verifier-rich domains.
• The hub: Hugging Face catalogue (>3M open models) and the curated weekly catalogue on Microsoft Foundry Managed Compute (B).

Lab. Produce a model-selection dossier for a stated use case: shortlist, licence review, hardware BOM, reproduction of two vendor numbers, measured parse-failure rate, go/no-go recommendation. Any row not fillable from primary sources within one week is deleted.

Module 13: Inference engineering (Weeks 19–20)

Content.

• Serving stacks (vLLM, SGLang, TensorRT-LLM, llama.cpp): continuous batching, paged attention, prefix/KV-cache reuse, speculative decoding, disaggregated prefill/decode, expert parallelism for MoE.
• Quantisation (FP8, FP4, GGUF K-quants, AWQ/GPTQ) and its measurable effect on long-horizon tool-use accuracy—often worse than on short benchmarks.
• Chat templates and tool-call parsers: the most common silent failure when running an open model in a foreign harness. Unit-test serialisation, reasoning-token handling, stop tokens.
• Capacity planning: agentic workloads (long prefixes, bursty tool latency) differ sharply from chat; use Kingman (§0.8) to predict tails.

Lab. Serve one MoE and one dense model with two engines; characterise throughput, p95 latency, and tool-call parse-failure rate under a replayed agent workload.

Module 14: Model–harness co-adaptation and heterogeneous fleets (Weeks 21–22)

Content.

• Running open models in harnesses built for proprietary conventions; what must adapt (tool schemas, reasoning formats, compaction thresholds, retry policy).
• Capability-tiered architectures: strong planner + cheap executors; routers, cascades, verification-gated escalation (§0.9).
• Distilling harness behaviour into smaller models (Harness-Zero).
• Data sovereignty and air-gapped deployment.

Lab (Part III capstone). Hold the task set fixed; cross three open models with three harness configurations in a 3×3 factorial; decompose variance into model, harness, and interaction effects (§0.4); report the interaction term as the quantitative answer to “is the harness load-bearing here?”

Module 14b: Harness–model co-evolution research agenda (Week 23)

New module. Deepen Module 6’s classification into a research programme.

• Which components are converging across harnesses (imitation), and which are diverging (task-specific)?
• Does harness evolution encode general engineering knowledge (transferable across task families) or benchmark-specific overfitting? Design an experiment to distinguish them.
• What is the minimal harness that preserves safety properties as capability increases? (Bridge to Module 19.)

Lab. Take one component from Module 6’s classification and design a longitudinal experiment (two model generations or two capability tiers) to test whether it is compensating or irreducible. Pre-register the prediction.

PART IV: TRAINING AND ADAPTATION OF AGENTS (Weeks 24–30)

Module 15: Trajectory SFT, distillation, and data engineering (Week 24)

Content.

• Rejection-sampled trajectories; teacher–student distillation; trajectory filtering by verifier (note: filter quality is verifier reliability, §0.5).
• Data contamination, privacy, licence provenance of trajectory corpora.
• SWE-agent-style trajectory datasets; SWE-RL (arXiv:2502.18449, P) as a bridge to RL.

Lab. Build a filtered 5,000-trajectory SFT set; analyse which filtering criteria change the student’s pass^k; report the verifier’s ROC used for filtering.

Module 16: Agentic reinforcement learning (Weeks 25–27)

Content.

• Foundations: GRPO (arXiv:2402.03300, R); RLVR lineage (DeepSeek-R1, arXiv:2501.12948, R); survey (arXiv:2509.08827, P).
• Credit assignment over long horizons. VPR (arXiv:2605.10325, P) converts symbolic/algorithmic oracles into dense turn-level supervision; benefit depends on verifier reliability. RLVP (arXiv:2607.07435, P) uses verifiable per-action penalties within GRPO.
• Instability and diagnosis: RL gains masked by control-token and formatting failures; sparse turn-level rewards cause collapse (APPO, PACT via survey arXiv:2608.05179, P; read primaries).
• Reward hacking as the dominant failure; verification as a limited resource allocated adaptively (§0.5, §0.9).
• Off-policy and asynchronous rollout systems; KL control; entropy collapse (§0.6); rollout infrastructure costs.

Lab. Small-scale agentic RL experiment (7B–30B open model on a verifiable terminal/tool-use environment). Deliverable: report with explicit reward-hacking audit, outcome-only vs dense-verifiable ablation, and a pre-registered replication attempt of one published result at affordable scale. The deliverable is the failure analysis: what broke, what the verifier missed, what compute prevented testing.

Module 17a: Environment engineering (Week 28)

Content.

• Environments as the new datasets: hermetic, resettable, instrumented, non-leaky.
• Synthetic task generation from failure traces; curriculum design; difficulty calibration.
• Formal-verification domains (Lean 4) as the extreme case of reliable reward.

Lab. Construct a 100-task environment with held-out verifiers; publish a datasheet including exploits found by attacking your own graders.

Module 17b: Verifier engineering and reliability measurement (Week 29) — new module, split from v1 Module 17

Rationale. The curriculum’s central claim—that autonomy is bounded by verification—requires a dedicated module with the same statistical discipline as evaluation.

Content.

• Oracle construction: symbolic, differential, metamorphic, property-based.
• LLM-as-judge calibration against human labels; report ROC, not accuracy (§0.5).
• Measurement of TPR/FPR with confidence intervals; base-rate dependence of precision.
• The autonomy threshold $(1-\mathrm{TPR})\pi C_f<C_h$ and its use in release decisions.
• Sequential verification (SPRT) and adaptive verifier allocation.
• Verifier attack: reward hacking, specification gaming, judge manipulation.
• Verifier economics: cost per verified success; the optimal operating point on the ROC curve.

Lab. Construct a verifier for a task family; attack it to find exploits; report its ROC curve on a held-out distribution with confidence intervals; compute the autonomy threshold for a stated $C_f/C_h$; implement one SPRT-based sequential verification policy and compare its expected sample size to fixed-length verification.

Readings. arXiv:2605.10325 (P); arXiv:2607.07435 (P); arXiv:2608.05179 (P); AgentDojo (arXiv:2406.13352, R).

Module 17c: Verification budget and autonomy economics (Week 30) — new, bridge module

Content.

• Total cost per task = generation + verification + expected failure cost (§0.9).
• Minimisation over verifier operating point and candidate count.
• Routing, cascades, and verification-gated escalation.
• Case study: a high-stakes vs low-stakes task family; compute the optimal verification spend for each.

Lab. For a stated deployment, compute the optimal verification budget across a grid of verifier operating points and candidate counts; produce a decision memo recommending an autonomy level with the supporting arithmetic.

PART V: MULTI-AGENT SYSTEMS, SECURITY, GOVERNANCE, PRODUCTION (Weeks 31–38)

Module 18: Multi-agent architectures and protocols (Weeks 31–32)

Content.

• Orchestrator–worker, debate, blackboard, market, hierarchical patterns (AutoGen, arXiv:2308.08155, R; Generative Agents, arXiv:2304.03442, R).
• MAST failure taxonomy (arXiv:2503.13657, P): 14 failure modes across system design, inter-agent misalignment, task verification. Test the null hypothesis that a single well-harnessed agent beats the multi-agent design.
• A2A v1.0: agent cards, declared security schemes; card-rewriting risk (redirection, prompt injection).
• Coordination costs, shared-state consistency, cross-agent identity.

Lab. Build the same task as single-agent and multi-agent systems; compare reliability, cost, diagnosability; MAST-code failures across ≥50 trajectories per condition; report failure-mode frequencies and which categories are architecture-specific vs model-specific.

Module 19: Agent security (Weeks 33–34)

Content.

• Threat model: indirect prompt injection (Greshake et al., arXiv:2302.12173, R); tool poisoning; malicious skills; confused deputy; exfiltration through permitted channels.
• The lethal trifecta as a design constraint (new framing). Private data + untrusted content + external communication. Teach learners to rule out architectures that cannot be secured, not merely to harden chosen ones. Include memory poisoning, inter-agent communication, and cascading failures from the OWASP Agentic Top 10 2026 (B).
• Provable-by-construction defences: CaMeL (arXiv:2503.18813, P); capability-based information-flow control; privilege separation.
• Benchmarks: AgentDojo (arXiv:2406.13352, R).
• Ecosystem standards: OWASP Top 10 for Agentic Applications 2026; scanners for MCP servers/skills.
• Supply-chain hygiene: skills, MCP servers, model weights (pickle and template-injection risks).

Lab 19a (pre-design). Given a task specification, identify which architectures are ruled out by the lethal trifecta, memory poisoning, and cascading-failure potential; justify each elimination in writing. Lab 19b (red-team). Red-team your Module 7 harness against an indirect-injection suite; implement one architectural mitigation; quantify residual attack success rate with confidence intervals.

Module 20: Oversight, alignment, and governance (Week 35)

Content.

• Control and monitoring of capable agents; scalable oversight; sabotage/sandbagging evaluations; chain-of-thought monitorability and its fragility.
• Reward hacking in deployment vs in training (bridge to §0.6).
• Regulatory landscape (EU AI Act obligations for GP and high-risk systems; sectoral rules); logging and auditability; accountability for delegated action.

Lab. Governance dossier (risk register, human-oversight design, audit-log specification) for a hypothetical high-autonomy deployment; include the autonomy threshold and verification budget from Modules 17b/17c.

Module 21: Computer-use, research, and domain agents (Week 36)

Content.

• GUI and browser agents (OSWorld, WebArena); perception–action grounding; why browsing benchmarks reward persistence.
• Autonomous research agents and the verification gap (arXiv:2608.05179, P): verification of agent behaviour is often the limiting obstacle, not raw capability.
• Domain adaptation in high-stakes verticals; human-expert integration.

Lab. Select a domain relevant to your practice and specify its verifier before designing the agent; report the verifier ROC and the autonomy threshold.

Module 22: Production operations and organisational adoption (Weeks 37–38)

Content.

• SLOs for stochastic systems; canarying harness changes; model-version pinning and regression suites; rollback.
• Unit economics and FinOps; the three-term cost invariant (§0.9).
• Team topologies; review practice for agent-authored changes; measuring productivity without Goodhart effects.
• Stability of operational feedback loops (new). §0.7 applied to canary → rollback cycles.

Capstone. See §3.

3. Capstone and assessment

3.1 Capstone tracks (Weeks 35–38, in parallel with Modules 20–22)

1. Harness track. A novel instrumented harness component or optimisation loop with a factorial evaluation across ≥2 open-weight models, a pre-registered analysis, and a stability analysis of the evolution loop.
2. Training track. An agentic RL or distillation study with a documented reward-hacking audit, a released environment and verifier, and a verifier ROC.
3. Systems-security track. A production-grade deployment architecture with threat model, red-team results, operating-cost model, and an architecture-elimination justification (Module 19a). Optionally grounded in a real Datacraft workload.
4. Replication and negative-result track (new). A pre-registered replication of a published result (e.g., VPR, RLVP, AHE’s Terminal-Bench delta, a self-correction result), with a report publishable whether or not the result replicates. The deliverable is the evidence, including failure analysis and the conditions under which the result did or did not transfer.

3.2 Assessment weights

Labs 40%; evaluation-methodology critique of one published agent paper 15%; capstone 35%; oral defence 10%.

3.3 Mastery criteria

1. Every claimed improvement carries uncertainty estimates, harness controls, and a power calculation.
2. Every autonomy increase is paired with a named verifier, its ROC, and the autonomy threshold.
3. Every external input is treated as untrusted, and every architecture is checked against the lethal trifecta before it is built.
4. Every citation carries its evidence tier and reproduction status; every vendor claim is either reproduced or explicitly marked unreproduced.
5. Every factorial comparison reports the model × harness interaction term.

4. Suggested ongoing literature practice

Maintain a weekly triage of arXiv (cs.AI, cs.CL, cs.SE, cs.CR), the Hugging Face Daily Papers feed, and the awesome-harness-engineering index (https://github.com/ai-boost/awesome-harness-engineering). Record each paper’s evidence tier, reproduction status, and whether its headline result has an independent reproduction. Log negative results in a shared register; they are scarce and valuable.

5. Principal references

Foundational (verify identifiers before circulating): arXiv:2210.03629, 2302.04761, 2303.11366, 2305.10601, 2305.16291, 2307.03172, 2308.08155, 2310.06770, 2405.15793, 2406.12045, 2406.13352, 2402.03300, 2501.12948, 2503.13657, 2503.14499, 2503.18813, 2302.12173, 2505.22954, 2506.13131.

Harness and agent engineering: Li et al., Agent Harness Engineering: A Survey (ETCLOVG), https://picrew.github.io/LLM-Harness/; Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents, arXiv:2609.00006 (S); Lin et al., Agentic Harness Engineering, arXiv:2604.25850 (P).

Verification and RL: Verifiable Process Rewards for Agentic Reasoning, arXiv:2605.10325 (P); Li and Shi, Penalize the Path, Reward the Outcome (RLVP), arXiv:2607.07435 (P); Autonomous Research Agents: A Survey of AI Scientists and the Verification Gap, arXiv:2608.05179 (P).

Specifications and vendor material: Anthropic, Building effective agents, https://www.anthropic.com/engineering/building-effective-agents (B); A2A specification, https://a2a-protocol.org/v1.0.0/specification/ (B); OWASP Top 10 for Agentic Applications 2026, https://genai.owasp.org (B); awesome-harness-engineering, https://github.com/ai-boost/awesome-harness-engineering (C).

6. Open questions (revised: intellectual, not administrative)

1. Convergence or divergence? Is harness engineering converging on a canonical architecture, or are harnesses diverging into task-specific families? What evidence would distinguish the two?
2. General engineering knowledge or benchmark overfitting? Does harness evolution encode transferable knowledge, or does it overfit to the benchmarks used to evaluate it? Design the experiment.
3. Prospective verifier reliability. Can verifier reliability be estimated before deployment on a new task distribution, or only post hoc? What are the assumptions under which prospective estimation is possible?
4. The minimal safe harness. As capability increases, what is the minimal harness that preserves safety properties (permissions, audit, verification) while shedding compensating scaffolds?
5. The autonomy threshold under uncertainty. How should the autonomy decision change when $C_f$, $\mathrm{TPR}$, and $\pi$ are themselves estimated with uncertainty?
6. Credit assignment in harness evolution. When a harness edit improves a noisy small-sample metric, how should the evidence be weighted against the multiplicity of edits and the possibility of benchmark overfitting?

Administrative questions (delivery mode, on-prem vs hosted weighting, annotated bibliography) remain open and should be resolved before circulation but are not intellectual contributions to the syllabus.