Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.gainable.dev/llms.txt

Use this file to discover all available pages before exploring further.

​
The trust model

Gaia Autopilot is autonomous. Autonomy without guardrails is reckless, so every agent action is bounded by a risk tier. The tier governs whether an action runs, whether it pauses for approval, whether it can be undone, and how often it’s allowed to run. The default for outbound work is draft-and-approve. Nothing goes to a customer without a human reviewing it. Agents earn higher autonomy by demonstrating, in the action log, that their drafts are consistently approved as written.

​
The three tiers

TierBehaviorDefault for
draft_and_approveDrafts are produced and land in Autopilot. Nothing executes until a human approves.All outbound communication tools
auto_with_undoAction executes immediately. Has a configurable undo window during which the user can reverse it.Internal updates, low-blast-radius changes
autoAction executes immediately. No human review. Cannot be reversed by the user.Reads, internal notifications, action-log writes
You’ll rarely choose tiers manually. Each tool has a default tier. Each playbook can constrain tiers further but never relax them.

​
Graduation

Tiers aren’t immutable. A playbook can graduate from draft_and_approve to auto_with_undo (and rarely to auto) when:
  • It has a long enough history of drafts being approved as written
  • The recipient class is internal or trusted (org employees, internal channels)
  • The org explicitly opts in
The runtime tracks approval rate per playbook, per tool, and per recipient class. The Autopilot UI shows when graduation is available and what the recommended next tier is.
Graduation is opt-in. Gainable never silently changes a risk tier. The recommendation appears in Autopilot. The org decides whether to act on it.

​
Undo windows

auto_with_undo actions are reversible. The undo window varies by tool:
ToolUndo windowWhat undo does
update_records24 hoursRestores prior field values
notify_user5 minutesRemoves the notification before it’s read
create_task24 hoursMarks the task as withdrawn
send_emailNot eligible for auto_with_undo(always draft_and_approve unless graduated to auto)
send_slack5 minutesDeletes the message
send_smsNot undoable(always draft_and_approve)
call_externalNot undoable(always draft_and_approve)
The undo window is enforced by the runtime. Once the window closes, the action is permanent.

​
Rate limits

Every playbook has rate limits. The defaults are conservative; the org can tighten or loosen them.
LimitDefaultWhy
Drafts per user per day25Keeps an individual’s Autopilot inbox manageable
Drafts per recipient per week3Protects external recipients from agent floods
Auto actions per playbook per hour100Bounds blast radius if a playbook fires too often
Tool calls per playbook run50Hard cap. Prevents runaway loops.
Rate limits are checked before the tool runs. A blocked call writes to the action log with a rate_limited outcome.

​
Per-user caps

Personal-scope playbooks (see scopes) inherit per-user caps. Two examples:
  • A user with 50 deals can’t generate 50 outbound drafts in a day from a single playbook unless the cap is raised.
  • A user can’t run a call_external tool more than 10 times an hour, even on-demand.
Per-user caps protect the org from a single user inadvertently turning an agent into a denial-of-service.

​
How a draft becomes an action

The lifecycle of a draft-and-approve outbound:
1

Trigger fires

Schedule, data change, webhook, or user click.
2

Playbook runs

Steps execute. The final outbound step is wrapped in draft_for_approval.
3

Draft lands in Autopilot

The configured owner sees it in their inbox. The action log records the draft creation.
4

Owner reviews

Approve, edit, skip, or unsubscribe future drafts in this class.
5

On approval, the underlying tool runs

send_email, send_slack, etc. Action log records the execution.
6

On skip, nothing runs

The action log records the skip with the reason if provided.

​
How auto-with-undo runs

The lifecycle of an auto-with-undo action:
1

Trigger fires

Same as above.
2

Tool runs immediately

The action takes effect.
3

Notification surfaces in Autopilot

The user sees what happened with an “Undo” button.
4

Undo window opens

Configurable per tool. 5 minutes for messaging, 24 hours for record updates.
5

If undone, the runtime reverses

Records restored, messages deleted, notifications removed.
6

Window closes, action is permanent

No further reversal. The action log shows the final outcome.

​
Configuring tiers

Risk tiers are part of the playbook guardrails: 
guardrails:
  risk_tier: draft_and_approve
  rate_limit_per_user: "10/day"
  rate_limit_per_recipient: "1/week"
  undo_window: "24h"
You can describe risk posture in natural language too: 
For the stalled-deal playbook, keep risk tier at
draft-and-approve. The deals manager wants to review
every outgoing nudge before it sends.

Graduate the daily-briefing playbook to auto-with-undo
with a 5-minute window. It only writes to personal inboxes,
so the cost of a mistake is low.

​
Best practices

Don’t graduate a playbook to auto_with_undo because it would be more convenient. Graduate it because the action log shows users approve drafts unchanged at least 90% of the time.
When a playbook is producing too many drafts, tighten the trigger filter or rate limit before relaxing the risk tier.
Internal Slack? Graduation candidate. External customer email? Stay in draft-and-approve unless you have an explicit, opted-in customer commitment to automated communication.
A spike in rate_limited outcomes in the action log means the playbook is firing more often than expected. Investigate before raising the limit.

​
Learn more

Tools

Default risk tier per tool

Playbooks

Where tiers are configured

Inbox

Where drafts and undo surfaces live

Agent action log

The audit trail behind tier decisions