I spent a month thinking about how to organise the information.
I called the process atomisation. The name was also a small tribute to my grandfather, who had an agricultural machine called an atomiser. His dealt with plants. Mine had to deal with my recorded calls and course material.
The material I described at the time included 2,800 recorded calls and almost 900 manuals, slide decks and other documents. The point was to extract the useful parts through a defined process, rather than throw everything in together.
I had to decide what to extract. How to extract it. What form the pieces should have, how to organise them and what relationships there should be between them.
The resulting database contained almost 50,000 pieces of knowledge. I wanted the AI to use my reasoning, examples and language when answering questions. That required deciding what those pieces actually were.
My real involvement was supplying the material and designing that extraction process. What should the pieces look like? What logic should they follow?
That was a lot of work.
The technical part, which is what frightens many people, involved me pressing keys and asking the AI which keys to press next. I was not becoming a software engineer. I was working out how my information should be structured, then getting help to build it.
This distinction matters when you think about using AI in a company. You know things about the work that the tool has not been given. You know why a document exists, which exception matters and what an answer would need to include to be useful.
Those decisions need to be made explicit. A folder full of material does not make them for you.
For my project, the work was deciding what knowledge to preserve and how the pieces belonged together. The code came after that.