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, waiting for a provider event—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

Workflows begin in one of two ways:

• Events and webhooks. A connector normalizes the provider payload into a typed event such as github.issue.opened.
• Schedules. A workflow runs on an interval or at a specific time. If a scheduled run is still active, later ticks coalesce instead of creating a backlog.

There is no special “polling trigger.” A scheduled workflow can check for new work and exit early when it finds none.

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 so duplicates do not start duplicate runs.

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 draft can be simulated against a sample event without executing external 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. Failed triggers can be replayed against the original version or the currently published one.

The CLI and MCP interface are under active development. The engine and public API contract are being built in the open on GitHub.