Autonomous Agents

An autonomous agent is a self-paced loop: the agent runs one cycle, decides on its own when to wake up next, carries its state forward across every wake, and stops itself when the objective is met (or runs until you stop it). It is one of the two flagship capabilities in Aura Workshop — the other is Multi-Agent. Reach for an autonomous agent when a single task isn't enough because the work needs to happen over time: iterate until something is true, or keep watching something and act only when it changes.

How a loop works

A loop alternates between two states: armed (a scheduled wake is pending) and running a cycle. When the wake fires, the agent loads the state it saved last time, runs a single cycle of work, decides whether it is done, and — if not — picks a next-wake delay and re-arms itself. Nothing runs continuously; the agent only exists during a cycle and while it's waiting between cycles.

armed ──(wake fires)──▶ run one cycle ──▶ done?
   ▲                                        │
   │                          no ┌──────────┴──────────┐ yes
   └──── arm next wake ◀── pick next-wake delay      stop
         (persisted)         (clamped 5m–24h)     (achieved / cap)

Every next wake is armed as its own scheduled row, so the loop's progress lives in durable storage rather than in memory. A restart of the app or daemon resumes the loop cleanly from where it left off — the pending wake is still on the schedule.

Goal vs. monitor

Every autonomous agent is one of two kinds. The kind decides what makes the loop stop on its own.

For a goal loop, each cycle ends with a verification step: an LLM verifier judges the result against the objective's success criteria and only ends the loop when it is confident the goal is met. A monitor loop skips that gate and simply re-arms — it is designed to run indefinitely.

Execution modes

A cycle can be executed by one agent or spread across several. The mode sets how wide each cycle runs:

The mode is chosen once for the loop; every cycle uses it. Fan-out and team let a single wake do a lot of parallel work — for example, surveying many sources at once — before deciding whether to continue.

Inside a cycle

Each time the loop wakes, one cycle runs these steps in order:

1. Load state — the agent reads the loop state it saved on the previous cycle, so it remembers what it has already done and learned.
2. Build the cycle brief — the objective plus the carried-forward state become the prompt for this cycle.
3. Execute — the agent runs the cycle in its chosen mode (single, fan-out, or team).
4. Verify (goal loops) — the verifier checks the result against the objective; monitor loops skip this and always continue.
5. Check caps — max cycles, token budget, and end date are evaluated; a reason is recorded if any cap is reached.
6. Decide the next wake — if the loop isn't done, the agent proposes a next-wake delay (and can mark itself done); Aura clamps the delay to the safe window and arms the next scheduled wake.

The agent controls its own cadence and its own completion — it can say "wake me in 15 minutes" or "wake me in 6 hours," and it can declare itself finished — but always within the guardrails below.

Guardrails

Autonomy is bounded. Aura clamps and caps every loop so a runaway or misbehaving agent can't spin forever or burn an unbounded amount of tokens.

After every cycle Aura records a cap reason, so when a loop stops you can see exactly why — verified achieved, cycle cap reached, budget exhausted, end date passed, or an explicit Stop.

Two entry points

There are two ways to create an autonomous agent, for two different needs.

Composer "Auto" mode

In the Dashboard composer, cycle the mode button to Auto (the four modes are Execute → Plan → Goal → Auto). Type your objective and run. The agent runs its first cycle, picks a next-wake time, and either stops itself (goal) or keeps watching (monitor). Auto tasks show live loop status cards in the transcript so you can watch each cycle, and they survive app restarts because each next wake is a scheduled row. This is the fast path for a one-off autonomous run. See Workspace & Tasks for the composer and the other three modes.

Automation → Autonomous Agents

For a managed, named agent you can start, stop, and inspect, open Automation → Autonomous Agents. Here you define the loop up front:

• a name and an objective,
• a kind — goal or monitor,
• an optional model and project folder,
• the default interval, and (for goal loops) max cycles,
• and a runtime (see below).

Create & Start arms the loop. Each agent card shows its status (running / waiting / done / failed), and Inspect opens the underlying task's live transcript so you can watch its cycles. This panel lives alongside the other Automation triggers (schedules, listeners, webhooks, slash commands).

Running headless on the daemon

When you create an agent in the Automation panel, you choose where the loop runs:

On a daemon, the scheduler picks up armed loops the same way it fires any other schedule (with an atomic claim so two competing daemon containers can't double-fire a wake). This is what makes an autonomous agent a true background worker: deploy it once and it iterates or watches on its own, with no app window open. See Deployment & Security for the daemon and remote-deployment flow.

Examples

• Monitor — "Every 15 minutes, check the error dashboard; if the error rate exceeds 2%, summarize the top 3 failing endpoints and post to #ops." Runs forever on a cadence, acting only when the threshold trips.
• Goal — "Get the flaky integration test suite to pass 10 runs in a row; keep iterating on fixes until then." Iterates cycle after cycle, stopping the moment the verifier confirms the objective — or when a guardrail cap is hit.

Next: compare autonomous agents with Multi-Agent runs, wire them into Automation triggers, or read how they run in Deployment & Security.