The Automation Detail Page

Every automation (a managed AI agent that runs on your behalf) has its own detail page — the hub where you run it, monitor it, repair it, and jump to every related tool. Open it by clicking an automation card on the Automations tab of the Automations area.

Header and actions

The header shows the automation's name and description. If the automation is exposed to your external AI assistant (see Triggers: On-Demand and Scheduled), an Exposed to MCP harness badge appears. Any trigger type can be exposed — a scheduled or webhook automation invoked from the harness runs off-cadence as a manual run. A Staging copy badge appears next to the automation's name when you are looking at a staging copy rather than a production automation (a fresh copy is never exposed to your assistant).

Run now / Run with message

1. Click Run now to start a run with no extra input, or click Run with message…, type an instruction (for example, "Summarize last night's P1 tickets and draft an email to the on-call lead"), and click Run.
2. The message you type becomes the first user message of the run's AI session. If you leave it empty, the automation falls back to its configured default context (on-demand automations only).
3. As soon as the run is accepted you are taken to the run detail page, where you can watch the live stream and interrupt the run if needed.

Both run buttons are disabled — with a tooltip explaining why — whenever the platform would refuse the run anyway: consent has not been accepted, the automation is inactive, its remote resources are orphaned, or its remote (Anthropic-side) resources are not fully provisioned (provisioning still in progress or failed).

Archiving an automation

If you only want it to stop running, do not archive it. Turn off the Active switch in the builder's Guardrails & Deploy section and save. An inactive automation runs nothing — no schedule, no webhook, no manual launch — and you can turn it back on whenever you want. Archiving is the one-way action: it tears down the live remote resources and there is no self-service way back. See Turning an automation off and on.

1. Click Archive. The confirmation explains that StackJack removes the live Anthropic resources, revokes the MCP client, stops scheduled jobs, and hides the automation from active lists. It also says: "This also deletes the transcripts of its runs, from StackJack and from our AI provider."
2. Confirm to archive. On success you return to the automations list. There is no tenant self-service restore.
3. If remote cleanup only partially succeeds, the automation is not silently removed — it stays visible, marked as orphaned, with a banner explaining the state so you (or support) can finish the cleanup.

Archive is not a full data erasure. The local automation row, its run records, versions, audit history, knowledge rows and blobs, saved test scenarios, and other stored automation data remain retained. The transcripts of its runs are the exception: they are deleted from StackJack and from our AI provider, together with each run's input, final answer, tool inputs and recorded test data, as described in Deleting run transcripts. StackJack attempts to archive the associated memory store rather than hard-delete it. Erase the store first if you need it gone, from the Memory card described in Automation memory. Use the separate tenant data-deletion process when erasure is required.

Staging copies

A staging copy is an isolated clone of an automation, for trying configuration changes without touching the one that is live. Create one with Create staging copy; the copy gets its own detail page, marked with a Staging copy badge next to its name.

The copy is deliberately fenced from production activation and trigger wiring:

• Its schedule never fires. Staging copies are excluded from the background scheduler entirely — a copy of a scheduled automation will not run on its own, ever.
• It gets its own webhook secrets, MCP client, and knowledge sources.
• It starts inactive, in dry run, with no consent and no run-as binding, with exposure to your AI assistant, failure notifications and the support-ticket toggles switched off rather than inherited.
• It does inherit production's fixture-recording and concurrent-run settings, so check those two on the copy if they matter to your test. It does not inherit production's queued-run patience — a copy falls back to the platform default wait, so set it again on the copy if production uses a custom value.
• It does inherit production's outbound network access choice and host list, so the copy can reach what production reaches and a test is a like-for-like comparison. Changing it on the copy changes only the copy until you deploy. See Guardrails and Safety.
• It does inherit production's Run on choice and its Azure Foundry spend guard, so a test runs where production runs and stops where production would stop. If you switch the copy's Run on, it cannot be deployed until the copy and production run on the same engine again (see below). See Running on Your Azure Foundry.

This is not an isolated vendor sandbox. Tests can still read from your tenant's connected systems — and approving a paused destructive decision executes that call for real against them. A supervised test run is still a test run, but the approved call is not simulated; the automation's destructive-action acknowledgment is still required, and without it StackJack blocks the call even after you approve it. Denying it, or letting the deadline pass, leaves it unexecuted and recorded as “would have called.” See Run Detail.

A fresh copy is not provisioned yet. Use Re-sync agent on the copy's page to provision it. Provisioning makes it eligible to deploy; StackJack recommends testing it before deployment but does not require proof that a test run completed.

Each automation can have one staging copy at a time. While a copy exists, both pages carry a banner linking to the other one, and Create staging copy is disabled with a tooltip explaining why.

Deploying a staging copy to production

On the staging copy's page, Deploy staging to production copies the staged configuration over the production automation. The server-side transfer is:

• Transfers: description, system prompt, model, effort, trigger type and trigger configuration (including schedule, and any smart filter on a webhook trigger), tool policy and chains, pre-run and post-run tool steps (decision steps included), native tools, outbound network access, max runtime, max credits per run, max tool-result size, supervision setting, payload mode and sample payload, concurrent-run setting, and production approval policy. When both run on your Azure Foundry, the Foundry spend guard transfers too.
• Does not transfer: webhook URL and secrets, MCP client, run-as binding, activation state, MCP exposure, consent, knowledge sources, fixture-recording consent, the production requirement for passing checks, memory opt-in, failure-notification settings, support-ticket toggles, queued-run patience, or which engine the automation runs on (Run on).

Consequences worth knowing before you confirm:

