AI-derived columns

An AI-derived column is an ordinary column whose value the platform fills in for you. You choose which columns it reads and write one instruction; every row gets a value, and a row whose source text changes gets a fresh one.

For example, a tickets table with a message column can have a category column with the instruction "billing, bug, or feature request". When a ticket is saved, its category is filled in shortly after — no code involved.

Set one up

1. Open the table in the console and click the gear on the column that should hold the answer.
2. Switch on Derive this column's value with AI.
3. Pick the columns it may read from, write the instruction, and optionally list the allowed labels so it can only answer with one of them.
4. Save.

The editor shows what 100,000 rows would cost on your organization's provider before you commit. If no AI provider is connected yet you can still set the column up. It starts filling in — existing rows included — once one is connected.

How it runs

• In the background, never while saving. A save is never slowed down or failed by the model. A background pass finds rows whose value is missing or out of date and labels them in batches.
• Once per row. After a row is labeled, questions about that column — "how many bug tickets this week?" — are ordinary database queries with no model call. That is what makes this cheap at scale.
• On your fast model. Labeling runs on the fast model of your organization's AI connection (Integrations → AI providers), not the model your arbiter uses. Leave it blank to follow the platform's low-cost choice. If the model you picked is retired, the column pauses until you choose another; it never switches models on its own.

Rules

• A person always wins. A value someone edits by hand is kept, however often the column is re-run. Editing one of its source columns releases it, because that is a request for a fresh read.
• Redacted columns cannot be read. Saving a configuration that reads one is refused: the model would either see [redacted] and produce nonsense, or your redacted data would be sent to a third party.
• A column cannot read itself.
• Agents do not switch this on. Arbiter and your agents can read derived values like any other column, but configuring enrichment — which spends money on every row — is left to a person in the console or a handler author.

From code

The same thing is available to handlers as sdk.ai.annotate, for a one-off labeling pass or one driven by your own schedule. See AI in handlers.