Most automation projects spend weeks on what to build and minutes on who owns it.
That is backwards. The question of ownership decides whether you can change supplier, bring the work in-house, or simply keep the thing running if the person who built it becomes unavailable.
“Ownership” is not one thing. It is several separate questions, and each needs its own answer.
Whose accounts does it run in?
Automations run inside accounts: an automation platform, an AI provider, a cloud host, the applications being connected.
If those accounts belong to your supplier, the workflow lives on their side of the fence. That can be a reasonable arrangement, especially for a managed service, but it should be a choice you make knowingly.
Ask, for every account involved: in whose name is it registered, who pays for it, and who can log in?
Who holds the credentials?
Automations need access to your systems: passwords, API keys, connection tokens. Agree:
- That credentials belong to accounts you control wherever practical
- How credentials are stored and shared, and never by email or chat
- Who has access, and how access is removed when the engagement ends
- That keys can be rotated without breaking everything
What do you own, and what does the supplier keep?
Three things are easy to confuse:
- Your materials: your data, documents, brand assets and information. You should keep ownership of these.
- The deliverable: the specific workflow, configuration or output built for you.
- The supplier’s own tools: the frameworks, templates, internal software and methods they use across many clients.
Suppliers commonly keep ownership of their underlying tools, and receiving a deliverable does not automatically transfer them. That is normal. What matters is that the agreement says what you receive, what licence you have to use it, and what happens if you stop working together.
Can you export it?
Ask whether the workflow can be exported in a form someone else could rebuild or run. Depending on the platform, that might be an exported workflow file, source code in a repository you control, or a written specification detailed enough to rebuild from.
Some platforms make exporting easy. Some make it awkward. Knowing which before you start is far cheaper than finding out when you want to leave.
What documentation should you receive?
- A plain-language description of what the workflow does and why
- A diagram or list of every system it touches
- Where every account and credential lives
- What each AI step is asked to do, and how its output is checked
- Known limitations and the cases it does not handle
- What to do when it fails, and who to call
Documentation is the difference between owning a system and merely hosting it.
Who is trained to use and look after it?
Someone in your business should understand the workflow well enough to notice when it is wrong, pause it if needed, and explain it to a new colleague. That person needs time and training, not just a login.
What is the exit plan?
Plan the ending at the beginning. Agree what happens if either side ends the engagement:
- Which accounts transfer, and how
- Which exports and documentation you receive
- How access is removed and credentials rotated
- Whether any licence to use the deliverable continues
- How long the supplier keeps copies of your data, and how it is deleted
What to get in writing
- A list of every account involved, its owner and who pays
- Confirmation that your materials and data remain yours
- What the deliverable is, and the rights you have to use it
- Which supplier tools are used and not transferred
- The export format and documentation you will receive
- Support terms after launch
- The exit procedure
- Which third-party costs you pay directly
Ownership that was never written down is ownership you will have to negotiate later.
MonoGrain’s published Terms set out the defaults: you keep the materials you bring, and project deliverables, usage rights and third-party costs are agreed in the proposal for each engagement.