> ## 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.
# Objectives
> What an agent is trying to maintain or move forward
## What is an objective?
An **objective** is the goal an agent works toward. It's the "why" behind every playbook the agent runs. Examples:
* "Every claim resolved within 14 days."
* "No deal sits in a single stage for more than 21 days."
* "Inventory above the configured reorder point at all times."
* "Every sales rep gets a daily briefing of their pipeline by 8 AM."
Objectives are not free-form rules. Each one is a measurable target tied to a collection, a field, and a threshold. That's what makes them enforceable by an agent rather than a vague aspiration.
## How Gaia infers objectives
When you finish the [data and UI phases](/concepts/how-it-works) of a build, the **autonomy** phase kicks in. Gaia reads:
* **Your schema.** Field names, enum values, dates, foreign keys, status fields.
* **Your views.** What you've put on dashboards, kanban boards, and tables.
* **Your seed data.** Volume, distribution, recency.
* **Your prompt history.** The intent behind the app.
From these signals it proposes a starting set of objectives. A CRM with a `stage` enum and a `close_date` field gets stalled-deal objectives. A support app with a `status` field and `created_at` gets SLA objectives. An inventory app with a `quantity` field and a `reorder_point` field gets stock-level objectives.
You always see the objectives before they go live. The autonomy contract is reviewable, editable, and disablable. Nothing runs until you sign off.
## Anatomy of an objective
Each objective has the same shape:
| Field | What it is | Example |
| -------------- | -------------------------------------- | -------------------------------------- |
| **Name** | Short label for humans | "Stalled deal" |
| **Collection** | The data model the objective watches | `deals` |
| **Measure** | What's being measured | Days since `stage_changed_at` |
| **Threshold** | When the objective is at risk | More than 14 days |
| **Filter** | Which records the objective applies to | `amount > 5000 AND status != "closed"` |
| **Owner** | Who the resulting drafts go to | `deal.owner` |
| **Risk tier** | How the objective acts | Draft-and-approve |
## Editing objectives
Every objective is editable through follow-up prompts or the Autopilot UI:
```text theme={null}
Change the stalled-deal threshold from 14 days to 21 days.
```
```text theme={null}
Only apply the stalled-deal objective to deals over $10,000.
```
```text theme={null}
Disable the inventory low-stock objective for the
"discontinued" product line.
```
## Adding objectives manually
You're not limited to inferred objectives. Add new ones in natural language:
```text theme={null}
Add an objective: every new contact created in HubSpot
gets a welcome email drafted within 24 hours, sent
to the account owner's Autopilot inbox.
```
```text theme={null}
Add an objective: any invoice over 30 days past due
gets a draft escalation to the controller.
```
## When objectives fire
An objective produces work when its threshold is crossed. The trigger that detects the crossing depends on the objective:
* A **time-based** objective ("14 days idle") uses a [schedule trigger](/autopilot/triggers).
* A **state-change** objective ("stage moves to lost") uses a [data change trigger](/autopilot/triggers).
* An **inbound** objective ("new ticket from VIP") uses a [webhook trigger](/autopilot/triggers).
* An **on-demand** objective ("draft me a recap") uses a [user-triggered](/autopilot/triggers) button.
The objective stays the same. The trigger reflects how the world tells the agent the objective needs attention.
## Example: a stalled-deal objective end to end
```yaml theme={null}
name: Stalled deal
collection: deals
measure: days_since_stage_changed_at
threshold: ">= 14"
filter: "amount > 5000 AND status NOT IN ('won','lost')"
owner: deal.owner
risk_tier: draft_and_approve
playbook: nudge_with_email
```
When this objective fires:
1. The runtime queries `deals` for matching records once a day.
2. For each match, the `nudge_with_email` [playbook](/autopilot/playbooks) runs.
3. The playbook drafts a follow-up email referencing the deal's last activity.
4. The draft lands in the deal owner's [Autopilot inbox](/autopilot/inbox) with full reasoning attached.
5. The owner approves, edits, or skips. Nothing leaves until they do.
## Best practices
A high-stakes objective ("escalate every late invoice") creates more drafts than the team can review. Start with the top 10% of cases by amount or risk. Widen once approval rates settle.
`deal.owner` is more useful than "the sales team." Personal Autopilot inboxes are more actionable than a shared queue.
Disabled objectives keep their history and can be turned on with one click. Deleting loses the configuration.
The [agent action log](/autopilot/agent-action-log) shows what fired, what got drafted, what got approved, and what got skipped. Skipped drafts are the strongest signal that an objective needs editing.
## Learn more
The trigger, steps, and guardrails an objective runs
The four ways a playbook starts
How drafts become actions
The inbox where drafts land