Short answer

Every new joiner and every change of tool means explaining all over again how the organisation works. If that knowledge were curated as the organisation's own cards, in plain text with sources, an owner, a version and a review date, any AI assistant could use it and the organisation could take it along when it changes vendor. The hard part is not the format. It is resolving contradictions between documents, deciding who approves each card and withdrawing from use anything that has expired or depends on a source that has changed.

Key points

  • If an AI assistant's context is built inside a vendor's tool, it is lost or has to be rebuilt when the organisation changes vendor.
  • Curating knowledge as the organisation's own plain-text cards, with sources, owner, version and review date, makes it reviewable and portable across AI tools.
  • The hard part is not the format but resolving contradictions between documents, deciding who approves each card and withdrawing whatever has expired.
  • An unapproved draft should not feed answers, and permissions must be applied before building the context an assistant receives, not afterwards.
  • It is best to start with one well-defined process, validate the first cards with the people who apply them every day and then extend by department.

Context should not live inside the tool

AI assistants give better answers when they know the organisation’s definitions, procedures and decisions. The usual approach is to build that context inside the tool: custom instructions, uploaded documents, the assistant’s own memory. When you change vendor, all of that is lost or has to be rebuilt.

A library of Markdown knowledge cards with metadata is independent of the tool. There are open formats still evolving, such as the Open Knowledge Format, that propose conventions for provenance, verification and validity; they are useful as an exchange format, not as a guarantee of compatibility with any given product.

A card is a reviewed decision

Two procedures may say different things about the same deadline: one mentions thirty days and another, more recent one, forty-five. A model can propose a draft that reflects both, but the contradiction is resolved by someone in the relevant department, who corrects the text, records the reason and approves it. The approval records owner, date and version.

Each card keeps its sources and a history. An unapproved draft should not feed answers, and a card whose source changes should stop being distributed until it has been checked and approved again. Validity expires: the review cadence is agreed with each department.

Each team receives its own context

Not everyone should receive every card. Finance needs the margin criteria; sales, the renewal terms; operations, its procedures. Permissions must be applied before building the context an assistant receives, not afterwards.

A card’s metadata describe its provenance and validity, but they are neither an access control nor a signature of authenticity. An exported package is not encrypted: accounts, permissions, backups and the exit procedure remain part of the implementation, not of the format.

Start with a well-defined process

Converting all the documentation in one go usually fails. It is more useful to choose a specific process, select its authorised sources, curate the first cards, validate them with the people who apply them every day and put them into use. The work is then extended department by department, with agreed owners and reviews.

The result is a shared set of criteria across departments and tools, onboarding and handovers backed by reviewed knowledge, and the ability to change AI vendor without starting from scratch. It is organisational work with technical support, not the other way round.

Frequently asked questions

How can we avoid losing the context we have given an AI assistant if we change vendor?

Keep that context out of the tool itself: custom instructions, uploaded documents and the assistant's own memory are lost or have to be rebuilt when you change vendor. The alternative is a library of the organisation's own Markdown cards with metadata, independent of any tool. Each card records its sources, owner, version and review date, so any AI assistant could use it.

What should we do when two internal documents say different things about the same procedure?

The contradiction is resolved by someone in the relevant department, not by the model. A model can propose a draft that reflects both versions, but that person corrects the text, records the reason and approves the card. The approval records owner, date and version, and the card keeps its sources and a history. If a source changes, the card should stop being distributed until it has been checked and approved again.

How do we control which internal knowledge each team receives when using an AI assistant?

Permissions must be applied before building the context the assistant receives, not afterwards, because not everyone should receive every card: finance, sales and operations need different things. A card's metadata describe its provenance and validity, but they are neither an access control nor a signature of authenticity. Accounts, permissions, backups and the exit procedure are part of the implementation, not of the format.

Where should we start when documenting the organisation's knowledge for use with AI?

With one well-defined process: converting all the documentation in one go usually fails. Choose a specific process, select its authorised sources, curate the first cards, validate them with the people who apply them every day and put them into use. Then extend department by department, with agreed owners and reviews.