> ## Documentation Index
> Fetch the complete documentation index at: https://docs.roark.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Give Roark an objective and it improves your voice agent for you: it stages a copy, builds a test suite, changes the configuration, and proves the improvement with real simulated calls before you promote it

Autoimprove is Roark working on your agent instead of just measuring it. You pick one objective, a metric that should pass and the pass rate you want, and Roark runs the whole improvement loop autonomously: it clones your agent into a staging copy, writes caller scenarios that exercise the objective, measures a baseline over real simulated phone calls, changes the staging configuration, and re-tests until the objective holds. Production changes exactly once, when you promote a verified job's changes.

## Quickstart

Three commands with the [Roark CLI](/documentation/sdks/cli). Find your agent and the metric that defines success, then hand Roark the objective:

```bash theme={"theme":{"light":"everforest-light","dark":"everforest-dark"}}
roark agent list
roark metric definitions list

roark autoimprove job create \
  --agent-id "$AGENT_ID" \
  --objective-metric-definition-id "$METRIC_ID" \
  --objective-label "Consent collection should pass" \
  --target-value 90
```

That is the whole job description. Roark takes it from there; watch it work with:

```bash theme={"theme":{"light":"everforest-light","dark":"everforest-dark"}}
roark autoimprove job get <job-id>
```

The response carries the live worklog: every step, every batch of test calls with its pass rate, and Roark's own running notes. The same job is live in the dashboard under **Autoimprove**, where the worklog renders as a feed.

<Note>
  The objective metric should produce a pass/fail verdict per call: either a boolean metric, or a threshold on a scale metric (for example "Instruction Follow >= 4"). Create one in the dashboard's metric studio or with `roark metric definitions create`.
</Note>

***

## How it works

1. **Stage.** Roark clones your production agent inside your provider account (Vapi or Retell) as a clearly-marked shadow, gives it its own phone number, and registers it for simulations. Your production agent is never modified by the loop.
2. **Author.** It writes caller scenarios for the objective: the failure case it is hunting, an easy case, an edge case. Each becomes a real simulation flow with success criteria, graded by your metrics.
3. **Measure.** A baseline batch of simulated calls establishes where things stand. Every later change is measured against it.
4. **Change and re-test.** Roark edits the staging configuration through an audited funnel, then proves or disproves each change with more calls. It reads the graders' evidence, not its own opinion of the transcripts.
5. **Verify and hand over.** When the objective passes its target with repeated trials, the job waits for you: review the diffs and the numbers, then promote or dismiss.

## What Roark can change

The whole provider configuration document, not just the prompt: the system prompt, the underlying model and temperature, the voice, the transcriber, timeouts and endpointing, the first message, tool definitions. Credentials, URLs, webhooks, and privacy settings are protected and refused by the platform.

## The safety model

<CardGroup cols={2}>
  <Card title="Staging-only writes" icon="shield">
    The loop only ever writes to the staging copy. The one write path to production is the promote, and only you trigger it.
  </Card>

  <Card title="Rollbackable promotes" icon="undo-2">
    A snapshot of the production configuration is taken immediately before a promote, so every promote can be fully rolled back.
  </Card>

  <Card title="Guaranteed cleanup" icon="paintbrush">
    Whatever the outcome, everything the job set up is removed: the shadow agent, its phone number, the authored test flows and run plan.
  </Card>

  <Card title="Hard budgets" icon="gauge">
    Decision turns and simulated calls are capped (50 turns and 200 calls by default, tunable at create). Roark cannot exceed them.
  </Card>
</CardGroup>

## Job statuses

| Status             | Meaning                                                                                                                    |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------- |
| `RUNNING`          | The loop is working: authoring, changing, or validating.                                                                   |
| `NEEDS_INPUT`      | Roark is blocked on a question to you. Answer it and the loop resumes; after 24 hours it proceeds with the stated default. |
| `AWAITING_PROMOTE` | Verified. The staged changes passed the target and wait for your review.                                                   |
| `PROMOTED`         | You promoted; the changes are live on production.                                                                          |
| `NO_FIX`           | Concluded without a change to ship. This includes the positive case where the baseline already met the target.             |
| `CANCELLED`        | Stopped by request. Production was never changed.                                                                          |
| `FAILED`           | Stopped by an error. Production was never changed, and resources were cleaned up.                                          |

## Go deeper

<CardGroup cols={2}>
  <Card title="Running a job" icon="play" href="/documentation/autoimprove/running-a-job">
    The full lifecycle over the CLI and API: creating, watching, steering, answering, promoting.
  </Card>

  <Card title="CLI" icon="terminal" href="/documentation/sdks/cli">
    Install and authenticate the Roark CLI used throughout this section.
  </Card>
</CardGroup>
