Role Assistants request governed business capabilities — the platform enforces authority, policy, approval, scope, and evidence before any action runs.
Why it matters
Agent frameworks often give models tools and APIs directly. That model breaks enterprise accountability: permissions expand silently, actions are hard to audit, and “the agent decided” is not an acceptable answer for regulated work.
AI Fabrix compiles integrator-defined operations into enterprise capability keys (e.g. customer.search) and mediates every request through the capability gateway.
How it works
Bad model: AI → API → system action
AI Fabrix: AI → governed capability → control checks → execution → evidence
A Role Assistant may understand a request, gather context, draft a recommendation, and request a capability. It does not:
- invent authority beyond the active role
- bypass policy or approval gates
- expand permissions when skill level increases
- execute directly against enterprise systems with embedded credentials
The active role is the operating boundary — not the assistant persona.
Integrator connection
Capabilities become available to workers only after integrators:
- Model datasources with business metadata
- Expose and upload integrations
- Pass certification pillars (certification guide)
Operators should verify certification before assigning new capabilities to worker roles.
Limits
- Capabilities must be certified and uploaded before workers can request them in production; this page does not replace the Build → Business Entities configure track.
- Generic “agent” patterns without capability manifests are out of scope for AI Fabrix Role Assistants.
Example
A Finance Assistant recommends an approval package and requests approval.prepareRequest. The platform validates role, policy, and certification. The worker does not post to a finance API with embedded credentials.
Business value
Enterprise-safe execution, explainable allow/deny decisions, and a clear line between AI assistance and system mutation.