# Autonomous AI Everything else in these guides happens because someone made a request. This page covers what runs unattended: a task delegated to an agent that works through it alone, a routine that fires every weekday morning, and a briefing waiting when someone signs in. All of it is gated on the **module-tasks** entitlement. ## Tasks A task is a unit of work with a status, an assignee and, optionally, an agent assigned to do it instead of a person. ```bash curl -X POST https://api.genuineai.app/api/v1/tasks \ -H "X-Api-Key: gai_…" -H "X-Tenant-Id: " \ -H "Content-Type: application/json" \ -d '{"task_name": "Draft the Q3 customer update"}' ``` | `task_status` | | |---|---| | `new` | Created, not started. | | `in-progress` | Being worked on, including by an agent. | | `pending-review` | Work submitted, waiting on a human. | | `completed` | Approved and done. | | `canceled`, `closed` | Ended without completion. | | `template` | Not a task: a definition other tasks are made from. | `GET /tasks` filters on status, assignee, priority and creator. Three filters cover the autonomous side specifically: `task_autopilot_only`, `task_routines_only` and `task_workflow_only`. Templates are hidden unless `task_is_template` requests them, so a plain list returns the inbox rather than the machinery behind it. ### Expand a one-line brief ```bash curl -X POST https://api.genuineai.app/api/v1/tasks/enrich \ -H "X-Api-Key: gai_…" -H "X-Tenant-Id: " \ -H "Content-Type: application/json" \ -d '{"raw": "chase the overdue invoices before month end"}' ``` Expands a one-line brief into a fuller one, with a description and acceptance criteria, so the task an agent later executes contains enough to act on. This runs a model, so it costs credits. ## Autopilot Autopilot is a task that executes itself. Two fields turn it on: | Field | | |---|---| | `task_data.autopilot_mode` | `manual` (off) or `review` | | `task_copilot` | The agent that will do the work. **Required**: a task without one never runs, and asking it to run returns 400. | Create the task with both and it starts as `in-progress` with `autopilot_status: "pending"` rather than sitting in someone's queue. You can also run one on demand: ```bash curl -X POST https://api.genuineai.app/api/v1/tasks//run-autopilot \ -H "X-Api-Key: gai_…" -H "X-Tenant-Id: " ``` The platform then opens a thread for the task, builds a prompt from its checklist and context (*"work through every acceptance criterion you can complete with the information and tools available"*), and runs the copilot agent against it. Whatever [tools](/agents-and-conversations#tools) that agent carries are available while it works, which is the difference between an agent that summarizes the task and one that completes it. ### The confidence gate The agent's result is parsed into a structured submission carrying a **confidence** score, and that score decides whether a person ever sees it: | `task_data` field | Default | | |---|---|---| | `confidence_threshold` | `0.7` | Below this, the result always goes to review. | | `auto_approve_high_confidence` | `false` | When true, a confident result completes the task outright. | - Confident **and** auto-approval on → status `completed`, with an auto-approval recorded in `reviews` naming the confidence and threshold that allowed it. - Otherwise → status `pending-review`, with `submission.low_confidence` flagging which case you are in. The default is deliberately conservative: without opting into auto-approval, every autopilot result waits for a person. Turning it on lets the workspace act without supervision, and the audit trail records each time it does. ### Track a run `task_data.autopilot_status` moves `pending` → `running` → `completed`, or to `error` with `autopilot_error` explaining why. Two guards apply: asking a task to run while it is already running returns **409**, and a task not in `new` or `in-progress` returns **400** rather than restarting finished work. `GET /tasks/autopilot/activity` lists recent runs across the workspace. Read it to see what the platform did overnight. ## Review Autopilot shares its review path with human work, which is why an agent's output and a colleague's arrive in the same queue: | | | |---|---| | `POST /tasks/{id}/submit-review` | The assignee's half. Moves the task to `pending-review` rather than to done. | | `POST /tasks/{id}/approve` | The creator's half. `approved: true` completes it; `false` sends it back to in-progress with your `comments` attached. | `POST /tasks/{id}/send-email` sends the task's response out by email, which is the step that turns a completed task into something a customer receives. ## Routines A routine is a task template on a schedule. ```bash curl -X PATCH https://api.genuineai.app/api/v1/tasks//routine \ -H "X-Api-Key: gai_…" -H "X-Tenant-Id: " \ -H "Content-Type: application/json" \ -d '{ "enabled": true, "cron": "0 8 * * 1-5", "timezone": "America/New_York", "max_runs": 60 }' ``` Takes a cron expression and a timezone (`America/New_York` if you omit one), plus an optional `end_at` or `max_runs` so a routine can stop on its own. Presets cover the common cadences (daily, weekdays, weekly, monthly), all at 08:00. `GET /tasks/routines` lists them, `POST /tasks/routines/{id}/run` fires one immediately without changing its schedule, and `POST /tasks/{id}/copy` creates a one-off instance from the same template. Combined, the two halves complete the picture: a routine fires each weekday, creating a task whose copilot agent completes it, auto-approving when confident and queueing for review when not. ### Turn a conversation into a routine The best routines are usually discovered rather than designed: someone works something out in a thread, then wants it to happen every week. ```bash curl -X POST https://api.genuineai.app/api/v1/tasks/routines \ -H "X-Api-Key: gai_…" -H "X-Tenant-Id: " \ -H "Content-Type: application/json" \ -d '{ "thread_id": "", "instruction": "Do this for last week'"'"'s numbers every Monday", "schedule_hint": "weekly" }' ``` This reads what was worked out in the thread and answers with a proposed template rather than creating one, so a misclick is recoverable. Create the task from the proposal with `POST /tasks`, then put it on a schedule with `PATCH /tasks/{id}/routine`. `message_id` pins the proposal to one exchange rather than the whole conversation. `GET /tasks/suggestions` works in the opposite direction, surfacing work the caller repeats often enough that it could run on a schedule instead. It is a low-cost way to make a workspace more autonomous over time without anyone designing automation up front. ## Briefings ``` GET /tasks/briefing/today POST /tasks/briefing/run ``` The morning summary of what is waiting, generated on a schedule and readable at any time. `run` regenerates it immediately rather than waiting for the next cycle. ## Follow changes live ``` GET /tasks/events ``` A server-sent event stream of task changes across the workspace: creation, status changes and autopilot progress. It responds with `text/event-stream`. **Pair this with slow polling rather than relying on it alone.** The event bus is per-instance and in memory, so a reconnection can land on an instance that missed an event. Treat the stream as a latency improvement over polling rather than as a guaranteed log of everything that happened. Building for both is what separates a dashboard that feels instant from one that is correct: stream for responsiveness, and reconcile on a timer. ## Next steps - [Agents and conversations](/agents-and-conversations) covers the copilot agent and its tools. - [External data](/external-data) lets an autonomous task act on other systems. - [Usage and credits](/usage-and-credits) explains what unattended work costs.