A Role Assistant is a human-owned, role-scoped business capability that helps an identified person complete recurring enterprise work through governed capabilities and trusted business context.
It is not a free-form chatbot with system credentials, an agent assembled from arbitrary tools, a new organisational identity, a service account with independent authority, a static workflow encoded in prompts, or a replacement for the employee responsible for the outcome.
End users may see a Sales Assistant, Project Assistant, or Finance Assistant. The Business Role — for example Sales Manager or Account Manager — defines the governed operating boundary. The persona name is UX; the Business Role is governance.
AI can recommend, prepare, and request work. It cannot grant itself authority.
What this shows: ChatGPT, Copilot, Teams, and similar tools are approved AI interfaces. The Role Assistant in AI Fabrix sits between the conversation and your systems. The interface can change; the governed business capability remains with the enterprise.
What this is not: A ChatGPT plugin, Copilot agent, or Teams bot that calls enterprise systems directly.
Why it matters
Role Assistants translate Business Roles into AI-assisted work inside Operational Trust and Enterprise Knowledge. They reduce prompt chaos while keeping people in authority for outcomes, approvals, and release.
Enterprises adopt Role Assistants when they want repeatable assistance tied to roles and outcomes, not experimental chat with system access.
How it works
Business Role → Role Assistant (candidate → validated → available)
→ Task → Governed Capability → Outcome → Evidence
The active Business Role bounds what work may be requested — capabilities, approvals, decision and audit context. Dimensions and Operational Trust bound which records may appear in that work. Together they shape permitted business context; the role does not grant data by itself.
Assistants use:
- Enterprise Knowledge — business meaning, relationships, Smart RAG and Viewpoints
- Governed capabilities — approved operations, not unrestricted vendor APIs
- Operational Trust — identity, dimensions, policy, certification
- Evidence Fabrix — proof of completed, denied, waiting, or safely stopped work
Generation produces a candidate. Teams validate and test before an administrator makes the assistant available to the Business Role. Availability does not widen authority. Integrators make systems AI-ready in Build AI-ready systems; operators run assistants within that certified scope. How people reach an assistant: Conversation-first work and Assistant channels.
What a Role Assistant is not
| Not this | Why |
|---|---|
| Free-form agent with API keys | No structural trust path |
| Prompt-orchestration-first automation | Governance bolted on too late |
| Authority expansion at higher skill | Promotion improves maturity, not permissions |
| Replacement for enterprise IAM | Consumes Business Roles; does not redefine them |
| Owner of Knowledge, Trust, or Evidence | Uses those pillars; does not take them over |
Limits
- Behavior depends on certified capabilities, tenant policy, and channel configuration — not every CRM or ERP action is available on day one.
- Channel setup: Assistant channels. Creation path: How Role Assistants are created.
Example
A Sales Manager opens a weekly pipeline review. The Sales Assistant uses in-scope deals and customer context under Operational Trust, then requests capabilities to draft follow-ups. It does not silently update CRM outside certified capabilities. Existing applications remain authoritative for their transactions.