Context engineering: getting useful output from AI

For a while everyone chased "prompt tricks" — the magic phrase, the secret role-play, the "you are a world-class expert" opener. I've stopped caring about wording almost entirely. The thing that actually moves the needle on whether AI gives me something useful isn't how I phrase the request. It's the context I put around it.

There's a name for this now — context engineering — and I think it's a better frame than prompt engineering. Prompting treats the model like a slot machine you tune with clever words. Context engineering treats it like a capable colleague who can only be as good as the brief you hand them. Hand them a one-liner and they guess. Hand them the right material and they're sharp.

What "context" actually means

When people say context they sometimes just mean "the prompt." I mean everything the model can see when it answers: your intent, a few examples of what good looks like, the actual data or code it needs to work on, the constraints it must respect, the output format you want back, and any tools it's allowed to use. That whole bundle is the context window. The model reasons over what's in it — and nothing else.

The context window is the whole brief: instructions, examples, data, constraints and tools → model → output.

Garbage context in, garbage out

The old "garbage in, garbage out" rule never went away — it just moved up a layer. A model can't reason about a metric you never defined, a schema it can't see, or an edge case you didn't mention. When the output is vague or wrong, my first instinct now isn't to reword. It's to ask what I failed to give it.

Here's a concrete one from my own week. "Write me a SQL query for monthly active users" is a coin flip — the model has to invent your table names, guess what "active" means, and assume a date column. Compare that with handing it the schema, one sample row, and the exact definition:

-- Vague ask (model has to guess everything)
"write SQL for monthly active users"

-- Engineered context (model has what it needs)
Table events(user_id bigint, event_name text, ts timestamptz)
-- sample row: 481922 | 'app_open' | 2025-11-03 08:14:22+00
Definition: an "active" user = ≥1 'app_open' in the calendar month.
Want: one row per month, month + distinct active users, last 12 months, Postgres.
Format: just the query, no prose.

The second version isn't more clever — it's more complete. I removed every guess. The model now produces a query I can run, against my real table, measuring the thing I actually meant. That's the whole game: most "the AI got it wrong" moments are really "I left a blank the model filled in for me."

Giving the model the right context almost always beats finding cleverer words. The skill isn't phrasing — it's deciding what to put in front of it.

Examples and format do a lot of quiet work

Two of the cheapest, highest-leverage things you can add are an example and an output spec. One example of a "good" answer communicates taste and structure faster than a paragraph of description — show it one before/after pair and it infers the pattern. And telling it exactly how you want the result back ("a markdown table with these columns", "valid JSON, no commentary", "three bullets, max ten words each") removes a whole class of cleanup. I'd rather spend one line constraining the format than five minutes reshaping the answer afterwards.

Constraints work the same way. "Don't assume a library that isn't already imported", "use UK date format", "if the data doesn't support a conclusion, say so" — each one closes a door you'd otherwise have to walk back through. Anthropic's guidance on prompting makes a similar point: being explicit about what you want, and giving the model the material to do it, beats hoping it reads your mind.

What I actually add to a request Before I hit send, I check five blanks: intent (what decision is this for?), data (did I paste the schema/snippet/row?), example (one "good" sample), constraints (what must it not do?), and format (exactly how I want it back). Filling those beats any opening line.

But more isn't always better

Here's the part people skip once they're sold on context: more context isn't automatically better context. Dump an entire 40-tab workbook, three unrelated docs, and a chat history into the window and you don't get a smarter answer — you get a distracted one. The signal you actually need gets buried in noise, and the model can latch onto the wrong detail. Long, cluttered context can quietly degrade quality, an effect people sometimes call "lost in the middle", where information buried in a long input gets used less reliably than the same fact placed up front.

So the goal isn't maximum context — it's the smallest set of highly relevant context. Tight and on-point beats big and vague. That's a judgement call, and it's exactly the part that doesn't automate: knowing which sample row, which column definition, which one example actually represents the problem.

My one-line takeaway Stop polishing the prompt. Start curating the context — the right data, one good example, clear constraints, an exact format — and keep it tight enough that the signal doesn't drown.

Why this is an analyst's skill

I find this framing freeing, because it's not a new mysterious art — it's the brief-writing skill I already needed. A good brief to a junior analyst and a good brief to a model rhyme: state the question, share the data, define the terms, show an example, set the constraints, name the format. The people who get the most out of these tools aren't the ones hoarding prompt incantations. They're the ones who are clear about what they want and disciplined about handing over what's needed to get there.

That's the shift I'd encourage: treat the model as a fast, capable colleague who only knows what you tell it. Engineer the context, keep it lean, and the wording mostly takes care of itself.