Your AI Coworker Still Runs. Did the Connected API Change the Job?

The Connection Works. The Business Result Doesn't.

A customer address field changes in your CRM. The connection returns a successful response, but your AI coworker now prepares shipping updates using the billing address. Nothing crashes. Every dashboard stays green. The mistake reaches the customer before anyone notices.

On October 27, Salesforce announced API Evals, a forthcoming way to generate functional and performance tests from API specifications. Its point is straightforward: connected AI systems can fail when the APIs beneath them change. Salesforce says the feature enters beta in November 2026 and is planned for general availability in January 2027. It is an announcement, not a tool every business can install today.

The more important lesson does not depend on that release. A persistent AI coworker is only as reliable as its connections to the work. A response code can show that an endpoint answered; it cannot show that a customer got the correct message, a payment stayed with the right account, or the next human received a useful exception. When a connected application changes, test the work that crosses the connection, not just whether the connection exists.

This is a different operational problem from deciding which data a coworker may access. Permissions establish whether it can call a system. Change management asks whether the call still means the same thing after a vendor release, an internal configuration edit, or a new business rule. Small businesses do not need an enterprise testing platform to start answering that question. They need a short list of critical outcomes, clear release ownership, and an honest pause path.

An API Contract Is Not the Same as a Work Contract

An API contract describes endpoints, inputs, outputs, and errors. The OpenAPI Specification is a standard way to describe an HTTP API so people and software can understand its interface. That description is valuable: it can expose a removed field, an altered parameter, or a response type that no longer matches the consumer's expectations.

But a business work contract is wider. It says which record is authoritative, how fresh it must be, what an action is allowed to change, when a person must approve it, and how to tell whether the real-world outcome happened. If an order API starts returning a valid address value from a different address type, the schema can still pass while the delivery decision fails. That is not a defect in schema testing. It is a reminder that schema and business meaning are separate things.

Consider a service company whose scheduling Teammate checks availability, offers a window, then reserves it. The calendar API may continue accepting requests, yet a newly added location field could cause the Teammate to reserve a slot in the wrong office. An endpoint health check sees a success. The customer receives a confirmation. The dispatcher finds a double booking later. The failure crossed several seams: the field mapping, the selection rule, the reservation write, and the customer message.

A robust test therefore asks three questions. Can the system communicate? Does the returned data still represent the intended business fact? Did the permitted action produce the intended and recoverable outcome? The first is infrastructure. The second is interpretation. The third is operational accountability. You need all three before you trust a connected coworker with consequential work.

Salesforce's October announcement is useful precisely because it puts API changes next to ongoing quality checks and intervention. It does not make all failures disappear. It underscores that testing cannot be an onboarding ritual performed once and forgotten. Even if your team never uses Salesforce's products, a vendor changing a CRM field or an internal team changing a fulfillment status can alter what your coworker does tomorrow morning.

The quiet changes are often worse than the loud ones

A removed endpoint produces an obvious error. An added enum value, revised default, changed pagination rule, newly optional field, or different timestamp interpretation may leave the workflow running. The Teammate then acts on incomplete or misclassified information. These are examples to test for, not claims about any particular vendor's release.

Look for mismatches between a successful call and the next decision. If a sales Teammate's lead list starts omitting the second page of results, its weekly report can still look polished. If a finance Teammate reads a gross amount where it expects a net amount, its narrative may be coherent but wrong. The more fluent the explanation, the easier it is to miss the connection error underneath. This is why a response-only test must be paired with a known business example whose correct answer a human has already established.

Test the Decision Path, Not Just the Endpoint

A useful test fixture is a small, controlled example of real work. It includes a starting record, expected interpretation, approved action, and evidence that the action occurred. Keep sensitive customer data out of test fixtures where possible; use a dedicated test tenant or synthetic records with realistic edge cases. An isolated test protects production while preserving the shape of the decision.

What bad looks like: a team runs a nightly ping against the CRM, sees a 200 response, and calls the connection healthy. Its Teammate reads a preferred_contact field that now defaults to email when unset. The coworker sends emails to customers who had historically opted for phone contact. The ping was not false; it answered a different question from the one the team needed answered.

What good looks like: the team keeps a test customer with an explicitly recorded phone preference and a second customer with no preference. The test checks that the first is never queued for an email and the second is sent for human clarification. It verifies the draft and the chosen destination before anything leaves the system. If that rule fails, the Teammate can still collect and categorize requests, but sending is disabled until a named owner reviews the mapping. The failure stays inside a reversible seam.

Neither scenario requires a large testing department. The critical work is stating the expected outcome before running the test. Ask the person who owns the process what would count as an unacceptable result. The answer often reveals hidden rules: a customer must never be contacted after an opt-out, a refund above a limit needs approval, or an appointment cannot be promised without a reservation identifier.

Use several kinds of checks together. A contract check catches incompatible field shapes or missing parameters. A business example catches interpretation drift. A permission check ensures a change did not expand authority. A side-effect check confirms that a write went to the expected record exactly once. An exception check proves the coworker can hand incomplete work to a person with the original evidence attached. No single check covers the whole path.

Do not confuse a model evaluation with a connection evaluation. A model might summarize a sample record perfectly while the live CRM returns the wrong record. Conversely, the CRM may return the right record while the model chooses the wrong action. Testing the entire path identifies which seam broke, so the team can contain the right part of the workflow rather than switch everything off or rewrite instructions blindly.

