Andrej Karpathy, a founding member of OpenAI and former director of AI at Tesla, has spent the last year reframing how we should think about working with language models. His most repeated point is deceptively simple: the craft is moving from prompt engineering to what he calls context engineering. Not the clever one-liner you type, but the art of filling the model’s context window with exactly the right information for the task.
“Context engineering is the delicate art and science of filling the context window with just the right information for the next step.”
Andrej Karpathy
For an ecommerce support agent, that idea has a very concrete consequence. Your agent is only ever as good as the knowledge you put in front of it, and the highest-leverage asset you can build is a curated wiki written to be read by the model, not buried in a help-desk UI written for a human skimming on their lunch break.
Documentation, but for machines
Karpathy has made a related argument that has quietly become a best practice: as LLMs become primary consumers of documentation, we should write docs *for them*. That means plain, unambiguous language, canonical answers over marketing prose, explicit edge cases, and structure a model can parse instead of a carousel a human clicks through.
Most brands already have "the knowledge." It is just scattered, half in a Zendesk macro, half in a Google Doc, half in the head of your best support rep, and a surprising amount in the Slack thread where someone finally explained the returns policy for the third time. A support wiki is the act of gathering that into one legible source of truth.
What goes in the wiki
A good agent wiki is not your marketing site and it is not a legal PDF. It is a tightly written operating manual for answering customers. In practice it contains:
- Canonical answers. The single correct response to your most common questions, shipping times, returns windows, sizing, warranty, restocks, phrased the way you want the brand to sound.
- Edge cases and exceptions. The "except if…" rules that trip up new hires. Wrong address entered at checkout, split shipments, pre-orders, EU vs US returns, discount-code stacking.
- Tone and boundaries. How the brand talks, what the agent may promise, and where it must not improvise, refunds above a threshold, chargebacks, anything legal.
- Escalation rules. The explicit conditions under which the agent should stop and hand off to a human, and how.
- Product truth. Materials, care, compatibility, what is and is not in the box, the details that generate tickets when they are unclear.
The format is the point
Write it in Markdown. Short headers, short sentences, one fact per line where you can. Markdown is the lingua franca between your team and the model, humans can edit it in any editor, and the model reads it natively.
Wiki-in-context vs. RAG: when to use which
A fair question: if you have retrieval-augmented generation, why maintain a wiki at all? Because context windows are now large enough that, for a focused domain, you can often load a curated wiki *directly* into the prompt and skip retrieval’s failure modes entirely, no chunk boundaries slicing a policy in half, no embedding search returning the almost-right passage.
The two are not rivals; they are a hierarchy. The rule of thumb we use:
- Small, stable, high-stakes knowledge → put it in context. Policies, tone, escalation rules. It is a few thousand words, it rarely changes, and you never want the model to miss it. Load the whole wiki every time.
- Large, fast-changing, long-tail knowledge → retrieve it. The full product catalogue, thousands of historical tickets, live order data. Too big for the window, so fetch the relevant slice on demand.
“The wiki is what the agent always knows. RAG is what it can look up. Every serious support agent needs both.”
Keeping it alive
A wiki that goes stale is worse than none, it teaches the agent to be confidently wrong. The discipline that makes it work: every time a human overrides the agent or handles a novel ticket, that answer becomes a candidate wiki edit. The knowledge base compounds. Within a few weeks it encodes not just your policies but the accumulated judgement of your support team.
This is also why the wiki should be owned by the people closest to customers, not locked inside a tool only engineers can touch. Markdown in a repo, edited by whoever knows the answer, that is the whole idea.
The takeaway
Karpathy’s framing is a gift to anyone building support automation: stop obsessing over the perfect prompt and start engineering the context. For ecommerce, the context that matters most is a clean, curated, model-legible wiki of how you actually run your store.
We build exactly this for brands running on Gorgias and Zendesk, the wiki, the retrieval layer, and the agent that reads both. If you want a support agent that answers like your best rep, let’s talk.
Written by Henry Buisseret
Work with us
