How Role Assistants are created

Purpose

Role Assistants are generated from approved enterprise definitions — Business Role, Knowledge, Trust, governed operations, and Evidence requirements — not user-built chatbots and not hand-built in Builder. Enterprise teams do not compose assistants from arbitrary tools, prompts, or API keys.

Generation produces a versioned candidate, not operational authority. Teams validate and test for the intended scope. An administrator then makes an approved version available to the Business Role. Availability does not widen the user’s existing authority.

Administrators use Make available when a Draft (candidate) assistant should enter service; users receive role-specific assistants (Sales Assistant, Project Assistant, and similar). Lifecycle badges and generation rules: Role Assistant status and availability.

Architecture note: Role Assistants are compiled from published Connected System metadata and subscriptions — not hand-built per user. Customer UX uses Role Assistants and {Role} Assistant names.

Why it matters

Confusion between "building an agent" and "using a Role Assistant" drives security exceptions and unauditable scope creep. When users believe they are configuring capabilities, they will request broader access than governance allows.

Why assistants bind to a business role: learning, intent, and evidence are role-scoped. The platform compiles what a Sales Manager or Contract Steward may do — not a generic chat identity. That binding keeps planning evidence, outcome evidence, and capability catalogs aligned with how the enterprise already assigns responsibility.

Why users do not pick capabilities: integrations change continuously. New systems join the same resource type, certifications expire, and capabilities lose credibility when vendors drift. Manual per-user capability lists cannot keep pace. The philosophy is strict: only certified, published capabilities enter the Role Assistant catalog at compile time — then the platform recompiles when metadata or trust state changes.

How it works

What this shows: who creates Role Assistant assets versus who makes them available — platform generation, operator Make available, user provisioning.

What this is not: an agent builder, prompt studio, or capability picker at activation time.

What the platform generates

Enterprise Knowledge and role-scoped runtime metadata are generated external systems with real datasources, published contracts, role-based access control, and attribute-based access control — not runtime-only projections. Generation follows a composition path:

External systems → Datasources → Composition → Subscription filters (role + system kind)
  → Role-scoped runtime → REST + MCP + OpenAPI → Operator Make available → User provisioning

Subscription filters may include role keys and system kind include/exclude lists so assistants consume CRM, enterprise knowledge, and evidence systems without hardcoded vendor names in runtime code.

What administrators do

Administrators use Make available when a compiled Role Assistant should leave Draft and enter service (Active when capabilities exist). That is an operational gate — it does not assign capabilities at the user layer. Make unavailable returns the assistant to sticky Draft. Suspended is system-only when a published assistant has no live capabilities. Full matrix: Role Assistant status and availability.

Admins also coordinate certification review, role mapping, and optional channel connection before users receive assistants. Publishing an LLM provider regenerates governed LLM access only — it must not change Role Assistant status.

What users do

Users with matching roles receive assistants automatically (lazy provisioning). They may set an assistant name and preferred channel. They do not submit role keys, capability lists, subscriptions, or integration configuration. The platform copies role scope from compiled metadata.

Users may later rename the assistant or archive an activation — not the underlying capability allow list.

Complex business cases: you are not limited to one assistant per person. Multiple Role Assistants (different business roles) and external MCP clients can consume the same certified Enterprise MCP surface — standard protocol, no proprietary lock-in. Operational Trust enforcement is intentional everywhere (dataplane UI, MCP, REST): out-of-scope capabilities do not execute because a client asked nicely.

Capability catalog membership (generation, list vs execute): How Role Assistants get capabilities. Evidence and planning loop: Role Assistants, Evidence, and governed execution.

What users do not do

Runtime boundary

Execution follows a fixed stack — intent, task, role, enterprise knowledge, evidence, operational trust, capability, task result. The runtime assembles context from identity, role, task, and trust rules. It does not treat chat memory or private prompt libraries as authority.

Assistants learn from completed tasks, not casual conversation. Quick questions may be answered inline without creating tasks; measurable outcomes create tasks with audit trails.

Example

After integrators publish a CRM and document library, the platform generates a Sales Manager Assistant for the Sales Manager role. An administrator uses Make available when the Draft assistant should enter service. A sales manager sees Sales Assistant (or renames it). The runtime executes only capabilities allowed for that role — the user did not select those capabilities during provisioning.

After platform generation, integrators still promote package settings and Evidence per environment (dev → tst → pro) when runtime settings or Evidence rows change — see Manage Role Assistant packages.

Business value

Generated Role Assistants turn integration investment into repeatable Role Assistant capacity with the same contracts external AI systems use. Operators gain a single activation and evidence model instead of per-team agent experiments.

Limits

Role Assistant generation timing and channel hardening vary by tenant policy. Confirm which communication channels (UI, Teams, Slack) are connected before promising notification workflows.

This article describes the activation contract: business-role binding, certified capabilities only, and platform recompilation when integrations change — not a user-facing agent builder.