Name what a customer would lose
Switching costs in the agent era are the costs that remain when a customer can use capable automation to help change suppliers. The claim is narrower than saying the product is useful, familiar or integrated. Ask what the customer would lose during a specific move to a credible alternative, how much of that loss is recoverable and which part could be reduced by migration tools.
Helmer's switching-cost mechanism concerns damage to an existing customer from changing vendors. That makes the customer the unit of analysis. An expensive implementation is not automatically evidence of an expensive departure: the setup cost may already be sunk, and a rival may offer a simpler migration. Likewise, years of stored data are not automatically a barrier if the data and its meaning can be transferred easily.
Begin with a representative customer journey. Record the data to move, the definitions that need translating, the controls that need validating and the people who must approve the change. Separate one-time inconvenience from a continuing loss in performance or coordination. The result should be a map a customer recognises, with uncertainties visible, rather than a vendor's assertion that leaving would be difficult.
Test what automation actually removes
An agent could help write export scripts, reconcile fields or generate replacement integrations. These are plausible tasks to test, not proof that migration is universally solved. Use a bounded trial with the customer's permission: start from a representative export, define the target schema, and verify records, relationships and access controls after transfer. Measure human correction as well as automated execution. Fast output that fails reconciliation is an incomplete migration.
Compare equivalent outcomes. A demonstration that moves a sample file does not answer whether a live accounting workflow preserves its audit trail. A rewritten integration is not complete until its failure behaviour and permissions are understood. Record the tasks automation finishes, the tasks it accelerates and the tasks it leaves to qualified people. This produces a defensible estimate of the residual switching effort.
The early-2025 developer trial by Becker and colleagues is a useful caution about generalisation: AI slowed experienced maintainers in that particular setting. It does not establish the result of a migration trial, and it should not be used to dismiss newer tools. Its relevance is methodological. Benchmark the actual job under stated conditions instead of borrowing a universal productivity assumption from a demonstration or a headline.
Include portability in the scenario
Portability can change the baseline independently of model capability. The European Commission describes the Data Act as creating a framework for switching between providers of data-processing services and improving interoperability. The strategic implication is to examine whether a claimed barrier depends on obstructing data movement. A company should not assume that today's export practice, commercial terms or technical restrictions will remain a durable source of advantage.
This is a direction for analysis, not a legal conclusion about a particular service. Scope, contract facts, exceptions and implementation details require qualified advice. Ask counsel which obligations apply before relying on a clause or designing a migration policy. Keep the resulting legal assessment distinct from evidence of customer behaviour. A permissive portability rule does not prove that organisations can change every process overnight.
For a moat review, model an orderly, lawful exit. Assume the customer receives the data and assistance it is entitled to receive. Then inspect the remaining dependence: agreed operational definitions, revalidation work, coordination with counterparties and any measurable loss of service quality. This removes a fragile premise from the story and directs effort toward benefits customers would choose to preserve even when departure is possible.
Use retention to investigate the mechanism
Retention is useful evidence to investigate, but it does not identify the cause by itself. Customers may renew because the product is excellent, the alternative is unknown, the contract has not expired or changing requires scarce staff time. A founder who attributes every renewal to lock-in has skipped the causal question. Compare cohorts, listen to departure reasons and examine customers that seriously evaluated an alternative.
Create a departure record alongside the renewal record. What did the customer export? Which tasks required specialist work? Which issues did the competitor solve? Which losses persisted after the move? Avoid collecting unnecessary private information, and report uncertainty where accounts differ. One difficult departure is a case study; several carefully documented cases can reveal a pattern worth testing across the relevant customer segment.
Counterevidence matters just as much. If customers leave quickly with a standard tool, revise the estimate. If a rival pays for migration, distinguish the customer's temporary subsidy from the work still required. If customers keep both products, investigate whether the product is essential infrastructure or simply easy to retain at low cost. The test should explain observed choice rather than protect a preferred label.
Build a stronger reason to stay
A practical design agenda starts with the residual work the test uncovered. Make the customer's operational context more accurate, preserve interpretable history and support reliable coordination across their real workflows. Keep export usable. These are product choices to evaluate, not guarantees of a moat. Their strategic value depends on customers receiving a benefit a rival cannot readily reproduce under the same access and rights.
For example, a hypothetical maintenance platform might export its event log easily while retaining an advantage from a verified service process and experienced response organisation. The log itself would be a weak switching claim. The service outcome and the time a rival needs to match it deserve separate investigation. Stating the mechanism precisely prevents useful portability from being mistaken for the disappearance of all competitive advantage.
Today's Moat Index assesses switching costs within its v5.0 method on the 7 Powers, including AI-era tests. It is not a certified migration audit. A broader next version is coming. Read the methodology page, supply dated evidence and ask what a capable rival can now neutralise. A lower switching estimate can be a useful result: it tells the team where to improve the product instead of defending an assumption.
Sources
Sources support the linked claims; our interpretation and checklists establish no outcome for your company.