Base fields changed. Will the old agent task still work?

A field gains an option, changes type, or becomes a relation. A person may understand the new interface while a recurring agent still follows the old mapping. Some tasks fail loudly; others submit values whose business meaning is wrong.

Read the current Base schema, compare the task and its consumers, then validate read-only interpretation, a bounded change proposal, and the resulting business output.

A schema change has a different scope from a value edit

Editing a record value affects that data and its consumers. Changing a field’s type, options, or relation target can change how many tasks interpret records. Bases organize fields, records, and views; field types govern validation, rendering, and diffing.

Read display names, identifiers, types, options, and relation targets separately. A display-name change does not prove that a slug changed. Checking names alone can also miss structural or semantic changes. Diagnose the actual current schema before revising integrations.

Inventory real dependencies

List the fields read or written by the task: identifiers, types, required settings, options, cardinality, relation targets, and expected JSON shape. Locate those assumptions in Skills, task instructions, import scripts, API mappings, reports, and AirApps.

A suggested schema-review Base can track the change, affected resources, owner, dependency locations, read-only results, proposal link, and business acceptance. A Doc can hold reusable definitions. These records coordinate work; they do not automatically discover dependencies or migrate code. Reuse an existing change-management record when sufficient.

Validate interpretation before writing

Ask the connected agent: “Read the current Base schema and this task’s old instructions. List mismatched fields, types, options, and relations. Read existing records and explain how they map to the intended output. Report unknown states and missing fields separately. Do not write yet.”

Select records that cover actual branches, including missing values, multiple relations, and new options. Check preserved meaning, not merely successful retrieval. Revise mappings that silently treat unknown states as an old default.

Parsable JSON is only one layer

Field Types requires JSON and YAML fields to parse before submission or merge. This catches syntax errors. It does not establish that keys match a downstream contract, units are correct, evidence is reliable, or a relation points to the right business object.

Check three layers: parsing, current field mapping, and business rules. Valid JSON can omit a required consumer key. A valid select value can still be misinterpreted by old instructions. Put structural requirements and business decisions in the appropriate scripts, Skills, and acceptance checks.

Try a bounded proposal and inspect consumers

After updating mappings and reusable instructions, propose a ChangeRequest for a small, explicitly authorized set of real records. Show current values, replacements, reasons, and preserved fields. Do not turn compatibility repair into an unrelated table rewrite.

After merge, read canonical records, then inspect dependent reports, exports, and applications. Record outcomes and remaining work for each consumer. Recheck older pending proposals against today’s schema. Production schema and code changes still require their own applicable permissions and authorization.

Resume against an explicit accepted contract

Resume gradually once the schema, mappings, business rules, and main consumers agree. Save the rule version, scope, verified results, and untested branches. Ensure future tasks actually read the new rules; an old instruction does not update itself because a field changed.

Must every rename rewrite every task? Inspect real dependencies first. Does one passing record validate a batch? Cover the actual branches and consumers. Must you create a new review Base? No. What matters is a traceable structure difference, proposal, responsible owner, and acceptance result.