Education
Ten-plus businesses on one workflow, and nothing crosses between them
One qualification system serving every centre, where tenant identity becomes a filter on every retrieval and every route, and intent is scored on each message.
Client: A network of independent learning centres
System flow and narrative
Enquiry for: Centre A. Intent score: Hot. Path: Inbound message, then Webhook acknowledged, then Centre identified, then Centre A filter tag, then Fields extracted, then Validated and cleaned, then Written to the record, then Purchase intent scored, then Score change appended, then Hot pool, then Centre A administrator.
Ten-plus businesses on one workflow, and nothing crosses between them: 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
Why one workflow and not ten
Ten-plus independent learning centres each ran their own ads into WhatsApp. Each needed its own knowledge base, its own conversation experience and its own lead pipeline. Ten separate systems would have meant ten deployments to patch every time anything changed, so the build is one workflow serving all of them with complete isolation between tenants. The first thing the pipeline does with a message, before any processing, is acknowledge the webhook, so the provider never times out and fires a duplicate delivery.
02
Identity becomes a filter, not a branch
The first processing step identifies which centre the enquiry belongs to, and that identity becomes a filter tag applied to every subsequent vector query. A centre's answers can therefore only ever come from that centre's own documents, and leads route only to that centre's administrator. Nothing crosses. Switching the control here changes the filter tag and the receiving administrator, and nothing else moves, which is the clearest way to show that isolation is structural rather than a rule somebody remembered to apply.
03
Extract, then validate, then write
Incoming messages pass through two agents in sequence. The first extracts structured fields from natural language. The second validates and cleans what the first produced, before anything is written. No unvalidated input reaches the database. Splitting extraction from validation matters because the failure modes are different: an extraction agent asked to also be careful tends to be less willing to extract, and a single agent doing both has no second opinion on its own output.
04
Intent as a running figure, not a final verdict
A separate scoring agent rates purchase intent on every message, appends each change to a score history, and moves the contact between cold, warm and hot pools as the conversation develops. Because the score is appended rather than overwritten, the shape of a conversation stays visible: a contact that warmed steadily reads differently from one that spiked once and went quiet. Warm and hot contacts route to their own centre's administrator; cold ones stay in the pool and keep being scored.
The branch logic, as a table.
| Condition | Then | Why |
|---|---|---|
| immediately, before the payload is parsed | Webhook acknowledged | |
| Enquiry for is Centre A | Centre A filter tag | |
| Enquiry for is Centre B | Centre B filter tag | |
| Enquiry for is Centre A | Fields extracted | the tag filters every later retrieval |
| Enquiry for is Centre B | Fields extracted | the tag filters every later retrieval |
| every message, not only the ones that move a pool | Score change appended | |
| Intent score is Cold | Cold pool | |
| Intent score is Warm | Warm pool | |
| Intent score is Hot | Hot pool | |
| Enquiry for is Centre A, and Intent score is Warm | Centre A administrator | |
| Enquiry for is Centre B, and Intent score is Warm | Centre B administrator | |
| Enquiry for is Centre A, and Intent score is Hot | Centre A administrator | |
| Enquiry for is Centre B, and Intent score is Hot | Centre B administrator |
The stack.
| Layer | Tools |
|---|---|
| Messaging | |
| Orchestration | n8n |
| AI agents | Extraction agent, Validation agent, Intent scoring agent |
| Retrieval | Vector store with per-tenant filter tags |
| Lead pipeline | Per-tenant pipeline and administrator routing |
Safeguards.
- Tenant identity becomes a filter tag on every vector query, so one centre's answers can only come from its own documents.
- Leads route only to that centre's administrator, so no contact is ever visible to a competing centre on the same system.
- The webhook is acknowledged before any processing, so the provider cannot time out and fire duplicate deliveries.
- Two agents run in sequence, extract then validate, so no unvalidated input reaches the database.
- Test numbers are filtered out of production, and concurrent messages from one contact cannot create duplicate records.
Before and after.
- Systems to maintain
- Before: One build per centre, each drifting from the othersAfter: One workflow serving every centre, with isolation between them
- Answer scope
- Before: Shared content, or a separate knowledge base per deploymentAfter: Every retrieval filtered by tenant, so nothing crosses
- Lead data quality
- Before: Free text written straight to the databaseAfter: Extracted, then validated and cleaned, before anything is written
- Intent visibility
- Before: Read the thread and form an impressionAfter: Scored on every message, with a history, moving the contact between pools
- Duplicate records
- Before: A slow reply or a double message could create two contactsAfter: The webhook acknowledges first and concurrent messages cannot duplicate
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