The Supporting Disciplines

Part 9 defended the core stack — Prompt Craft at 8, Context Engineering at 18, Intent Engineering at 15, Specification Engineering at 22 — and the awkward truth that stack position and weight are different orderings. That accounts for 63 of the framework's 100 points. This part is about the other 37, and about a structural decision that is easy to miss on first reading: the remaining four disciplines are not layers. Agent Architecture & Orchestration (12), Evaluation & Quality Engineering (10), AI Safety, Security & Governance (8) and Domain Translation & Systems Thinking (7) operate across the stack, not within it — they are the enablers that make the core reliable, safe and connected to something a user actually needs.

Across the stack, not in it

Why does the distinction matter enough to shape the model? Because the core stack describes a dependency chain — a specification executes inside a context, intent needs information to act on, everything terminates in instructions a model reads — and the supporting disciplines refuse to sit anywhere in that chain. Evaluation applies equally to a prompt, a context file and a week-long specification run. Governance constrains every layer at once. Architecture decides how many agents the stack is even running on. Put any of them into the stack and you would have to pick a single layer they belong to, which would be a lie at three other layers.

The lineage note from part 9 applies here too. My earlier learning material described five disciplines, including Harness Engineering; the competency framework has eight, and Harness Engineering is not one of them. Its information half dissolved into Context Engineering — and its machinery half is exactly where this part starts, because the harness's moving parts, the sessions, handoffs and recovery paths, became Agent Architecture & Orchestration.

Agent Architecture at 12 — the joints between the sessions

Agent architecture is the discipline of designing systems where multiple agents collaborate, hand off work, recover from failures and produce coherent output across sessions. It is what systems design becomes when the components are not services but working sessions of a model — and like systems design, the interesting problems are all at the joints.

The weight of 12 encodes a hierarchy I want to be explicit about: architecture serves the specification, not the other way around. The most elegant orchestration system is worthless if the specification it executes against is ambiguous — you have merely built machinery for producing the wrong thing faster. But the reverse failure is real too. A precise specification driven by a fragile architecture gives you demos that impress and pipelines that collapse: agents that lose state between sessions, one failed subtask corrupting everything downstream, recovery that needs a human at exactly the moment the system was supposed to be autonomous.

The even split is deliberate — four concerns, none of which can be skipped. The second row names the Planner-Worker pattern common in production agent systems: a capable model plans the work and decomposes it into subtasks, cheaper and faster models execute those subtasks, and a validation pass verifies. It is an architectural decision with real leverage in both directions — get the split wrong and you either overpay for compute by pointing an expensive model at routine work, or under-deliver on quality by pointing a cheap one at work that needed judgement. The last row is worth a second look as well: tool and protocol design is context engineering applied to capabilities rather than information. Deciding which tools an agent may invoke shapes its behaviour as much as deciding which documents it may read.

For what this discipline looks like practised seriously, the reference I keep returning to is StrongDM's Software Factory: their open-source coding agent, Attractor, is non-interactive and driven entirely by markdown specification files, and the integration surface is handled by what they call Digital Twin Universes — behavioural clones of third-party services such as Okta, Jira and Slack, built so agent-written code can be exercised against realistic dependencies without touching the real ones. Specification in, working software out — and every hard part of that sentence is architecture.

Evaluation & Quality at 10 — a folder of expected answers

If prompt craft is the art of input, evaluation is the art of knowing whether the input worked. In a world where agents run unattended for long stretches, this discipline is the only thing standing between “the agent produced output” and “output we can actually use” — it is what debugging transformed into when the thing being diagnosed stopped being your own code and became a system's behaviour.

The weight of 10 has a dependency built into it. A good specification embeds its own evaluation criteria — that was the fifth sub-discipline of Specification Engineering in part 9 — so strong specification practice inherently shrinks the evaluation burden. What remains is the independent verification layer, and it does not shrink to zero, because the author of a specification is the worst-placed person to notice what it failed to say.

