Skip to main content
Persist data across interactions and sessions.

Overview

Memory stores enable agents to retain, access, and manipulate information during conversations and across sessions. This provides context persistence and stateful behavior without external databases.

Memory Types

Agentic Apps support two main types of memory: Session Meta Memory and Custom Memory Stores.

Session Meta (Default)

A built-in, read-only store for session-specific data and contextual metadata.
  • Scope: Single session
  • Lifetime: Duration of the session
  • Access: Read-only in prompts; writable via API
Contents:
  • metadata: Contextual data passed via API (for example. userId, channel, custom fields). Developers can update this field only via API.
  • sessionInfo: System-populated object with the following fields:
    • sessionId — Unique identifier for the session
    • appId — Identifier of the application
    • sessionReference — Reference string for tracking the session
    • userReference — Reference string associated with the user
    • userId — Unique identifier for the user
    • runId — Identifier for the specific execution run
    • timestamp — Date and time when session info was recorded
.
sessionMeta is read-only within code tools and cannot be updated or deleted programmatically. The metadata field can be updated via API only.

Custom Memory Stores

User-defined stores for persistent data.
  • Scope: Configurable (user, app, or session)
  • Lifetime: Configurable retention
  • Access: Read/write via code tools

Creating a Memory Store

Define custom memory stores in your agentic app configuration. Each store has a unique technical name and a JSON schema that defines the structure of the data it holds. Navigation: Go to Agentic app > Memory > Create new.

Configuration Fields

Example Schema


Accessing Memory

Agentic Apps provide Memory Stores to persist data across interactions.
  • Memory stores can be read from within prompts, workflow tools, and code tools, but can be updated or deleted via code tools or workflow tools.
  • Memory store can be referenced in tools using its technical name only.
  • sessionMeta can’t be manipulated via code tools.

In Prompts

Use the template syntax: {{memory.<store_name>.<field_path>}}

In Code Tools (JavaScript)

Memory methods are async and return a Promise. Use them with await keyword. Read from Memory Syntax: memory.get_content(<store_name>,<projections>) Parameters:
  • store_name(string): The technical name of the memory store.
  • projections(optional): JSON object specifying the fields to retrieve. If omitted, the entire record is returned.

In Code Tools (Python)

Memory methods are synchronous and return values directly.

In Function Nodes of Workflow Tools

Same syntax as code tools. Memory can be read, updated, or deleted using the Function Node within Workflow Tools. When working with memory stores, use the technical name of the memory store to ensure proper identification. Learn More.

Session Meta Access

Reading Session Data

In Prompts

Passing Metadata via API


Access Scopes

Scope Selection

Choose based on data lifecycle:

Retention Policies

Set appropriate retention periods based on specific usage of the data to balance performance, cost, and compliance.

File Attachments

When users upload files, metadata is stored in sessionMeta.artifacts. Learn More.

Supported File Types


Best Practices

Use Meaningful Technical Names

Define Clear Schemas

Schemas ensure data consistency:

Handle Missing Data

Always check for existence:

Clean Up When Done

Delete temporary data to free resources:

Import/Export

Memory store configurations are included in app exports:
  • Schema definitions
  • Access settings
  • Retention policies
Data content is not exported for security.