Swap the system, keep the operator

Most automation dies twice. The first death is dramatic: the vendor it was built on gets replaced, and the automation, written in that vendor’s dialect, goes down with it. The second death is quieter and comes earlier: the team, knowing the first death is coming, stops investing in the automation at all. Switching costs do not just make change expensive. They make everything built on top of the incumbent feel temporary, so nothing serious gets built.

Fibric was designed around a refusal to accept that trade. An operator’s logic — what it watches, what it decides, what it is allowed to do — never mentions a product name. It names capabilities: read the order, message the customer, adjust the setpoint. A connector is the separate, swappable piece that binds each capability to a real system. The operator holds the intelligence. The connector holds the dialect.

The shape of the indirection

Concretely, an operator’s plan says something like support.conversation.create. It does not say “POST to the Kustomer conversations endpoint.” At deploy time, a tenant’s configuration binds that capability to a connector, and the deterministic executor routes every disposed action through the binding. Change the binding, and the same operator, the same policies, and the same receipts now drive a different system.

Notice the third row. The indirection is intended to cover SaaS and building protocols with one capability contract. BearScope is the live proof point for governed CX and commerce data, but its current BFF does not route through the generalized kernel described here. BACnet and the hotel twin are managed reference patterns, not proof of the same executor running a live building.

What a swap actually involves

Suppose you move your support stack from Kustomer to Zendesk. The target pattern is to install and validate the replacement connector, map credentials and fields, rebind capabilities, re-run policy tests, and compare behavior before cutover. Operator intent may remain stable, but semantic differences, rate limits, permissions, and downstream side effects can still require implementation work.

The connector carries the vendor-specific burden: authentication, rate limits, pagination quirks, field semantics, and supported recovery behavior. The catalog currently has 48 listings: 5 live in BearScope and 43 offered through managed early access. Public publishing and marketplace checkout are not available today.

What this does to switching costs

Switching costs are usually discussed as a moat — something a vendor builds against you. The capability layer inverts the geometry. The cost of switching a downstream system collapses toward the cost of the connector swap, which is small and bounded. Three consequences follow:

• You negotiate from strength. When leaving a vendor is a rebind rather than a rebuild, renewal conversations change tone. The vendor has to win on merit every year.
• You can build for the long term. Operator logic accrues value for years because it is not mortgaged to any one system’s API. The second, quieter death never happens.
• Governance has a reusable contract. A replacement connector can inherit common policy, duplicate-control, and record interfaces, but it must pass parity and recovery tests before the new path is treated as governed.

The line we hold

It would have been easier to let operators call vendors directly, and every shortcut in the ecosystem points that way. We hold the line because the indirection is what makes the rest of the platform honest: capabilities are what policies are written against, what receipts are recorded against, and what the executor enumerates when it decides whether a plan is allowed to dispose. Collapse the layer and you collapse all three. Keep it, and the systems around your operation become what they always should have been — replaceable parts.

Keep reading: A connector in an afternoon · Anatomy of a connector: Kustomer