Skip to main content

Actors

Who the agent is talking to — the end user on the other side of a session, keyed by whatever your application already calls them.

Overview​

An actor is the identity a turn is attributed to. It carries a name, the persona instructions composed into that turn's prompt, your own external_id, and an optional link to the agent that answers for it.

Pass the actor's id as actor_id when you open a session, and every turn in that session is attributed to that person — which is what makes a transcript readable later and what lets one agent behave differently per end user without a second agent. Cap spend per end user reads that attribution back as spend per actor.

This module is a verbatim mirror of the runtime: every field, method, status code and error shape is the runtime's own, re-rooted under the project in the path.

See the OpenAPI spec for the full endpoint and schema reference, or browse it rendered under API Reference → Actors.

Data Model​

Actor​

FieldTypeDescription
idstringPublic actor ID.
project_idstringThe owning project.
namestringA human-friendly name. Required on create.
external_idstring, nullableYour own key for this person — a user id, an account number, a phone number.
instructionsstring, nullablePersona instructions composed into the effective system prompt for this actor's turns.
agent_idstring, nullableThe agent this actor is linked to. Mutually exclusive with chat_id.
chat_idstring, nullableThe chat this actor is linked to. Mutually exclusive with agent_id.
tagsobject, nullableTag map.
created_atstring (date-time)
updated_atstring (date-time)

Key Concepts​

Your key, not ours​

external_id is yours to choose, and GET /v1/projects/{project_id}/actors?external_id=… resolves it back to an actor — so you can hold your own identifier and look the actor up, rather than storing a second id alongside it.

Creating an actor is idempotent on external_id: a second create with the same one answers 200 with the existing actor rather than 201 with a new one, as Cap spend per end user relies on.

Linking an actor to an agent​

An actor may name the agent_id that answers for it. That is what POST /v1/projects/{project_id}/conversations/{conversation_id}/generate leans on for a conversation-level reply, and it is mutually exclusive with chat_id — one actor answers through one thing.

Filtering the list​

GET /v1/projects/{project_id}/actors filters by external_id, agent_id, chat_id and conversation_id, matches name as a case-insensitive substring, and paginates with limit/offset.

Tags​

GET / PUT / PATCH …/tags read, replace and merge an actor's tag map — PUT replaces it wholesale, PATCH merges keys in.

Deleting​

DELETE /v1/projects/{project_id}/actors/{actor_id} removes the actor. It is the erasure path for one end user of one project; nothing joins two actors that happen to be the same human, so it is a promise about an identity rather than about a person everywhere.

Examples​

Create an actor for one of your users​

naturali create-actor \
--project-id proj_V1StGXR8Z5jdHi6B \
--name Ana \
--external-id user_42

Give the actor a persona​

naturali update-actor \
--project-id proj_V1StGXR8Z5jdHi6B \
--actor-id act_V1StGXR8Z5jdHi6B \
--instructions 'Speaks Portuguese. Prefers short answers.'

Resolve your own key back to an actor​

naturali list-actors \
--project-id proj_V1StGXR8Z5jdHi6B \
--external-id user_42