> ## Documentation Index
> Fetch the complete documentation index at: https://docs.threetone.in/llms.txt
> Use this file to discover all available pages before exploring further.

# Redis context

> Design an application-owned context cache with identity isolation, expiration, and predictable failure behavior.

Use this design to prepare a small cache of application context, such as a verified user's preferred language and the timestamp of a recent lookup. Keep the authoritative record in the service that owns that data.

<Note>
  Threetone does not expose a user-configurable Redis context connector or a released session path that consumes this cache. Existing dynamic variables are saved authoring values. This cookbook describes a cache your application would own.
</Note>

## Before you begin

Have an authenticated application backend, a managed Redis owner, and an approved list of cacheable fields. Decide the maximum age of each field and what happens when it is missing.

<Steps>
  <Step title="Scope keys on the server" id="redis-cookbook-identity">
    Derive the workspace and user identifiers from authenticated server context. Include them in the cache namespace and never accept an unrestricted Redis key from a client. Store a source version and fetch timestamp with values that can become stale. A cache hit does not grant access to the source record.
  </Step>

  <Step title="Restrict the Redis connection" id="redis-cookbook-access">
    Follow [Redis security guidance](https://redis.io/docs/latest/operate/oss_and_stack/management/security/) for network isolation, ACLs, and TLS. Permit only the required commands and key patterns. Keep Redis credentials on the backend, outside prompts, browser bundles, mobile apps, and ordinary agent variables.
  </Step>

  <Step title="Set expiration with each write" id="redis-cookbook-expiry">
    Redis [`SET`](https://redis.io/docs/latest/commands/set/) supports an expiration on the same write, such as `EX` in seconds. Choose the duration from the data's freshness requirement. Review overwrite behavior so a refresh does not accidentally leave a key without expiry. Handle a cache miss by rechecking authorized source data or returning an explicit unavailable result.
  </Step>

  <Step title="Test stale and repeated work" id="redis-cookbook-failure">
    Plan for Redis outage, revoked source access, concurrent refreshes, and delayed results. Never reuse one user's context for another as a fallback. A temporary `SET NX` marker can coordinate work, but expiration or eviction means it cannot prove an external action executed exactly once.
  </Step>
</Steps>

Use synthetic [dynamic-variable placeholders](/agents-platform/configure/personalization/dynamic-variables) to review the expected values today. A future runtime integration must authenticate and validate context before substitution. Redis expiry does not establish deletion of logs, backups, transcripts, or provider copies; review [retention limits](/agents-platform/monitor/privacy/retention) separately.

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Does a cache TTL enforce Threetone retention?" id="faq-redis-cookbook-retention">No. It controls that Redis key's expiry. Other copies and Threetone retention enforcement have separate lifecycles and limitations.</Accordion>
  <Accordion title="Can a cache miss use the last available customer's data?" id="faq-redis-cookbook-fallback">No. Keep identity boundaries intact. Fetch authorized data for the current user or report that context is unavailable.</Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.