Context Assembly: Deciding What the Model Sees
Selecting, ordering, and trimming the user data, documents, and history that go into each call — the hidden skill behind features that feel smart.
Two AI features can run the same model with nearly the same system prompt, and one feels like it knows your product while the other feels like a stranger guessing. The difference is rarely the wording. It's what each call was shown: which records, which documents, in what order, and what got cut when it didn't all fit.
That selection happens in your code, on every request, usually in a function nobody reviews. In this lesson you'll make it deliberate. You'll build a context assembler for Deskmate's "draft a reply" feature that picks sources, gives each one a priority, trims gracefully against a token budget, lays the result out in a sensible order, and records exactly what the model saw so you can debug it later.
Every call is a briefing packet
A model call has no memory, no database access, and no idea what screen the user is looking at. Everything it knows about this request arrives in the request: the system prompt, the messages, any documents, any tool definitions. Think of it as a briefing packet you hand to a very capable contractor who has never seen your company before and will throw the packet away when they're done.
For Deskmate's reply drafter, the candidate contents of that packet look like this:
| Source | Example | Why it might matter |
|---|---|---|
| Ticket thread | All messages on the ticket | The actual question, what's been tried |
| Customer record | Plan, seat count, account status | Answers differ for free vs. business plans |
| Reply policies | Refund rules, tone guide, escalation rules | Prevents promises you can't keep |
| Help articles | Top matches from the knowledge base | Grounds instructions in real docs |
| Past tickets | This customer's recent tickets | Context like "third time this month" |
| Agent's notes | Internal notes on the ticket | Things the customer can't see |
Context failures come in four recognizable kinds, and all of them look like model problems:
- Missing context produces confident guesses. No refund policy in the packet means the model invents a plausible one.
- Irrelevant context dilutes attention. Ten loosely related help articles make the one right article less likely to be used well.
- Stale context produces answers that were true last week. A cached customer record that still says "trial" leads to a reply about upgrading an account that already upgraded.
- Conflicting context produces coin flips. If a help article says one thing and the policy says another, and nothing says which wins, you'll get both answers across a hundred tickets.