Purpose
Role Assistants are platform-generated from certified business roles — not user-built chatbots. Enterprise teams do not compose assistants from arbitrary tools, prompts, or API keys. The platform compiles integrations, enterprise knowledge, and role scope into executable catalogs that administrators Activate for AI; users receive role-specific assistants (Sales Assistant, Project Assistant, and similar).
Architecture note: The platform entity is a Digital Worker (
systemKind: digitalWorker) per role. Customer UX uses Role Assistants and{Role} Assistantnames only.
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 activates them — platform generation, admin Activate for AI, 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 → Admin Activate for AI → 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.
| Asset | Role in Role Assistant catalog |
|---|---|
| Enterprise Knowledge | Source of capability meaning and compiled maps |
| Evidence Fabrix | Operational memory from completed governed work |
| Role Assistant (platform: Digital Worker per role) | Role-scoped executable catalog entry |
What administrators do
Administrators Activate for AI per business role when metadata is published. Activation is an operational gate — it does not assign capabilities at the user layer. Admins coordinate certification review, role mapping, and optional channel connection before users receive assistants.
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): uncertified or out-of-scope capabilities do not execute because a client asked nicely.
For the full loop — planning evidence, outcome evidence, capability compilation, recompilation, and trust gates — see Role Assistants, Evidence, and governed execution.
What users do not do
Don't:
- Build assistants from prompts or ad hoc tool lists
- Pick capabilities or datasources at activation
- Expand permissions when skill level increases
- Bypass approval or certification gates through the activation API
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 certify a CRM and document library, the platform compiles a Sales Manager Assistant for the Sales Manager role. An administrator Activates for AI for that role. A sales manager sees Sales Assistant (or renames it to "Regional Pipeline Assistant"). The runtime executes only capabilities certified for that role — the user did not select those capabilities during provisioning.
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.