A support agent asks the assistant where an order stands. It answers in a full sentence, with a date and a status, and it sounds certain. The status was correct at two in the morning, when the reporting table last refreshed. It is now mid afternoon, the order shipped at eleven, and the customer on the phone already has a tracking email the agent cannot see.
Nothing failed. No exception was thrown, no alert fired, and the model did exactly what it was asked to do. It read the freshest thing it had access to and reported it accurately. The problem sits upstream of the model, in the layer that decided which copy of the order it was allowed to read.
The Assistant Is Only as Current as the Table It Reads
That example is worth following all the way down, because the fix sits below the prompt. The order system owns order status. The reporting database holds a copy, refreshed by an overnight job, because that is what reporting needed and nobody was querying it in real time. When the assistant was wired up, the reporting database was the convenient source: already flattened, already fast, already permissioned for read, already documented.
The staleness window is the gap between the last refresh and the question. For a job that runs at two in the morning, an afternoon question reads data up to fourteen hours old, and a question asked shortly before the next run reads data nearly a full day old. For inventory counts, order status, ticket state, appointment times, or account balances, that window is long enough to be wrong in a way that reaches a customer.
A stale dashboard is survivable because it carries a timestamp in the corner and a person who has learned to distrust it before lunch. A sentence generated in confident prose carries neither. The agent reads it aloud to the customer.
Which Record Owns the Truth?
Before an assistant is connected to anything, every fact it will be asked about needs a named owning system. Order status belongs to the order system. Account entitlement belongs to the CRM. Invoice state belongs to the accounting system. Written down it sounds obvious, and it is routinely violated in practice, because the copy is always easier to query than the owner.
Once the owner is named, the useful question is how fresh the copy has to be for each fact, and the answers differ sharply inside a single assistant. A customer mailing address tolerates a day of lag without consequence. An order status does not tolerate an hour. Splitting retrieval by tolerance is usually cheaper than making everything real time: the assistant reads the flattened copy for slow-moving facts and calls the owning system directly for the two or three that move fast.
The Second Copy Nobody Deletes From
Retrieval that goes through an embedding index adds a copy that behaves differently from a replica, and the difference shows up in deletes. When a document is embedded and indexed, the index holds its own representation of that content. Teams naturally build the insert path first. The delete path is easy to leave out.
So a contract is superseded, a policy document is withdrawn, or a customer exercises a deletion request, and the record disappears from the source system. The embedding index carries on answering from it. The assistant cites a document that no longer exists, with no link that resolves and no row to reconcile against. Support cannot confirm the document was ever real without going to backups.
Vendors have not overlooked this. SQL Server ships a database scoped configuration named ALLOW_STALE_VECTOR_INDEX, which exists so a team can deliberately accept stale vector search results in exchange for being allowed to write to the indexed table. Earlier vector index versions leave that table read-only once the index is created. The newer version supports full data modification with automatic index maintenance, but it is currently available only in Azure SQL Database and SQL database in Microsoft Fabric. Which of those you are on decides whether your delete path is automatic, manual, or absent.
The check is the same whatever the retrieval technology. Delete a record in the source system, then ask the assistant about it. If it still answers, the delete path does not exist.
The Permission Check That Quietly Disappears
An assistant usually connects through a service account, because a service account is what makes the connection simple. That account can read everything the integration was granted. The person asking the question can read considerably less.
Where the retrieval query does not carry the identity of the requester, the assistant becomes a way around the permission model the application spent years getting right. A support agent scoped to one region can ask about accounts in another. A portal user can ask about a document belonging to a different tenant. The application would have refused both through its own interface. The assistant answers them, in prose, leaving no record that a boundary was crossed.
Filter at query time using the identity of the requester, not by trimming the model output afterwards. Post-filtering means the restricted data was already retrieved, already sitting in the context window, and already shaping what the model said.
What Support Sees When the Answer Is Wrong
The first wrong answer arrives as a complaint about the assistant. There is no stack trace attached to it, no failed job, and no error queue to work through. Someone still has to establish what happened, and a chat transcript alone will not get them there.
Log the retrieval alongside the conversation. For every answer, record which records were returned, their identifiers, the last-modified timestamp on each, and which system each came from. That converts an argument about whether the assistant can be trusted into a short factual check: the record it read was last updated at two in the morning, the order changed at eleven, and the retrieval went to the reporting copy. Now there is something specific to fix.
The same log answers the question that tends to arrive weeks later from somewhere else in the business, which is what the assistant told a named customer on a particular day.
Where IKRC Fits
The model is rarely the hard part of this work. Mapping which system owns each fact, deciding the freshness each answer requires, building a delete path into the retrieval index, and carrying user identity through to the query are ordinary integration and data problems. They are also the ones that decide whether anyone still trusts the assistant after the first month. That is the layer IKRC works at, through practical AI and software integration.
A useful first conversation is short. Name the five questions you want the assistant to answer, and for each one, say which system owns the answer and how old the copy is. Call IKRC at 646-783-1441 or email info@ikrc.co.
Related Reading
For where the retrieval index itself can live, read SQL Server Can Now Power Semantic Search Without a Separate Vector Database. For exposing your systems to AI tools deliberately, read Customer-Facing MCP Servers.
Need this solved in your software?
IKRC builds the custom systems, integrations, and modernization work discussed in this article.