What You Actually Own When You Own an Intelligence System

Owning an intelligence system means you hold six specific things: the files, the structure inside them, the trail behind every answer, the business rules the system follows, the accounts it runs on, and a clean way out. Ownership is the sum of those six, and most of the confusion about it comes from treating it as a feeling rather than a list you can check.

The confusion is understandable. Almost every supplier says the client owns the data, and in the narrow sense it is usually true. The records are yours, the contract says so, and there is an export button somewhere. Then the partnership ends, or the tool gets replaced, and the business discovers that what came back was a pile of files with the structure stripped out, a set of automations nobody can read, and an admin login registered to someone who left the supplier two years ago.

This post is about what you hold. What goes inside a working system, and how it stays current, is covered in the anatomy of an intelligence system. The wider case for why any of this matters is in what you are renting when your knowledge sits in other people's tools. The question here is narrower and more practical. If you own one, what exactly can you point at?

What does owning your AI system mean?

It means the business could keep running the system, change it or move it, without the permission or the goodwill of whoever built it. That is a higher bar than having your data, and it is the right bar, because an intelligence system is only worth anything while it is being used and maintained.

None of that requires hosting anything yourself. A business can own its AI stack while every part of it runs on rented cloud services, which is how nearly everyone runs theirs.

A useful way to hold it in your head is to imagine the partner who built your system disappearing on a Friday afternoon. There has been no falling-out. They have simply gone. On Monday morning, could a competent person you hired open the knowledge, understand how it is organised, see why each answer says what it says, read the rules the automations follow, log in to everything and carry on? Each part of that question maps to one of the six things below, and a business that can answer yes to all of them owns its system in every sense that matters.

I should say plainly that this applies to us as much as to anyone. If a business we build for could not pass that test, we would have built it wrong.

The six things you should be able to point at

What you hold	What good looks like	The warning sign
The files	Readable pages that open without the tool that made them	Knowledge only reachable through one vendor's interface
The structure	Fields and links written into the files themselves	Relationships that exist only in the tool's own database
The trail	Sources on every answer and a full history of changes	Answers you cannot trace, or history that stays behind when you leave
The rules	Business rules and instructions someone else can read	Logic buried in a vendor's platform or inside a trained model
The keys	Accounts and admin access in your company's name	Logins registered to the partner or to a former employee
The exit	A handover that is mostly in your hands already	A leaving process that has to be negotiated or assembled

Read the warning signs column as a list of things that feel fine until the day they stop being fine. None of them causes a problem while the relationship is working, which is precisely why they survive for years without anyone looking at them.

Portability is something you arrange, not something you are given

Plenty of businesses assume data protection law has this covered. It covers something much narrower. The UK right to data portability is real, and the ICO describes its purpose clearly. It allows individuals to obtain and reuse their personal data for their own purposes across different services. The scope is just as clear. The right only applies to information an individual has provided to a controller.

That is a right for people over their personal data. It gives a business no equivalent claim over its pricing logic, its recorded decisions or the corrections its team has made to an AI tool since it first started using one. Whether that material can leave a supplier, and in what shape, is decided in practice by how the system was built and what was agreed at the start. If nobody arranged it, nobody has it.

This is why AI data portability is worth pinning down before a project begins. For an intelligence system it means everything the system knows can leave in a form another system can use straight away. That rules out more than people expect, including anything learned by adjusting a model's trained weights, which cannot be read, checked or carried across to a different model. It is one of several reasons memory and retrieval suit most mid-market businesses better than fine-tuning, and ownership is the least discussed of them.

The files, and the structure inside them

The first two belong together, because the second is what people lose when they think they have kept the first.

The files should be in a format that does not need the tool that created them. Plain text pages, usually written in Markdown, are the safe default. They open in anything, they will outlast today's tools, and any competent developer or AI model can work with them without converting them first. The government reaches the same conclusion for its own technology. Using open standards increases interoperability, which in plain terms means technology that is easier to upgrade and can talk to other technology. That guidance is written for public sector projects, but the reasoning carries across to a business of any size.

