Loading...
Sentrul is a governed AI operations platform. It combines departments, agents, approvals, research, documents, billing controls, and admin tooling into one workspace so teams can launch AI-assisted work with traceability instead of ad hoc prompting.
This handbook is written from the user perspective. It covers:
Start with department access, quick actions, and recent execution visibility.
Run research, targeted agents, or tracked workflow executions from one screen.
Ground work in verified web, academic, semantic, and internal sources.
Upload and index governed documents for department search and retrieval.
Drive work across departments, workflows, approvals, and execution history.
Operate inside one workspace, coordinate teams, and manage governed execution.
Review audit evidence, encryption health, restricted activity, and approval comments.
Manage capacity, provider settings, connector controls, and launch readiness.
Sentrul is not just a chat interface. It is a workspace for governed AI execution.
The platform is built around:
From a user perspective, the main pattern is:
Operators usually spend most of their time in:
Department leads usually work in:
Knowledge-heavy users usually work in:
Billing owners usually work in:
Admins see additional operational screens for:
Sentrul exposes several public routes before authentication:
Registration creates the initial workspace identity and sends the user into onboarding. Pricing CTAs may pre-select a target plan, but the real workspace behavior still depends on the active subscription state and billing flow.
After login, private routes become available through the application shell. If an unauthenticated user tries to open a private route, Sentrul redirects them to the login page.
The /docs surface is the public handbook. It is the best starting point for learning how the platform works before entering the private application.
Dashboard is the normal private starting point. It is where users orient themselves before choosing a department or launching work.
Use Dashboard to:
Departments are the main unit of operational ownership.
Use Departments to:
The Agents surface is for capability discovery and execution setup.
Use Agents to:
Agent Builder and Skills are part of the workspace navigation for users who need reusable capability setup rather than only execution.
Command Center is the most direct launch surface for governed AI work.
Use it when you already know:
Tasks help users monitor in-flight work and background operations. This is the page to check when something has been launched but not yet resolved.
Decisions is the approvals surface. Operators and approvers should review it whenever the system pauses for policy, risk, or workflow checkpoints.
Messaging is the conversation and coordination surface. It is appropriate when a user needs an ongoing thread with the workspace rather than a one-shot launch from Command Center.
Research is the grounded research surface. Use it for discovery, synthesis, and evidence collection before taking action in Command Center or departments.
Knowledge Vault is the governed document and knowledge area. It is where users inspect or upload durable knowledge when their plan enables document uploads.
Memory is the workspace surface for retained context and retrieval-oriented state. It is useful when the team wants to understand what long-lived knowledge has already been captured.
Documentation is the in-product handbook and search experience. Use it when you need operating guidance, route definitions, or workflow context without leaving the product.
Connections is where users manage external system access in a governed way.
Integrations is plan-gated and becomes visible at Essentials and above.
Compliance is visible on Operations and Enterprise. It should be treated as the operational surface for audit-ready controls and retention-aware review, not as a blanket certification statement.
Audit Logs are visible from Essentials upward. The exact retention window depends on the active plan.
Settings is the control plane for user preferences, provider keys, oversight mode, and workspace configuration.
BYOK behavior is plan-specific:
Provider keys should be treated as a controlled configuration surface, not as a generic bypass for all platform limits.
The Billing surfaces include:
/billing for overview and usage/billing/plans for plan comparison/settings/billing for workspace billing actions and token packsUse Billing to:
The most important practical plan differences are:
| Plan | What Changes For The User |
|---|---|
| Trial | BYOK-only execution, smallest workspace limits, no managed token pool |
| Starter | First managed token tier, 30-day audit retention, small-team footprint |
| Essentials | First document-upload tier, larger collaboration limits, Boost pack eligibility |
| Operations | Premium model access, parallel BYOK behavior, SSO, private VPC option, HIPAA BAA availability, 365-day retention |
| Enterprise | BYOK-primary execution, negotiated overage, permanent audit trails, priority handling, unlimited scale markers |
Managed usage is weighted by model lane:
This means premium-heavy workloads exhaust the managed pool faster than low-cost routing.
Current token-pack access is plan-gated:
Audit-related retention behavior currently maps to plan tier:
Admins have access to operational screens that standard users do not.
Used for commercial and operational visibility.
Used to manage connector-level administration and bootstrap guidance.
Used for deployment readiness and launch checks.
Used to inspect routing behavior, lane distribution, and model configuration controls.
Used for plan operations, tenant billing oversight, and margin-sensitive review.
The likely causes are:
Check:
This can happen because:
Start with:
/docs/help/getting-started/termsThese surfaces provide the clearest path from orientation to execution.