How it works

Workflows as code

A sync.cheap workflow is ordinary Python control flow running inside a constrained VM. Local variables, conditions, and loops execute inside the VM. Anything that reaches the outside world—reading a spreadsheet row, sending an email, or saving workflow state—is an explicit typed host call.

That split gives agents a flexible language without giving workflow code direct access to credentials or the network.

if trigger["data"]["amount"] > 500:
    await send_slack(
        f"Large order: ${trigger['data']['amount']}",
        connection="finance",
    )

Triggers

Published workflows currently begin with connector events and webhooks. A connector normalizes each provider payload into a typed event such as github.issue.opened, and exact resource-and-action selectors prevent unrelated deliveries from starting a run.

You can also invoke an enabled, published workflow manually for testing or operations. Manual invocation is a way to start a run, not a second persisted trigger. Scheduled triggers are planned, but they are not part of the initial release model yet.

Durable execution

Each external call is a checkpoint. A workflow can wait for up to a year without holding a process open, then resume from the same version of its code. Provider deliveries are assigned stable identities that the platform uses to deduplicate repeated deliveries.

Every workflow also has up to 1 MB of JSON state for cursors and small pieces of durable context. Concurrent event runs update that state with compare-and-set semantics instead of silently overwriting one another.

Drafts and publishing

Changes do not edit the running workflow in place.

1. Your agent submits a complete draft.
2. sync.cheap validates its trigger, action allowlist, connection aliases, and permissions.
3. The agent can run focused snippets in the same execution environment to inspect data and test individual actions.
4. You approve a specific numbered version for publication.

Exactly one version is published at a time. Existing runs stay pinned to the version they started with. Publishing an older version is a rollback.

Connections and credentials

Connectors declare typed inbound events and outbound actions. A workflow uses friendly aliases such as team or repo; the platform resolves those aliases to your connections at the host-call boundary.

Credentials never appear in workflow code. Publication fails if the selected connections do not have the permissions required by the workflow’s declared actions.

Observability

The operating surface is intended for people and agents. You can inspect run status, duration, logs, action inputs and outputs, and exact credit use. Replay and rerun controls are planned for a later release.

The CLI and MCP interfaces are under active development.