What the SAGARIS AI receptionist may do on a call

What it can do, and what is on by default

The receptionist is given a tool list rather than a free hand. Twelve actions are built in. A new route starts with five of them selected: transferring the call, capturing a message, scheduling a callback, looking up a returned call, and hanging up. The same five also run on a route whose saved list is empty, or names only actions that no longer exist. Otherwise a route runs the actions it has selected, plus the returned-call lookup, which every inbound route carries unless its route metadata sets returnedCallLookup to false. The rest are opt-in.

transfer_call

On by default. Transfers a qualified or urgent caller to a human queue. It is a direct transfer: the AI does not speak to the person who answers before the caller is put through.

capture_message

On by default. Record a callback message when no human owner is available.

schedule_callback

On by default. Record the caller's requested day and time as a due item on the team's callbacks list. It never dials: a person places the call.

lookup_returned_call_number

On by default, and kept on for every inbound route even when it is not selected, unless the route metadata sets returnedCallLookup to false. When a caller says you called me, match the number they were reached on against recent outbound dials and the CRM, so the greeting starts from what is already known.

hangup_call

On by default. End a resolved, abusive or caller-requested disconnect cleanly.

book_meeting

Off until enabled. Books a real meeting on the calendar and creates an inbound-call lead.

answer_question

Off until enabled. Answers product and support questions from the workspace knowledge base.

research_company

Off until enabled. Looks up a live summary of the caller's company mid-call, grounded with sources.

create_note

Off until enabled. Creates a follow-up note for the workspace after the call.

send_verification_code, check_verification_code

Off until enabled. A one-time SMS code to the caller's on-file number, and the check of the code they read back, so identity is verified before any account detail is discussed.

diagnose_account

Off until enabled, and only after the caller is verified. A read-only summary of what is wrong with their account.

A workspace can also define its own actions. A customer action carries a JSON-schema parameter block and a webhook URL, and compiles into the same tool list as the built-ins. Its requests are not signed. No secret store is wired behind an action's signing-secret reference yet, so the request carries no signature header, and an action that names a secret is refused rather than sent unsigned. The built-ins always come from code, so a database problem can only ever remove customer actions, never grant one and never mute the receptionist.

• What the receptionist does on an inbound call The product page for the same feature, where the limits are printed beside the capabilities: that the AI disclosure is spoken on every call and a greeting cannot remove it, and that every transfer request is logged.

What it may write while the caller is on the line

Every action is classified by what it does to the world, and the classification is what the approval gate keys on.

none

Returns information into the call and creates nothing durable for a human to act on. Transferring, hanging up, answering from the knowledge base, researching the company, the verification pair and the account diagnosis are all in this class.

autonomous

Commits during the call, under a cap. Booking a meeting, capturing a message, scheduling a callback and creating a note are in this class. One exception depends on the caller: when the number does not match exactly one of your contacts, a booking, and the lead an urgent message would create, is held for a rep to approve instead of being committed, and the receptionist tells the caller it is noted, not booked.

proposal

Never commits live. It writes a row for a rep to review. No built-in action is classified this way. Customer actions are, and approving one of their rows does not run the action yet: the approval is refused and nothing is committed.

Recording, and when a disclosure is spoken

An inbound session can transcribe and store the caller's audio, which in an all-party consent state is a recording decision rather than a preference. The caller's state is resolved from the number they are calling from, using the same jurisdiction authority the outbound dialer uses; there is no second classification to drift from the first.

The gate fails closed in the only safe direction. Recording proceeds when the state is a known one-party state, or when the disclosure will actually be spoken. An unknown or unresolved jurisdiction counts as all-party. If a disclosure is required and cannot be guaranteed to be spoken, the capture mode is downgraded rather than the recording proceeding silently.

When it cannot take the call

By the time the application decides whether to run a receptionist session, the phone system has already answered and a human being is listening. So every refusal carries an instruction for what the caller hears: a transfer to the route's non-AI fallback where one exists, and otherwise a spoken apology before the line drops.

The refusal is still a refusal. Nothing is relaxed to keep the call alive, and the caller never hears an internal billing or entitlement message. What changed is that the caller no longer hears silence.