If your competitors have the same AI, where is your advantage?

Sources checked on 12 October 2026.

Imagine a field-service company launching an AI assistant to take fault reports. It reads the customer's description, identifies the type of problem and proposes a visit time. The team celebrates how easy booking has become. A few weeks later a competitor announces a similar feature, using roughly the same model. At the next service meeting, the question that enthusiasm had postponed comes back: why would a customer choose us?

The two experiences may look alike on a phone screen. The difference appears when the technician arrives and finds that the spare part is not available, or that the appliance needs a different specialism. The customer has to wait for a second visit. Booking an appointment quickly did not solve the problem they paid to have solved: getting the appliance working again.

Lower entry barriers change the investment question

Agent37 offers to host agents in isolated environments and competes on the cost of running them. This is a commercial offer from the vendor. It does not prove that the cost of AI as a whole has fallen; the site makes clear that model usage, search and integrations are billed separately. Even so, the announcement is a reminder that a company can buy a growing share of the infrastructure needed to build a product, without building all of it in-house. [1]

The management conclusion here is a proposal for analysis: when other competitors can obtain the same components, an investment decision needs an explanation of what the company will add on top of them. The quality, speed and cost of a model may still matter a great deal for a specific task. But choosing a model does not explain how you will win the customer, or why they will stay once an alternative appears.

In the maintenance example, the desired outcome may be to fix the fault on the first visit whenever the case allows it. Defining that goal helps the team choose the technology and the information it needs, and it makes the appointment an operational promise that must be kept.

Data and integration need an outcome

The claim that the advantage lies in "our own data" needs testing. A company may hold thousands of maintenance reports, but some are old, some do not identify the appliance precisely, and some describe the action taken without recording the result. What helps the assistant is the correct appliance history, the spare parts available now, and the technicians' ability to carry out the job at the proposed time.

Data becomes a useful asset when it supports a decision that is hard to make with public material alone. Ask, for example: did the problem recur after a previous repair? Does the new visit need a different part or a more specialised technician? If the system cannot connect these details to the report, the size of the archive will not justify investing in it.

The value layers show work moving from technical components to the customer's outcome. This is a map for thinking, not a fixed ranking of how hard each layer is to copy. Integration with the inventory system may be available to everyone, and handling a recurring fault may be the knowledge that really sets your team apart. Examine each layer by task and by market.

Then comes the practical test: does a report turn into an appointment with a qualified technician and an available part, or does a coordinator rebuild the plan by hand? The customer needs a path they can rely on. If the part's availability changes, the team must know how to adjust the appointment and tell the customer. These details make the promise usable day to day.

That includes reaching the customer. A good service that is hard to book, or whose coverage is hard to understand, may lose to a company that makes it easier to book a visit and track its progress.

Test the reason for choosing you before widening the service

Suppose the team can build three functions: summarising the fault description, checking spare parts, and matching the visit to technician capacity. Summarising the report may be easier to demo and more exciting, but unavailable spare parts may be a recurring reason repairs are not completed on the first visit. The order of development needs evidence from the actual service, and an understanding of what costs the customer extra time.

Start with cases that have already happened. Ask the operations team to trace the last visit that did not solve the problem. What was known beforehand? What was discovered on site? How was the customer affected? These details give you a hypothesis that can be tested. The question "Do you want a smart assistant?", by contrast, allows a positive answer that commits the person to nothing, such as changing how they book or which company they choose.

The proposed matrix combines how important a problem is with how testable it is. Use it to pick a short experiment that can expose an assumption that matters. An important problem that is hard to test may need better access to operational data before a team is asked to build a full solution. The positions of the ideas in the figure are illustrative; customer research in each company determines them.

In the maintenance trial, plans can be prepared for a sample of reports in parallel with the current method, with a coordinator approving before visits are confirmed. Measure first-visit completion, appointment accuracy and the manual edits required. Add the cost of use, review and support to the calculation, and follow the reasons for the cases that did not succeed instead of settling for a general average.

The trial may show that understanding the report works well while inventory records disrupt the service. The next decision then becomes clear: improve the data source or narrow the promise, before adding another function to the interface.

What is worth building yourself?

Buying a ready-made component may let the team concentrate on a more specific problem. Building one in-house may be justified if it meets a decisive requirement that the alternatives do not offer. The decision needs a clear effect on the customer's experience and a calculation of the cost of maintenance and operation, not a general preference for building or buying.

Compare the options on the same task. Does swapping the model change the accuracy with which a report is interpreted, or the plan for preparing a visit? Does the system's architecture stop you from changing vendor if quality or terms change? Having a tested alternative can protect continuity of service, without meaning that all models are equivalent or that switching is free.

Also track what accumulates with every visit. The company can learn which faults recur, which parts run short, and where the plan needs a technician to step in. Turning these observations into useful improvements takes reliable data, suitable permissions and a team responsible for corrections. Collecting records alone does not create an advantage; the service has to change because of what they reveal.

Some improvements will stay easy to copy, and that does not make them worthless. A small feature may be a necessary condition for competing, while distinction comes from speed of response, trust in the technicians or the quality of coverage in a particular area. What matters is knowing the role of each investment, so that you do not ask an interface update to do the work of a full strategy.

At the next service meeting, choose one problem faced by a specific customer. Write down the outcome they will pay for, what the model contributes to it, and what the company must contribute. Then define an experiment that can show whether that difference matters. If a competitor can buy the same technology tomorrow, you should still have a concrete answer to why the customer chooses you.

Sources

• [1] Agent37: agent hosting and cost model. A primary source from the vendor, accessed on 12 October 2026. The published service and pricing details are not an independent assessment of its viability or savings.

The article's examples and figures are hypothetical, and its strategic framework is editorial analysis.