Building With an Agent, the CLI or the API

Everything the builder does is also an operation your agent, the CLI and the API can call, in the same words. The one thing none of them can do is decide for you: approving a grant, deciding an approval, going back to an earlier version and running a run again are a person's, made in the app.

Ask your agent to build one#

The in-app agent and any MCP client connected to your workspace (Claude, Cursor and the rest) have the automation tools. Describe what you want:

Build an automation that, when any bank needs signing in again, adds a row to my "Reauth log" table with the bank's id and the time. Dry-run it and show me each step's status.

The agent searches the step catalogue (search_automation_nodes), reads the chosen steps' settings (describe_automation_nodes), makes a draft (create_automation, or installs one of BankSync's templates with installs_plan and installs_create), edits it (edit_automation), checks it (validate_automation), rehearses it (dry_run_automation) and publishes it (publish_automation). Then it hands back to you: open the automation, read its grant, approve it, turn it on.

An agent may publish a change to an automation that is on; the new version waits until you approve its grant, and the one that runs keeps running. What an agent reads from a run's output is marked untrusted, so an agent never follows instructions it finds in your data.

Tool by tool, with what each takes: Automations with an agent.

Keep automations as files with the CLI#

banksync automations export writes an automation as a portable file — its steps, layout and sample data, with no ids of your workspace, no config values and no secrets — and banksync automations import brings one back as a draft, in the same workspace or another. Keep the file in a repository and the automation is reviewable like code. import also reads an n8n workflow or an Activepieces flow and prints what did not carry across.

The CLI creates, edits, validates, publishes, binds, configures, turns on, runs and dry-runs automations, lists runs and reads what they produced, and works in CI with an API key. Command by command: Automations from the CLI.

Drive them from your own code#

The API serves the same operations over /v1/automations, /v1/automation-runs, /v1/automation-grants, /v1/automation-approvals and /v1/automation-nodes (templates install through /v1/installs), with the permissions automations:read, automations:write and automation_outputs:read. A draft is edited by commands under the version you read, publishing refuses a draft with blocking findings, and every refusal carries a stable code. Endpoint by endpoint, with the error table: Automations over the API.

What a person does#

A key or an agent that reaches one of these is refused, and can instead read the grant, approval or run and point you at it.