---
title: Automation Builder
---

# Automation Builder

## What it is

The **Automation Builder** (called **"Automation Helper"** until 2026-08-10) is an in-app
assistant that helps a non-programmer turn an idea into a real, working, scheduled automation
— without writing any code themselves. It **builds** automations for you; **managing** the ones
you already have lives in the separate **My Automations** panel. It is the sibling of
[Ask Omniscio](ask-amc.md): where Ask Omniscio _explains_ the app, the Automation Builder
_builds things for you_.

> **Status:** on by default. Gated by the `automationHelperEnabled` setting
> (default **on**; existing installs are flipped on once by a one-shot migration,
> then your choice is respected). Its sidebar row is named **Automation Builder** and lives
> in the **Automation** group; turn it off in **Settings → Features** to hide it.

### What it does

When you open it, you land on a **calm, create-focused** page built around one question —
**"What should I automate?"** A **composer** leads: type what you want in plain words and press
**Build** (or Enter) and it **spawns a builder session right there**, warm with your description
(a few example prompts sit under it to spark ideas). Below that is a small **list of ready-made
templates** and a link across to **My Automations** to manage what you've already built. You
either **describe your own** or **pick a template** — which sets that automation up for you,
asking only for the few specifics it needs. Either way it then:

1. **Confirms the details** in chat — when it should run, what it needs, what
   success looks like — translating plain English into a schedule for you. (A
   ready-made template front-loads most of this, so the chat is a quick
   confirmation rather than a cold interview.)
2. **Builds it** — creates a folder for the automation under your automations
   base directory, writes the code + a README, and (best-effort) creates a
   **private GitHub repo** for it.
3. **Proves it works — and won't stop until it does.** Rather than a single
   "does it run?" check, the Helper **red-teams** what it built: it dispatches a
   few throwaway helper agents that each try to break it (an empty week, the
   website being down, bad data, and more), fixes every problem they find, and
   loops until a full round comes back clean. As a final check, a fresh reviewer
   that did **not** build it reads the whole automation end-to-end before it's
   handed over — the guard against "it passed my own tests" — and only then does
   it tell you it's working. To keep the test honest it _will_ run safe, undoable actions for real
   (writing a file, publishing a page to your own Shares); anything it can't take
   back — a real email or message to someone, a charge, a public post — it takes
   right up to the last step and shows you the draft instead, so nothing
   irreversible happens without your approval.
4. **Registers it** — schedules it on Omniscio's cron engine and adds it to a
   **"My Automations"** group in the left sidebar as its own project.

The automation lands as a **pending approval** in your inbox — nothing runs on a
schedule until you approve it. **When you approve a script automation, Omniscio runs it
once right then — a real "proving run" — so its very first run happens while it's being
watched:** if it works, the schedule goes live already proven; if it fails, the schedule
is paused and the automation is handed straight back to the Helper to fix, instead of
failing silently at its first scheduled time.

**Every automation clears the same bar.** Before it can be registered, an automation
has to pass an eleven-point **great-automation checklist** — it handles a quiet day
gracefully, fails safely (recovers from a passing blip, and when it gathers from several
sources, one failing still delivers the rest with a note about what was skipped), keeps
secrets out of the code, stays a single bounded run, treats anything it reads online as
information (never instructions), actually hits the success signal you agreed on, ships
with a plain-English runbook, leaves anything irreversible for your approval, delivers
**readable** output — a plain-English summary line and a clear, dated title, never
something blank or broken — is **safe to run twice** (a repeat run never double-sends or
double-charges), and **keeps a run log** so a later fix can see what happened. This isn't
just a promise in the Helper's instructions:
Omniscio **won't let it register** an automation without submitting its proof — what it
ran, how it tried to break it, and that checklist — so "I proved it works" is something
it has to **show**, not just say. The **approval card** puts this in front of you before
you switch the automation on: the **next few times it will run** (with a plain heads-up if
the cadence looks unusually frequent, or costly for a session automation) and the **proof
it was tested** — the red-team rounds it survived and how many quality checks it passed.