Build a Small-Business API Change Routine

Start with one high-impact workflow, not every connection at once. The aim is a repeatable release gate that a business owner or operations lead can run without reading source code. It should fit on a page and identify both the technical contact and the person accountable for the customer outcome.

1. Name the business result. Write a sentence such as “the correct customer gets one appointment confirmation for the reserved location and time.” Avoid “calendar integration works.” The first sentence can be verified; the second hides assumptions.
2. Map the path. List the source system, fields used, Teammate decision, destination system, external effect, and human owner. Record which steps are read-only and which create or modify records. Include any other route that can reach the same system, such as a manual export.
3. Save three fixtures. Keep one normal case, one ambiguous case, and one case that must stop. For scheduling, these might be a single available slot, two locations with overlapping windows, and a customer record lacking a confirmed timezone. State expected behavior for each.
4. Watch for change signals. Review vendor release notes, integration configuration edits, authentication scope changes, error rates, and unexpected shifts in output volume. A release note is a prompt to test, not proof that your specific workflow changed. Make one person responsible for deciding which changes need a rerun.
5. Run checks before restoring writes. Test shape, meaning, authorization, and side effects in a safe environment. If you cannot isolate a test write, use a dry run that presents the exact proposed action to a human. Never test a dangerous write on a real customer merely to see whether it succeeds.
6. Set a fail-safe mode. On an uncertain field mapping, pause the consequential write or customer send while preserving read-only preparation and a clear handoff. Specify who receives the exception, what evidence they see, and when the work must be completed. A blanket shutdown is sometimes necessary, but it should not be the only available response.
7. Record the release decision. Keep the date, changed dependency, tests run, failures found, person who approved resumption, and any customers or records requiring correction. An audit trail that begins before the first real run makes those records much easier to reconstruct. When the next change comes, this history tells you what was actually proved, not what everyone remembers proving.

Run this routine after a known connector update, before a model or workflow change that alters connected actions, and periodically for workflows whose dependencies can change without notice. Frequency should follow risk. A weekly internal report can tolerate a delayed review; payroll, payments, and customer-facing commitments need a tighter gate. Decide the interval from the cost of a wrong outcome and the time available to correct it, not from a generic industry rule.

A checklist is not an assurance certificate. Keep a small sample of real results under human review after a release. Compare them with the expected business outcome, not merely with the test fixtures. If the sample reveals a discrepancy, make correction work visible: which records were touched, which customers were contacted, which actions can be reversed, and which require a personal follow-up.

Contain the Write, Preserve the Work

The hardest moment is a partly completed task. Imagine the Teammate has checked a customer's eligibility, sent a draft to an approver, and then the benefits system changes its response format. It should not quietly continue to a final decision using a guessed value. It also should not discard all evidence and force a human to redo the inquiry from scratch.

A better design freezes the affected action, snapshots what was observed with timestamps and source identifiers, and routes the case to a named reviewer. The reviewer can see which facts were verified before the change, which facts must be fetched again, and which action has not yet happened. If a request times out after a write, treat the result as unknown, not automatically failed. Check the destination record before retrying, or the coworker may make a duplicate booking, invoice, or message.

The distinction between requested and completed work matters. A model can decide to book an appointment. The connector can send a booking request. Only the source system can confirm that a reservation exists, and even that may need a business-level check for the right customer and location. Store a stable request identifier when the system supports one; otherwise, design a lookup by the relevant business key before any retry. Escalate when the state cannot be established.

Salesforce's announcement also describes quality-triggered intervention, but its availability note separates capabilities generally available today from Agent Evals and API Evals slated for later rollout. Do not buy a future feature in your head and leave today's workflow unprotected. A simple human-owned pause rule and a tested rollback path are useful now, independent of the product roadmap.

The operating question is not “does the AI still run?” It is “can we tell whether the connected business result is still correct, stop the part that is uncertain, and finish the customer's work without guessing?” That is the difference between a convenient integration and a dependable coworker. A connection is plumbing. A work contract is a promise you can inspect, test, and repair.

FAQ

Q: What is AI coworker API change management? A: It is the practice of checking whether changes to connected software alter an AI coworker's data interpretation, permissions, actions, or business outcomes. It combines technical contract tests with known business cases and a recovery plan.

Q: If an API returns success, isn't the integration healthy? A: It shows that a request reached an endpoint and received a successful response. It does not prove that the returned field means what your workflow assumes, that the right record was updated, or that the customer received the intended result.

Q: Do small businesses need an automated evaluation platform? A: No. Start with a few controlled cases for the highest-risk workflow, a named owner, and a documented pause path. Automation becomes valuable as the number of connections and changes grows, but it does not replace a clear definition of the right business outcome.

Q: What should a Teammate do when a connection changes mid-task? A: Stop the affected consequential action, preserve the source evidence and task state, identify whether earlier writes completed, and hand the exception to a named person. Resume only after rechecking the changed facts and confirming the next action is authorized.

Q: How often should connected workflows be retested? A: Retest after known vendor or configuration changes and on a schedule matched to the harm and recoverability of a wrong result. Review a small sample of live outcomes as well, because not every meaningful change appears in a schema or release note.

If you're ready to run AI coworkers whose connected work can be tested, paused, and recovered as your systems change, explore Associates AI Teammates and choose a plan.