The Five Primitives

Part 12 finished the tour of the five disciplines, and a tour is exactly what it was — a map of skills at the altitude of a career. Maps are no help on a Tuesday afternoon. When a ticket is open and an agent is waiting, “master context engineering” gives you nothing to type. Somewhere below the disciplines there has to be a craft layer: the concrete things a practitioner writes, over and over, that the disciplines are made of.

After enough time directing agents daily, I went looking for that layer in my own transcripts. Everything I write that actually moves work forward reduces to five recurring artefacts. I call them the five primitives, and this part is each of them with a worked example. The framing is mine — creator voice throughout — distilled from my own practice rather than borrowed from anyone's framework.

The layer under the disciplines

The 2024 playbook for working with models was clear instructions, relevant examples, chain-of-thought prompting and output formatting. All of that still matters, and part 2 argued it has become table stakes — the entry fee, not the differentiator. What replaced it as the differentiator is not one big skill but five small ones, each producing a specific artefact:

1. Self-contained problem statements
2. Acceptance criteria
3. Constraint architecture
4. Decomposition
5. Evaluation design

Each is small enough to write in minutes. Each is also a discipline in miniature, which is why I think of them as the craft layer: the primitives are how the disciplines survive contact with an ordinary working day. Through this part I will use one invented project as the running example — a freight-quoting service I will call quote-engine, an API that prices shipments from weight, route and service tier.

Primitive one: the self-contained problem statement

The rule: rewrite every request as if the recipient has never seen your project, does not know your organisational context, and has access to nothing beyond what you include. Here is the request most of us actually type:

Fix the rounding bug in the quote totals.

That statement leans on a heap of knowledge the agent does not have — which totals, rounded where, wrong how, correct compared to what. Here is the self-contained version:

quote-engine prices shipments in minor currency units (pence).
QuoteCalculator.ComputeTotal() multiplies a per-kg rate by weight,
applies a tier multiplier (0.85, 1.0 or 1.3), then converts to a
display amount. Totals are occasionally 1p off what finance expects.

Finance's rule: round half away from zero, once, at the final
display conversion — never on intermediate values.

Current behaviour: the tier multiplier result is rounded before
the conversion, so two roundings can occur.

Change ComputeTotal() so rounding happens exactly once, at display
conversion, using midpoint-away-from-zero. Do not change method
signatures or the tier multiplier values.

The second version took four minutes to write, and most of those minutes were spent discovering that I had never actually pinned down finance's rounding rule. That is the quiet value of this primitive: it audits your own understanding before it briefs anyone else's.

Primitive two: acceptance criteria a stranger could check

For every task, write three sentences that an independent observer could use to verify the output without asking you any questions. If you cannot write those three sentences, you do not understand the task well enough to delegate it. That test is the sharpest diagnostic I own — it catches under-specified work before an agent spends an hour building the wrong thing confidently.

For the rounding fix:

1. For a 12.5kg shipment on the standard tier at 30p/kg, the API
   returns exactly £3.75, matching finance's hand calculation.
2. A property test across 10,000 random weight/tier combinations
   shows every total equals the unrounded computation rounded once,
   half away from zero.
3. No public method signature in QuoteCalculator has changed.

Notice what the three sentences are not. They are not a restatement of the task (“the bug is fixed”), and they are not implementation instructions (“use decimal arithmetic”). They are observations a stranger could make. When the agent finishes, verification is mechanical — and when the agent works against them from the start, it tends to build the verification into the work.

Primitive three: constraint architecture

Constraints come in four categories, and a well-run agent needs all four stated: what it must do, what it must not do, what it should prefer when several valid approaches exist, and what it should escalate rather than decide on its own. Part 9 made the case that constraint documents age better than implementation documents; this primitive is that argument turned into a writing habit. For quote-engine:

MUST      keep all money arithmetic in minor units until display
MUST NOT  add new third-party dependencies without approval
PREFER    extending QuoteCalculatorTests over creating new fixtures
ESCALATE  any change that would alter a persisted quote record

The underrated category is escalate. Must and must-not are fences; prefer is taste; escalate is encoded judgement — a statement about where your delegation ends. An agent told what to escalate stops guessing at the boundaries of its own authority, and you stop discovering those boundaries in a diff. The best context files I have written are mostly this primitive: short, high-signal constraint documents rather than tours of the architecture.

Primitive four: decomposition

Break large tasks into components that can be executed independently, tested independently, and integrated predictably. My working rule is subtasks under two hours of agent work, each with explicit input and output boundaries. Suppose quote-engine needs multi-currency support:

1. Introduce a Money type (amount in minor units + currency code);
   adopt it inside QuoteCalculator only.        [no behaviour change]
2. Add an exchange-rate provider interface with a fixed-rate fake.
   [new code only]
3. Convert quote totals at display time using the provider.
   [depends on 1 and 2]
4. Persist the rate used on each quote record.  [depends on 3]
5. Property tests: conversion round-trips and rounding still
   single-pass in every currency.               [depends on 3]

Why two hours? Because review cost is the real budget. A two-hour unit produces a diff you can genuinely read in one sitting; a two-day unit produces a diff you skim. And the bracketed dependency notes matter as much as the numbering — they tell you which packages can run in parallel across separate agent sessions, and which failures stay contained when one goes wrong.

Primitive five: evaluation design

Build a growing test harness of prompts with expected results, and run it against every new model. The working rule: three to five cases with known-good outputs for every recurring AI task. For the tasks I delegate repeatedly around quote-engine, the harness is just a folder:

evals/
  rounding-fix/        prompt.md   expected-properties.md
  rate-import/         prompt.md   expected-shape.json
  release-notes/       prompt.md   good-example.md

Each case pairs a real prompt from my history with what a good answer verifiably contains. When a new model version arrives, the question “is it better for my work?” becomes an hour of running the folder instead of a fortnight of vibes. I will be honest, because part 15 is the honest ledger for this whole series: this is the primitive I practise least well. My folder exists; it is thinner than the rule I just gave you. It earns its place in the five anyway, because it is the only primitive that checks the other four.

Five primitives, five disciplines

The mapping back up the stack is not one-to-one, but it is real. The self-contained problem statement is context engineering in miniature — deciding, deliberately, everything the model gets to see. Acceptance criteria and decomposition are specification engineering scaled down to a single task: what done looks like, in verifiable units. Constraint architecture carries intent (the trade-offs and escalation boundaries) and feeds the harness (the constraint file that ships with the repository). Evaluation design is the empirical check on all of it — the layer that tells you whether any of the layers above actually work.

Which raises the question the primitives cannot answer on their own: given the same five artefacts, why do some practitioners delegate an autocomplete's worth of work and others run a factory? Next, the ladder that maps where people actually stand.