Day 1 · Lesson 4 of the series

Context Engineering: The Right Payload, Not the Clever Prompt

Feeding the factory: what the agent knows, and when.

Lesson 3 named the factory's five parts, and its very first input: Specs & Context, the thing that defines what to build. This lesson zooms into that input. Every agent you run is only as good as the payload it starts from, and shaping that payload is the skill.

Recall first (spacing — answer before reading on)

From Lesson 3: the factory's first input — the thing that defines what to build — is —

A bigger model
Specs and context
The final output

Specs & context sit at the head of the line: they say what to build before any agent builds it. This lesson is that input, up close.

The one idea

As the field matured, one insight settled the argument: the quality of AI-generated code depends less on the cleverness of your prompts and more on the quality of the context you provide.¹ That is the durable reframe. The question worth asking isn't "how do I trick the AI into writing good code?" but "what would a new teammate need to know to contribute effectively, and how do I encode that knowledge in a form the AI can use?" Models don't need cleverly worded instructions so much as they need the same context a skilled human would need to do good work.

The six types of context

Every agent draws on six primary types of context:¹

Instructions — the agent's core role, goals, and operational boundaries.
Knowledge — retrieved documents, architectural diagrams, and domain data.
Memory — short-term session logs (what just happened) and long-term persistent state (what the project is).
Examples — few-shot behavioural demonstrations and codebase reference patterns.
Tools — the precise definitions of the APIs, scripts, and services the agent can invoke.
Guardrails — hard constraints, formatting rules, and safety validations.

The real trade-off: static vs dynamic

Context engineering is really about balancing which of those six the agent holds upfront versus what it retrieves on demand. That split is the whole game.¹

Static context is always loaded: system instructions, rule files (AGENTS.md, CLAUDE.md, GEMINI.md), global memory, persona. It defines who the agent is, and it's expensive, because every token is present in every interaction regardless of relevance.
Dynamic context is loaded on demand: skill instructions triggered by task match, tool results retrieved mid-execution, documents fetched from RAG, windowed session history. It's efficient: you pay the token cost only when the information is needed.

STATIC   (loaded every call)          DYNAMIC   (loaded on demand)
  ─ system instructions                 ─ skill instructions (task-matched)
  ─ AGENTS.md / CLAUDE.md rule files    ─ tool results
  ─ global memory + persona             ─ RAG documents
                                        ─ windowed session history

The static/dynamic boundary is a first-class architectural decision, reviewed and versioned like any other configuration. Too much static wastes tokens and dilutes signal; too little and the agent forgets critical rules.

And this is not only a technical dial. A dense, high-signal payload (a precise AGENTS.md, sharp guardrails) raises the agent's first-pass success rate and cuts token OpEx at scale, avoiding the trial-and-error loops that plague vibe coding. Context engineering is a financial lever.²

Agent Skills & progressive disclosure

The most powerful pattern for managing dynamic context is Agent Skills: structured, portable packages of procedural knowledge the agent loads only when the task calls for it.¹ Rather than embedding every specialism in the system prompt, skills let the agent stay a lightweight generalist that flexes into specialist roles through progressive disclosure:

startup     →  lightweight metadata only        (cheap; always present)
task match  →  full skill instructions load      (paid only when relevant)
deep need   →  reference material pulled          (paid only when explicit)

The result: one agent carries dozens of specialisms while paying the token cost for only the one it's actively using. Skills solve four problems that have plagued agent development: context rot from overloaded prompts; the absence of procedural memory for LLMs; the operational overhead of multi-agent architectures; and the need for portability across tools and vendors. (Aside: this very course is delivered through Claude "skills", the pattern in action as you read.)

Linkage: how Lessons 1–4 stack

Nothing new to memorise, context threads back through every prior zoom level:

CONTEXT   is the FACTORY's first input (specs & context)            ← Lesson 3
  └ STATIC context physically lives in the HARNESS's rule files       ← Lesson 2
      └ good context raises first-pass success → moves the DIAL right ← Lesson 1

Static context isn't abstract: it's the instructions and rule files that are the harness. Get the payload dense and the agent lands correct work more often, which is just a task pushed rightward on the dial. Day 3's companion paper takes sessions, skills & memory much further.

The governance layer, on context

Governance overlay · Lesson 4

You can't govern what an agent silently ingests

Guardrails-as-a-context-type are a build-time V Validation seed: they constrain the agent's output before it leaves. But controlling which Knowledge and Memory an agent may load or retain is a Compliance concern (C), data governance, not just prompt design. And static rule files are where policy is declared: the BIND phase of the governance ladder, which becomes "where agent instructions live" in Day 5. That declared policy is only worth what its enforcement, its VERDICT, makes real at runtime.

Ladder read: constraining an agent's accessible context is part of reaching L3 Controlled: you can't govern what an agent silently ingests. An agent with a versioned static/dynamic boundary and named limits on what it may retrieve is auditable; one that quietly pulls whatever it likes is back toward L1 Unseen.

Through your three lenses

Individual (IC)

Audit your agent's context: is it a dense, high-signal payload or a noisy dump? Put the stable rules in static (AGENTS.md) and pull the rest on demand. Write your first Skill for a workflow you repeat.

Team

Treat the static/dynamic boundary as a reviewed architectural decision, versioned in the repo, and share a Skills library so everyone's agents flex into specialists without bloating every prompt.

Organisation

Context engineering is a financial lever: dense payloads raise first-pass success and cut token OpEx at scale. Standardise rule-file conventions and a shared skills registry across teams.

Check the reflex

Recall, don't re-read.

Context engineering says AI output quality depends most on —

The cleverness of prompts
The size of model
The context you provide

The context. The reframe is from tricking the model with clever wording to giving it what a skilled teammate would need, encoded in a form the agent can use.

A rule file loaded on every single call is —

Static — always in context
Dynamic — loaded on-demand
A transient tool result

Static, and therefore expensive: every token is present in every interaction regardless of relevance. Dynamic context is paid for only when actually needed.

Agent Skills keep a generalist agent cheap by —

Embedding everything up-front
Loading detail only on-demand
Adding more frontier models

Progressive disclosure: metadata at startup, full instructions on task match, deep reference only when needed. That's how the agent stays a lightweight generalist that flexes into a specialist without carrying every specialism at once.

Carry this into the week

Open one agent's system prompt and read it line by line with one question: "which lines are truly static, needed on every single call, and which should be a Skill that loads only when the task calls for it?" Move one thing across the boundary. That's context engineering, done once.

Go deeper (primary source)

The Day-3 companion paper in this series, Context Engineering: Sessions, Skills & Memory — is the deep dive: designing sessions, writing and evaluating skills, building persistent memory, and optimising token economics for production. For a working practitioner's routine, Addy Osmani's "My LLM Coding Workflow" shows the payload discipline applied day to day.

Notes

Osmani, Saboo & Kartakis, The New SDLC With Vibe Coding (Day 1), "Context engineering: the real skill" pp.15–17.
Ibid., "Context Engineering as a Financial Lever" p.41.

Up next → Lesson 5: Conductor & Orchestrator + the 80% Problem. How the developer's role splits between conducting and orchestrating, and where AI's last 20% bites the hardest.