Workflows

No flowcharts.

When the work should keep happening — every morning, on a schedule, or whenever you press Run — Access writes it as code. You can read it, rerun it, and trust it. Visual builders are fiddly. A node canvas that breaks when someone moves a box is not how this workspace does recurring work.

You still just ask. The agent writes TypeScript.

How to create a workflow

Press + Workflow. Chat starts a thread and writes the steps with you. You can also just ask:

Every weekday at 9, query Postgres for failed jobs and post a Slack summary.

After I run it, call Kubernetes and write a status file the next run can read.

To change a workflow that’s already saved, open it and ask Chat to edit it — or ask from any thread by mentioning the workflow.

You can also link a folder on the Workflows page and deploy from there.

💡 Tip: Workflows can start on a schedule, from Chat, or when you press Run. They can’t yet start from a GitHub label or an incoming webhook.

How a run works

1. Access loads the saved version of the workflow.
2. It runs in a locked-down environment — no leftover files or network from your laptop.
3. Each call to a connection, file, or agent is recorded on the timeline.
4. The run finishes, fails, times out (15 minutes by default), or pauses for your approval.

If a step needs you (a write you’ve asked Access to check first), the run moves to Waiting on approval. The timeline shows what’s pending.

1. Approve or deny that step.
2. Continue the workflow.

Finished steps are reused so they don’t run twice. Deny fails that step.

There isn’t a “sleep until later” pause or a public link to resume a run. Approval is the pause that exists today.

What the agent writes

This is the kind of file Chat produces when you describe the job. You don’t have to write it yourself — but you can read every line.

export const workflow = {
  name: "failed-jobs-digest",
  description: "Weekday digest of failed jobs.",
  schedule: "0 9 * * 1-5",
  resources: ["prod-pg", "ops-slack"],
};

export default async function run({ event, client, files, agents, run }) {
  const pg = client.postgres("prod-pg");
  const slack = client.slack("ops-slack");

  run.progress("querying failed jobs");
  const result = await pg.exec(
    ["psql", "-c", "select count(*) from jobs where status = 'failed'"],
    { key: "count-failed" },
  );

  await slack.call(
    "chat.postMessage",
    { text: `Failed jobs: ${JSON.stringify(result)}` },
    { key: "notify" },
  );
  return { ok: true };
}

List every connection the workflow may use. Deploy fails if a name isn’t connected yet — Access does not guess from the rest of the file.

Inside run, the workflow can:

• Read the input you passed, or see that a schedule started it
• Use a connection by the name you gave it
• Call secret("the-name") for a secret grant, then fetch — Access puts the real value only on requests to the hosts you listed
• Read and write files you allowed
• Ask a named agent for judgment
• Show a progress label on the timeline

Inspect and repair

Open the workflow → History. Each run has a timeline of logs, steps, and files it produced.

If a run failed, ask Chat:

Why did last night’s failed-jobs-digest run fail? Fix it and redeploy.

The agent reads the run, edits the steps, and saves a new version. Old runs stay attached to the version that produced them.

Next

Agents — teammates a workflow can ask. Resources — what it’s allowed to call.