Add a saved agent to a table
Deploy a saved agent onto the table as a linked enrichment column: a parent agent column plus a child column per selected output, each named after its FIELD and folded into one group labelled with the agent's name. Created unrun; pass run_rows to run that many first rows straight away. Bounded batches only: no run-all.
Request
- Base URL: https://api.getoneprofile.ai (the document declares no server; this is the origin it was published from)
- URL: https://api.getoneprofile.ai/tables/{table_id}/columns/add-agent/
- Auth: one of:
- API key in header X-API-Key
- HTTP bearer
Path parameters
Request body
What to call the parent column; the agent's own name when omitted. Worth asking for: the name labels the fan-out group, it is the only column visible while that group is collapsed, and for a single-output agent it IS the answer column. It is also the only way to deploy one agent onto a table twice.
Which table column (id) feeds each agent input (by the input's id).
What to call each fanned-out child column, keyed by output field name. The setup dialog previews these names, so it sends every one it showed rather than only the edited ones. A preview is worth having only if it is what the table gets. A field with no entry keeps the derived name, and a name already taken falls back to the derived one rather than losing the column.
The output fields to fan out into their own columns.
Insert position; appended when omitted. Places the parent column, and its fanned-out children land immediately after it, so one position anchors the whole group where the author clicked.
Rows to run once the column exists, counted from the top of the table's own order. Omit to create it unrun, so the author can adjust the mapping before spending credits. Bounded deliberately: there is no 'run all' here at any value.
The saved agent to deploy.
Whether the deployed column folds the rest of the row in as context, decided HERE rather than inherited. Null keeps the agent's own stored answer, which is what a client that does not ask the question should get; the setup dialog always sends an explicit value, because whether a run reads the whole row is a per-table decision and the agent's flag was set somewhere else entirely. Stamped onto the column either way. Reading the agent's live value on every run would let a later edit silently change what a deployed column sends.
Response
Successful Response
Whether the AI assistant created this column through a workspace action. A fact about who made it, not a state: it stays true after a person edits the column.
Whether data changes recompute this column by themselves; explicit runs ignore it.
The type a user picks for a table column.
Ordered as the picker shows them, which is also the order the groups below run in: text-ish, then numeric, then choice, then structured.
Type of a property. Used while creating/updating/deleting properties.
Bumped on definition changes; cosmetic edits leave it untouched.
Direct chain inputs; empty for manual columns.
Author-written note on what the column holds; null when unset.
The column group this column belongs to, or null. Groups are user-managed entities delivered on the column list's groups; this field is the membership edge, and the members' order is simply the columns' position order.
Whether this member stays visible while its group is collapsed. Meaningful only while group_id is set. Every group keeps at least one output.
Kind of a table column.
MANUAL cells are user-editable; FORMULA cells are a pure computed chain over other columns; ENRICHMENT cells are produced by an external action (an AI model, a research agent) run once per row. Formula and enrichment cells are both computed (read-only in the grid) but only enrichment work leaves the process and costs credits.
SOURCE cells hold one imported record verbatim, written only by the table's import source. Like MANUAL it is an externally-written leaf rather than a computed node (it joins no run plan and derives from no other column), but unlike MANUAL nobody may edit or retype it: the whole point is that a refresh can overwrite it wholesale, and every get_path column promoted off it reads paths that only survive while its shape does.
EXPORT cells hold the RECEIPT of pushing the row to a connected destination (status, the destination record id, when it happened), never the row's own data. The mirror image of SOURCE: where a source column is an externally-written leaf, an export column is an externally-READ leaf. It joins the run plan like a computed column (its mappings are dependencies, so a changed input re-pushes) but nothing may depend on it in turn, nobody may edit it (a hand-edited receipt would silently pin the row out of future pushes), and re-running it means "push again", not "re-answer".
SEQUENCE cells hold a contact's live status in an email sequence, or the messages it sent them, written by the outreach send engine and nobody else: an externally-written leaf with no run plan, no dependencies, no user edits, no retyping. A status column, like EXPORT receipts, may not be referenced in a formula: the status only exists to be looked at, never derived from. A messages column may, the way a SOURCE record may: the engine requests a run of its dependents whenever it rewrites a cell. The columns are created by the sequence that targets the table, not from the add-column catalog.
The definition has changed since these cells were last computed, so they are stale. Set by a save made with suppress_run, cleared when the column next finishes a run.
Self re-run cadence in hours; 0 is off.
When set, run_condition is inherited from this column group and is rewritten whenever the group's changes. Set a run_condition on the column to override it, or clear the column's to inherit again.
When set, the column follows this saved view's filter as its run condition. The engine evaluates view membership at run time rather than reading run_condition. Editing the run condition directly detaches from the view.
Pre-run wait in seconds; 0 runs immediately.
Every filter operator this column admits, in display order. The server owns the list so a picker cannot offer a pairing the rows query will reject: value operators follow the storage slot, and a computed column additionally admits the execution-state family (has an error, has results, has not run, is stale, ...), which reads run metadata a manual column never writes.
Changes
No recorded changes to this operation across all 1 revision of this API.