Engineering a Governed Multi-Agent RAG System for Consultative Customer Service

Abstract

This case study documents a published proof of concept for a fictitious travel company, ViaSul Experiências Turísticas. The business problem was to scale a consultative email service model without replacing personalisation with generic automation or allowing a probabilistic model to claim that operational actions had been completed. The implemented solution combines Microsoft Outlook, n8n, local open-source language and embedding models through Ollama, Supabase-based retrieval-augmented generation, Google Drive ingestion, Google Sheets operational persistence, specialised agents, deterministic routing, conversation memory, human handoff, and calendar integration.

The evidence demonstrates successful tests for document-grounded replies, insufficient-evidence escalation, human-notification verification, two-step call scheduling, persisted conversation state, repeated-confirmation blocking, defensive fallbacks, and controlled publication. No ROI, productivity percentage, or financial saving was measured. The demonstrated value is qualitative: improved operational control, traceability, source governance, and safer automation.

1. Introduction

The project began with a business tension rather than a technology preference. A consultative service model had to absorb growing email demand while preserving context, factual accuracy, and escalation to human staff when necessary. Simply adding a conversational model would not address the main operational risks: delayed responses, unsupported commercial claims, mixed customer contexts, duplicated actions, and confirmations sent before an integration had actually completed its work.

The strategic objective was therefore to prove that AI-assisted service could be scaled under explicit controls. The solution had to distinguish interpretation from execution, keep document retrieval separate from agent autonomy, preserve the state of multi-message interactions, and provide a safe termination path for unexpected conditions.

2. Problem Statement

3. Solution Architecture

The published solution is an event-driven n8n workflow with two operational entry points. Microsoft Outlook receives service emails. Google Drive monitors new commercial documentation for ingestion into the retrieval layer. A shared RAG subworkflow provides validated evidence to specialised agents.

Microsoft Outlook Trigger
  → Mark message as read
  → Prepare customer identification
  → Find customer by email in Google Sheets
  → Prepare registration result
  → Classify service destination
  → Route with Switch
      ├─ Sarah
      ├─ Fidelizer
      ├─ Concierge
      ├─ Operational continuation
      ├─ General human service
      └─ Orchestrator fallback

Google Drive Trigger
  → Download document
  → Extract text
  → Split document
  → Generate local embeddings
  → Store vectors and metadata in Supabase

The Orchestrator classifies but does not execute. Specialised agents interpret their assigned requests. A structuring chain converts intermediate responses into validated contracts. Deterministic n8n nodes then decide whether to reply, notify a team, write to a sheet, or create a calendar event.

Published workflow areas and nodes

Agent responsibilities

• Sarah: handles new-customer and new-purchase questions, replies from validated documentation, or requests human review.
• Fidelizer: supports returning customers, manages the two-step call-scheduling interaction, and uses persisted state for continuation.
• Concierge: supports customers with contracted travel and escalates unsupported or operational questions.
• Orchestrator: selects a route but has no operational tools.

4. Technology Stack

5. Implementation Journey

6. Technical Decisions and Architecture Rationale

7. Source Code Analysis

The implementation evidence includes n8n JavaScript expressions and JSON Schemas rather than a conventional application repository. The excerpts below are taken from the configured workflow expressions discussed and tested during implementation.

Conversation-scoped memory key

Purpose: bind Sarah's local memory to the normalised Outlook conversation identifier. Problem solved: prevents using an individual message ID or mutable customer attribute as the session key. Architectural role: supports continuity in the AI Agent without mixing distinct conversations.

{{
  String(
    $('Reunir Contexto da Sarah e RAG')
      .first()
      .json
      .conversation_id ?? ''
  )
}}

Technical analysis: the expression explicitly reads the normalised contract and applies an empty-string fallback. The dependency is the context-unification node. Security depends on ensuring the key is not empty in production execution. The pattern improves maintainability by reducing direct coupling to the trigger's raw field name. Simple Memory remains local to one n8n instance and was not validated for multiple workers.

Two-step state cleanup

Purpose: clear pending proposal attributes after successful event creation. Problem solved: avoids reusing a previously confirmed date and time. Architectural role: prepares the deterministic contract used to update the existing conversation-state row.

{{ '' }}

Technical analysis: an explicit empty string was used for ultima_acao_pendente, data_proposta, and horario_proposto. The pattern is intentionally simple because the Google Sheets update must clear previous cell values. The dependency is the successful Outlook Calendar path. This supports idempotency but does not itself address concurrent writes.

Fallback-safe message composition

Purpose: build a safe customer reply for an unknown Sarah action. Problem solved: avoids guessing the correct route while preserving a professional response. Architectural role: terminates the defensive branch before any operational action.

