A longer paste will not fix a refund that violates policy. Northline B2B (composite) hit that limit on a tier-2 support assist. The pack loaded a draft refund article and the last forty ticket messages, and the model promised a credit outside policy. Ops raised the token cap. Legal then found two policy packs in the same run, and no named owner for which one applied. The team froze pack edits, named the support ops lead as spec owner, and only then cut the ticket window and pinned one policy version. A checker now blocks the send when the proposed credit falls outside that version. A person takes the case when the checker cannot decide. Raising the token cap had been the wrong first move.
The question worth asking is whether the system is implementing clear rules badly, or whether the rules and the owner are still unclear. This page uses that question as a practical split of responsibility. Architecture sets the rules and who is accountable for them. Engineering implements those rules in the pack and checks the run. The two activities overlap on the same workflow. Bharani Subramaniam’s line, as Birgitta Böckeler records it, names the engineering half: curate what the model sees so the result improves. Context architecture is the owned spec for what may enter, in what order, under which policy. Anthropic describes a wider craft in Effective context engineering for AI agents: system instructions, tools, external data, and message history across steps. The split here is an operating assignment for a regulated workflow, and it is narrower than that description.
Read the signal first
Name the failure before anyone opens a vector index. The table is the first check for the latest bad send. A team can match more than one row. Confirm the row against the run log before you choose a fix.
| Observed signal | First check | Likely next step |
|---|---|---|
| Stale or wrong source in use | What did the system show the model? | Fix selection, refresh, and filtering |
| Two approved rules conflict | Which rule applies to this case, and who decides? | Set precedence and name the owner |
| The rule is right, and the answer breaks it | Where should the check have fired? | Fix generation, validation, or the action gate |
| Another customer’s data is in the window | Does access control separate tenants? | Fix data separation before you retune the pack |
| Rules and sources are both unclear | What is the smallest approved operating mode? | Agree the rules, implement them, test, and tighten |
A quality gap across customer segments can mean a stale source. It can also mean a harder task, or a scorer that treats unlike cases as the same case. Inspect what the run showed the model before you treat the segment as proof that the pack is wrong.
Engineering may propose which records load. The spec owner accepts or refuses that list. A retrieval score does not settle which policy applies, and a policy sentence does not name which article loads on Tuesday.
When the pack is the first check
On this page, context engineering is how one run is packed and checked: which instructions, records, tool results, and memory slices load now. Who may change that list next quarter sits with architecture. The two still meet on the same send.
The usual pack failures are concrete. Retrieval returns last year’s refund article because the pack has no freshness rule. A thread of forty messages crowds the task frame, so early constraints fall off. Teams then add more text, and context rot gets worse. The clause that mattered sits in the middle, and the model under-weights it.
A later instruction can sway the answer when two policy sentences share the window. That influence is real. It is not a guaranteed order for resolving a conflict. If both sentences are approved, the first check is which one applies to this case and who decides.
The pack response is a versioned pack. Name the allowed sources, the denied classes, the token cap per source, and the refresh trigger. Bind the pack version to the run log so a reviewer can see which sources and versions the run used. That record is traceability. It leaves out documents and tool results fetched during the run, and a second execution of the same version can still differ. Exact replay is a stronger claim than a version number can keep.
When the eval pass rate drops after a pack change, roll the pack back the way you roll a prompt back.
When the rules are the first check
Start with the rules when two approved policies conflict, or when nobody can name who owns denied sources. Retrieval cannot invent a policy pack that has no version and no owner. A larger window makes that clash easier to hide inside one run.
Own the spec per workflow. A named owner is accountable for the spec. Approval rights can sit with more than one role. Keep policy versions separate from prompt templates, and name denied sources in the spec.
The control a regulated send still needs sits between reading and acting. What the model can read is separate from what the system may let it do. A correct refund rule can still leave the model free to propose a credit. Something before the send has to check permission and hand the case to a person when that check cannot decide. Grounding fails in the same place when the check is missing, and the bad answer moves to the next gap.
Another customer’s record in the window is an access check first. Confirm tenant separation and the denied classes before you judge the pack as merely noisy.
Three tests, then the pack
Write the spec, then version the pack that implements it. A pack without a spec is packing theater. A spec that never becomes an allow list, a token cap, a refresh rule, and a send check still ships rot. Tie the pack version to the same promotion gate as the prompt. If a send is possible while the pack version is blank, the spec is not operating yet. Do not promote a pack change that eval cannot fail.
Run three tests on the next pack before you call the control real.
Load last year’s refund article beside the current policy. The run log should show which version the model saw, and the send should follow the current rule. That is the stale-rule test.
Put two approved sentences in the same window. The case should resolve by the named precedence, or stop for the owner. It should not depend on which sentence arrived later. That is the conflict test.
A second customer’s ticket must not enter this run. If it does, fix access and data separation before you edit the prompt. That is the foreign-data test.
When the same case produces different quality and the model input is truly the same, look past the operator. Check hidden context, model settings, and how people score the output. Prompt engineering versus workflow engineering separates the prompt from the workflow. Capture the expert’s step after that check, before you fund a new index.
