Deployment

Deployment Model

How Persona is provisioned, bounded, and rolled out in a production environment.

Updated Apr 9, 2026 10 public pages

Persona is meant to be deployed as a bounded production product, not as an experimental demo layer.

What a deployment includes

A real deployment usually includes:

  • one space
  • one or more apps inside that space
  • one or more Personas
  • a tenant or account boundary
  • a set of built-in capabilities
  • a set of connected external capabilities
  • operator visibility and control
  • runtime tokens for the integrations that need access

The important point is that Persona is not just “turned on.” It is provisioned inside a controlled environment.

Boundaries matter

If Persona is going to remember, plan, and act over time, then deployment boundaries have to be clear.

That includes:

  • who owns the runtime
  • which users or teams can access it
  • which capabilities are enabled
  • which actions are allowed
  • which environments it can touch

Without those boundaries, the product stops feeling reliable very quickly.

Typical production shape

A common production shape looks like this:

Persona

The persistent AI entity that users interact with or experience.

App

The product integration identity or surface through which Persona is embedded, exposed, or connected.

Space or working environment

The context where that Persona operates, stores state, and uses capabilities.

Capability set

The native and external surfaces available to that Persona.

Operator controls

The human-facing controls for rollout, review, and governance.

Rollout advice

The right rollout is usually staged:

  1. narrow pilot
  2. bounded production workflow
  3. broader capability exposure
  4. deeper embedding in product or operations

Trying to launch Persona everywhere at once usually creates more confusion than value.

What buyers should look for

If you are evaluating Persona for production use, the important questions are:

  • Does the Persona have the right built-in surfaces?
  • Can it connect to the systems that matter in our product?
  • Can we keep the rollout bounded?
  • Can operators stay in control?
  • Does the runtime preserve continuity in a way that matters to our use case?

Those are better buying questions than “how many tools can it call?” because they map to real product value.