Context Engineering 101: Give AI Enough of You That It Helps

If your AI output feels generic, the model isn't the problem. You're giving it generic input. The fix isn't a better model or a more clever prompt. It's context — specifically, your context, served to the model in a form it can read faster than you can re-explain yourself for the hundredth time.

This post is the short version of how. It assumes you already know how to prompt. It assumes you have a life, a business, a voice, or a project that contains enough of you to be worth feeding a model. And it assumes you're willing to do about ninety minutes of one-time setup in exchange for never writing the same background paragraph into a chat window again.

What Context Engineering Actually Is

Context engineering is the practice of assembling, classifying, and retrieving the background material an AI needs to do a specific job well. It's a new name for something you've been doing badly — pasting long context paragraphs into chat, giving models access to your Notion, uploading PDFs — and a shift in how you think about the work.

The old paradigm: prompt engineering. You had a short prompt and you tweaked the words to squeeze better output from a fixed model. That worked when the models were small and the tasks were short. It stops working when the task depends on knowing you.

The new paradigm: context engineering. You assume the prompt is short and obvious. You invest the time in the context the prompt is going to reach for. You build a retrievable library about yourself, your business, your taste, your constraints. Then a ten-word prompt can do what a two-page prompt used to.

Why Bigger Windows Didn't Fix It

When models went from 4K tokens to 32K to 200K to a million, a lot of people — me included — thought the problem was solved. Just paste everything. Let the model sort it out.

The experiments were humbling. The more you paste, the more the model's outputs regress to the mean of what you pasted. A model with all your blog posts in context starts writing like a composite of all your blog posts — which is less like you, not more. The model averages. That's what models do.

The answer turned out to be the opposite of what bigger windows suggested. Don't paste everything. Paste the specific thing the current task needs. The craft of picking what to paste — and building the retrieval infrastructure that makes picking cheap — is context engineering.

The Five-Step Starter

Here's the minimum viable context stack. Ninety minutes. Open a notes app. Do not overthink any of these.

Step 1: Write Your 'Who I Am' in Six Lines

Six lines, no more. Six characters, ideally:

• Name and age. (Two words.)
• Where you live. (One city.)
• What you do for money. (Ten words or less.)
• What you're secretly working on. (One sentence.)
• One non-obvious thing about your taste. (Aesthetic, food, music, whatever.)
• One line that tells me what you're scared of being wrong about. (This one takes a minute.)

That's it. That's your starter Context DOT. It's six lines because any more and you're hiding. Six lines is the length at which you have to commit to a version of yourself.

Step 2: Extract Your Voice, With Three Examples

Find three pieces of writing that sound like you. An email you sent a friend, a tweet that performed, a paragraph from something you abandoned. Copy them into a document. Don't edit them. They don't need to be about the same topic. They need to be, as written, how you'd sound on your best day.

Then — and this is the actual step — ask a model to describe the voice these three share. Something like:

You will see three writing samples by the same person.

