Ai Keeper/Guides/Automation
← All workflows
Collection 07 · Work that runs itself

Automation

Turn a proven prompt or workspace into a scheduled job, cron rule, heartbeat, background task, multi-step flow, or signed webhook trigger with bounded retries.

7 workflowsBeginner-first

Find one workflow

Filter this collection by name, outcome, provider, engine, channel, mode, or command.

7 shown
Workflow 01

Create and test a scheduled task

Run a known-safe prompt or agent job at a chosen time.

Beginner10–20 minResult · A test run and next schedule succeed✓ Source-audited workflow
Automation > Flows showing four representative recurring jobs, schedule details, routes, and per-job controls.
The populated Jobs surface makes schedules and destinations easy to compare before you run, edit, inspect, or remove a job.
Before you start
  • A prompt/agent that already works manually.
  • A route expected to be available at run time.

  1. Open Automation > Flows, select Tasks, and create a task.

  2. Name the outcome, choose the route/agent, enter the exact prompt, and set a schedule.

  3. Set a reasonable output limit, timeout, retry count, and approval behavior. File writes, commands, browsers, channels, and external actions should remain approval-gated unless you have reviewed the full path.

  4. Click Test Job. Read the actual result, not only a green connectivity badge.

  5. Enable the task and confirm its next-run time and timezone.

You are done when
The test produces the intended deliverable, the task is enabled, and the displayed next run matches your local-time expectation.
If something looks wrong
Test says route unavailableVerify the selected instance with a normal Chat request; reasoning models may need enough output tokens for the probe.
Wrong timezoneCheck System language/region and the schedule's explicit timezone before enabling.
Workflow 02

Create a cron schedule

Use the Cron Editor for a precise recurring cadence and preview future run times.

Intermediate5–10 minResult · Cron expression matches intended dates✓ Source-audited workflow
Automation > Flows showing four jobs and the Jobs Surface toggle between Jobs and Cron Editor.
Use Jobs to review recurring work at a glance and switch to Cron Editor when you need visual control of the schedule.
Before you start
  • Know the desired local time and days.

  1. Open Automation > Flows and choose the Cron Editor.

  2. Build the expression with the form controls or enter it carefully. Prefer the visual controls if cron syntax is unfamiliar.

  3. Inspect the next several calculated run times, including weekday/weekend and daylight-saving boundaries.

  4. Attach the schedule to the intended job and save.

You are done when
At least the next three previewed times match the dates you would write down manually.
If something looks wrong
Every minute by accidentDo not save until the preview matches. A wildcard in the wrong field can create excessive work.
DST shiftUse an explicit timezone and inspect dates around the transition for time-critical work.
Workflow 03

Build a multi-step workflow

Chain prompts, agents, tools, and conditions into a repeatable flow.

Advanced20–45 minResult · A test follows the intended branches✓ Source-audited workflow
Automation Workflows showing a selected three-step Release Readiness Brief with execution mode, cost tier, prompts, ports, and outputs.
A populated workflow exposes the exact configuration to review before saving or running it.
Before you start
  • Each individual step works on its own.
  • A defined input and final output.

  1. In Automation > Flows, create a Workflow and name its final deliverable.

  2. Add the smallest ordered steps. Define the input, success output, failure behavior, and side effects for each.

  3. Add conditions only where a real decision exists. Keep the default path obvious.

  4. Set timeouts, cancellation, retry budget, and approvals per side-effecting step.

  5. Test with a harmless input that exercises the normal path, then another that exercises one failure/alternate path.

You are done when
Both tests end in the expected branch, with bounded retries and a clear final result or error.
If something looks wrong
Flow is hard to debugSplit by ownership or observable boundary, not into dozens of tiny opaque steps.
Retry repeats a side effectRequire idempotency for externally visible actions and preserve signed idempotency keys where supported.
Workflow 04

Create a bounded heartbeat

Wake an agent regularly to check state, while preventing an endless autonomous loop.

Intermediate10–20 minResult · Heartbeat runs and stops within limits✓ Source-audited workflow
Automation Flows navigation showing Heartbeat beside Jobs, Workflows, Approvals, and Background.
Heartbeat has its own surface because recurring agent turns need limits separate from normal jobs.
Before you start
  • A check that genuinely benefits from recurring model judgment.

  1. Open the Heartbeat area in Automation > Flows and create a heartbeat.

  2. Write a check-only prompt with an explicit no-change outcome, such as If there is nothing actionable, record no action and stop.

  3. Set interval, maximum iterations, timeout, and stop conditions. Never leave iterations unbounded.

  4. Keep side-effecting tools approval-gated and run one manual test.

  5. Enable it and inspect the first scheduled result.