The structure is the part that goes missing. When a business moves off a knowledge tool, the pages usually come out and the arrangement of them does not, because the tool kept the links, the categories and the relationships in its own database. The answer is to write that structure into the files themselves. Each page carries a short block of fields at the top, and links to other pages are ordinary text inside the page, so the structure travels with the content wherever it goes. The fields themselves are few, and what matters here is less which ones you choose than where they live.

Ours works exactly this way. The business memory we run Agenticise on is a folder of plain Markdown pages, most of them carrying their dates, sources and confidentiality in a short block at the top, held in a private Git repository we control. The tools we use to search it and write into it are all replaceable. If every one of them vanished tomorrow, the pages would still open in a text editor and still make sense, with every link intact.

The trail behind every answer

An answer worth trusting has two things behind it, the source it came from and the history of how it reached its current wording. Both need to be in your hands, and being able to see them through someone else's screen is not the same thing.

Sources are straightforward once the structure lives in the files. Each summary page lists the documents it was built from, those documents are files you hold, and a citation becomes a link between two things you own instead of a reference to a record ID inside a vendor's platform. That distinction matters on the day you leave, because a citation pointing into another company's database stops working as a citation the moment you lose the login.

History is easier to overlook. Most tools keep a version history, and most exports leave it behind. For a store of what the business knows, the history is often as valuable as the current page, because it tells you when a position changed and what it replaced. Keeping the store in version control solves this almost for free. Every change carries a date and a description, and the whole history lives alongside the content and moves with it.

The rules the system follows

This is the item most ownership conversations miss entirely, and it is where a good deal of the value sits.

An intelligence system is rarely just a store. Around it sit the automations and agents that act on it, and those follow rules. The rules decide which enquiries count as urgent, how confident the system has to be before it acts without a person checking, and which customer a message belongs to when the email address does not match anything on file. They are your commercial judgement expressed as logic, and they are as much a part of what the business knows as anything in the pages. The same goes for the instructions an AI model is given, which often took months of refinement and deserve to sit in the store as pages you hold.

The government spells this out in its own purchasing guidance. Its technology contracts must be explicit about the ownership of intellectual property involved in the delivery of a technology service (including software code and the business rules that process information between user interfaces and stored data). The detail in the brackets is the useful part. Business rules are named alongside code as something with an owner, which is a higher standard than most businesses think to ask for.

We saw the practical version of this with a UK commercial flooring business whose RFQ processing we automated. Quote requests arrive as emails, spreadsheets, PDFs and photos, and the system extracts the details, scores its own confidence field by field and matches each request to the right customer account. Processing fell from around 20 minutes per RFQ to under 90 seconds, and at least 12 hours of office capacity came back every week. For this post, the part worth noticing is where the judgement sits. The confidence scoring and customer matching are written as explicit logic in a workflow a person can open, so whoever looks after the system next can see exactly how they work and change them.

The keys

Every account an intelligence system depends on should be in the company's name, with admin access held by a named person the business employs. That includes the repository or storage holding the knowledge, the automation platform, the account with the AI model provider and the billing on each of them. A partner should work through access you granted and can withdraw.

The way this goes wrong is almost always innocent. A partner opens an account in their own name to save a week at the start of a project, meaning to transfer it later, and the transfer never happens. Years afterwards the business runs on a system whose administrator works at another company, or whose login belongs to a personal email address of someone who has since moved on. Nothing is broken, so nobody notices, until the day a password needs resetting or a card payment fails. The same thing happens from the inside when someone on your own team holds those keys and leaves, which is why a proper handover treats access as part of the record.

The exit

The last thing you hold is the ability to leave cleanly, and it is mostly a consequence of the other five. If the files are open, the structure lives inside them, the history travels with them, the rules are readable and the accounts are yours, then ending a partnership is an afternoon of revoking access rather than a project.

Government contracts are designed around the same idea. Where it makes economic sense, they should include a break clause at a maximum of 2 years which allows you to terminate the contract with minimal exit costs. A break clause is only worth having if leaving is genuinely cheap, and a contract cannot make it cheap by itself. A clause can require a partner to hand everything back, but it cannot turn knowledge held in a proprietary shape into something another team can use.

