Vertiqa Help← Back to app

Walkthrough: safely turn on a recurring agent loop

Configure policy, budget, schedule, run-now testing, and expected output before an agent runs repeatedly.

Use this walkthrough before enabling a recurring agent loop. The goal is to prove that the agent can run, stay within controls, and produce reviewable output before it becomes part of daily operations.

Real-life example

Every weekday morning, an IT services team wants Vertiqa to scan open customer commitments and stale project tasks. The team wants proposed actions in Command Center, not autonomous record changes.

Before you start

Pick one agent loop and one narrow outcome. Do not turn on several new loops at once. A narrow first run is easier to inspect and tune.

Start in AI OS Activity & Health

  1. Open AI OS Activity & Health at /ai-os to review your active AI loops, their guardrails, usage limits, and recent activity in one place.
  2. Confirm the loop you are turning on has read access only to the sources it needs, and that record-changing actions stay in propose-only mode for the first rollout.
  3. Confirm a conservative usage limit (spend or quota ceiling) is in place before the loop runs repeatedly.

Advanced detail: a recurring loop is backed by a policy, a budget, and a schedule. Your Vertiqa team configures these for you in the internal admin surfaces. The /ai-os overview is the tenant-facing place to review them.

Prove it with a single run

Before relying on recurrence, prove the loop runs cleanly once. Your Vertiqa team can trigger a single manual run, then you confirm in Recent activity on AI OS Activity & Health that:

  • a run was created for the correct agent type,
  • the run has events,
  • policy decisions are present when actions were evaluated,
  • usage appears in the usage report,
  • failures are visible rather than hidden in logs.

Expected output

One of these outcomes is acceptable:

  • the run completes and creates Command Center items,
  • the run completes and finds no matching work,
  • the run is blocked by policy in a way you expected,
  • the run is deferred or limited by budget in a way you expected.

The important requirement is inspectability. You should be able to tell what happened without asking an engineer to read server logs.

Enable recurrence

Enable recurrence only after the single run has a clean explanation. For the first week, check Recent activity in AI OS Activity & Health and Command Center after each run.

Failure paths

If the run fails, open it from Recent activity and inspect events, error, checkpoints, and policy decisions. Retry only after the cause is understood.

If the budget is over, reduce frequency, narrow the agent scope, or raise the budget only after confirming the output is valuable.

If Command Center receives too many low-value items, tune the rule or schedule before increasing autonomy.

Success criteria

The recurring loop runs on schedule, stays within policy and budget, creates useful queue items when work exists, and leaves enough run history for operators to recover failures.

Related

Last reviewed