Describe the voice in 4 bullets. Each bullet should:
- name one specific habit of the voice (e.g., "uses em-dashes
  instead of semicolons")
- cite a short example from the samples
- end with one anti-pattern (what this voice would NEVER do)

Do not describe the person. Describe the voice only.

<samples>
[paste the three pieces]
</samples>

Save the output. That's your Voice DOT. Four bullets. From now on, any agent that needs to sound like you gets those four bullets plus the three originals pasted in. That's the whole voice system. You don't need more. You definitely don't need the five-thousand-word 'brand voice guide' a consultant tried to sell you.

Step 3: List Your Frameworks

A framework is any named mental model you use to decide things. Not theoretical — the ones you actually use. Most people have between three and seven and don't realize they have them.

Write them down. A framework DOT is at minimum: name, one-sentence statement, one example from the last month where you used it. That's the whole template. If you've been running a business for more than two years, you almost certainly have a framework you use to decide what to say yes to, a framework you use to price things, and a framework you use to decide who to hire. Those three alone will already rescue most of your agent outputs from the generic swamp.

Step 4: Capture the Ten Decisions

The single highest-leverage context you can give an AI is the ten most recent non-trivial decisions you made and why you made them that way. Not the decision tree — the decision itself and the sentence that justifies it.

Example:

Decision: Launch the blog at /blog with [slug] at root level.
Why: Footer already expects /blog; root-level catch-all would
     conflict with every static route. Ship the safer thing first.

Decision: Use TS modules for blog content, not Sanity.
Why: Three seed posts don't justify the CMS overhead. Move to
     Sanity the week we get a writer who isn't me.

Decision: Skip Giscus for launch; use static "comments closed
     during beta" note.
Why: Giscus needs GitHub Discussions enabled on the repo and
     we don't want public discussions tied to this repo's
     activity yet. Revisit at 1k weekly readers.

Ten of those. You'll notice while writing them that you hold strong opinions you'd forgotten you held. Those opinions are what a model needs to imitate you. A decision log gives an agent the taste you've been trying and failing to put in a prompt.

Step 5: Set a Retrieval Rule

Now you have five artifacts. Six lines of Who. Four bullets of Voice. Three Frameworks. Ten Decisions. (And you've got this blog post open, which is the fifth.) The last step is deciding how you'll surface them.

For ninety minutes of setup, the rule is simple: paste all of them at the top of any agent chat before the real request. Don't automate anything yet. The goal is to feel how differently the outputs behave when the context is yours. Once you feel it, you'll want to automate. Automate second.

Common Traps

Trap 1: Pasting a Dump, Not a Structure

The most common failure is pasting a single giant block — your entire LinkedIn profile, your last six newsletters, three client transcripts, and a voice guide — as one context string. Models dilute. The more you paste, the more the model averages across the paste. An agent with your raw dump writes like the average of you and LinkedIn; an agent with six structured DOTs writes like you.

The fix is almost mechanical: chunk. Give each artifact a label. Prefer six short labeled artifacts over one long one. Even if the total token count is identical, the model retrieves better when there are retrieval edges — the boundaries between your labeled chunks — because it can reason about which chunks to weight.

Trap 2: Contradiction-Tolerance

The second trap is keeping stale DOTs around. You wrote your Voice DOT in January. Your voice changed in March. The January DOT is now lying to every agent that retrieves it. Agents don't flag contradictions unless you tell them to; they blend them.

The fix is a rhythm. Once a month, skim your DOTs. Delete anything that's no longer true. This is ten minutes. Skip it for six months and the vault becomes an anchor pulling every agent output back to a version of you that doesn't exist.

Trap 3: Treating Examples as Exposition

The third trap — and the one that took me the longest to see — is writing descriptions of how you'd do something instead of showing the model the thing itself. 'I write casually, with a lot of one-liners' is exposition. Three actual one-liners, tagged as examples, is ten times more useful to a model. Examples are the highest-leverage DOT type by a wide margin. If you only do one step from this post, do Step 2.

What Good Looks Like

You'll know your context stack is working when three things stop happening.

1. Agents stop asking you clarifying questions that you've already answered somewhere. (If an agent asks what your voice is, you're missing a Voice DOT. If it asks who your customer is, you're missing a Customer DOT.)
2. You stop re-pasting the same background paragraph. You find yourself writing a ten-word prompt and getting a full-page output that sounds exactly like you wrote it.
3. Outputs start surprising you — in the good way. An agent connects two DOTs you didn't realize belonged together. That's the forward-dot-connecting the whole infrastructure is pointed at.

When those three things happen, you've graduated from prompting to context engineering. The next thing to learn is routing — giving different agents different subsets of your vault based on task. But that's the next post.

The One-Sentence Takeaway

Write yourself down in pieces a machine can pick up one at a time, and the machine will stop sounding generic at you.

That's it. That's the whole thing. The platform is the scaffolding to make this cheap at scale — but you can do the ninety-minute version today with nothing but a notes app and any decent model. Do the ninety minutes. See what changes. Then decide whether to build the rest.

Next in the series: context routing — how to give different agents different slices of your vault, and why one Voice DOT beats three half-written style guides every time.