Workflows & Automations — agent-first builder for OpenHuman (early design check)

[alediez2048]

Hey team — pointed here from Discord. I've been prototyping a Workflows/Automations feature on a fork; Phase 0 is complete locally and I want to surface the design before going deeper on Phase 1.

One-liner: a first-class Workflows surface where users describe an automation in chat and OpenHuman drafts, persists, and runs it against their connected accounts and memory.

Two examples that frame the product shape:

• "Every time I retweet something, draft a LinkedIn post in my voice and publish it."
• "Send a DM to every person who comments on my Instagram posts."

n8n / Zapier are the aha for users ("oh, automations") — but the product shape is agent-first, not canvas-first. The user never opens a graph editor; they describe what they want, OpenHuman drafts a workflow as a rich preview, the user clicks Save.

Why it fits OpenHuman: the primitives are already here — cron, webhooks, composio, channels, the agent, memory, approvals, the event bus. What's missing is the surface that lets a user name and manage a long-running automation as a first-class entity. Today every action is one-shot.

Status

Phase 0 — Connections Hub: complete on my fork (17 commits across P0-1 through P0-7).

• /connections route live; /skills redirects (P0-4).
• All six sections wired: Composio, Channels, Browser Accounts (webview), Built-in Integrations, MCP Servers, Generic HTTP.
• New connections:: Rust domain (connections_list RPC + aggregator) per the controller-registry pattern.
• Generic HTTP CRUD with security/secrets integration.
• Browser-accounts roster curated for the agent-first workflow use cases — dropped Gmail/GMessages/Zoom, added X / Instagram / Messenger.
• Capability catalog updated, E2E spec passing.

Phase 1 — Workflows engine: in progress. workflows:: domain skeleton + the propose-and-click contract for workflow_propose_create are next up.

Happy to do a short Loom or live screenshare of the Connections Hub + the chat-creation flow if useful — much faster than the text.

Sketch of the full plan

• Phase 0 — Connections Hub ✅ shipped locally. Partially addresses Add local-first connector mode for user-owned tool connections #1819 by surfacing local user-owned connections (browser accounts, MCP, Generic HTTP) as first-class.
• Phase 1 — Workflows engine: new workflows:: Rust domain, cron + manual triggers, agent_prompt node, separate workflows.db. Hero flow: chat → propose → preview component → user clicks Save. Seeded read-only template catalog (RU-1..RU-4).
• Phase 2 — Execution expansion: webhook / composio_event / channel_message triggers; http_request / tool_call / condition / delay nodes. External platforms (n8n, Zapier, IFTTT, Make) are just-another-connection via generic plumbing — no platform-specific code.
• Phase 3 — Visual canvas: deferred. Chat creation + chat editing cover the hero story.

Safety pattern (relevant to #1339)

The agent has no mutating tools. Only read tools (workflow_list, workflow_get, …) and propose tools (workflow_propose_create, …). Every propose tool returns a payload that the chat renders as an interactive <WorkflowProposalPreview> component; the user's click is what calls the actual workflows_create RPC. Silent agent-driven mutation is impossible at the type level. Documented in ADR-010 (button confirmation not text matching) and ADR-012 (UI direct mutations, no mutating agent tools).

Design tensions I'd love feedback on

1. Background execution. Since fix(core,cef): run core in-process and stop orphaning CEF helpers on Cmd+Q #1061 the core dies with the GUI, so scheduled workflows only fire while the app is open. Right move: (a) accept and document, (b) opt-in background daemon, or (c) revisit the in-process decision? I couldn't find this discussed post-sidecar-removal and it's the one design call I haven't been able to make confidently solo.
2. Approval model. ADR-012's "agent has no mutating tools" is how I'm aligning with Keep triggers read-only until users approve writes #1339 at creation time. For execution time — should runs also pause for per-action approval on writes (Slack post, email send, etc.) on top of the creation-time gate? Or does the creation-time gate plus user-explicit enable cover it?
3. Connections Hub vs. Add local-first connector mode for user-owned tool connections #1819. Phase 0 surfaces local user-owned connections (browser accounts, MCP servers, Generic HTTP) as first-class alongside Composio. Does this partially close Add local-first connector mode for user-owned tool connections #1819, or do you want a separate effort focused on the local-first credential model?
4. Naming. docs/agent-workflows/ already exists as a docs folder for contributor tooling (deep-work, agent-batch). Does "Workflows" read clearly as a user-facing product surface, or would you prefer a different label (Automations, Routines, Plays)?

What I have in the fork

Full PRD + 20 ADRs + ticket primers for Phase 0 (done) and Phase 1 (drafted) are checked in at Automations/. If the direction is aligned, I plan ~5-7 small PRs for Phase 0 upstreaming and ~8-12 for Phase 1, coverage gate respected throughout.

Even "we'd prefer a different shape" is much cheaper to hear now than after another four PRs. Thanks 🙏

— Ale (@alediez2048)