Approvals
Where human judgment enters the loop, and how to respond when it is yours.
Sebati is built for governed autonomy. Agents can prepare and execute work, but consequential actions can be configured to wait for a human decision. If you are that human, this page is for you.
When you'll be asked
Builders decide, per action type, how much freedom an agent has: act freely, act but notify, or wait for approval. Typical approval points:
- An agent wants to send a message or write into an external system.
- A Case task reaches its review stage and needs sign-off before completing.
- A sensitive tool call is configured to require confirmation.
Responding to a request
An approval request shows you what is being approved: who or what triggered it, what the agent proposes to do, and the content or payload involved.
You respond in one of two places:
- In Sebati: approval requests appear in the product, where you approve or reject with an optional note.
- From a link: some workflows send approval requests by email with a secure link. The link opens a minimal approve-or-reject page, no sign-in required. Treat the link like the authority it carries and don't forward it.
Requests can expire. An expired request is treated as not approved, and the work waits or fails visibly rather than proceeding silently.
What approval means
Approving executes the pending action exactly as shown. Rejecting stops it; in Cases, the task returns to the agent or the queue with your note attached, which is often the fastest way to say "close, but fix this one thing".
Every decision is recorded: who decided, what, and when. The audit trail is visible to your workspace admins.
An approval request is not a sign the agent failed. It is the deployment working as designed: autonomy where it is safe, judgment where it matters.