**You can watch it build.** While the Helper is working, a **"Builds in progress"**
strip appears at the top of the Automation Helper page (and in **My Automations**),
with a row per in-flight build: which step it's on ("Understanding what you want",
"Proving it works", …), whether it's **waiting on you** for an answer, and its running
verification checklist. Click a row to jump straight into that build's chat. A build
whose chat was closed before it finished shows as **stalled**, so you can re-open and
continue it — nothing is lost.

Throughout, the Helper is built to **do the work for you**. It assumes you're not
technical and drives the whole setup itself — researching online, writing the
code, wiring things up, testing — so you only ever answer a couple of plain
questions and approve the result, rather than following technical steps. When the
**browser tool** is switched on (it's **off by default** — enable it in Settings),
it can go further and carry out web tasks in a real browser on your behalf: opening
sites, signing in with logins you've saved, filling out and submitting forms. It
stays off until you turn it on — the Helper never flips it silently — but it will
**proactively offer** to switch it on the moment a browser would help, so you're not
left wondering. And the safety line always holds — anything it can't undo, or that
reaches the outside world, it takes right up to the last step and waits for your
approval.

### Ready-made automations (presets)

Below the composer, the landing offers a small **list of ready-made templates** — curated
automations you can set up in a couple of clicks instead of describing one from scratch. Picking
one starts a Helper session that's already loaded with that automation's full build recipe, so it
skips the cold interview and asks only for the specifics it needs (e.g. your city). The composer
**leads** the page — the freeform path is the hero. Once a conversation starts, the landing steps
aside and the normal Helper chat takes over.

**More ready-made templates.** Beyond the flagship and **GitHub Trending Repos**, four zero-setup
templates deliver straight to your Omniscio inbox: **Morning Brief** (a short brief of the
headlines that matter to you, each morning), **Page Watch** (tells you the moment a web page you
care about changes — and what changed), **Weather-aware Day Plan** (a quick morning heads-up on
the weather and how to plan around it — no account, just your city, off the free Open-Meteo API),
and **Weekly Reading Digest** (a handful of genuinely interesting reads on your topics, once a
week). Each posts a card to your inbox and, like everything here, runs nothing until you approve it.

**The flagship preset.** The **Local Events Digest** is the flagship ready-made
automation — it leads the gallery, so a signed-in user with the Automation Helper on
finds it the moment they open the Helper from the sidebar. Like everything here,
nothing runs until you approve it.

## Where to find it

### Describe your own (the composer)

The composer is the front door. Type what you want automated in a sentence — *"email me a weekly
summary of my competitors' pricing,"* *"alert me when this page changes,"* *"give me a morning
news brief"* — and press **Build** (or Enter). It **spawns a builder session immediately**, warm
with your description, so the Helper confirms the specifics with you in chat instead of
interviewing from scratch. A few **example prompts** sit under the composer; tapping one starts a
build from that idea, exactly like typing it.

However you start it — the composer, an example, or a template — the automation still lands as a
**pending approval** (nothing runs until you approve it), and the build runs on the model chosen
in the gallery's **Build with** picker.

Every preset that produces a **published visual digest** is held to one shared
**quality bar** so they all feel consistent and polished: a **deep-but-bounded**
run (it fans out a fixed handful of cheap, fast agents, one per source area, so a
run is rich without ever running away), the items **sorted into categories** with a
filter and a **Grid/List** toggle, a **real, unique photo for every item** (never a
stock photo, never the same image twice; a tasteful placeholder when a real one
can't be found, so nothing ever shows up broken), an **automated quality check that
must pass before it publishes**, and a publish to your Shares. The look is a
premium, **gender-neutral** dark design — a blue/cyan/teal gradient hero, a
headliner spotlight, a sticky category filter bar with live counts, a Grid/List
toggle, and glassy image cards — so every digest reads polished and universal to
any reader, never a stereotypically gendered palette.

Crucially, that **design is built by code, not written by the AI**. The builder
gathers the events and hands over just the **facts** (each event's name, date,
venue, link, photo); a hardened, tested **renderer** turns those facts into the
page. So the look can never drift build-to-build, and the page is guaranteed to
pass its own quality check every time — the AI can't accidentally ship a broken or
off-brand layout. Even so, the builder still **opens the finished page and confirms
it looks right** (on a phone-sized and a desktop-sized view) before publishing —
belt and suspenders.

The flagship preset is **Local Events Digest**: a weekly, **bounded** session
that starts with a **brief interview** — where you are and how far you'll travel,
who it's for (just you, family, date nights, friends), which kinds of events to
lean into, your budget, and how often you want it — then bakes your answers in so
every weekly run reflects them. It researches ~20 real local events near you (it
fans out a fixed handful of cheap, fast agents, one per source area, so a run
stays rich but predictable and never runs away), **sorts them into categories**
(Music & Concerts, Festivals & Markets, Food & Drink, Arts & Theater, Family &
Kids, Outdoors & Sports, Nightlife & Comedy, Community), gives **each event its
own real, unique photo** (never a stock image, never the same photo twice),
renders a polished standalone page you can filter and flip between grid and list,
**runs an automated quality check that has to pass before it publishes** (so a
broken or duplicate-image page never goes out), **publishes it to your Shares** (so
it opens on any device), and **emails you the link**. A quiet week renders a
friendly "nothing notable this week" rather than failing.

A second baked-in preset, **GitHub Trending Repos**, shows the _other_ delivery
style — straight to your **Omniscio inbox** instead of a published web page. Every
Sunday it scrapes GitHub's trending repositories, writes a short plain-English
pitch for each (translating anything foreign, skipping the unclear ones), and
posts the list to your inbox as a formatted card — a fresh card each week, no
email. Because it delivers to the inbox rather than Shares, it's a plain
(non-visual) preset: it skips the digest quality bar, and its build recipe
carries its own inbox-delivery instructions.

The preset catalog is a single baked-in source of truth, and so is the shared
quality bar (`PRESET_ARTIFACT_STANDARD`) — adding another preset is one data
entry: a **digest** preset inherits the whole standard automatically, while an
**inbox** preset like GitHub Trending Repos carries its own delivery recipe
instead — no new wiring either way.

### Choosing the engine & model

By default the Automation Builder builds your automations with your **normal
default model** (Claude). If you'd rather build one on a different **engine** or
model — say a faster, cheaper one for a quick build — pick it right on the
**Automation Builder page**: the **Build with** control tucked into the page header
(the same picker you see when starting a session). It offers the full set of
engines that can actually build an automation — Claude plus its cheaper,
Claude-powered siblings (DeepSeek, Kimi, GLM, MiniMax) — grouped by engine, so
choosing one of their models IS how you pick that engine. (If you haven't enabled
alternate engines in Settings, it simply shows Claude — the same as everywhere else
in the app.) Set it, then click an automation — a ready-made card or "describe your
own" — and that build runs on the chosen engine + model; leave it alone and it uses
your normal one. It's **per build**, so you can change it between clicks to build
different automations on different engines.

Only engines that can run a full build are listed — an engine that couldn't sustain
the Helper's multi-step "write code → test → register" flow is never offered, so you
can't pick one that would quietly fail.

## How it behaves

### Automations you've built (it keeps track)

The Helper remembers every automation it has set up for you. Once you've built at least one,
the create-focused landing shows an **"Automations you've built (N) →"** link that opens the
**My Automations** panel — the one place that lists every automation with its name, what it
does, when it runs, and its **live status** (live, waiting for approval, paused, or
needs-attention). The Builder page no longer repeats that list inline; **My Automations** is
the single home for reviewing and managing them. Before it builds something new (or fixes a
broken one), the Helper also consults the same record, so it knows what already exists, won't
create a duplicate, and can tell you in plain English everything you've got ("you now have 5
automations").

The list is **derived on demand** from the records each automation already keeps
(its `automation.json` + its cron job) — there is no second copy to drift, so it's
always accurate: delete an automation and it simply drops off. Live status comes
from the **cron job** (the manifest's own status isn't rewritten when you approve a
job in the inbox), and any automation whose files are missing or unreadable is
quietly skipped rather than shown as a broken row.

### The weekly report it sends you

Once a week the Helper sends you **one card in your inbox** about everything it
has built for you. It leads with the week itself — how many times your
automations ran and how many of those runs failed — and then lists every
automation under a **🟢 On** heading and a **⚪ Off** heading, each showing how
many it covers: the ones that are running, and the ones you've switched off.

Every automation that is on carries its own week, so you can see at a glance
which one is struggling: the ones with failed runs come first, with how many of
their runs failed, and the rest simply say "no failures". If anything failed, the
card's title says so; if nothing did, it tells you that instead. Anything waiting
on your approval gets its own **⚠️** section, and that section only appears when
something is actually waiting — there is no "0 need you" line.

It stays quiet when it has nothing to say: if every automation is switched off and
nothing is waiting on you, **no card is sent at all**. And if it cannot read a
week's runs, that automation shows **no numbers** rather than a zero — the card
never claims a clean week it couldn't actually see.

### When something breaks

A registered automation is **resilient by default**: a transient blip (a network
hiccup, a momentary API error) is **auto-retried** — a free script twice, a paid
session once — before anything surfaces to you.

If a run still fails, the failure shows up in your **inbox** with a one-click
**"send it back to the Helper to fix"** button. That opens a session right in the
automation's own repo, reads its `automation.json` manifest and recent error, and
repairs it.

**And if it keeps failing, Omniscio repairs it for you — no click needed.** After a few
scheduled runs fail in a row, the automation is handed to the Helper **automatically**:
the inbox card switches to **"repairing automatically"** and a repair session starts on
its own. First, though, Omniscio works out **what kind** of failure it is, because only a
genuine **code** problem is worth a repair: an expired login or API key gets a plain
**"reconnect"** prompt instead (a code fix can't log you back in), and a temporary
rate-limit or network blip is left to recover on its own — so a paid repair only fires for
the kind of failure it can actually fix. When one does fire it draws on that automation's
own small **daily repair budget**, so one stuck automation can never run up an unbounded
bill on repairs; it only fires after repeated failures, and never bursts many repairs at
once. And if an automation just **keeps failing** — repairs and all — Omniscio **pauses
it** with a clear "this keeps failing — needs you" card, so a broken automation stops
failing over and over instead of looping forever; it comes straight back the
moment you approve it again after a fix. The
repaired automation always comes back to your inbox as a **fresh approval** before it can
run again — self-repair never puts an automation live without your say-so. And for a
**script** automation Omniscio **re-tests the fix once before it asks you**, so the
approval lands with a green "already re-tested" result in hand; if that re-test fails it
quietly goes back to the Helper instead of asking you to approve a fix that still
doesn't work.

**When an automation goes _quiet_.** A script automation can keep "succeeding" while
its source quietly dries up — the same green status, but nothing actually produced.
Omniscio watches for that: it remembers what a **healthy** run of that automation looked
like (captured from its first real result), and if a script that used to produce results
runs **empty — or suddenly produces far less than it used to** — several times in a row,
it raises a one-click **"this automation has gone quiet — have the Helper check it"** card,
so a silently-broken automation can't just fade away unnoticed. It only fires after a
sustained streak, only for automations that _used_ to produce output, and stays lenient
about normal ups and downs — so a genuinely quiet week, or a slightly shorter result,
never nags you.

**Your weekly automation check‑in.** Once a week Omniscio drops a short **health summary**
in your inbox — how many of your automations are running fine, how many are paused or
waiting on you, and which (if any) need attention — so you get a proactive "all good" (or
"these two need you") without having to go looking. It costs nothing (no AI session runs to
produce it), and you can turn it off in settings.

### Spotting automations you could use

Omniscio also watches for work you keep doing **by hand** and offers to automate it. When it
notices you've started the same kind of digest-or-report session several times on a regular
rhythm — say a weekly roundup you keep asking for from scratch — it drops a single **"want me to
automate this?"** card in your inbox. Accepting it opens the Automation Builder already briefed on
the pattern, so it's a head start rather than a cold interview.

It's deliberately quiet and careful. It only speaks up when a pattern is genuinely strong — the
same ask several times, spread over several days, on a regular cadence, and still ongoing — it
waits until it has seen the pattern hold before saying anything, it shows at most one suggestion
every few days, and once you dismiss a suggestion it never brings that one back. The spotting is
**free**: it reads patterns already computed on your machine, never runs an AI session and never
sends anything anywhere — only *your* accepting a card ever starts a build. And it's private —
it works from the math of your session titles, never the actual words of what you asked, and it
ignores your existing automations' own runs so it never suggests automating something that's
already automated. (This is a newer capability still being rolled out, so it's off until it's
switched on.)

### How it works under the hood

- The Helper is a normal Claude session living in the `__automation_helper__`
  virtual project, with **full tools** (it writes code, and — since it is not one
  of the isolated Search/Ask sessions — gets the **Playwright browser MCP** when
  `playwrightMcpEnabled` is on, so it can drive a real browser) and a bootstrapped
  workdir holding its persona + build playbook (`resources/automation-helper-claude.md`).
  The persona (generic — it addresses "the user", never a hard-coded name) directs
  it to drive the whole build itself and act on the user's behalf, within the
  reversible-vs-irreversible safety boundary (locked by `persona-verification.test.ts`).
  The **per-build engine + model** picked on the gallery rides the launch onto the
  new session's `provider` + `model` rows (the normal per-session path resolves it —
  there's no Helper-specific model logic and no global model setting). The picker
  offers the full build-capable **"Claude Code" engine span** (Claude + the
  anthropic-compat vendors DeepSeek/Kimi/GLM/MiniMax, which run the same Claude
  binary), derived from the provider registry's `runtimeKind` so a non-Claude-binary
  engine that can't sustain a build never appears. A separate dev-only
  **company-API-account routing** toggle (`automationHelperUseCompanyApiKey`, see
  `automation-helper-account-plan.ts`) can fund the spawn with the built-in company
  key — gated to a native-Claude build so an anthropic-compat pick keeps its own
  vendor key. Neither ever restricts the Helper's tools or caps its budget.
- The **preset gallery** is the integration's `panelComponent` in the renderer's
  ui-registry, with `shouldYieldToSessionChat` so it shows only while no Helper
  session is active. On **mobile** the entry sets `mobilePrefersPanel`, so the gallery
  is the phone's landing surface (without it the mobile 'sessions' slot falls through
  to an empty session list — the gallery would be unreachable); `launch-preset.ts`
  then advances the phone to the session-detail slot after a launch so the build chat
  comes forward. The catalog itself is renderer-only (`presets.ts`, the single
  source of truth); clicking a card calls `launchSession(initialPrompt = the
  preset's kickoff brief)`, and the persona recognizes that brief by its
  `--- BEGIN/END SPECIFICATION ---` markers to skip the cold interview. A preset
  marked `producesArtifact` also gets the shared `PRESET_ARTIFACT_STANDARD`
  appended to its brief (between `--- BEGIN/END QUALITY STANDARD ---` markers) so
  its result meets the bar every digest aims for.
- The digest **design is deterministic code**, not prompt output. A pure
  `renderDigest(data)` (`src/shared/automation-helper/digest-render.ts`) turns
  validated event JSON (`DigestDataSchema` — 8 canonical categories, http(s)-only
  links) into the neutral page, and is exposed as `POST
  /automation-helper/render-digest` (the sibling of the `verify-digest` QA gate).
  The builder POSTs its curated **data** and gets back the HTML — it never
  hand-writes markup — so the page can't drift and always passes `verify-digest` by
  construction (the render/verify contract). Both the shipped preset and a personal
  recipe render through the one endpoint (contract I42).
- The **"describe your own" wizard** (`DescribeAutomationWizard`, built on the
  shared `Wizard` primitive) is renderer-only too. Its four steps collect a few
  plain-English answers; on finish `buildDescribedAutomationKickoffPrompt` composes
  them into a warm first message and `launchDescribedAutomation` launches like a
  preset (the brief rides `initialPrompt`, so the build spawns immediately on the
  chosen engine + model). The brief deliberately carries **no** preset markers, so it lands
  in the persona's normal warm-interview lane — no persona change. A failed launch
  keeps the wizard open (answers preserved). The "just start chatting instead" link
  falls back to a blank Helper session (`launchBlankAutomationHelper`).
- Each finished automation is recorded by an on-disk **`automation.json`**
  manifest plus a cron job (`cron_jobs`) and a sidebar project row under the
  "My Automations" **divider** — no new database table.
- Registration goes through `POST /automation-helper/register` on the CLI control
  server: it ensures the divider, creates/links the project, schedules the
  **pending-approval** cron job, and writes the manifest last as the commit
  marker (idempotent by repo path). If a record is already there but no longer
  parses, it **refuses** (`AUTOMATION_MANIFEST_UNREADABLE`, naming the file and
  the bad field) instead of reading it as a brand-new automation — a record that
  cannot be read is not the same thing as no record, and treating it as one
  scheduled a second cron job beside the live one. The mirror image is refused
  too: if a record's linked job has been **deleted** (from the Cron Jobs panel,
  or over `DELETE /cron/jobs/:id`) the register answers **409
  `AUTOMATION_CRON_JOB_MISSING`** naming the record and the dead id, and leaves
  the record untouched — reuse is only right while the job it reuses exists,
  and answering success there reported an automation as scheduled that nothing
  could ever run. Retiring a job is *not* this case: a retirement switches it
  off and leaves the row, so a retired automation still re-registers normally. The way out is to set that record's `cronJobId` to null and
  register again, which schedules a fresh job and keeps its history. Re-registering
  an automation that already has a job reuses that job and writes the new schedule,
  job config and name onto it, so the schedule that actually fires is always the one
  the manifest records. That write also re-asserts the job's **run mode** as
  recurring (the shape a fresh register creates): the update path re-checks the
  run mode against the row it found, so on a row someone had reshaped into a
  one-time job a schedule-only write would quietly keep the old fire instant.
- The "what I've built" list is **derived live** (no stored index): it enumerates
  the "My Automations" projects, reads each `automation.json`, and joins the cron
  job's live status. One shared derivation is exposed two ways —
  `GET /automation-helper/list` on the CLI server (for the spawned Helper process)
  and the `automation-helper:list` IPC channel (for the gallery section, since the
  renderer can't read the manifests itself). Both gated on `automationHelperEnabled`.
- **Live build progress + the verification gate** are the reliability spine. The Helper
  POSTs each phase to `POST /automation-helper/build-progress`; Omniscio stores it in a
  per-build file under `<userData>/automation-helper/builds/` (**no DB table**) and the
  **"Builds in progress"** view reads it via the `automation-helper:builds-list` IPC channel
  (refreshed by the coalesced `automation-helper:builds-changed` push, or `GET
  /automation-helper/builds` for a CLI inspector) — needs-you and stalled builds float to
  the top. The register call's input **requires** a `verification` object (proof + red-team
  summary + a checklist covering the eleven-point bar); the route rejects a missing or
  incomplete one, and the evidence is stored in the manifest. The **approval card** fetches
  that evidence on demand via the `automation-helper:verification-for-job` IPC (matched to the
  cron job by the manifest's `cronJobId`; gated + blocked from the mobile bridge since it reads
  a local file), and shows it beside a **schedule preview** — the next few run times + a cadence
  warning — computed renderer-side from the cron job; both degrade to nothing on missing data
  (`cron-approval-display-contract` I9). The bar itself is one source of truth (`quality-bar.ts`),
  woven into the persona and enforced at the register chokepoint; the persona also steers the
  build toward robustness by default — a final pre-flight review by a fresh reviewer, preferring
  a proven pattern over novel code, pinning dependency versions, and checkpointing a multi-step
  job so a retry resumes.
- **First-run reliability** is enforced end-to-end. At registration, Omniscio
  normalizes + validates the job so a mis-shaped one can't schedule and then die
  silently — a script's command shape is fixed up and its working directory anchored to
  its own folder, and an invalid schedule is rejected with a clear, actionable reason
  (`AUTOMATION_CONFIG_INVALID`). At approval, a **script** automation fires one real
  **proving-run** through the exact path a scheduled fire uses (`runJobNow`) — green arms
  the schedule, red parks it (`markJobCompleted`) and the shared failure path raises the
  fix-it card. At runtime, runs **auto-retry** a transient failure (script 2× / session 1×);
  after a few scheduled runs fail in a row the failure handler **classifies** the failure and
  **auto-fires** a Helper-in-fix-mode repair **only for a code/logic failure** — an auth failure
  routes to a reconnect-copy card and a rate-limit/network failure to a passive card, never a paid
  repair (`classifyAutomationFailure`, which defaults to logic so an ambiguous failure still
  repairs — I32). The auto-fire is bounded by a per-streak in-flight guard, a fleet cap, and a
  give-up ceiling; a reused re-register **re-pends the cron approval** (`resetJobApprovalToPending`
  via the register flow's `rependCronApproval` port), so a repaired automation can't fire until you
  re-approve it (I4/I32). Before that approval is nudged, a **script** fix runs one free
  **pre-approval proving-run** (`proveRepairBeforeApprovalCard`) — green nudges "ready to approve",
  red holds it and the fix-it card is the signal instead (I31). And a script that keeps succeeding
  with **empty output — or output that collapsed far below the healthy baseline captured in its
  manifest** — raises a sustain-gated, lenient "gone quiet" card (I33). A session automation is proven at **build** time instead — a scheduled
  session "succeeds" merely by launching, so a go-live proving-run wouldn't add real proof
  and could double a paid outward send.
- The base folder for automations is the `automationsFolder` setting (default
  `<defaultProjectsFolder or ~/Claude>/Automations`).
- **Proactive discovery** is a cost-free scanner (`automation-discovery-scanner-service.ts`, a leaf
  ~12h StartupTask) that reads the **pre-computed** session embeddings for recent **manual-origin**
  sessions (`getRecentManualSessionEmbeddings` — it excludes an automation's own runs), clusters them
  with a small pure core (`automation-discovery.ts`), and — only when a cluster is repeated,
  digest-shaped, on a regular cadence, and **sustained** across scans — raises ONE
  `automation-discovery:<signature>` card carrying the Builder project id + a generated
  name+cadence brief, seeding a Helper build through the existing "Start session" alert seam (no new
  handoff code). It clusters on the **vectors** and labels with session **names** only — never the
  raw ask text — and runs no inference/network/spawn in the tick, so detection is free; only
  accepting a card spawns. Sustain + never-re-pitch live in a `discovery-state.json` file (no DB
  table). Gated `in-development` (`automationDiscoveryEnabled`, default off; flips to on-by-default
  at release). See `automation-helper-contract.md` I40/I41.

### Cost & safety

Building an automation — and each run of a scheduled _agent-session_ automation —
spawns a real (paid) Claude session. Scheduled runs are **approval-gated**, so
nothing runs until you approve it. Secrets never go in a repo: the Helper stores
them in Omniscio's encrypted vault and the automation reads them at runtime.

**Operators:** a dev-only toggle — _"Automation Helper: use our API account"_
(Settings → Features, visible only in a development build) — runs the Helper's
builder session on the built-in company Anthropic key instead of the user's own
Claude account, so setting up automations never spends their quota. It applies to
the builder session only, is off by default, and silently falls back to the user's
account when no built-in key is configured.

## Related

- [Ask Omniscio](ask-amc.md) — the explain-the-app sibling.
- Contract: `.claude/memory/contracts/automation-helper-contract.md`.