Automation Runs
Automation runs are agent conversations that start without a person pressing Send. AgentPress uses them for scheduled agent work, external provider events, and agent-created follow-ups that continue an existing task later.
Use the Automation Runs page to answer operational questions:
- Did the automation start?
- Which agent and user did it run as?
- Which thread did it write to?
- Is a follow-up still queued?
- Why did a run fail or get interrupted?
Where to find it
In the console, open Agents → Monitor → Automation Runs.
The page is shown when Agent Run Automations are enabled for the organization. That feature flag also controls scheduled runs and self-scheduled follow-ups.
Owners and admins can inspect org-wide automation runs. Other users only see runs attributed to themselves.
What creates an automation run
Automation runs are grouped by source.
| Source | What it means |
|---|---|
| Schedule | A configured schedule started an agent on a daily, weekly, interval, or one-off cadence. |
| Provider event | An external provider event, such as an Outlook or webhook-backed event, queued an agent run for a specific context. |
| Follow-up | A previous agent run scheduled itself to continue the same task later. |
| Manual | A run was started directly by the system or an internal/manual caller. |
Scheduled runs are configured from an agent's Capabilities section under Scheduled runs. Each schedule has a name, cadence, run instructions, and a "run as" user. The run instructions become the prompt for each scheduled attempt.
Self-scheduled follow-ups are available when the agent's Self-reschedule capability is enabled. The agent can create a future continuation prompt with optional stop conditions, such as "do not send anything if the customer replied."
How a run is recorded
Each automation attempt is stored as an agent_runs row. The row records:
- organization, agent, and run-as user
- source and lifecycle status
- thread, schedule, or action linkage when available
- context type and context key for deduplication and continuity
- provider context fields for external systems
- input snapshot, metadata, timestamps, heartbeat, lease, and last error
The monitor reads those rows and joins the related agent, user, and thread so operators can open the conversation that received the run.
Run statuses
| Status | Meaning |
|---|---|
| Pending | The run has been created but has not started yet. |
| Running | A worker owns the run and is sending heartbeats while the agent is invoked. |
| Completed | The agent finished successfully and the run row has a completion timestamp. |
| Failed | The agent invocation failed; inspect Last error in the detail panel. |
| Cancelled | The run was stopped before completion. |
| Interrupted | The run was recovered from stale ownership or an incomplete follow-up bookkeeping path. |
The Automation Runs summary cards show counts for pending, running, completed, failed, cancelled, interrupted, scheduled, and active follow-up work. Click a card to apply the matching filter.
Follow-ups
Follow-ups are queued work items that become automation runs later. They are tracked separately from run attempts so you can see what is still waiting.
Open the Follow-ups tab to inspect:
- scheduled time and claim/completion timestamps
- continuation prompt
- stop conditions stored by the agent
- previous run, thread, context type, and context key
- last error, if the follow-up failed
Only pending and running follow-ups count as active. Completed, cancelled, and failed follow-ups are available from the status filter.
Provider events and context continuity
External triggers use a context type and context key to keep related work together. For example, an email provider event can map to the same conversation context across multiple events.
Before scheduling a provider-triggered run, AgentPress checks for existing active work for the same organization, agent, context type, and context key. If another run or pending schedule already owns that context, the new trigger is deferred instead of starting a duplicate conversation.
When possible, provider-triggered runs reuse the latest thread for the same agent and context. That keeps follow-up automation in the same conversation instead of scattering related work across threads.
API endpoints
The console uses these org-scoped endpoints:
| Endpoint | Purpose |
|---|---|
GET /orgs/:orgSlug/agent-runs | List run attempts and summary counts. Supports agentId, source, status, and limit. |
GET /orgs/:orgSlug/agent-run-follow-ups | List queued follow-ups. Supports agentId, status, statusGroup=active, context filters, thread filter, and pagination. |
DELETE /orgs/:orgSlug/agent-run-follow-ups/:id | Cancel a queued follow-up. |
GET /orgs/:orgSlug/agent-run-schedules | List user-configured schedules for an agent. |
POST /orgs/:orgSlug/agent-run-schedules | Create a daily, weekly, or interval schedule for an agent. |
PATCH /orgs/:orgSlug/agent-run-schedules/:id | Enable or update an existing schedule. |
DELETE /orgs/:orgSlug/agent-run-schedules/:id | Disable an existing schedule. |
All of these routes require actions:manage permission. Owner and admin roles
query org-wide data; member-level access is scoped to the current run-as user.
Troubleshooting
Start with the monitor before inspecting logs.
| Symptom | What to check |
|---|---|
| A schedule did not run | Confirm the schedule is enabled, has a future Next run, and Agent Run Automations are enabled for the org. |
| A run is stuck in running | Check heartbeat/lease fields and whether the worker recovered it as interrupted. |
| A provider event did not start a run | Check whether active work for the same context already deferred the trigger. |
| A follow-up did not happen | Open the Follow-ups tab and inspect status, scheduled time, last error, and stop conditions. |
| The agent wrote to an unexpected thread | Compare the run's context type/key and thread ID against previous runs for that context. |
Related
- Creating agents — configure agent capabilities and prompts.
- Tool approvals — control approval behavior for automated action tools.
- Background tasks — understand durable worker-style execution for longer-running tool work.