Get startedIntroduction
Introduction
SAGARIS is a revenue operating system with agents inside it. The CRM, the dialer, the inbox, SMS, social and the AI receptionist are one system over one set of records, and AI agents work that pipeline under an autonomy level you set, an approval queue you own, and an audit trail. This page is the shape of the system: what a workspace is, what is in it, and what has to be true before anything reaches a real person.
The workspace is the boundary
A workspace is your company's tenancy: its contacts, deals, sequences, calls, mailboxes, settings and people. Every record carries a workspace id and every query is filtered by it. You will see the word in the API, in roles, and in the audit log, and it always means the same thing.
The boundary is enforced rather than assumed. An API key belongs to exactly one workspace, and every authenticated request is pinned to the workspace resolved from that key. A client cannot pass a workspace id and be believed, because no request-supplied workspace id is read at all.
One consequence worth knowing early: to integrate two workspaces you need two API keys. There is no cross-workspace key, and there is no request-level way to ask for another tenancy's data.
What is inside a workspace
The product is one application with fourteen top-level sections. They share the same contact and account records, so a call, an email and a pipeline stage are three views of one history rather than three systems to reconcile.
- Home
- The day: your queue, the command center, goals and quota pacing, and the workflow approvals waiting on you.
- CRM
- Contacts, leads, accounts, customers, audiences and the pipeline, plus import, enrichment and lifecycle rules.
- Engage
- Campaigns, sequences and the channels they run on.
- Unified Inbox
- Email, SMS and the rest of the reply surface in one thread list.
- Parallel dialer
- Dialing, call history, local presence and the calling configuration.
- AI receptionist
- The inbound answering agent and its routing.
- Calendar
- Meetings and booking.
- Analytics
- Reporting, forecasts and insights.
- Intelligence
- Signals, deal insight and coaching.
- Wins
- Recognition and the team's closed business.
- Social
- The social workbench: hub, studio, calendar, review, listening and insights.
- Data
- Data health, datasets, field mapping and writeback mapping.
- Admin
- Workspace and platform administration. Management roles only: the section is not rendered for an individual contributor.
- Settings
- Workspace, channel, integration and API-key configuration.
How an agent is allowed to act
An agent does not decide for itself what it may do. Each action it can take carries a risk tier, whether the effect is reversible, and whether it touches the world outside SAGARIS. The workspace carries an autonomy level. The two together decide whether the action runs unattended, waits for a person, or is refused outright.
- manual
- Nothing runs unattended. Every action waits for a human.
- assisted
- Low-risk reversible actions self-run. Everything else needs sign-off.
- supervised
- Low and medium-risk reversible actions self-run. High-risk actions need manager approval. A critical, irreversible action with an external side effect is blocked outright.
- autonomous
- Low and medium-risk actions self-run, and so do high-risk actions that are reversible or have no external side effect. A high-risk irreversible action with an external side effect still needs approval, and so does anything critical.
The tiers are set per action, not per mood. Drafting an email, summarizing a call, enriching a contact and tagging a lead are low risk. Sending an email, updating the CRM and scheduling a meeting are medium. Placing a call, sending a contract and applying a discount are high. Deleting a record and issuing a refund are critical.
There is one floor no autonomy level lifts: an action that is critical, irreversible and externally visible can never run unattended. The same check refuses any action whose risk metadata is missing or unrecognized, so a malformed action fails closed instead of falling through to a permission.
Anything that needs a person appears in workflow approvals, where it can be approved, edited or rejected. The decision, and who made it, is recorded.
Before anything reaches a real person
Outbound is the part of the system where a mistake is not undoable, so it is the part with the most holds. Every app-originated send path to a real contact passes a global gate that reads the environment and is fail-closed: an absent, empty or unrecognized flag keeps it shut, and the flag is deployed shut by default. Opening it, per channel or overall, is a deliberate act.
- A platform-wide kill switch that can be armed at runtime, without a redeploy, and that also holds if it cannot be read.
- A per-workspace send pause.
- The suppression list, which is keyed on the email address and the phone number rather than on the contact row, so it survives a contact being edited, deleted or re-imported, and applies across every channel. A read error counts as suppressed.
- The approval flow, for any action the autonomy level does not let an agent take alone.
Transactional mail deliberately does not pass through the outbound gate. Sign-in links and receipts keep working when outbound is shut, so closing the gate never locks your team out of the product.
Where to go next
- Quickstart, for the first hour in a new workspace: connect a mailbox, get contacts in, and launch a first play.
- Authentication, if you are integrating: how an API key is minted, what a scope grants, and how a key is revoked.
- REST API, Webhooks and Rate limits, for the programmable surface.
Behaviour on this page is read from
- src/lib/dashboard-navigation.ts
- src/lib/auto-execution-policy.ts
- src/lib/outbound-gate.ts
- src/lib/global-outbound-kill-switch.ts
- src/lib/suppression-store.ts
- src/lib/public-api-auth.ts
Was this page helpful?