An ERP adapter is not a magic switch

A useful semantic operation has a name and a contract that describes the business question. customer.search or purchase_order.search should not have to become a different cognitive primitive every time the provider changes.

An adapter can handle the concrete API, authentication, field mapping, error semantics and result normalization. That is valuable because the reasoning layer need not memorize every vendor's endpoint naming.

Vendors disagree about what counts as a draft, approval, shipment or receivable. Entities split differently; custom fields change rules; some operations have no direct equivalent.

A new adapter must earn the claim of interoperability. It needs mapping tests, permission checks, verification that returned data means what the capability says it means, and explicit unsupported states.

Portability is easier for a constrained read operation than for a multi-step write with approval, taxes and irreversible side effects. A read-oriented provider seam should never be advertised as a complete cross-ERP transaction layer.

A capability catalog can preserve its conceptual vocabulary while each connected provider declares what it actually supports. The agent should be able to see a missing capability instead of inventing a workaround.

The source ERP remains the system of record. The agent's normalized view is a projection over that record, not a new authoritative database.

Build at least two genuinely independent implementations and compare them on representative tasks: filters, joins, currency and date semantics, permissions, missing fields, error behavior and postcondition verification.

If only one real backend exists, call the adapter a foundation, not proof that switching is automatic.

An honest seam is still an important architectural step. It is the difference between designing for change and claiming change is already free.

A good adapter is not a bag of endpoint aliases. It has to establish the meaning of identifiers, filtering, ordering, pagination, currency, timestamps, and the transitions that a provider actually exposes. A supplier named the same way in two systems is not necessarily the same business entity. Company scoping and tenant boundaries are also part of the contract, not deployment trivia.

Suppose a user asks which orders are blocked by a supplier delay. One system models delivery dates on purchase-order lines; another exposes them through a fulfillment or logistics module. The business intent is recognizable in both systems, but an adapter that only translates the noun 'order' will return false answers. The implementation needs an explicit capability mapping and enough evidence to verify that the returned records satisfy the requested interpretation.

This is why the capability layer benefits from distinguishing discoverability, runtime availability and support guarantees. The registry may understand the concept of an operation even when no current provider can fulfill it correctly. The honest answer in that case is an unavailable capability, not an invented best effort.

An adapter is also a trust boundary. A common semantic operation must still respect the source provider's permission model, the user's business authority, the tenancy of the underlying connection and the sensitivity of the requested fields. Replacing an ERP connection does not copy old privileges into the new system.

Reads are already subtle; writes are harder. A submitted invoice, a validated quotation and a confirmed payment may correspond to different business events across platforms. There is no safe generic 'approve' action unless its preconditions and effects are defined for that provider. The agent should not compensate for an unsupported transition by assembling undocumented lower-level writes.

A strong product can keep the high-level experience familiar while admitting that two vendors have different available actions. Interchangeability is a tested degree of portability, not a binary marketing checkbox.

A useful conformance suite would start with canonical read scenarios: customer matching, purchase-order filters, document state, currency precision, permission-denied responses and missing provider fields. It would then cover failures: timeouts, contradictory states, a deleted record and repeated requests. Even with an identical output shape, the provenance of each result should remain inspectable.

For mutation-capable providers, add negative authorization tests, idempotency, side-effect verification and recovery after partial completion. Two adapters are meaningfully interchangeable only for the subset of operations shown to preserve those semantics under representative conditions.

Artemis currently has an ERPNext-backed provider and a typed, primarily read-oriented adapter foundation. That is an architectural seam, not evidence that a production company could migrate to another ERP overnight. The corresponding public design note explains that distinction: https://github.com/sarooo17/artemis-architecture/blob/main/docs/19-CAPABILITY-TAXONOMY-AND-ADAPTERS.md.