4.3 Everything Is a Transformation

There is one more habit of mind that makes all of this click, and it comes from the shape of the machine underneath. A large language model is a transformer, and it is extraordinarily good at one thing: turning an input into an output according to a simple-up-to-pretty-complex mapping function that it learns from its training data. So I suggest you frame every task you hand it as a series of transformations — the skill in using an agent is sizing each transformation to the model and to the guarantee you need. This chapter is about that sizing, and about how the three skills are all built from it.

A note for the curious. A "learned mapping function" is simpler than it sounds. Picture the model as one enormous mathematical function: you feed in the words of your prompt, and it hands back the words most likely to come next. "Learned from its training data" means nobody wrote that function's rules by hand — its billions of internal dials were tuned automatically, over a mountain of text, until its output matched the patterns in the data. The particular design that let this approach scale to today's models is the transformer, introduced in the 2017 paper "Attention Is All You Need" ¹1. Ashish Vaswani et al., “Attention Is All You Need,” in “Advances in Neural Information Processing Systems 30 (NIPS 2017),” special issue, Advances in Neural Information Processing Systems 30 (NIPS 2017), 2017, 5998–6008..

4.3.1 Size the leap to the model and the guarantee

Give a model an input and either examples of a transformation or a precise description of it, and it will apply that transformation to something new — as long as the new thing is close enough to the examples, or the rule is precise enough. The stronger the model, the bigger the leap it can make reliably. A strong model turns abstract instructions into working code; a weak one turns the same instructions into a dumpster fire, or nothing that compiles. So you tune two things together: the level of abstraction you speak at, and the size of the leap you ask for — against the model's strength and against how much guarantee you want.

The trade has a sweet spot, and you can feel for it by counting reasoning steps. Want high guarantees? Ask for smaller leaps, and check the result of each one as it lands. Want speed? Ask for bigger leaps, and accept that you trade away some of that per-step trust. The smaller the leap, the surer each step lands — and yet the more steps and tokens you pay; the bigger the leap, the fewer the steps — and yet the longer the reasoning each one takes. The right size is big enough to use the model's full power, but not so big it needs an exhausting chain of thought. And there is a hard reason not to let the chain run long: probabilities compound. A one-percent chance of going wrong per step is nothing over two steps and almost a certainty over a hundred. Size the transformation to the task's complexity and the model's scale, and you keep the failure probability where you can live with it.

4.3.2 The right-sized leap, and the wrong-shaped one

Two transformations from this book show the lens at work — one sized right, one shaped wrong.

The remediation core could ask a strong model for the whole leap: here is a document, hand back an accessible one. That is a single enormous transformation, and a strong enough model can, of course, sometimes make it. But it is expensive — the model reasons over the entire document on every call — slow, and unauditable, because you cannot see which change it made or why. So the system sizes the leap down. It scopes the work to a closed vocabulary of small typed edits — set the alt text on this image, set the role of this block, reorder these children — the same edit language the editor speaks in Part 5. The model is asked for one bounded edit at a time; each call reasons over one scoped task instead of the whole document, and each edit comes back typed, stamped, and reversible. This is where the transformation-sizing lens earns its keep, and changes a decision the loop-and-model lens does not: that lens says call the model to remediate; the sizing lens says call it for one edit at a time — cheaper, faster, and auditable, all at once.

Learn more about this governance mechanism: remediation verbs.

Sizing is only half of it. The transformation also has to be the right shape for the task and the model. I learned this the expensive way. For two weeks I sized a transformation beautifully and pointed it at the wrong problem — pulling a PDF's reading order out of the geometry of its bounding boxes, and handing that geometry to cheap vision models, which are bad at geometry. The model cheerfully made a doomed shape better and better. A well-sized transformation of the wrong shape is still the wrong transformation. So the skill has two halves: sizing the leap, and finding the one leap that fits both your task and your model — then abandoning the one that does not.

4.3.3 The skills are transformations all the way down

Figure 4.3-1 shows the shared skeleton — each skill carrying an input to an output through a sequence of sized transformations.

Once you see everything as a sized transformation, the three skills reveal a common skeleton. Each holds a set of models the agent reasons over, and each names the steps — the transformations — that carry an input to an output. What you supply, in your own context, is the breakdown: the playbooks and runbooks for the steps your work actually takes.

• Self-communicate stacks its transformations on the model's language weights, then layers the rhetorical figures (the "not X, but Y" among many others), then the writing genre from Diátaxis, then the lexicon for this context. It leaves the top layer to you: who is the audience, and what do they know? The skill cannot know that; you tell it.
• Self-operate puts the lifecycle models at the base, maps an incoming event to the kind of activity it is (development, bug fix, resource management, deploy), and then transforms forward: event to defect characterization or design document, design to steps, steps to distinct agent launches with their briefs. Each arrow is one transformation of input to output toward a goal.
• Self-governance holds a model of governance itself — architecture versus sensors, the properties that should hold of any codebase (don't-repeat-yourself among them), the kinds of sensor (static analysis, dynamic tests), the invariants you write over models, the languages you write them in, the checkers that validate them. Each catalogue entry is itself a transformation: from the symptom — the recurring failure you are living with — to the mechanism that ends it.

That last point runs through the whole book: each skill takes a general reasoning task and breaks it into a series of transformations over inputs into outputs, with steps the model can follow. This is not a coincidence of design — it is the shape of working with a transformer at all. It is why the companion catalogue can be read like a lookup table: you arrive with a symptom and leave with the mechanism, because the entry is the transformation between them. Work with agents through this lens — every task a sized sequence of input-to-output steps — and you will find yourself a much happier engineer.