Skip to main content
Available now. The identity object and its provisioning tooling are live. The policy layer governs which identities an agent may use, and what each may do.
A persona is the identity object itself — the small, durable record that every endpoint and secret hangs off of. It answers one question for the agent: who am I being right now?

​
Attaching to agents

Agents reference identities; identities reference no agents. The relationship is many-to-many.
1

Create the persona

CLI
2

Give it endpoints

Provision domains, inboxes, numbers, and connections on the identity.
3

Attach to one or more agents

CLI

​
One agent, several identities

An agent can hold more than one identity and choose which to act as per task — a support persona for inbound tickets, an outbound sales persona for prospecting.

​
Choosing which to act as

When an agent holds multiple identities, the acting identity is named on the run. Whichever one it is, the persona’s name, description and the addresses it owns are put in front of the model for that run only — the agent’s stored configuration is never rewritten, so selecting a persona mints no new agent version. Per session, for an interactive run:
CLI
On the deployment, for unattended scheduled runs — the mode a persona that owns an inbox actually operates in. The persona is resolved and grant-checked when the schedule is written, so a bad reference fails while you are watching rather than at 03:00:
CLI
Inbound does not yet select a persona, because inbound does not yet wake an agent. Mail and SMS that arrive for an identity’s endpoints are authenticated, matched and stored — readable through vetta identity email messages — but no session is started for them, so the routing-selects-the-persona path described in Inbound events is not live. Until it is, a persona answers on a schedule or when you start a session, not on arrival.

​
Endpoints are specific, not boolean

An identity does not “have email” — it owns ava@acme-mail.com. It does not “have a phone” — it owns +1 415 555 0142. This is what makes personas concrete and safely shareable:
  • billing@acme.com and support@acme.com are two different identities, even on the same domain.
  • Routing, policy scoping, and inbound matching all key off the specific address or number.

​
How personas relate to policies

Every persona is governed by a policy. The policy decides:
  • Which primitives the identity may use (email, phone, connections, vault, domains).
  • Which connections it may authorize and which tools it may call, at toolkit and tool granularity.
  • Which actions require human approval (e.g. spend over a threshold, provisioning a number, purchasing a domain).
Enforcement is at the tool-call boundary and fails closed — an identity can never reach a system or spend money the policy did not grant.

​
The identity object

​
string
Stable identifier for the identity (e.g. idn_ava). Referenced by agents and per session.
​
string
required
Human-facing name of the persona, e.g. "Ava Sales" or "Acme Billing". Surfaced to the model so it acts in character.
​
string
What this persona is for. The model reads it to decide tone, scope, and which endpoints are appropriate — e.g. "Handles invoices and refunds for Acme."
​
array
The verified web domains this identity sends and receives on.
​
array
The email inboxes the identity owns (localpart@domain). Each is tied to an owning agent for routing.
​
array
The phone numbers the identity owns, with their messaging capabilities and campaign state.
​
array
The third-party connections the identity has authorized over OAuth.
​
object
The write-only credential vault scoped to this identity.

Next: web domains

The dual-track domain system that email sits on top of.