Schemas

Memory Configuration

Schemas define the structure of memory objects. They describe which fields exist, how values are validated, and which parts of an object should be treated as important for identity or search.

What schemas define

A schema can define:

• Fields and property types — the shape of the data (strings, numbers, booleans, arrays, nested objects)
• Validation rules — constraints that objects must satisfy before being stored
• Identity fields — which subset of fields uniquely identifies an object for idempotent upserts
• Embedding schema — an optional projection used for semantic indexing
• UI representation — how the object renders in the admin interface

Creating a schema

1. Navigate to Admin > Memory > Types and select Create Type.

2. Enter a unique type name that describes the kind of knowledge this schema represents (e.g., TroubleshootingGuide, ProductSpec, FAQEntry).

3. Optionally provide a display name and description to help team members understand the schema’s purpose.

4. Define the JSON Schema for your type. This is the core contract for the object’s structure.

5. Optionally configure an identity schema (idSchema) to define which fields determine object uniqueness for idempotent imports.

6. Optionally configure an embedding schema to focus semantic search on the fields that matter most.

7. Save the schema. It is created in draft (unpublished) state.

Property types

Schemas use JSON Schema to define field types. Common property types include:

Type	Description	Example
string	Text values	Product names, descriptions, error codes
number	Numeric values (integers or decimals)	Prices, version numbers, quantities
boolean	True/false flags	Active status, feature toggles
array	Ordered lists of values	Tags, steps in a procedure, related items
object	Nested structures	Address blocks, configuration sections

Note

Fields can be marked as required or optional within the JSON Schema. Required fields must be present in every object conforming to the schema; optional fields may be omitted.

Type groups

Schemas are organized into groups that indicate how the type is used within the platform:

Group	Purpose
PARAMETER	Input schemas for tool parameters
RETURN	Output schemas for tool results
KNOWLEDGE	Business knowledge schemas such as FAQ entries, product specs, or guides

Tip

Most schemas you create manually will belong to the KNOWLEDGE group. PARAMETER and RETURN types are typically generated automatically when tools are synced.

Publishing and unpublishing

Schemas have a publication state that controls whether they can be used to create objects:

• Unpublished (draft) — the schema is visible in the admin panel for editing but cannot be used to create memory objects. Use this state while iterating on the schema design.
• Published — the schema is active and can be used to create and import objects. Agents can query objects of this type.

To publish a schema, open it in the admin panel and select Publish. You can optionally provide a new type name during publication if the original name needs to change.

To unpublish, select Unpublish. Existing objects remain in memory but no new objects can be created against the unpublished schema.

Renaming schemas

You can rename a published schema without creating a new version. Open the schema detail page, update the type name, and save. All existing objects referencing the schema continue to work under the new name.

Updating schemas

When you update a schema, the platform validates that the change is still compatible with stored objects. Updates can include:

• Adding new optional fields
• Modifying field descriptions
• Adjusting validation rules
• Changing the embedding schema or UI schema

Caution

Changing required fields or removing existing fields may invalidate objects already stored against this schema. Review existing objects before making breaking changes.

Schema composition

Schemas can reference other published schemas inside their JSON Schema. In practice this lets you build larger structures out of smaller reusable ones.

Examples:

• A troubleshooting guide schema can reference a reusable symptom schema
• A product bundle schema can reference an item schema for each included product

Use this when you want composition and reuse. Most users do not need to think about the underlying relationship model directly.

Identity schema (idSchema)

The identity schema defines which fields uniquely identify an object of a given type. When it is configured, imports and upserts can match an existing object instead of creating a duplicate.

This is especially useful for repeat imports. For example, if a Product schema uses productCode as identity, re-importing the same product updates the existing record instead of creating a second one.

Configure the idSchema when creating or editing a schema by specifying which subset of fields should determine uniqueness.

Embedding schema

The optional embedding schema lets you control which parts of an object are included in semantic indexing.

Use it when:

• Your full object contains fields that are useful for storage but noisy for retrieval
• IDs, timestamps, or internal metadata would otherwise dilute search quality
• You want to focus retrieval on summaries, descriptions, symptoms, steps, or other meaningful text

If you do not define an embedding schema, the platform uses the stored object content as the basis for indexing.

Schema usage

From a schema’s detail page, you can view:

• Object count — how many memory objects currently use this schema
• Related types — other schemas that are connected through composition
• Group memberships — which type groups the schema belongs to

Next steps

Objects Create and import memory objects that conform to your schemas.

Explorer Browse memory objects organized in a folder hierarchy.

Knowledge Graph Connect objects through typed relationships.