Ask your corporate AI where the container is
Picture a normal question at work: where is the client's container right now, how much is left to ship, what did the manager promise last week and is there a new invoice?
At one company, the answer starts in the CRM, moves to email, then to a spreadsheet, then somebody calls the logistics manager. Twenty minutes later they discover the useful note was sitting in another manager's client record.
At another company, a person asks the same question in a corporate assistant and gets five useful lines: current status, remaining quantity, last promise to the client and links to the source documents. No full biography of the container from the day it was built.
The difference is not the model. It is what the model can see.
I'll tell you straight: a corporate assistant without a prepared internal knowledge base is like a new employee who gets a password to the shared drive and one instruction, figure it out. He will figure something out. He may even sound confident. That does not mean he found the right answer.
RAG does not organize chaos
Retrieval-augmented generation, or RAG, is a way to find relevant material in a knowledge base and give it to a language model when a question arrives. The model does not need to memorize your invoices, client cards, procedures or manager notes. It needs to retrieve the right source, read it and show where the answer came from.
There is one unpleasant detail. If the company has five versions of the same contract, a spreadsheet called final_2_really_final.xlsx, three spellings for one client and no dates on half the files, RAG will not repair the system by magic.
It will find the mess faster.
So the first job in corporate AI is not choosing a model. It is preparing knowledge that a model can actually read.
Three layers instead of one large index
At NF ELIT, we built retrieval in stages. The source set included corporate documents, financial materials, sales data, client records and manager notes. A document did not get one embedding and disappear into one large pile. It got a navigation layer.
The first layer was the document record. Title, type, date, version, owner, client, related process, access level. It also had a short description in plain language: what the document contains and when somebody should use it.
The second layer was the semantic map. A concise summary, main sections, companies, people, orders, invoices and shipments mentioned inside. At this level the agent checks its own route: yes, this is the document that can answer the question, not a neighboring file with a similar title.
The third layer was the source itself. Headings, paragraphs, tables, rows, pages. Now the agent can pull the exact passage, or read the full document when the question is broad.
This looks like extra work until you try searching only through small text chunks. A small chunk can answer a precise question and still lose the surrounding meaning. A large chunk preserves context and drags half the document into the answer. The hierarchy handles that normally: find the document, check its map, then open the passage.
Sometimes the exact word matters. Sometimes the meaning does
One search method is not enough for corporate data.
If somebody asks for an invoice number, a container number, a BOL, a product code or an exact phrase from a contract, you need full-text search. Exact identifiers should match exactly.
If the question is, "Why is this client delaying confirmation again?" or "What do we normally do when this exception happens?" you need semantic retrieval by meaning.
In practice, the two searches belong together. Hybrid search uses a lexical index for exact words and identifiers, embeddings for meaning, then merges and reranks the results. This matters in logistics and finance. A model can understand the meaning of shipment. It should find a container number without philosophy.
You can also add document context to each chunk before indexing it. Then a paragraph that says "payment within 15 days" does not float by itself. It carries a short note saying which client agreement and which version it belongs to. Contextual retrieval is one current approach to this problem.
It cuts down the number of polished answers built from somebody else's paragraph.
Documents need to know each other
The useful part starts when documents stop behaving like separate files.
An invoice is connected to a client record. The client record is connected to the manager and the manager's notes. Then come orders, shipments, claims, website analysis, public news, email. A shipment has its own links: container, trailer, carrier, dates, remaining quantity, documents, exceptions, current status.
Those links should not depend only on similar wording. Use stable identifiers such as client_id, invoice_id, shipment_id, manager_id. A graph layer can sit on top when questions genuinely cross several entities and documents. Microsoft GraphRAG, for example, models documents, text units, entities and relationships as separate connected objects.
The graph is not there because the word looks good in a presentation. It is there when the answer cannot exist without the relationship.
Take this question: "Which open invoices belong to this client's shipments that were delayed after the manager's last message?" One paragraph will not answer it reliably. The agent has to follow the links, collect several sources, compare dates, then write the answer.
Do not mix the archive and live data blindly
This is another boundary people miss.
Policies, instructions, contracts, notes and reference materials work well as indexed documents. Current balances, amounts, arrival dates, trailer locations and container statuses change over time. You cannot load them into a vector database once and call them true forever.
For that data, the assistant should query the live source through an API, SQL or a tool provided by the corporate system. RAG explains context. The API reports the state now.
You see this clearly in logistics. Connect carrier data or a tracking API, and a manager can ask, "What is happening with Client X's cargo?" The assistant finds the client record, open orders and recent notes, then requests fresh statuses from the carriers. The final answer keeps the exceptions and the next action. The rest stays behind the screen.
The user does not need to watch that route. The user needs the answer.
What belongs in the knowledge layer before the first question
Start with the raw material the company already has: CRM records, folders, PDFs, spreadsheets, procedures, email, notes, call transcripts. An agent can help sort it by subject, identify documents, versions, entities and possible links. The owners of those processes still have to check the result.
For every source, record a few plain things:
- What is the original, and where does it live?
- Who owns the data, and who is allowed to see it?
- How often does it change?
- What must be preserved word for word, and what can be indexed by meaning?
- How does it connect to a client, order, employee or shipment?
- How will the assistant show the source and the last update time?
Then enrich the base where it helps: the client's website, industry references, official registries, relevant news. Keep that external layer visibly separate from internal facts. A manager's note, a CRM record and an article on the internet do not carry the same weight.
And here is the main thing. After ingestion, write real control questions. Not "What is in the database?" Ask "Show the client's open orders," "Why did the amount change?" "What did the manager promise?" "Which shipments have not moved for more than two days?"
For each question, you should already know the correct source. That tests retrieval, not the beauty of the prose.
A packaged platform or your own layer
Commercial platforms already cover part of this work.
Bitrix24 stores CRM records, tasks, files and chats, and it can index document contents. Its CoPilot can summarize conversations and suggest updates to CRM fields. This works when most of the company's activity already lives inside Bitrix24. But its CRM search still depends on the fields in the record, and document search does not automatically turn files, notes, external statuses and entity relationships into one dependable knowledge system.
Microsoft 365 Copilot connectors bring external sources into search while respecting source permissions. Atlassian Rovo connects Jira, Confluence and third-party applications through Teamwork Graph. Salesforce Agentforce Data Library indexes knowledge articles, uploaded files and web sources around CRM workflows. Glean, ServiceNow and other enterprise search layers work in the same broad space.
The choice is simple. If the company already lives inside one ecosystem and the standard relationships fit the work, a packaged platform shortens the route. If the data is split among a CRM, a financial system, logistics APIs, local folders and custom processes, a company-specific layer built with APIs, a search index and an agent often fits better.
A prototype can be inexpensive now. I would not promise that the working system needs almost no setup. Access rules, document versions, updates, deletions, control questions, manual review of early results, all of that stays.
The model got cheaper. Order inside the company did not become free.
What the employee sees
From the outside, the whole thing should look simple. You open the normal interface and ask:
"Show the current status of this client's orders, the manager's latest promises and any shipments with an exception."
Inside, the system finds the client record, checks connected documents, reads the short descriptions, chooses the right passages, requests live statuses, applies permissions and builds an answer with sources.
The employee does not see that. Should not.
The employee sees five lines worth trusting.
That is what corporate AI should do.