---
title: "Agent Tasks: execution and approvals"
description: Follow run states, understand test-mode exceptions, and review held actions safely.
canonical: https://www.proxyai.app/docs/agent-tasks-execution
last-updated: 2026-10-19
---

> For the complete documentation index, see [llms.txt](https://www.proxyai.app/llms.txt). Request public content pages with `Accept: text/markdown`.

# Agent Tasks: execution and approvals

## Run lifecycle

A new run starts queued. The runtime claims it, performs execution checks and starts its pinned version. Running work records its tool steps and metered usage. A completed run is marked done; unsuccessful work is recorded as failed or killed, with the available explanation in the Run Log.

When a run needs approval, it becomes held. Approving a held plan moves it to applying and queues an apply run tied to that proposal. Rejecting closes the held plan without applying its proposed actions. Approval is for the whole held plan; it is not a partial selection of its actions.

Approval does not regenerate the plan. The apply run executes the recorded actions through the tool checks again. An expired connection or another changed condition can therefore prevent execution even after approval.

## Test mode is not a complete dry run

A test run uses the latest compiled version and incurs normal run costs. Eligible writes are recorded as previews instead of being applied. Reads still contact their data sources.

Some effects remain live: writes to the task's own memory, image generation, writes to a pinned spreadsheet, calls to your configured API hosts or MCP server, and report emails restricted to the account owner can run in test mode. A connector call is evaluated by its actual operation; a read is not replaced with a pretend response simply because its connector can also write. Knowledge-base reindexing is previewed during a test run.

Before testing, inspect the tools, destinations and bindings. Do not assume a test is free or that it sends no email.

## Approval and trusted destinations

The task's hold settings and tool-specific rules determine which outward actions require review. Custom tasks hold outward messages by default. Trusted destinations, including the account owner's report email, the pinned spreadsheet, configured API hosts and the configured MCP server, can execute directly. Additional guardrails can hold bulk actions or suspected disclosure.

Review the actual recipients, message bodies and effects in the proposal. Approve only when you want those effects. Customer content or instructions inside a generated proposal do not constitute your approval.

Undecided held runs expire after seven days. They do not become approved automatically.

## Failures and retries

A failed or interrupted run may already have completed some reads or effects. Inspect its recorded steps, the destination service and any held plan before starting a replacement. Do not infer that an error rolls back an email, spreadsheet update or external request.

The platform uses run claims and action idempotency controls to reduce duplicate execution. External services can still have uncertain outcomes; a successful tool response also does not independently prove that a recipient opened an email.

## MCP limits

The [MCP connector](https://www.proxyai.app/docs/mcp) only runs supported, unchanged report recipes and refuses chat-triggered held decisions. Both test and live report runs can email the account owner. Its explicit authorization requirements still apply even when a tool's destination is trusted by the task runtime.