Data Types

Blueprints JSON Schema

Why Data Types?

Data Types are blueprints for your data. They declare what a record must look like so agents and tools always work with reliable structures.

Think of a type as a contract:

“Every time we save an Invoice, it must have a totalAmount and a dueDate.”

The platform enforces that contract on every write.

Benefits

• Validation – prevents “garbage in, garbage out”. Missing required fields or invalid values are rejected.
• Consistency – an invoice created by any agent follows the same shape.
• Versioning – schemas can evolve over time without breaking existing records.

Defined with JSON Schema

Types use JSON Schema to express required fields, enums, formats, and more.

Example: a support ticket type with constrained priority.

{
  "type": "Ticket",
  "version": 1,
  "jsonSchema": {
    "type": "object",
    "required": ["ticketId", "status", "priority", "description"],
    "properties": {
      "ticketId": { "type": "string" },
      "description": { "type": "string" },
      "status": {
        "type": "string",
        "enum": ["open", "pending", "resolved"]
      },
      "priority": {
        "type": "string",
        "enum": ["low", "high", "critical"]
      }
    }
  }
}

Versioning

Schemas change as your business changes. Types are versioned so you can add fields without breaking existing objects:

1. Create version 1.
2. When you need a new field, create version 2.
3. Existing objects stay on version 1; new ones use version 2.

Version IDs matter

Internally each version has its own ID. Always use the type ID returned from the API when you create or update objects so you target the correct version.

Groups

Types are tagged by role to signal where they are used:

Group	Purpose
PARAMETER	Inputs required by a tool or agent.
RETURN	Structured output an agent produces.
KNOWLEDGE	Reference documents used for retrieval.

A type can belong to multiple groups when needed (for example both KNOWLEDGE and RETURN).