agenthub · data.read
Data Read (SQL)
Run a read-only SELECT against a connected database and get rows back, with run values bound as named parameters.
Why the node earns its place
The deterministic way to read a table: pick a source the org connected, write a SELECT, get rows. Available in every palette, so a chat agent can look a caller up in the org's own database without dropping to a tool call.
Targeting is org-scoped and safe. The node names a source key, resolved under the caller's own access — a publisher cannot read another tenant's database by editing the canvas — and execution is hard-guarded: select only, a single statement, a row cap, a statement timeout, and a read-only connection.
How it works at run time
- 1Resolve the named source for this org.
- 2Bind every
:namein the SQL from the wired params, else from run context or saved variables — soWHERE phone = :phoneworks on a messaging surface with no wiring at all. - 3Execute read-only and return rows, count, and whether the result was truncated.
What you wire
Inputs
- paramsobject
Outputs
- okboolean
- dataobject
- errorobject
Configuration
| Key | Type | Default & options | What it does |
|---|---|---|---|
| source * | string | choices from distribution:data_sources | The connected data source to read from (its key, e.g. 'bni'). Connect databases in the Data surface. |
| sql * | string | — | A single read-only SELECT / WITH statement. Reference run values as :name (e.g. SELECT stage FROM members WHERE phone = :phone). Values are bound from the wired `params` input or run context. |
What usually goes wrong
Watch for this
Values are always bound, never formatted into the SQL string. Writing the value inline instead of as :name gives up the safety and the automatic context lookup at the same time.
Behaviour & provenance