• Run on must match. A deploy never changes which engine an automation runs on. If the copy and production run on different engines (for example, you switched the copy to your Azure Foundry to test it there), the deploy is refused and nothing changes. To move production, change its Run on first; it then needs a re-sync. To keep production where it is, switch the copy back, test it, and deploy.
• If the staged tool set adds destructive tools the production automation has not acknowledged, its destructive-action consent is cleared and has to be accepted again before it runs.
• Changing to a webhook trigger gives production its own webhook URL and secrets; it never adopts the staging copy's credentials. Changing to a scheduled trigger registers the production schedule after the deploy only while the production automation remains active. An inactive production automation stays unregistered until it is reactivated and reconciled.
• The production update records an immutable version snapshot, so the captured fields can be restored from Version history → Restore. Settings outside version snapshots still keep their current production values. The staging copy itself is kept after deploying.

The button stays disabled until the copy is provisioned. This readiness check does not prove that the copy has actually completed a test run.

Checks before a staging deploy

The detail page can show saved-run comparisons between the current version and its predecessor. It also has a per-automation fixture recording control. Recording is off by default and retains copies of real tool calls and vendor responses, so enable it only when that customer-data retention is acceptable. The setting is read when a run starts, so turning recording off does not stop a run already under way; it keeps recording until it pauses or ends. A run that pauses for approval stops recording, and an automation that allows concurrent runs normally records nothing. Recordings have no automatic expiry. Contact support to delete them. A staging copy does inherit this consent from production — check it on the copy if it matters to your test — but it is deliberately not carried back when a staging copy is deployed over production.

The current Portal is a read-only evaluation-results surface when check scenarios and runs already exist; it does not let a tenant create scenarios, launch checks, or delete scenarios/evaluation runs. An empty panel therefore means no comparison data is available; it is not evidence that the staged version passed.

Some production automations may already have a server-side require passing checks before deploy policy. That policy is not configurable in the current builder. It applies only when deploying a staging copy—not when saving, testing, or promoting an automation directly:

• With no active checks, the gate passes.
• Otherwise, the latest run of every active check must be Passed. A check that has not run, is still running, or did not pass blocks the deploy.
• The refusal panel lists the blocking checks. An authorized builder can choose Deploy anyway, optionally add a reason, and confirm. StackJack records the person, time, refusal report, and reason before applying the override; if that audit record cannot be written, the override is refused.

Version history shows these Deployed without passing checks decisions, including attempts where the authorized override was recorded but the deployment later failed.

Discarding a staging copy

Discard staging copy archives the copy and removes its live remote Anthropic agent/environment/vault, MCP resources, and schedule. The production automation is untouched, but the staging copy's local run/version/audit history, knowledge rows and blobs, past Anthropic session transcripts, and other stored automation data are retained; StackJack attempts to archive its memory store rather than hard-delete it. There is no tenant self-service restore.

Status banners

Depending on the automation's state, one or more banners appear under the header:

Configuration card

The Configuration card summarizes the automation's settings:

• Model — which Claude model the automation uses.
• Trigger — OnDemand, Scheduled, or Webhook.
• Status — Active or Inactive.
• Max runtime — the per-run wall-clock limit in seconds.
• Max credits/run — the per-run spending cap in credits.
• Dry run mode — whether read-only connector calls execute while write and destructive connector calls are simulated. The exception is a destructive call you approve yourself in a supervised test run, which executes for real.
• Consent — when autonomous operation was accepted (or "Not accepted").
• Sync status — Synced, or one of the drift states described above.

Scheduled automations show four extra rows:

• Cron — the stored cron expression (the schedule in standard 5-field cron syntax).
• Timezone — the timezone the schedule is evaluated in.
• Next run — the next computed fire time.
• Schedule registration — the authoritative answer to whether the schedule is actually registered with the background scheduler. It reads Registered, Not registered (a drift condition — use Re-register schedule), or (unknown) when the check could not be reached.

Run transcripts card

The Run transcripts card holds two things. Delete all transcripts deletes the transcripts of every finished run of this automation, after a count and a typed confirmation. The Delete transcripts automatically switch deletes each run's transcript once the run is over and its billing is final; it saves as soon as you flip it. Only owners and administrators see the button and can flip the switch; everyone else sees the switch read-only. See Deleting run transcripts.

Webhook panel (webhook automations only)

If the automation is webhook-triggered, the detail page adds a Webhook card with the webhook URL, signing secret, curl examples, and a rotate action, plus a Recent webhook receipts panel showing the last 20 delivery attempts. These are covered in full in Webhook Triggers.

System prompt

The full system prompt (the standing instructions the automation runs with) is displayed read-only at the bottom of the page. Use Edit or the Advanced Builder to change it.

If a run fails to start

When Run now is refused, the page shows a specific message with a support code and a Retry button:

Two refusals are not retryable whatever code is shown. Read the message body, not just the title: if it says your organization has run out of automation credits, or that your Agent Runner plan has ended and your own Anthropic key is no longer used for runs, the run was refused for that reason and retrying will not help. Both currently appear under the generic Run failed (SJ-RUN-SERVER-ERROR) heading even though neither is a server error. Fix the cause instead — see Credits and BYOK.

If the page itself fails to load, you will see a typed error instead: SJ-AGENT-FORBIDDEN (your tenant may not view this automation), SJ-AGENT-NOT-FOUND (it does not exist or was archived), SJ-AGENT-UNAVAILABLE (transient — retry), or SJ-AGENT-SERVER-ERROR (retry, then contact support with the code).