Identities are an early-access feature. The shape of this surface may change before general availability.
- “What did this customer ask in the last week?”
- “Which agent stored this memory?”
- “Show me everything attributed to user
acme-corp/jane.”
Identities are per-organization. They sit alongside namespaces — a namespace is the data boundary, an identity is the actor attribution.
The shape
| Concept | Purpose |
|---|
| Identity type | A category. Examples: customer, agent, team_member, service. Defines a reusable template (name, slug, description, icon) you can attach identities to. |
| Identity | An instance of a type. Has a name, the type, and optionally an external_id you control (for cross-system linking). |
Creating identity types
Identity types are managed under Identities → Types in the console.
| Field | Required | Purpose |
|---|
name | Yes | Display label |
slug | Yes | URL-safe identifier, used in queries and audit logs |
description | No | Free-form description for your team |
icon | No | Icon key for visual differentiation in the UI |
| Type | Slug | Use for |
|---|
| Customer | customer | End users of your product |
| Agent | agent | AI agents acting on a user’s behalf |
| Team member | team_member | People inside your organization |
| Service | service | Automated systems and scheduled jobs |
Creating identities
Once at least one type exists, create identities under that type from the Identities page.
| Field | Required | Purpose |
|---|
name | Yes | Human-readable label |
type_id | Yes | The identity type this belongs to |
external_id | No | Your own ID for this actor — useful for cross-system linking |
Editing and deleting
Open an identity from the list to view its detail page. From there you can:
- Rename — change the display name (the
external_id can also be updated for cross-system re-mapping)
- Delete — permanently remove the identity. The action is audited; any operations attributed to the deleted identity remain in audit logs and tool calls (the historical record isn’t rewritten)
The identity type itself is fixed once an identity is created — you can’t move an identity between types. To re-categorize, delete and recreate.
Relationships
Identities can be linked to one another to express that two actors are connected — for example, “user X works for org Y”, “agent A acts on behalf of user U”, or “service S is owned by team T”.
Each relationship records:
| Field | What |
|---|
target_id | The other identity’s ID |
type | A free-form label describing the relationship (works_for, acts_on_behalf_of, etc.) |
type is a free-form string today — pick a small consistent vocabulary and stick with it.
Identity-aware operations
Identity-aware variants of remember, recall, forget, and ask are in active development. The current API surface does not yet accept an identity_id parameter on those operations — track the API reference for the field once it ships.
In the meantime, a workable pattern is to encode the identity in external_reference_id on the namespace or in metadata on the memory itself, so the attribution travels with the data even before the dedicated parameter is available.
Audit trail
Operations performed by a known identity surface that identity in the audit log, making it easy to trace activity per actor. Filtering by identity is available in the Admin → Audit log view alongside filtering by user and API key.
What’s next
This feature is rolling out gradually. If you’d like access in your organization, contact us at support@deyta.ai. Once enabled, the Identities entry will appear in your console sidebar.
