Automation without vendor lock-in, and how to spot it in a proposal

"What if you are gone in two years?" It is a fair question to put to anyone who wants to build software inside your business, and you will not answer it by checking how long the supplier has been trading. Automation vendor lock-in is settled by whose name the accounts are in, who holds the source code, and whether anyone wrote down why the thing works the way it does. All of that can be agreed before you sign.

Automation vendor lock-in starts with the accounts

An agent that reads mail and creates records in your ERP needs logins to your systems and access to a language model. If those accounts belong to the supplier, your process stops the day their invoice goes unpaid. If they belong to you, the workflow stays yours no matter who built it. This costs nothing to get right, and it still gets waved through at kick-off, because a developer using their own accounts gets started faster.

A contract line about usage rights does not settle the code question. An agent is software: prompts, validation rules, API calls, the handling of exceptions. If it lives in a repository only the supplier can open, you are renting the result. Once the source sits in your own repository after acceptance, any competent developer can pick it up.

What gets expensive later is the reasoning nobody wrote down, because it costs nothing while everything runs. Why does the agent take the delivery date from the subject line instead of the PDF? Why does anything above 5,000 euros go to a person? A single workflow holds dozens of those decisions. If none of them are recorded, a successor reconstructs them from the code, which takes longer than the original build.

What should be in your hands the day after handover

Say a wholesaler has order confirmations checked automatically and a year later the supplier is unreachable. Whether that is an annoyance or a stoppage comes down to five things, and they belong with the customer from day one rather than at final acceptance:

• the source code in the customer's own repository, with its change history
• credentials held in accounts issued to the customer, model access included
• an operating manual saying, step by step, what the agent does and what it deliberately leaves alone
• the house rules in plain language: thresholds, exceptions, escalations, each with its reason
• a set of real cases with the expected outcome for each

That last one carries the most weight and is the only one that takes effort. With two hundred checked cases on file, you can hand the workflow to a stranger and know within half an hour whether their change broke something. Without them, every adjustment is guesswork, and that is where dependency actually comes from.

Running costs say more than the exit clause

A monthly platform fee ties you in, because cancelling means the workflow stops. Model usage billed straight to you does not, since the model contract is in your name anyway. So alongside the build price, ask what leaves your account each month, to whom, and for what.

Part of that answer is who looks after the agent when something shifts. Interfaces get rewritten, suppliers change their document formats, models are retired. With nobody watching, an agent does not fail loudly. It returns slightly worse results until someone in purchasing notices.

Four questions for any proposal

Who owns the source code after acceptance, and which repository is it in?

Whose name is on the access to your systems and to the language model?

What does the documentation cover, and is it included in the price?

What does running it cost per month, and how much of that goes to the supplier?

Silence on any of these is itself an answer. Get all four in writing before you sign. A supplier working properly has no issue with that, because the money is in building the thing, not in your inability to leave.

Sophera builds automation at a fixed price, with no subscription, and the result belongs to the customer. Every automation comes with a maintenance agent included in the fixed price. It watches operations, checks each interface for changes on the way in and out, tests changes against earlier cases and handles the move to newer models. Anything it cannot resolve goes to the customer's IT as a ticket. In the free automation check we work out which process to start with, which access is needed, and what ends up in your hands.