Regulatory compliance
A compliance line that answers from the documentation, or says it cannot
A PIN-gated voice agent answering regulatory questions from verified documentation only, sitting on a knowledge base that keeps itself current without a developer.
Client: A disability-sector compliance advisory
System flow and narrative
Caller PIN: Valid. Retrieval: Match found. Path: Inbound call, then Document changed, then Weekly source crawl, then PIN collected, then Downloaded, chunked, then Checksum compared, then PIN validated, then Vector store updated, then Bridged to the agent, then Spoken question, then Semantic retrieval, then Answered from docs.
A compliance line that answers from the documentation, or says it cannot: system flow
Edges: live is a thicker, full-opacity, travelling dashed line; not taken is a thinner, dimmed, solid line. Nodes: live is a thicker, full-opacity outline; not taken is a thinner, dimmed outline. Color is never the only signal.
01
The call is authenticated before it is a conversation
An inbound call hits a Twilio webhook, which returns instructions to collect a PIN. That PIN is validated against a company registry before anything else happens. A valid PIN bridges the caller to the voice agent. An invalid one ends the call cleanly rather than dropping it mid-flow or leaving a half-open session behind. Authentication sits at the front because the system speaks to callers about regulatory obligations, and who is asking is part of the answer being appropriate.
02
Answering strictly from what is on file
Spoken questions route to an agent that retrieves exclusively from a vector store built out of verified compliance documentation. When retrieval finds something relevant, the caller gets an answer grounded in it. When nothing relevant is found, the agent returns a defined fallback rather than inventing a plausible one. That second path is the point of the whole design: in a compliance context a confident wrong answer is worse than no answer, so the system is built to be able to say it does not know.
03
The knowledge base maintains itself
The requirement was that the system stay accurate without developer intervention, so two workflows keep the store current and run independently of any call. A Drive webhook syncs the knowledge base as documents are created, updated or deleted, and a deletion removes the corresponding vectors, so withdrawn guidance cannot be quoted back to a caller weeks later. It is the same Pinecone store the retrieval step reads, which is why a withdrawn document stops being answerable the moment it is deleted. These run on their own trigger, which is why they sit beside the call path on this diagram rather than inside it.
04
Crawling without re-reading the whole web
A fourth workflow crawls a maintained list of compliance URLs weekly, checksums each page against what it stored last time, and skips anything unchanged. Most regulatory pages do not change from week to week, so the checksum step is what keeps a weekly crawl from becoming a weekly reprocessing of the entire corpus. It is a small decision that decides whether the maintenance workflow is sustainable or merely possible.
The branch logic, as a table.
| Condition | Then | Why |
|---|---|---|
| Caller PIN is Valid | Bridged to the agent | |
| Caller PIN is Invalid | Call ends cleanly | no partial session is left open |
| Caller PIN is Valid | Spoken question | |
| Caller PIN is Valid | Semantic retrieval | |
| Caller PIN is Valid, and Retrieval is Match found | Answered from docs | |
| Caller PIN is Valid, and Retrieval is Nothing relevant | Fallback returned | no relevant document, so no answer is invented |
| created, updated or deleted | Downloaded, chunked |
The stack.
| Layer | Tools |
|---|---|
| Telephony | Twilio |
| Voice AI | Retell AI |
| Orchestration | n8n |
| Language model | OpenAI |
| Vector store | Pinecone |
| Source crawling | Firecrawl |
| Documents | Google Workspace, Google Drive |
| Access control | Company PIN registry |
Compliance notes.
- Authentication sits at every external boundary, with credentials held in a credential store rather than hardcoded into the workflow.
- Retrieval is restricted to verified documentation, with a defined fallback instead of a guess when nothing relevant is found.
- A deletion in Drive removes the corresponding vectors in the same sync, so withdrawn guidance cannot be quoted back to a caller.
- Deliberate pauses precede every download and every batch upsert, keeping the system inside published rate limits.
- Failure paths are explicit rather than incidental: clean exits on bad PINs, fallback routing when retrieval finds nothing, and null-safety in the parsing code.
Before and after.
- Knowledge base currency
- Before: Updated by a developer when someone noticed it had driftedAfter: Drive changes and a weekly crawl keep it current with no developer involved
- Answer discipline
- Before: General model knowledge, unverifiable by the callerAfter: Verified documentation only, with a defined fallback when nothing matches
- Caller access
- Before: Questions answered by staff, during office hoursAfter: A PIN-gated line answering from the same documentation, at any hour
- Crawl cost
- Before: Every listed page refetched and reprocessed on every runAfter: Pages checksummed and skipped when nothing has changed
- Withdrawn guidance
- Before: Superseded documents stayed answerable until someone cleaned upAfter: A deletion removes its vectors in the same sync
This is one delivered system, published in full. See how we build AI automation
Want this on your own stack? See our n8n automation agency page.
Start a conversation
Tell us what you’re building.
Share the essentials and we’ll reply within 4 hours with a real next step, not an auto-responder.
What happens next
- We reply within 4 hours, from a real person, not an auto-responder.
- A short scoping call to understand the goal, constraints, and timeline.
- A fixed-scope discovery sprint: a working prototype and a written estimate.
- info@irenictech.com
- Office
- Austin, TX, United States
- Hours
- Mon–Fri · Async + scheduled calls