When a customer-service system gets an answer wrong, teams often start by editing the prompt. But if what goes in is an outdated rule, the wrong order or incomplete trip details, no amount of careful wording can fix the facts. Context design should be engineering work in its own right, just like the interface and the APIs.
Split information into three layers
Anthropic describes context engineering as the ongoing work of selecting and maintaining the information a model needs, rather than writing a prompt once.[1] For business applications, we suggest first separating three kinds of information: relatively stable rules, state that changes with the business, and the goal of the task at hand.
A refund policy is a rule, whether an order has shipped is state, and a customer wanting to change their address is the current goal. Mixed into one long document, the system struggles to explain what to do when information conflicts. Once layered, each can have its own owner, update frequency and way of being read.
Every key fact should answer “where did this come from?”
A business fact that a decision relies on should carry, at minimum, its source, when it was updated and what it relates to. “The car has been returned”, for instance, must point to a specific trip and the time it was recorded; it should not carry over to a new booking just because it came up in an earlier conversation.
The interface can include a short evidence area: the order used this time, the policy version cited, and any fields that could not be confirmed. It does not need to show the model’s internal reasoning; it shows evidence that business staff can check. When a source is unavailable, it should say clearly what is missing and pass the next step to the right person or system.
Take only what the current task needs
More information does not necessarily mean better answers.[1] In practice, narrow the scope first by identity, order and type of business, then retrieve the rules relevant to the question. A lookup path like this is also easier to explain: why the system read this content, and why it did not read other customers' data.
A question about where to return a car, for example, usually needs this trip’s location instructions and valid times, not the customer’s entire history. Permission filtering should happen when data is read; it cannot be patched up afterwards with a line saying “don’t reveal unrelated information”. Where data from other customers is involved, test that the isolation boundary holds.
Treat missing information as a normal state
Context design also covers how to admit not knowing. Without the latest shipping status, the system can return the last confirmed time and suggest a human check; when the conditions for a policy are incomplete, it can ask for them first. Inventing a plausible-looking answer only buries the data problem deeper.
We recommend making information upkeep part of operations: who updates it, who reviews it, how old versions are retired and who handles exceptions. When evaluating, check not only the answer but whether the evidence used belongs to the right record and a valid version. For business systems, an answer that can be checked fits into daily work far more easily than a fluent one that can’t be traced.
Pick the question your system answers most often and check it item by item: is it the right record, is the source reliable, is the rule still valid, and what happens when something is missing?
References
This article combines public sources with SWYZL & Co.’s recommended methods. The hypothetical scenarios illustrate design thinking and do not represent client results.