The top row is the individual-scale habit I think every practitioner should copy, and it has a famous practitioner. Tobi Lütke, Shopify's CEO, has described keeping a personal eval — a folder of prompts with expected, judged results — that he runs against every new model release, so that “is the new model better for my work” is a measurement rather than a vibe; he talks it through in an ACQ2 interview. That is an eval harness in its smallest viable form, and the same shape scales all the way up to the third row, where StrongDM's factory keeps its scenarios outside the codebase: the agent builds the software, the scenarios judge it from the outside, and the agent never sees the criteria it is being judged against, so it cannot optimise for passing them instead of working. That is the holdout-set idea from machine learning applied to software delivery, and it addresses a behaviour that barely existed when humans wrote all the code — when an agent can see the test, teaching to the test is the default.

The failure mode without this discipline is the quiet one: output that looks reasonable and is subtly wrong, and regressions introduced by a model update that nobody detects because nobody built the eval. The gap between “does it look correct” and “is it actually correct” is exactly ten points wide in my model.

Safety, Security & Governance at 8 — the licence to deploy

This discipline is where the traditional framework's security concerns arrive in the AI era, and I frame it deliberately as a governance discipline: the set of duties an organisation must discharge before, during and after letting agents act on its behalf. It is the responsible-deployment question — what are we permitting this system to do, under whose oversight, within which rules — answered in infrastructure rather than in a policy document nobody reads.

Read the four rows as four duties of care. Adversarial defence is the duty to know that an agent reading untrusted content — a web page, a customer message, a retrieved document — can be steered by instructions hidden in that content, and to design so that being steered does not become being betrayed. Privacy and compliance is the duty owed to the data flowing through agent workflows, which process and generate text that may contain exactly the information regulations exist to protect. Bias and fairness is the duty owed to the people on the receiving end of automated output. And the fourth row is governance proper — approval workflows, monitoring, incident response, explicit human-oversight requirements — the machinery that turns “we deployed an agent” from a leap into a decision.

Why only 8 points? Because in this framework the discipline operates as a constraint on value creation rather than a source of it. Non-negotiable, in the way brakes are non-negotiable — a brilliant but ungoverned system is worse than a mediocre well-governed one — but for most practitioners the investment produces diminishing returns beyond a solid baseline, with deep expertise concentrating in specialist roles. The honest caveat from part 1 applies with full force here: the weights are defaults. An organisation deploying agents in a regulated industry should turn this dial up deliberately, and I would argue with anyone who ran the default weighting in a bank.

Domain Translation at 7 — the lowest weight, wearing it badly

The final discipline carries the framework's lowest weight, and the number reads worse than it is. Domain translation and systems thinking is the ability to connect what agents can do to what users actually need — the AI-era continuation of product understanding and user focus. And I will say in my own words what I believe about it: the qualities that separate great engineers from adequate ones have always included the ability to hold a whole product in your head, to reason about how the pieces interact, and to sense what the customer meant rather than what they said. None of that got less valuable when agents started writing the code. If anything, an agent amplifies whatever understanding — or misunderstanding — you hand it.

So why 7? Two reasons, neither of them disrespect. First, this is a meta-skill: it amplifies every other discipline rather than standing alone, and a weighted model prices distinct, trainable competencies, not multipliers. Second, it is the discipline where AI engineering borrows most directly from traditional engineering — these skills transfer almost unchanged, so the software framework has already paid for them once.

Where the discipline earns its place most visibly is brownfield work. Picture a system where the specification does not exist, the documentation is wrong, and the tests might cover 30 per cent of the code while the rest runs on institutional knowledge. No agent can write the specification for that system, because the specification lives in the head of the engineer who knows why the billing module treats Canadian customers differently. Formalising that knowledge — turning what a system implicitly does into something explicit an agent can execute against — is deeply human work, and it is the last row of that table.

That completes the framework: four core layers, four braces holding them steady, 100 points argued for across three parts. What remains is to make the numbers do something. Next, the template that turns the model into a plan: weighted planning and the 90-day loop.