The useful part of my agent stack wasn't better retrieval. It was making one customer change reach the right team automatically.

I connected six places where a B2B company keeps customer context: chat, tickets, wiki, CRM, mailboxes and meeting notes. The first version searched all six and returned grounded answers. Useful, but it didn't remove the real work. Someone still had to notice that a ticket, a CRM account and a meeting note referred to the same customer, decide which source was current, and copy the change to whoever needed it. That turned out to be a mapping problem more than a retrieval problem. The layer now maps source records onto shared entities while keeping the source, timestamp and quoted passage attached. When a new signal arrives, it can determine which customer, project or decision it belongs to, compare it with the current state, and route only the change to the subscribed team. One update can appear in a customer change radar and become proposed CRM or wiki updates without someone manually moving the information between systems. The difficult cases are surprisingly ordinary: a company gets renamed a parent and subsidiary share contacts people use a product name as the customer name the CRM says active while the latest ticket says blocked the same decision appears in chat and meeting notes with different wording Search can return all of that. It cannot tell you what belongs together or who should know. Permissions still run as the person asking, and writes are proposed for a human to approve. I see that as the trust boundary, not the main value. The main value is that a decision stops being trapped in the system where it happened. For people building cross-system agents: what fails first at volume: entity matching, deciding current truth, or routing changes without turning every channel into noise?