Workflow Automation

Usejarvis includes a full workflow automation engine, think n8n or Zapier, but built into your AI daemon. Since 0.9 it runs on a vendored Activepieces engine executing in a sandboxed child process, with a visual canvas editor and natural language composition.

Overview

Workflows are event-driven automations: when X happens, do Y. A flow is a tree of steps built from pieces. You can build them three ways:

1. Chat: tell Usejarvis in conversation: “Create a workflow that checks my email every hour and sends a Telegram summary”. The manage_workflow tool composes the flow for you.
2. Visual canvas: the Workflows room in the dashboard.
3. API: create programmatically via REST endpoints.

Pieces

The unit of functionality is a piece. Two sources:

• Jarvis pieces (built in): agent, ask, context, notify, regex, test, tool, trigger, validate. These bridge flows into the agent itself: run an agent step inside a flow, send a notification through your channels, call an agent tool.
• Catalog pieces: a curated library of 650+ integrations (Slack, Gmail, Notion, GitHub, and so on) installable at runtime from the pieces library, marked verified or community. There is no arbitrary npm side-loading.

Step inputs reference earlier outputs with {{step.field}} template expressions, with a variable picker in the editor.

Chat-Driven Creation

The manage_workflow tool supports: compose (the primary create path: describe the flow, the LLM builds it), create (empty flow), list, get, run, enable, disable, publish, delete, list_runs, get_run.

Composed flows are created disabled; publish them to make triggers live. If a compose needs pieces you have not installed, it returns suggested installs instead of failing silently.

Triggers

Three kinds:

Kind	Behavior
schedule	Cron (5-field), plus an @every Ns extension for sub-minute intervals
webhook	HTTP endpoint at /api/webhooks/<flowId>
piece triggers	Managed by the piece itself (polling or events), enabled on publish

Execution Model

Runs execute inside a sandboxed child process with a warm pool, isolated from the daemon. Statuses: PENDING, RUNNING, SUCCEEDED, FAILED, PAUSED.

• Pause and resume: waitpoint steps checkpoint the run’s state to disk, so paused runs survive daemon restarts and resume via POST /api/webhooks/waitpoints/<id> (idempotent).
• Progress: the dashboard polls run state while a flow is running; each step’s output is captured for inspection and for the variable picker.
• Connections: credentials used by pieces are stored encrypted at rest (AES-256-GCM).

The engine is single-tenant and local-first by design: a SQLite-backed job queue on your machine, not a distributed cluster.

The Canvas Editor

Open a workflow in the Workflows room:

• Horizontal canvas of steps; right-click the canvas to add a piece, right-click a node for delete and error-handling options
• Loop and router branches render as indented sub-graphs
• Each step exposes its sample output, which powers {{step.field}} autocompletion
• Versions: flows are versioned, with a lock and publish cycle

API

Main routes under /api/workflows:

Route	Purpose
GET/POST /api/workflows	List, create
GET/PATCH/DELETE /api/workflows/:id	Read, update, delete
POST /api/workflows/:id/run	Run now (optionally a single step for testing)
GET /api/workflows/:id/runs	Run history
POST /api/workflows/:id/publish	Publish the current version
GET/POST /api/workflows/:id/versions	Version history
GET /api/workflows/pieces	Installed pieces
GET /api/workflows/pieces/library	Browse the catalog
POST /api/workflows/pieces/library/:id/install	Install a catalog piece
GET/POST /api/workflows/connections	Piece credentials
POST /api/webhooks/:flowId	Webhook trigger entry point

Good First Workflows

• Every weekday at 8:00, summarize unread email and send it to Telegram
• When a webhook fires from your CI, ask the agent to triage the failure and notify you
• Every hour, pull new items from a feed and file them into Notion