Notes / Workers
What should you recheck when an AI Worker's connected tool changes?
A practical change record for maintaining an AI Worker's job when connected tools, fields or permissions change.
By Edu Rigonato. Published Sep 30, 2026. 11 min read.
Your CRM has changed a field. The integration still connects, and the Worker can still open the record. The remaining question is whether the job now reaches the right result.
After a connected tool changes, the Worker should investigate what changed, work out the appropriate adaptation and verify the result within its existing authority. Routine adjustments should not become repair assignments for the owner. Keep unaffected work moving, preserve pending context, and bring the person in charge a recommendation when business meaning, permissions or consequences need their decision.
That is the maintenance approach this article addresses: the Worker takes responsibility for diagnosing and handling the change, with targeted human verification where needed. Its available tools and agreed maintenance permissions determine which adjustments it can carry out itself.
Consider a hypothetical service-intake Worker that organizes incoming requests and updates a CRM. The CRM replaces a status field with a different set of options. Reading a request might still work. Marking it ready for assignment might now mean something different to the team receiving it. A capable Worker should investigate the replacement options and test a likely mapping, rather than simply report a broken field. We will use that example to distinguish an adaptation it can handle from a business decision it should verify with you.
What changed—and which parts of the job depend on it?
The Worker should start with the actual change, then follow its dependencies through the job. “The CRM was updated” is too broad to tell anyone what to check.
The useful description identifies the old and new behavior. A field may have been renamed, removed or given a different meaning. Permissions may have narrowed or expanded. A browser control may have moved. An integration may now return different information, even though the connection remains available.
Not every software update requires the same response. GitHub’s API versioning documentation distinguishes breaking changes from compatible additions. That distinction helps teams scope their review: a documented change to a field used by the Worker deserves different attention from an addition it never reads.
Frequently asked questions
Does every software update require a full retest?
No. Scope the checks to the changed behavior and its dependencies. A documented compatible addition may warrant a different review from a change to a field, permission or action the Worker uses. Unclear impact may require broader investigation.
Can the Worker handle a routine tool change itself?
Yes, where its tools and existing authority support the adjustment. It should investigate, make or propose the adaptation, and verify the resulting business state. A clear field rename need not become a repair task for the owner. Ambiguous business meaning or expanded permissions require the appropriate decision.
Can the Worker keep working during the change?
Independently unaffected work can continue within existing authorization when its dependencies remain valid. The Worker can investigate and validate affected actions while that work continues. Do not assume all read-only work is unaffected.
What if an action’s outcome is uncertain?
Preserve the task context and distinguish the last confirmed step from the attempted action. Establish the resulting state before deciding whether to repeat, correct or escalate the action.
Who approves resuming affected work?
Follow the agreed operating rules. A validated routine adaptation may resume under existing authority. When a business rule, expanded permission or consequential decision requires confirmation, the Worker brings the person in charge its recommendation and evidence. A passing test does not grant new authority.
Evidence note: This article draws on public API-versioning documentation, agent-testing guidance and operational risk-management guidance. Vendor policies apply to their own products. The CRM example is hypothetical, and the checklist is a practical synthesis rather than a measured guarantee of reliability. The Worker-led approach describes an operating design requiring suitable tools, access and maintenance rules; it is not a claim that every model can repair every integration. Tests and limited rollouts cannot cover every future input.
Explore Workers