How We Built a Weekly RAG Update Cycle from Chats, Spreadsheets and Invoices

Open a normal week inside a company and the data is everywhere. A promise to a client sits in a chat. A shipment date sits in a spreadsheet. An accounting invoice lives in another system. The manager remembers why the quantity changed, but that explanation never reached the client record.

People like to start this conversation with vector databases and models. I do not. The first problem is collecting the material without losing where it came from.

At NF ELIT, the first workable rhythm was a weekly update. We collect raw information about clients, orders, shipment movements, invoices and manager notes, structure it, check it, run control questions, then refresh the database used by our retrieval-augmented generation system. Once a week. Simple enough to control, frequent enough to be useful.

The archive starts as a mess

A RAG archive does not begin as an archive. It begins as chat exports, spreadsheets with different client names, PDFs, accounting records, email, notes, status tables, duplicate files and documents with no clear date.

An agent can do the first sorting pass. It can identify the client, document type, date, order, invoice, shipment, people involved and possible relationships between records. It can also write a short description of what each document contains. That saves time. It does not remove the need to check the result.

If one client appears under three spellings, two invoices share the wrong order number, or a manager's note belongs to last year's shipment, the search system will not politely repair the history. It will retrieve the mistake faster.

What the weekly cycle actually looks like

1. Collect the raw sources. We pull the current client data, order and shipment movements, manager notes, tables, invoices and other documents added since the last update. Every item keeps its original source and timestamp.
2. Normalize names and identifiers. Client names, order numbers, invoice numbers, container references, dates and responsible employees need one consistent form. Similar text is not enough when the answer depends on an exact number.
3. Let agents structure the first draft. Agents classify the material, produce short descriptions, identify entities and suggest links between records. They reduce the pile. They do not get the final word.
4. Review conflicts and exceptions. Duplicates, missing dates, competing versions and unclear relationships go to manual review. This is where the process owner decides which source is current.
5. Run known-answer questions. We ask questions whose correct source is already known: which orders remain open, what changed in the quantity, what the manager promised, which invoice belongs to a shipment, where the status came from.
6. Refresh the searchable base. Only after the answers point to the right records do we update the knowledge base and its search index.

The index is the last step in that list. That order matters.

I described the document side of this design in more detail in Ask your corporate AI where the container is. The short version is that a document needs a record, a semantic map and the original source text. The weekly cycle is what keeps those layers connected to current work.

Why we started with once a week

Real-time updates sound better on a slide. They also need stable APIs, access rules, monitoring, change logs, source ownership and a clear response when one system sends bad data at 2:00 a.m.

A weekly batch gives you a clean control point. You know which period is included. You can review the exceptions before they enter the archive. If an import is wrong, you can stop it and return to the previous version. Most important, you learn what the company actually produces before building pipes for everything.

Start with a rhythm you can keep. Then make it faster.

The management problem is extra work

You can design a perfect form and tell every manager to fill it after every call. Then the real day begins. The call runs long, the client sends another message, a container moves, somebody changes a quantity, the form waits.

I ran into this as a manager during implementation. Asking employees and management to send material to one more place, follow one more format and remember one more step is hard. Even a good system loses if using it feels like a second job.

Corporate AI should be almost invisible to the people using it.

An employee should not need a course, a new daily ritual and another empty screen asking for a prompt. The system should collect information from the tools where work already happens, then return the useful part at the moment a decision is being made.

The next layer collects information by itself

The next step is to connect approved internal and external communication channels through APIs. At the end of the workday, or continuously where the source allows it, one agent produces source-linked summaries of the events that matter: a new client request, a changed delivery date, a promise made by a manager, an invoice received, a claim opened, a decision that affects an order.

A second agent checks those summaries against rules for the knowledge base. Which facts belong in the client card? Which event changes the shipment record? Which note is temporary? Which conflict needs a person? Approved information then enters the database and the RAG index can be refreshed.

This removes the worst part of the process. People keep working in email, chat, the CRM, accounting and logistics systems. The collection happens behind them.

Where the employee should see the result

The assistant should appear inside the work, not beside it.

During a sales conversation, it can show the latest client history, flag a missing fact and suggest a draft reply based on the current order. During logistics work, it can bring forward the last confirmed status, the exception, the responsible carrier and the next action. In a claim, it can collect the relevant messages, invoices, shipment records and dates, then suggest a correspondence strategy without pretending to make the final decision.

The person sees a clear suggestion and the sources behind it. The system does the searching.

Online updates come after discipline

The goal is an online knowledge base where new qualified information reaches the correct record quickly and the RAG layer searches current data. Getting there requires infrastructure, but the harder part is discipline.

Every important record needs a stable identifier. Permissions from the original systems need to survive retrieval. Updates and deletions need to propagate. The system needs logs, tests and a way to stop when the source is wrong. Real time does not mean every sentence from every chat belongs in the archive. It means the right event reaches the right record without somebody copying it by hand.

If an employee has to stop working to feed the AI, the system is unfinished. The assistant should collect quietly, show its sources and place the suggestion where the decision already happens.

Most people in the company should never think about RAG.

They should get better information at the right moment.