feat(automations): propose an Automation from chat - #3552
Merged
Conversation
Asked for recurring work, the in-app agent had no idea Automations exist: it read the workspace, found leftover shell scripts, and started writing a launchd plist. Nothing told it the product has a scheduler. Three layers, following the shape closed PR #3236 used for Scheduled Tasks: - Knowledge: an Automations section in the capabilities prompt. It names the feature, forbids scheduling OpenWork work through cron/launchd/systemd/ Task Scheduler, gives the exact once/daily/weekly shapes, and states the two honesty constraints — proposing is not creating, and an occurrence is missed when no desktop runner is connected. - Affordance: an `automations` contribution exposing `automation.propose`. It validates against the shared contract and returns the proposal. It does no I/O at all: Automations are active the moment they exist and the Den credential lives in the renderer, so an agent can describe one but only a person can create one. - Card: the proposal renders in the thread with its schedule and instructions behind a Create button that uses the renderer's own Den session, and explains itself when the preview flag is off or Cloud is signed out. `scheduleLabel`/`formatTime` move from the Automations page into automation-format so the card and the page label schedules identically. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Warden security clearance: clear. No new security issues found in this diff (477ff9b821cb44f2572cf81e525d16771445cd79). Automated clearance satisfies the required-review gate only — a human still reviews and merges. Analysis run
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Asked to "create a test automation that prints hello every 5 minutes," the in-app agent had no idea Automations exist. It read the workspace, found leftover shell scripts, said "I see the existing pattern — they use
launchdplists", and started writing one. Nothing in the product told it there is a scheduler, so it improvised an OS-level cron the user cannot see or manage from the app.This teaches the agent the feature and gives it a safe way to hand one over.
What changed
Three layers, following the shape closed PR #3236 used for Scheduled Tasks:
Knowledge — an
## Automationssection in the capabilities prompt: what Automations are, that recurring work goes throughopenwork_executeidautomation.propose, and an explicit prohibition on scheduling OpenWork work with cron, launchd, systemd, or Task Scheduler. It carries the exactonce/daily/weeklyshapes (hours 0-23, minutes 0-59, weekdays 0=Sunday), says there is no interval schedule and to offer the closest supported cadence plus Run now instead, and states the two honesty constraints: proposing is not creating, and an occurrence is durably missed when no desktop runner is connected.Affordance — a new
automationsfeature contribution exposingautomation.propose. It validates arguments against the shared contract and returns the proposal. It does no I/O at all — no Den call, no local server call,{ data: "none", ui: "none", external: false }. Automations are active from the moment they exist and the Den credential lives in the renderer, so an agent can describe an Automation but only a person can create one. A test asserts zero requests reach the fake backend.Card — the proposal renders in the thread with its schedule and instructions behind a Create Automation button that uses the renderer's own Den session and active org, then links to the Automations view. It explains itself when the preview flag is off or Cloud is signed out rather than failing on click.
scheduleLabel/formatTimemove out ofautomations-page.tsxintoautomation-format.tsso the card and the page label schedules identically.Trying it
With the Automations preview on and Cloud signed in, ask a thread for something recurring — "check my Slack every morning and summarize the last message." The agent proposes; you create.
Asking for "every 5 minutes" now gets an honest answer about intervals instead of a launchd plist.
Checks
Run on
477ff9b82:pnpm --filter @openwork/app typecheck— passedpnpm --dir apps/server typecheck— passedmessage-list-loadingfailures that reproduce identically on unmodifieddev(645 tests, same 2 failures) and only under full-suite--isolate. Not introduced here, and not claimed as passing.No dependency changes, so
pnpm-lock.yamlis untouched.Notes for review
automation.proposeby parsing theopenwork_executeresult rather than adding a dedicated tool, so no new tool surface appears in the model's tool list.🤖 Generated with Claude Code