You are done when
The heartbeat records a useful check, respects max iterations, and stops cleanly when there is nothing to do.
If something looks wrong
Heartbeat chats foreverSet max iterations and a positive stop condition. Recurrence and agent turns need separate bounds.
High token useUse a compact prompt and a small capable model for routine checks.
Workflow 05

Run and cancel a background task

Send longer work out of the foreground and verify cancellation leaves a clear terminal state.

Intermediate5–30 minResult · The task completes or cancels cleanly✓ Source-audited workflow
Automation Flows navigation showing the Background long-running-jobs surface.
Use Background for cancellable long-running work; use Jobs for scheduled recurrence.
Before you start
  • A long-running but interruptible job.

  1. Create a Background Task under Automation > Flows.

  2. Set its model/agent, prompt, maximum duration, and output destination.

  3. Start the task and confirm its status becomes running without blocking the whole app.

  4. For a test, cancel before completion. Inspect the final state and any partial output.

  5. Run again and allow a small task to complete.

You are done when
Cancellation does not leave the task stuck as running, and a normal run produces its final result.
If something looks wrong
External side effect already happenedCancellation cannot undo a completed send/write. Keep irreversible steps late and approval-gated.
Workflow 06

Create a signed webhook trigger

Let an external system start one automation through an authenticated, replay-resistant endpoint.

Advanced15–30 minResult · One signed test event starts one run✓ Source-audited workflow
Automation hub showing Webhooks as the inbound-endpoints destination beside Flows.
Open Webhooks from the top navigation and keep authentication enabled when adding a route.
Before you start
  • A trusted external sender that can sign requests.
  • A tested automation to trigger.

  1. Open Automation > Webhooks. Under Webhook Endpoints, note the Port — webhooks listen on their own port, not the proxy port — then add a route by filling Path and Label and confirming.

    Paths are entered under /webhook/, so a path of /webhook/deploy becomes the full route below.

  2. Generate/store its secret through the protected secret flow. Copy the full value with the button next to Token: — the row only displays the first 16 characters.

    Configure signature, timestamp/replay window, and idempotency requirements at the same time. Treat the token like a password.

  3. Send one harmless test payload. The app shows this exact command under Test with cURL with your real port and token filled in.

    curl -X POST http://localhost:YOUR-WEBHOOK-PORT/webhook/test \
  -H "Authorization: Bearer YOUR-WEBHOOK-TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"message": "Hello from webhook"}'
    shell

  4. Watch the received-payloads list on the same screen. It shows the response code for each delivery, and reads No payloads received yet until the first one lands.

    If nothing appears, the request never reached the app — check the port and that the route path matches exactly.

  5. Confirm authentication actually bites: send the same request with a wrong token and check that it is rejected rather than run.

    -i prints the status line. Never skip this — an endpoint that accepts anything is an open remote trigger.

    curl -i -X POST http://localhost:YOUR-WEBHOOK-PORT/webhook/test \
  -H "Authorization: Bearer definitely-not-the-token" \
  -H "Content-Type: application/json" \
  -d '{"message": "should be refused"}'
    shell

  6. Send the exact same idempotency key again and confirm it does not duplicate the action.

You are done when
A valid unique request starts exactly one run; invalid signature, stale timestamp, or duplicate idempotency key is rejected.
If something looks wrong
Unsigned webhook acceptedDisable the endpoint and fix authentication before using it with real actions.
Secret appears in payload logsRotate it and use the Secrets store/reference rather than embedding it in task text.
Workflow 07

Retry, recover, or export a failed automation

Diagnose trends, inspect encrypted dead letters, and resume only after the cause is fixed.

Advanced10–30 minResult · A failed item is recovered or documented✓ Source-audited workflow
Automation Jobs with Jobs, History, and Dead Letters available for reviewing outcomes.
Start with History and Dead Letters instead of immediately recreating a failed automation.
Before you start
  • A failed job, webhook delivery, or workflow item.

  1. Open the failed automation and read its summarized error, attempt count, and failure trend.

  2. Inspect the relevant System request/log entry to identify auth, routing, timeout, payload, or tool-policy cause.

  3. Fix the cause before retrying. For side effects, confirm the original action did not already complete.

  4. Open the dead-letter/recovery action, decrypt through the app's authorized flow, and retry or discard the exact item.

  5. Export the failure report when another operator needs evidence.

You are done when
The recovered item reaches success once, or the discarded item is terminal and the exported report explains why.
If something looks wrong
Blind retry duplicates workCheck idempotency and external state first.
Same error repeatsStop retrying and fix the underlying configuration; retry budgets are safety limits, not a repair strategy.

Keep going

← Agents and workspacesPrevious collectionExtensions, MCP, and channels →Next collection