{{
  (() => {
    const nome = String(
      $json.nome ??
      $json.output?.cliente ??
      $('Reunir Contexto da Sarah e RAG').first().json.nome ??
      'cliente'
    );

    return [
      `Olá, ${nome}!`,
      '',
      'Não consegui processar a sua solicitação com segurança.',
      '',
      'Por favor, descreva novamente o que deseja solicitar para que o atendimento seja direcionado corretamente.',
      '',
      'Sarah',
      'ViaSul Experiências Turísticas'
    ].join('\n');
  })()
}}

Technical analysis: the expression prioritises current-item data, then the structured output, then the unified context. This made the node work both in the real path and in isolated controlled simulations. The nested fallback increases resilience but also couples the expression to named n8n nodes. The message intentionally avoids exposing technical details or claiming a completed action.

Restricted Sarah action schema

Purpose: constrain Sarah's structured decisions to a minimal contract. Problem solved: prevents obsolete or unsupported operations such as direct call scheduling. Architectural role: supplies deterministic input to the action Switch.

{
  "type": "object",
  "properties": {
    "acao": {
      "type": "string",
      "enum": [
        "responder",
        "encaminhar_atendimento_humano"
      ]
    },
    "cliente": { "type": "string" },
    "resposta_cliente": { "type": "string" },
    "necessita_atendimento_humano": { "type": "boolean" },
    "motivo": { "type": "string" }
  },
  "required": [
    "acao",
    "cliente",
    "resposta_cliente",
    "necessita_atendimento_humano",
    "motivo"
  ],
  "additionalProperties": false
}

Technical analysis: the enum limits the route space and additionalProperties: false rejects unplanned fields. The schema depends on the structuring chain and is not attached directly to Sarah's AI Agent. This improves reliability and security by reducing operational ambiguity. It also means any new action requires coordinated schema, routing, and downstream changes.

8. Challenges and Resolutions

9. Results and Outcomes

• Sarah produced a real document-grounded reply for a new-purchase request and preserved the Outlook conversation.
• An unsupported package question was escalated through Sarah without inventing the requested commercial fact.
• The human-service team notification was sent, success was verified, the customer was then informed, and the handoff was recorded in Google Sheets.
• The Fidelizer created one 30-minute Outlook event only after final confirmation in the same conversation.
• A repeated confirmation was blocked by the completed conversation state and did not create a duplicate event.
• Cancelled, inactive, unknown-state, notification-failure, unknown-agent, and unknown-action paths were validated through controlled simulations.
• The workflow was published after Google Drive credential recovery, with email and document-ingestion triggers active for controlled demonstration.

10. Engineering Highlights

11. Lessons Learned

1. Model intent is not operational proof. The workflow must verify the connector that performs the action.
2. RAG quality depends on evidence governance. Retrieving semantically similar text is not enough; validation and entity filtering matter.
3. State can be more reliable than memory for operational continuation. Persisted date, time, status, and pending action protected the scheduling process.
4. Fallbacks are part of the product, not an afterthought. Unknown values must terminate safely rather than silently or by guesswork.
5. Controlled simulations are valuable. They validated defensive routes without sending messages or creating events.
6. Publication readiness includes credentials. A correct workflow still cannot activate if a trigger credential is disconnected.

12. Future Improvements

• Implement persisted continuation for Sarah and Concierge.
• Replace local Simple Memory with a shared memory architecture if multiple workers or queue mode are adopted.
• Test concurrent Google Sheets updates and duplicate conversation rows.
• Define retention, deletion, and expiration rules for states, messages, and handoff records.
• Replace provisional internal email addresses with official corporate mailboxes.
• Implement monitoring, retry policies, incident response, and dependency-outage tests.
• Evaluate a technical-occurrence store, which was intentionally left outside the POC scope.
• Complete formal privacy governance, legal-basis mapping, data-subject processes, access controls, and legal review before real-customer production use.
• Confirm rotation or revocation of the previously exposed elevated Supabase key.

13. Conclusion

The ViaSul proof of concept demonstrates that a multi-agent RAG service can be implemented with local open-source AI while preserving explicit operational boundaries. Its most important contribution is not the number of agents. It is the architecture around them: deterministic identity, validated evidence, restricted contracts, visible routing, persisted state, real-operation verification, and defensive termination.

The project was published for controlled demonstration, not declared production-ready for real customers. That distinction is part of the engineering maturity demonstrated by the case. The evidence supports technical feasibility and qualitative improvements in control, traceability, and operational safety. It does not support unmeasured financial or performance claims.