Personas
A persona is an AI character you build, own and run. You give it a name, a prompt and a personality, then choose the model that runs it, and you decide what it knows, what it remembers between conversations, which tools it may use and what it may do on your behalf. Once it is public, people can chat with it on its own page. So can you.
You open Personas from your workspace, and it brings LLM Providers, Agentic Knowledge, Persona Services and All Data with it as parts.
Topics
- What a persona is: who owns a persona and everything you set on it.
- The prompt: how the persona's purpose, personality and interests become its instructions.
- Knowledge: what the persona searches when it answers.
- Memory: what it keeps between conversations.
- Abilities, permissions and access: what it may call and do, and who may use it.
- Chat: public chat, demo chat, and the status line shown while it thinks.
- LLM providers and persona services: connecting a model provider and choosing a model.
Everything you do with a persona on the site, a program can do over the API: create and edit personas, declare special interests, try a turn of a demo script, set who may use a persona, connect a provider and search a persona's knowledge. A persona itself reaches the hub over MCP, with a token of its own.
Personas, special interests and demo preview are the persona routes in the REST reference. The demo preview call plays one turn of a script that has not been saved. Who may use a persona is set through the access routes.
Persona services are the persona routes for services, templates and the model catalog. A template names the wire protocol the backend speaks, openai, anthropic or gemini, and how to authenticate, by bearer or by header.
Acting tokens are how a persona acts. One is minted from the persona and carries the persona's id and who it acts for: itself, a user, a team or an organization. On the MCP endpoint the token is checked against what the persona may do, and every tool call then passes through the grant and approval checks. A persona token is refused on plain REST.
Bootstrap is one call that takes only a bearer token and returns what a persona implementation needs: the persona, its prompt, its auth, its buckets, its memory, its tools and its chat settings. A persona token gets the full answer, a visitor token a restricted one, and an application token or a user session is refused. The call never widens access; it returns only what the token already reaches.
Visitor tokens are minted for a public persona so that a visitor can chat without signing in.
Knowledge is searched with the searchPersonaKnowledge tool, which takes a query and an optional limit. Embeddings come from gemini-embedding-001 at 1536 dimensions. The embedding backfill is a call on the corpus that needs the update verb on it, not the read verb, because reading a document does not entitle you to spend the owner's embedding budget.
Memory is read and written over MCP with the memory get and set tools, alongside the key-value, counter, list, event, queue and keyword tools of the persona-storage tool group.
The full list of routes, with each one's parameters, body and responses, is the REST reference on the help site. The tools an agent gets are listed in the MCP reference.
A persona is an ecosystem. Its integrations, storage and features are reached by going into the persona, the same way a product's are reached by going into the product. That is why the workspace Integrations picker does not list personas.
Abilities, Permissions and Access are three questions. Abilities ask what the persona may call. Permissions ask what it may do, and Access asks who may use it. Keeping them apart keeps each one small enough to reason about.
One allowlist for chat tools, as a security boundary. Chat's tool loop runs outside the MCP governance stack, and a public visitor's turn runs the same path. Adding a name to the allowlist is a security decision. The executor takes the set of names offered this turn as a required parameter, so no caller can omit the guard.
Keyword and semantic search both run, every time. They fail in opposite directions: keyword search wins on exact words, search by meaning wins on paraphrase. The scores are not normalised, because one is unbounded and the other is bounded, and there is no honest way to weigh them against each other.
The embedding model is pinned. Changing the model re-embeds nothing on its own, because a comparison between two models' embeddings is meaningless. The operator clears and backfills.
Money is measured in money. Tokens measure work; only micro-dollars measure cost. Reserving before a turn and settling after bounds any overshoot to one reserve.
The demo is the opening act. Demo mode describes the persona rather than standing in for a model, which is why the script has no slot filling and no variables carried across turns, and why a signed-in visitor goes through to the real model.
The status line is decoration and cannot take a chat down. Its validator never throws, and its size is bounded because it is republished as-is on a page anyone can reach.