October 23, 2026: Field deactivation, analyses through the agent, and failure records

This update includes field deactivation with a dependency check and the management of fields and analyses through the AI agent. The account also records its own failures, and the limit of lists in filters considers the size of the values.

Deactivate and activate fields

The new Deactivate action, in the field’s menu, stops storing a field without deleting the values already stored. Activate resumes storing it. The two actions replace the Status setting. Deactivation is refused while any resource depends on the field, and the new Usages tab lists these resources.

For example, a coupon field the integration no longer sends can only be deactivated after the coupon metric stops using the field. See Deactivate a field.

Fields through the agent

The AI agent connected via MCP (Model Context Protocol) now creates, edits, deactivates and removes fields, with the same usage check as the panel. Before deactivating or removing a field, the agent can look up what depends on the field, without changing anything. Activation remains restricted to the panel.

Ask, for example: “On the store-us account, check what depends on the coupon field before deactivating it.” See Agents.

Analyses through the agent

With the agent, you create analyses and analysis drafts and add, change, reorder and remove cells in the conversation itself. A rule can be simulated with an analysis draft, which tests the new rule and the new analysis together before anything is published. Publishing remains restricted to the panel.

Ask, for example: “Create a draft of the payments analysis with a cell for declines per card in 1 hour, and simulate the payments rule with that draft.” See Agents.

Version comparison through the agent

The agent compares two versions of a rule, condition by condition, or of an analysis, cell by cell. The comparison is the same one the panel shows before publishing. For an analysis, the comparison indicates the changes that restart a cell’s window.

Ask, for example: “Compare the payments rule draft with the active version.” See Analysis versions.

Failure event type

Every account now has the _failure event type, which records what went wrong in the integration. Failures include requests rejected by the events API, rules that failed while processing an event, and monitors that did not run. You identify a failure by its record, not by missing data.

For example, select _failure in Explore, under the More menu, to find the requests rejected in the last hour. See Failure event type.

Lists in filters

The new limit of lists in filters considers the total size of the values, added up over every filter of the query, not the number of items. A filter over the limit is refused on saving. If a list grows later and exceeds the limit, Explore shows a warning in place of an incomplete result. The monitor, in that case, records the failure in _failure.

For example, a list of 2,000 emails takes up more space in the query than a list of 2,000 BINs. See Lists in filters.

Other improvements

  • Agents: a metric reading takes a past window, with a start and an end, up to 3 years wide. Ask, for example: “Compare the approval rate of March 2025 with that of March 2026.”
  • Agents: the detail of an event type reports the usages of each field. Before changing a field, the agent identifies the affected resources.
  • Agents: to preserve the panel’s query capacity, a user’s agent runs at most 2 operations at the same time. A third simultaneous call is refused, and the agent retries the call shortly after. See Usage limits.
  • Explore: a menu on each column header of the event table opens the field in the side panel (View field), copies the identifier (Copy ID) or hides the column (Hide column). For example, View field shows a field’s usages without leaving the query. See Table.
  • Fields: the Usages and Items tabs show the number of usages and of items next to the title. The count indicates whether a field is in use before the tab is opened.