Context Engineering Is the Job Now

Not prompt writing — that's the visible part and the small one. The work is deciding what reaches the model, in what form, at what moment, and it's where most agent failures start.

The role that emerged around agent systems doesn't have a settled name, and the work is consistent enough to describe: deciding what information reaches the model, in what form, at what moment.

Not prompt writing. Prompt writing is one small part of it, and the part that gets disproportionate attention because it's the visible one.

What the daily work consists of

Deciding what goes in the array. For each turn: which standing instructions, which retrieved material, which tool results, which accumulated history, which structured state. This is a per-turn budget allocation with real trade-offs, and it's mostly invisible in any prompt file.

Deciding what gets excluded, and how. Trimming, summarizing, moving out to a reference, replacing with a handle. Every exclusion is a bet about what won't be needed.

Deciding what's structured versus narrated. Run state as a compact block the loop regenerates, or as accumulated conversational turns. The first is checkable and survives compaction; the second is what happens by default.

Shaping what tools return. Field selection, unit clarity, empty-versus-failed distinction, error text that says what to do. → This is context engineering even though it looks like tool design, because a tool result is context.

Managing position and stability. What sits at the front, what at the end, what stays byte-identical across turns so caching works.

Deciding what's captured for later. What gets written to memory, notes, or decision records — which is context engineering across time rather than within a run.

Why it's the leverage point

Most agent failures are context failures. The information was missing, was buried, arrived in an unusable form, or was carried when it should have been dropped.

The diagnostic order for a failing agent puts context first for exactly this reason — and in practice most investigations end there, before reaching tool selection or reasoning.

⚠️ The tell that a team hasn't recognized this: repeated prompt edits attempting to fix a problem where the deciding information isn't in the array at all. A stronger instruction can't make the model use a fact it can't see.

What the skill actually requires

Reading the raw array. Not the rendered conversation — the exact payload. This is the single most important habit, and the one that separates people who debug agents effectively from people who guess.

Thinking in budgets. Every token is re-sent every turn. Context is a recurring cost, not a one-time allocation, and that reframing changes what you're willing to carry.

Anticipating what a later step needs. Turn twenty's requirements are decided at turn three, when something was kept or dropped.

Knowing what the model can't infer. Domain conventions, unit assumptions, organizational context. The gap between what's obvious to you and what's derivable from the array.

Comfort with structured state. The instinct is to put things in the conversation. The discipline is to put them in state the loop owns.

✅ The practices

  • Print the array on every turn, behind a flag, and read it when something goes wrong.
  • Hold run state as a regenerated block, not as accumulated messages.
  • Cap what any tool can return, and shape the return for a model rather than a log.
  • Re-inject standing constraints at the end of each turn's context.
  • Keep the prefix byte-stable so caching works, and measure hit rate.
  • Move large results out of context behind a reference.
  • Track context size per turn — growth should be predictable, and a jump is a defect.

💡 Why it's a distinct role

The work sits between the model and the domain. It requires knowing what the model can and can't do with a given input, and knowing the domain well enough to tell which information matters.

That combination is unusual, which is why the role is emerging as its own thing rather than being absorbed into either machine learning work or ordinary backend work. It's closer to systems engineering than to either, and the closest existing analogue is probably performance work: budgets, measurement, and knowing which of many plausible causes actually dominates.

The takeaway

Context engineering is deciding what information reaches the model, in what form, at what moment — including what tools return, what's held as structured state, and what's captured across runs. It's where most agent failures originate and where most of the leverage is. Read the raw array, think in recurring budgets, hold state outside the conversation, and stop trying to fix with instructions what's actually missing from the input.

Keep reading

Similar posts

Matched on shared tags and category — the more bars, the stronger the overlap with what you just read.