The Authoritative Store Problem: Why an Entitlements Table Decides Your LLM Roadmap

A consultant writing on dev.to published field notes from a week of AI integration work at a B2B company that has been shipping since 2014, and the week's actual content was not model selection but working out which of roughly twelve places customer data lives could be trusted ^[1][2]. The consequence is narrow and expensive: in that stack, the only system that knew which features a customer was entitled to was a MySQL application nobody wanted to discuss, and an assistant that answers "yes, you have access to X" without reading it will hallucinate entitlements and generate a support fire ^[3][4].

The brief was "an AI assistant that answers customer questions from our knowledge base and CRM," which the author calls a sentence rather than a specification ^[5]. His day-one work is mapping where data lives, who writes to it, and how stale it is by the time anyone reads it ^[6]. The heuristic he now applies is that the ugliest system in the stack is usually the real source of truth, and the presentable SaaS layered on top is a view, not a fact ^[7]. He will not touch a prompt until that map is signed off, and he treats an inability to say whether Salesforce or NetSuite wins a conflict on the same field as a sign the project is data governance wearing an AI costume ^[8][9].

That decision propagates into the plumbing. His rule of thumb is that synchronous HTTP to the model works when a user is waiting and the latency budget is under two seconds, and fails badly for anything touching more than two backend systems ^[10]. Webhook plus queue, on SQS, EventBridge, or a Postgres-backed queue, is where he puts about 70 percent of real B2B integrations ^[11]. Scheduled workers handle enrichment and backfills, and agent loops are reserved for branching decisions a deterministic workflow cannot express ^[12][13]. For this client he built an EventBridge bus in front of Lambda workers, fed by Zendesk and Salesforce webhooks, with a single agent loop for the one task that needs to check entitlements, retrieve the right knowledge base passage, and decide whether to escalate ^[14]. Everything else stayed linear, on the grounds that linear workflows are debuggable at 2am ^[15]. Notably, that agent task touches three systems, which is one more than his own ceiling for a synchronous call ^[17].

The retrieval side inherits the same authority question. The corpus was 4,200 Confluence pages, 18,000 closed Zendesk tickets, and a 380-page PDF manual, which is roughly 22,200 documents before chunking ^[18][19]. Each source refreshes on its own cadence: Confluence by API every six hours, Zendesk by webhook on ticket close, the PDF once with a manual re-ingest hook ^[20]. Chunks carry metadata including source system, last modified, author, and customer tier visibility ^[21], stored in Postgres with pgvector alongside a tsvector column, with vector and lexical results merged at query time by Reciprocal Rank Fusion ^[22][23]. He reports that hybrid retrieval alone fixed a class of failures where pure vector search missed exact product names and error codes ^[24]. The trap he names is the demo build: a prompt inside a Zapier or Make step writing back to a CRM with no queue, no retries, no idempotency key, and no audit log, which breaks the first time the model emits malformed JSON and leaves nobody able to say which record was corrupted ^[25][26].

What to watch: whether the conflict table is written down and versioned rather than agreed in a meeting, and whether entitlement checks read the MySQL system live or a cached copy, because a stale copy reintroduces the failure the architecture was built to prevent. The published notes cut off mid-sentence after the Reciprocal Rank Fusion step, so the reranking and evaluation layer is not described ^[27].