An export assistant that rereads a long product manual for every question can be slow and expensive. Caching a stable system instruction, tool definition or document prefix can reduce repeated processing. The risk is easy to miss: a cache does not know that a certificate was replaced or a price expired. It can simply return the old context more efficiently.

AWS described prompt-caching patterns on September 15, including mixed time-to-live settings and tenant isolation. These details turn caching from a technical speed feature into an information-governance decision. The team has to decide which context is sufficiently stable to reuse, how long it remains valid and who is allowed to share it.

Brand language, a durable output schema and an approved classification rule may be good candidates. Inventory, freight, exchange rates and quotation terms change quickly. Putting every long input into the same caching strategy confuses size with stability.

Put the business version in the key

A key called “product manual” is not specific enough. Include product family, language, destination market, document version and approval date. European and North American variants can carry different electrical requirements. An old Chinese manual should not share a cached state with a revised English document merely because the model and system prompt are the same.

Invalidate the affected cache when a source changes. Waiting for a natural expiry can leave a known obsolete answer active. The document-release workflow should identify which keys depend on the changed source, clear them and run a small regression set against the new version.

Customer context needs a harder boundary. Distributor pricing, contract attachments and conversation records must not enter another account's response through a shared cached prefix. Separate company-public, market-specific, customer-specific and session-only context using infrastructure-level namespaces. A sentence instructing the model not to mix customers is not isolation.

Expiry should match the information. A style guide may remain valid for months. Stock or freight may be useful for minutes. A quotation should be tied to an approved revision and validity date. There is no universal optimal time-to-live; there is only the maximum staleness the business can accept for a particular fact.

Measure what a hit actually reused

Cache-hit rate alone can reward the wrong behavior. Record the key version, context source, tokens avoided, answer citation and whether a fresh source was loaded after invalidation. A high hit rate accompanied by frequent corrections suggests that the system is accelerating stale information.

Testing should include isolation attempts. Ask similar questions under two customer identities, two markets and two product versions. The answer should use only the authorized context for that test. After invalidating one version, confirm that it no longer appears while unaffected markets continue to benefit from caching.

Caching also does not replace retrieval. Knowledge that changes frequently and must be cited by passage still belongs in a retrieval layer. A cache can hold stable prefixes or short-lived repeated context. Separating the two gives a company faster responses without losing the ability to show which current document supports the answer.

The operating principle is simple: reuse computation, not assumptions. Every cached context needs a version, audience, lifetime and removal path before it becomes part of a customer-facing AI workflow.

A useful release test deliberately changes one controlled fact. Update the packing dimensions for one model, invalidate only the affected market and language keys, and ask questions about the old model, the new revision and an unrelated product. A passing result requires more than displaying the new dimensions. The old revision must no longer appear, the answer must cite the current source, and unaffected products should continue to receive the expected performance benefit.

Ownership should be explicit. Engineering can operate the cache, but the document owner decides when a business fact becomes obsolete. Security defines tenant boundaries, while the product owner sets acceptable staleness for each use case. If a team cannot identify who triggers invalidation after a certificate, price list or manual changes, the cache is not ready to support external answers, regardless of its latency improvement.

The safest performance gain is one the business can reverse quickly and explain from a log.

Sources

Amazon Web Services, Optimizing cost and latency with Amazon Bedrock prompt caching, September 15, 2026.