So the handover you should expect is short. It is the knowledge store in its open format with its full history, the workflows and rules in a form someone else can read, admin access to every account, and a brief written note of how the pieces connect and what needs regular attention. If assembling that takes months, a good deal of what you thought was yours had been sitting with the partner.

Why this is cheap to get right at the start

None of this costs much if it is designed in. Plain files are no more expensive to keep than proprietary storage, an account in the right name takes the same five minutes to open as one in the wrong name, and a readable workflow is no harder to build than an unreadable one. Nearly all of the cost of ownership arrives later, and it only arrives for the businesses that never decided it.

That is the principle behind owning your intelligence, and it is why we build every system on the assumption that the client should be able to run it without us. The contract still matters. Its job is to record what the design has already made true.

Practical takeaways

1. Run the Friday afternoon test. Imagine the partner who built it gone by Monday and walk through whether someone new could open the knowledge, understand it, trace an answer, read the rules, log in and carry on. Each no is a specific gap you can fix, which is far more useful than a vague worry.
2. Open the knowledge on a laptop with no subscriptions. If it cannot be read and followed without a particular application, the format belongs to the vendor.
3. Ask where the links and fields live. If the structure sits in the tool's database rather than inside the files, an export will hand back pages without the arrangement that made them useful.
4. Treat business rules as intellectual property. Confidence thresholds, routing logic and refined model instructions are your judgement written as logic, and they should be readable and yours.
5. List every account the system depends on. Note whose name each one is in and who holds admin access. It usually takes about an hour, and it is the cheapest ownership fix there is.

Frequently asked questions

What do you own when you own an intelligence system?

Six things you should be able to point at. You hold the files themselves, in a format that opens without the tool that made them, and the structure that makes them navigable, meaning the fields and links, kept inside the files and not in a database only the software can read. You hold the trail behind every answer, which is its sources and a history of every change, along with the business rules and instructions the system follows. The accounts it runs on are in your company's name, and you know exactly what arrives if a partnership ends. Anything on that list that only exists inside someone else's system is on loan to you.

What format should company knowledge be in?

Plain text files in an open format, with the structure written into the files themselves. In practice that usually means Markdown pages with a short block of fields at the top recording dates, sources and ownership, and links between pages written as ordinary text. The test is simple. Copy the folder onto a laptop with no internet connection and none of your subscriptions, and see whether a person can still open it, read it and follow the links. If the answer depends on a particular application being installed or paid for, the format belongs to the vendor, whatever the product page says about exports.

What does data portability mean for an AI system?

It means everything the system knows can leave in a form another system can use straight away, without being rebuilt by hand. The legal right most people have in mind does not cover this. UK data protection law gives individuals a right to move personal data they have provided between services, and it gives a business no equivalent claim over the operating knowledge it has built up, so for a company, portability is in practice whatever was arranged at the start. For an AI system it also means the knowledge sits in readable pages the system retrieves from and not inside a model's trained weights, because a lesson baked into weights cannot be read, checked or carried to a different model.

Who should hold the accounts and credentials?

Your business, in its own name, with admin access held by a named person you employ. That covers the repository or storage where the knowledge lives, the automation platform, the account with the AI model provider and the billing on each of them. A partner doing the build should work through access you granted and can withdraw, never through accounts they opened on your behalf and still control. The usual failure is an innocent one. A partner sets up an account in their own name to save a week at the start, and years later nobody at the company can reset the password on a system the business runs on.

What should you receive when a partnership ends?

Everything needed to keep running the system, or to hand it to someone else, without asking the old partner a single question. That means the knowledge store in its open format with its full history, the workflows and business rules in a form someone else can read, admin access to every account the system touches, and a short written note of how the pieces connect and what needs regular attention. If the partner built it properly, very little of that should need producing at the end, because it was yours throughout. A handover that takes months to assemble is telling you where the ownership really sat.