Studio · Durable automation

Workflows

Workflows combine approved data reads, model synthesis, fixed context, human decisions, and exact external actions in a durable run that can pause, resume, retry, and preserve its history.

Automation with a narrow action surface. A workflow can read from a defined catalog of tools. It can write externally only through three typed actions, with a frozen preview and approval policy.

⌁ Durable runs

Definitions and in-flight state survive closing the Studio or app interruption.

◷ Three triggers

Run manually, on a minute interval, or for newly-arriving matching mail.

◇ Human gates

Pause at a decision step or before an exact external action.

≋ Verified history

Review outputs, attempts, approvals, and a hash-chained event record.

Open it from the Studio picker, say “open Workflows,” or type /workflows. A connection and its credentials must be ready before the corresponding read or action can succeed.

What it is#

A workflow is a named, enabled definition with a trigger and an ordered list of up to 24 steps. When a run starts, Zimac copies that definition into the run. Editing the workflow later does not rewrite an in-flight plan or its history.

Each step receives the original input and prior results. Templates such as {{input}}, {{last}}, and {{steps.step-id}} can carry those values into instructions, read arguments, or typed action payloads.

Start a workflow#

The editor includes starter definitions for an OpsGenie on-call pulse, Jira sprint health, AWS cost anomalies, a Chronosphere service-health snapshot, Kafka consumer health, and a blank workflow. Starter arguments are examples you can inspect and edit before saving.

A starter is not a guarantee that the integration is configured or that its sample query fits your environment. Review board names, IDs, thresholds, PromQL, accounts, and targets before the first run.

Triggers#

ManualRun from the Studio or from a workflow card. You can supply an input object for that run.

IntervalRun every 5 to 43,200 minutes. This is a minute interval, not a cron-expression scheduler or timezone calendar.

Incoming emailMatch new incoming mail by From, To/CC, Subject, Body, account, attachment presence, and unread status. Existing mailbox history and outgoing messages are ignored.

Email matches are case-insensitive and deduplicated. The normalized email text and attachment metadata become untrusted workflow input; HTML bodies and attachment contents are not automatically treated as instructions.

Step types#

Step	What it does	Boundary
Read data	Calls one tool from the Studio’s fixed read-only catalog.	No mutations; credentials and source availability still apply.
Synthesize	Makes one bounded model call over the instruction and fenced prior data.	Cannot publish or perform an external write.
Agent work session	Runs a tool-restricted Sage work step with reads, research, memory, and consults.	No interactive proposals or external publishing.
Decision gate	Durably pauses and asks you whether to continue.	One decision for that checkpoint; no standing approval.
External action	Renders one supported typed payload, freezes it, and stages it.	Hash-bound approval or a matching active grant is required.
Fixed context	Adds deterministic text to later steps.	No model call.

The read catalog is broad but finite. It includes selected operations for OpsGenie, Jira, AWS, Azure, Google Cloud, Chronosphere, Datadog, Kafka, Confluence, Drive, Slack DMs, Figma, Wiz, Vertex AI Search, and a small security-tool surface. The editor shows the authoritative list in your build.

External actions#

The current typed action registry contains exactly:

slack.send_message — send text to an exact Slack channel or DM ID;
jira.transition_issue — transition one exact Jira key with a transition ID; and
confluence.publish_page — publish Markdown to an exact Confluence space/title target.

A model step cannot smuggle a write through a read step. External changes are executed only by the typed action registry after validating and freezing the rendered fields.

Approvals#

Before a typed action, the run shows its exact preview and a hash of the frozen payload. Approve once applies only to that payload. Any changed field produces a different hash and requires a new decision.

From the Studio you may create a standing approval for the same workflow definition, step, action, and target scope. It activates only after the approved action succeeds, expires after 30 days or 100 uses, and is automatically invalidated by relevant workflow edits. You can revoke it at any time.

Standing does not mean broad. A Slack grant is bound to its channel; Jira is bound to the issue and transition; Confluence is bound to its publish scope. An action with an uncertain outcome cannot receive standing approval.

Runs, retries & history#

The run view shows status, current step, results, attempts, approval notes, and audit events. Ordinary read or model steps can retry up to the configured attempt count. A typed write is treated differently: if the app or connection fails after execution may have begun, the outcome is marked uncertain and the run stops for human review. It never silently replays the write.

Workflow mutations are atomic, runs resume from durable state, and events form a SHA-256 hash chain so ordering changes are detectable. History is bounded: the local store keeps the most recent runs rather than acting as an unlimited compliance archive.

What it does not do#

No arbitrary shell commands, code execution, connector tools, or free-form HTTP actions.
No general cron syntax, business-calendar scheduler, or “run at 9:00 every weekday” expression.
No model-authored external write outside the three typed actions.
No guarantee that a starter query, model summary, or integration result is correct.
No automatic retry of an action whose outcome may already have happened.