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: 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 — the explain-the-app sibling.
• Contract: .claude/memory/contracts/automation-helper-contract.md.