feat(automations): model picker with thinking level, readable receipts, and agent management

[reachjalil]

Four enhancements to how a person — and the in-app agent — picks, reviews, and manages the model an Automation runs on.

#	Enhancement	Before	After
1	Readable model on the receipt	lpr_01kz6ecd25fevt4ywj49q9.../deepseek/deepseek-v4-flash, overflowing onto the next column	OpenWork Models · DeepSeek v4 Flash, wrapping inside its own cell
2	The real model picker in the editor	a bare <select>	the same ModelPickerModal used in chat — search, provider grouping, free/cloud badges
3	Thinking level on an Automation	not expressible at all	chosen in the picker, stored on the revision, applied to the scheduled run
4	The agent can manage Automations	it only knew how to propose one, and was told it "cannot create, activate, or run" any	it can check status, inspect runs, edit, pause, run, and cancel through the Cloud capabilities

---

1. Readable model on the receipt (the reported bug)

The Desktop execution card rendered the model as providerId/modelId straight from the record. For a Den provider that is lpr_01kz6ecd25fevt4ywj49q9... — one long unbroken string with nothing to wrap on — so it overflowed its grid cell and drew on top of the Next run column:

Model
lpr_01kz6ecd25fevt4ywj49q98/6/2026,10:50:00AMek-v4-flash

Two causes, both fixed:

• Identity → name. The card now shows the provider and model names the person actually picked, resolved through the same authorized-model list the editor uses.
• Overflow → wrap. Every cell in that grid gets min-w-0 + break-words, so no long value can overlap its neighbour again.

describeAutomationModel also keeps a revoked model inspectable: if the member loses access to it, the card falls back to the raw identity rather than rendering blank.

2. The real model picker in the editor

Configuring an Automation used a bare <select> with no reasoning control, while the same person picks a model in chat through the full picker. The editor now opens that same ModelPickerModal, fed by the models Den authorizes for that member — so the list stays exactly the set the server revalidates on save, but with the search, grouping, and affordances people already know.

To be clear about the scope: the old <select> already listed every authorized model. What was missing was the familiar control — and the reasoning levels it brings with it.

3. Thinking level, end to end

The contract had nowhere to put a reasoning level, so this is the enhancement with real plumbing behind it:

Layer	Change
Contract	optional variant on automationModelSchema — the same value the composer sends as its behavior pill
Persistence	nullable model_variant on automation_revision and automation_run (migration 0055: two additive ALTER TABLE ... ADD, nothing rewritten)
Dispatch	carried on the runner assignment
Execution	desktop runner → POST /workspace/:id/sessions → promptAsync

Two behaviours worth knowing:

• Switching model clears the variant. Reasoning levels are specific to a model; carrying high onto a model that has no such level would silently mean nothing.
• Levels come from the local runtime catalog, since the desktop is what executes the run. A model Den authorizes but the local runtime does not know still lists — just without levels, rather than disappearing.

4. The agent can manage Automations

Nine management operations have been MCP capabilities since #3466, but the agent's guidance never mentioned them — and flatly asserted it "cannot create, activate, or run an Automation." So asking a thread "what automations do I have?" gave it nothing to reach for, and asking it to change one told it it was powerless.

The guidance now names the capabilities and states the rule that actually matters:

• Read and edit existing Automations directly — listAutomations / getAutomation for what exists, listAutomationRuns / getAutomationRun for history and receipts, updateAutomation, activateAutomation / deactivateAutomation, runAutomationNow, cancelAutomationRun, archiveAutomation.
• Still prefer the proposal card for new ones, because an Automation is active the moment it exists and starts running work on the person's machine. createAutomation is used directly only when explicitly asked.
• Status comes from a capability call, never from memory — no invented next-run times or run outcomes.
• Deactivating ≠ cancelling a run already in flight.
• If OpenWork Cloud is not connected, say so rather than guessing.

Runner-credential minting stays blocked from the MCP catalog, as fixed in #3466.

---

Checks

Run on 5a535c2ef:

• pnpm --filter @openwork/app typecheck, pnpm --dir apps/server typecheck, pnpm --filter @openwork-ee/den-api typecheck:automations — passed
• All server OpenCode-plugin suites — 75 passed (includes the updated capabilities-knowledge assertions)
• Den runner protocol/auth/model-authority — 17 passed
• packages/automations — 10 passed
• Desktop runner (node --test electron/automation-runner.test.mjs) — passed
• App Automations model-options suite, including 2 new tests for the label fallback and for reasoning levels being offered on the selected model only — 5 passed
• Full app suite — 648 passed, 2 failed; both are the message-list-loading failures that reproduce identically on unmodified dev under full-suite --isolate and pass when that file runs alone. Not introduced here, not claimed as passing.

The previous commit was green across all 23 CI checks; this push adds the knowledge change and is re-running.

Migration 0055 was generated with db:generate, so the schema/migration sync check has its matching snapshot. No dependency changes, so pnpm-lock.yaml is untouched.

Not covered

I could not exercise the picker against a live Den org or run a scheduled occurrence end to end, so the reasoning level and the agent's capability calls are verified by types, unit tests, and reading the call path — not by a live run. Worth a manual pass: pick a model with reasoning levels, save, confirm the receipt shows provider · model · level, then ask a thread what Automations exist and to change one.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-app	Ready	Preview	Aug 5, 2026 9:30am
openwork-den	Ready	Preview	Aug 5, 2026 9:30am
openwork-den-worker-proxy	Ready	Preview	Aug 5, 2026 9:30am
openwork-landing	Ready	Preview, v0	Aug 5, 2026 9:30am

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
openwork-diagnostics	Skipped		Aug 5, 2026 9:30am

[diff-warden]

Warden security clearance: clear. No new security issues found in this diff (8c096baf9ea86e6b58b7b11fcbdb6a63421b5481). Automated clearance satisfies the required-review gate only — a human still reviews and merges. Analysis run

[diff-warden]

Warden security clearance: clear. No new security issues found in this diff (5a535c2ef660f7337ea1538bf2e04238cce1acf5). Automated clearance satisfies the required-review gate only — a human still reviews and merges. Analysis run