How context gets designed

The situation

The Support Context Demo shows what happens when the same raw customer service materials go through three different levels of curation before reaching an AI model. This piece is about the part the demo doesn't fully narrate: what curating that context actually involved, and what's reusable about it outside customer support entirely.

The domain is deliberately unrelated to the rest of this site's work. If context design only shows up somewhere UX-adjacent, it's easy to mistake it for a UX technique with a new name. The point of picking customer support was to test whether the same discipline holds somewhere with no overlap at all.

The problem

The raw material was a five-message ticket thread from a customer, Dana Ellery, about order #48213: a cracked shelf bracket, a replacement promised thirteen days ago that never arrived, a second replacement promised six days ago that also never arrived, and a final message asking for a refund on just the bracket while keeping the rest of the order. Alongside that: a three-paragraph refund policy excerpt, and a short tone guide.

Handed all of that unedited, with the instruction "reply to the customer," a model produces something that sounds reasonable on first read and falls apart on inspection: it offers Dana a third replacement (the thing that's already failed twice), never acknowledges the two missed follow-ups, drags in an unrelated upsell about restocked inventory, and opens with the kind of hedging the tone guide explicitly rules out. Nothing in that response is factually wrong. It's just built from the raw material instead of from an understanding of it.

My role

This is the part AI-assisted workflows tend to skip. Someone has to turn messy material into something a model can actually work from, and that's more than shortening it. I had to decide which details mattered, which issues were already settled, which information was a distraction, and which tone requirements the reply genuinely needed. Those decisions are the work. The brief is just where they end up.

The curation process

A first pass at curating the brief fixed the obvious problem: it correctly identified that a refund was the right call, no further escalation needed, since a replacement had already been promised and missed. The resulting response was accurate and moved the situation forward: a refund processed, a timeframe given, the rest of the order left alone.

But it still read like first contact. Nothing in that response acknowledged that this was the third attempt at fixing the same problem. Getting the policy question right wasn't the same as understanding the situation.

The brief that actually worked did three things the partial one didn't:

• Named the history explicitly: when the issue happened and how many times, rather than just "a replacement was already promised".
• Said what to leave out, not just what to include: the thread contained an unrelated question about a restock, and the brief told the model to ignore it unless Dana raised it again.
• Made the tone requirement actionable: instead of asking the model to be warm, it said to "own the two missed follow-ups without naming the previous agents" and to "end with a specific, confirmed next step, not another promise to escalate."

The final response acknowledges the history in its first sentence, says the refund is done rather than promised, and gives a specific timeframe. It closes by recognising Dana's history as a customer instead of offering vague reassurance. The facts were the same in the partial and full versions. What changed was which facts got emphasis, which were left out, and how the tone was defined.

What generalises

None of this is specific to customer support. The same four moves show up in curating context for any AI-assisted task:

1. Describe the history, not just the current request. What's already happened changes the right response, and a model can't reliably work that out from a raw thread.
2. Say what to leave out as well as what to put in. Telling a model to ignore something is as useful as telling it what to address.
3. Name the actual deliverable, not a vague resolution. Words like "escalate" or "process this" let the model decide when it's done. Saying what the output should be removes the guesswork.
4. Turn tone into actions, not adjectives. "Warm" isn't specific enough. "Own the mistake without naming who made it" is an instruction a model can follow.

The same moves apply to support tickets, research briefs, interview transcripts or product data. The specific curation changes with the material; the discipline doesn't.

These four moves map onto three of the seven layers in The Context Stack: History, Boundaries (which covers both what to leave out and how tone is stated) and Verdict shape. Naming them there doesn't change anything here. It just means this isn't the only place they show up.

Check your own brief against these four checks →

Or start from a template →