The umpteenth time runs itself.

Describe a recurring job in plain language. A AI agent runs it in a fresh sandbox and learns until a script does the work for next to nothing.

Weekly stale PR reportevery Monday · 08:00
  1. #1Explore4m 12s$0.42
  2. #2Explore3m 40s$0.37
  3. #3Assisted1m 58s$0.19
  4. #4Assisted1m 05s$0.11
  5. #5Assisted52s$0.08
  6. #6Scripted3s$0.00
  7. #7Scripted3s$0.00
  8. #8Scripted2s$0.00
Cost per run$0.42 → $0.00
Time per run4m 12s → 2s
Graduatedrun 6

How it works

Three steps to the optimal job.

A job starts as an agent exploring. It ends as a script, with the agent on call. Every run in between makes the next one cheaper.

  1. Explore

    1Describe it

    Write the job like you would brief a colleague. A compile step turns it into a schedule, success criteria, outputs and the MCP servers it needs, and you confirm before saving.

  2. Assisted

    2Run it in a sandbox

    Every run gets a fresh container with resource limits, no capabilities by default and a network policy. The agent works with shell tools and your MCP servers, and every step is recorded with its cost.

  3. Scripted

    3Let it learn

    After a run, reflection writes down what the job learned: notes, tested scripts, installs moved into its Dockerfile. Three identical runs in a row and it graduates to a script that runs without the agent.

Use cases

The legwork, done before anyone looks.

An alert, a release or the clock starts the job. The agent gathers the context from your tools and puts its findings where you look first.

Webhook · On alert

Checkout alert triageSucceeded
Webhook{"alertname": "HighErrorRate", "service": "checkout"}
  1. loki__query_range{app="checkout"} |= "error"1,284 lines+3s
  2. bashgit log --since="3 hours ago" --oneline2 commits+9s
  3. read_filerunbooks/checkout.md86 lines+14s
  4. loki__query_range{app="checkout"} |= "too many connections"94% of errors+26s
  5. oncall__add_noteHighErrorRateadded+50s

Note on the alert

HighErrorRate · checkout

Errors started at 02:51, four minutes after the deploy of #1432, which lowered the database pool to 10.

94% of them are pq: too many connections. Rolling back #1432 or raising the pool size clears them.

Webhook · On release

Docs syncSucceeded
Webhook{"tag": "v2.4.0"}
  1. bashgit log v2.3.0..v2.4.0 --oneline41 commits+2s
  2. bashgrep -rln "SESSION_TTL" docs/2 pages+11s
  3. edit_filedocs/configuration.md+4 −3+34s
  4. edit_filedocs/upgrading.md+12+47s
  5. github__create_pull_requestacme/web#1455+1m 03s

Pull request

Update the docs for v2.4.0

acme/web #1455 · 2 files changed

docs/configuration.md

Set `SESSION_TTL` to the session length in hours.

Set `session.ttl` to a duration, such as `12h`.

Schedule · Every hour

Security report checkSucceeded
Schedule0 * * * *
  1. github__list_security_advisoriesstate=triage1 new report+2s
  2. read_filereport.md2,113 words+4s
  3. bashgit log -S parse_header_ex --onelineno commits+9s
  4. bashgcc poc.c -lparse -o pocundefined reference+17s
  5. slack__post_message__af19bffb014a49a522f6#securitysent+38s

Posted to #security

Heap overflow in parse_header_ex()

Reported as critical · 2,113 words

Not reproduced

  • parse_header_ex() appears nowhere in the code or its history.
  • The proof of concept fails to build against any release.

Schedule · Every night

Major upgradesSucceeded
Schedule0 2 * * *
  1. github__list_pull_requests__ad9447e31bdd1822b562author:app/dependabotvite 5 → 6+2s
  2. bashpnpm test12 failed+41s
  3. bashcurl -s https://vite.dev/guide/migration48 KB+44s
  4. edit_filevite.config.ts+6 −2+1m 18s
  5. bashpnpm test214 passed+2m 07s
  6. bashgit push2 commits+2m 12s

Pushed to the pull request

Bump vite from 5.4.11 to 6.0.3

acme/web #412 · open since March

  • a41c9e2Switch Sass to the modern compiler API
  • 7be03fdSet resolve.conditions for the Vite 6 defaults

214 tests passed

Schedule · Mondays at 8:00

Monday catch-upSucceeded
Schedule0 8 * * 1
  1. umpmcp call teams list_chats38 threads+1s
  2. umpmcp call outlook list_messages61 emails+2s
  3. umpmcp call github list_notifications24 notifications+3s
  4. umpllm --model utilitydigest+9s
  5. umpmcp call outlook send_mailsent+10s
  6. Verification passed3 of 3 checks+12s

Email to you

Your Monday catch-up

Waiting on you

  • TeamsPriya asked in #platform whether the Q3 migration can slip a week.
  • OutlookThe hosting contract needs your signature by Wednesday.
  • GitHubTwo review requests on acme/api, #881 and #884.

Decided while you were out

  • TeamsThe web team moved Thursday's release to Friday.

Named for the lazy developer's instinct. Do it by hand once and take notes. Script the boring parts the second time. Keep trimming until the job runs itself, and only get up when something breaks.

Umpteenth does the same on a schedule, with a receipt for every run, and it never forgets what it learned.

What you get

Everything a recurring job needs, none of the ceremony.

  • Plain-language jobs

    No workflow builder. The instruction is the job, and the compile step derives everything else for you to confirm.

  • Any trigger

    Cron schedules with time zones, authenticated webhooks, the API, or a manual run with input.

  • Isolated sandboxes

    A fresh Docker or Podman container per run, non-root with every capability dropped by default, and gVisor as a second kernel boundary if you want it.

  • Egress control

    On Docker, internet sandboxes cannot reach private networks, the Docker host or cloud metadata. Limit a job to a list of domains, or give it no network at all.

  • Per-job environments

    A job can carry its own Dockerfile. The image is built once and cached, so tools are not installed on every run.

  • MCP servers

    HTTP and stdio servers with a per-job tool allow-list. HTTP server credentials stay on the host, and stdio servers run as a separate user from the agent.

  • Any model

    The Anthropic API or any OpenAI-compatible endpoint: OpenAI, OpenRouter, Ollama, vLLM, LM Studio.

  • Cost control

    Per-run cost, turn and time limits, a daily spend cap for the workspace, and per-model pricing on every run.

  • Runs you can read

    A live timeline of model calls, tool calls and outputs for every run. Playbook changes are versions you can diff and roll back.

Give it the job you are tired of.

Describe it once. By the umpteenth time, it runs itself.