Skip to main content

System components

The thirteen step types describe what a step is. This page describes the components — the ready-made varieties of the "action" type that reach real systems.

You pick a component from the library and it arrives with the right form. You do not invent components: what is not in the catalogue does not exist for the flow.

What exists today​

ComponentWhat it doesNeeds a connection
Call an APIone HTTP callhttp (or a directly enabled address)
Query a databaseone SQL readpostgres
Write to a databaseinserts, updates or deletespostgres
Send email (SMTP)sends, with attachmentssmtp
Run over SSHruns a command on a registered machinessh
Upload/Download file (SFTP)transfers files over the SSH channelssh
Save/Fetch/List in storageS3-compatible storages3
Read CSV · Write CSVconverts between CSV and structured data—

All of them use Connections for server and credential. None accepts a password written inside the step.

Reading and writing a database are different components​

This is not a cosmetic split.

Query a database starts in a read-only transaction and refuses any statement that does not begin with SELECT or WITH. That is not a promise made by the form: it is the database itself.

Write to a database is the component that changes data — INSERT, UPDATE, UPSERT, DELETE. It exists separately, rather than as an option on the first one, for a concrete reason: if reading became writing by flipping a setting, it would be impossible to look at a definition and tell whether that step reads or alters the database. With two components, whoever reads the flow sees where it writes — and the Agent Space can enable one without enabling the other.

The step is atomic; the flow is not

The write runs inside a transaction: either every statement in that step counts, or none does.

That does not extend to the flow. If a later step fails, the committed write stays — Agents does not open a transaction across steps, because each one is executed, resumed and retried independently. Prefer putting the write after whatever can fail.

Files travel between steps​

The components that produce or consume files all speak the same shape:

{ name, mime, size, content_base64 }

That is why they chain without glue: Call an API → Write CSV → Upload file (SFTP) works because all three agree on what a file is. The same holds for attaching to an email or saving to storage.

The ceiling is 10 MB per file. Above that the path is storage: write it there and pass the reference along, not the bytes.

SSH and SFTP: the same connection​

Run over SSH and the SFTP steps use the same ssh connection — SFTP travels over the SSH channel.

The machine must be registered with its host key, and the executor requires exactly that key, of the same type. A different key ends the attempt. See Connections.

A private key written inside the step is refused. The credential comes from the vault, always.

Importing from an API you already have​

Two ways to avoid building the HTTP step by hand:

Import cURL — paste a curl command and Studio assembles the step: method, address, headers and body. If there is a credential in the command it does not become text in the flow: it is either stored as a secret or left out, with the field waiting for a connection.

Import OpenAPI — point at an OpenAPI 3.x document (file or URL), pick the operation, and the step is born configured. Reading by URL goes through the same network protection as normal calls: internal addresses, loopback and metadata are blocked.

The address must be enabled​

This holds for every component that reaches the network: the destination must be on the Agent Space's list. Publishing refuses what the policy does not allow, instead of leaving the discovery to the first execution.

Private, loopback, link-local and cloud-metadata addresses are always blocked — there is no exception configurable by whoever builds the flow. See Enabled resources.

Next steps​