The API contract is newer than the model

A remembered code example can make a customer update look effortless. In this illustrative case, an agent drafts one from memory. The method name is plausible. The fields look familiar. The test fixture accepts the request. The real vendor contract changed after the example was written.

The failure began before the call. The agent used memory where it needed a current source.

A talk about agents and changing APIs argues for retrieving the exact passage that answers the task. That principle is especially useful in integrations, where an API definition is a moving contract rather than background reading.

A plausible call is not a contract

Large models learn from code, documentation and discussions created at different dates. Those examples can remain useful for shape and idiom. They cannot establish what a vendor accepts today, on the version an app uses, in the account connected to the sync.

Shopify’s API versioning guide documents a quarterly release schedule and version-specific change notes. A developer can select a supported version, then read the changes relevant to an upgrade. The version in the request matters more than a model’s memory of “the Shopify API.”

Brevo’s contact creation reference adds another layer: custom attributes must exist in the account, and values that do not match a declared attribute type can be ignored. A generic API schema cannot tell the agent which attributes this particular account has created. That calls for an account-scoped lookup or validation.

The current contract has at least two parts: the vendor’s published operation and the account’s configured objects. The agent needs both when its task depends on both.

Version and account scope should travel with the retrieved answer. A correct operation description for one API version can be wrong for another. A correct attribute name for one Brevo account may not exist in the next. Include the selected version and account identifier in the test fixture, and fail when either is unknown. The assistant should not resolve that ambiguity by guessing from a nearby example.

Retrieve the small piece in use

A bad repair is to paste ten thousand operation definitions into every agent turn. The model then has more text to search, more stale passages to confuse and less room for the actual task. Ask for the operation that moves this record and the constraints that decide whether it succeeds.

For a contact update, the answer-bearing material might be the operation path, allowed fields, required identifier, attribute type rules and current API version. Give the agent those passages with their source URLs. Keep the rest available for another question.

Tajo’s Brevo API guide can help a reader orient around the provider. The official reference should settle a precise call before production code uses it. The reader needs a source they can reopen when the vendor changes something.

A repository can make this repeatable. Record the pinned version, the vendored specification’s hash and the date it was checked. A changed hash does not prove a breaking change; it tells the maintainer what to compare. A model can summarize the relevant diff. Tests should still exercise the operations on which a working sync depends.

Treat the generated request as a hypothesis with three checks. First, does it match the official operation and pinned version? Second, does the connected account contain the objects the request assumes? Third, does a bounded execution leave the expected state behind? A schema check can answer the first, an account lookup the second, and a read-after-write probe the third. None is a substitute for the other two.

1. Vendor operation version · fields

   What the published API accepts

   narrows
2. Connected account attribute · type

   What exists in this account

   narrows
3. Bounded execution write · read back

   What actually changed

Do not treat retrieval as execution proof

The fair objection is: “Official docs can lag the live service.” They can. Reading them is necessary but not sufficient. A contract test should send a bounded request through the same client code and check the response and destination state. If the service behaves differently, record the discrepancy and narrow the affected operation.

An agent should also stop when the contract is ambiguous. A guessed field mapping applied to many contacts is more expensive than one review of the field definition. The guide to integrating multiple business tools starts with identifying each data object’s source of truth; API freshness is the same discipline applied to the operations that carry the object.

The cost is maintaining current references and tests. The alternative is paying for the same stale assumption across every record a sync touches.

The model can remember the idea. It must read the contract and check the account it is about to change.

This need not make every interaction slow. Cache the narrow, versioned passage and account schema until a known invalidation event or a chosen refresh point. Store the source and retrieval date with the decision. The cost of a fresh read is then paid when the contract may have changed, not on every repeated row of an already approved sync.