LINE Chatbot · n8n Workflow Platform

ENGINEERING CASE STUDY · AGENT PLATFORM

Engineering case study

One LINE entry point routes varied AI tasks through semantic intent analysis into 19 independently maintainable workflows.

01

Problem & constraints

Problem

Putting RAG, fact checking, news, image, and web tasks into one bot flow quickly creates a tightly coupled system that is difficult to observe, test, and extend.

Constraints

• Users see one LINE conversation and expect the system to infer the task.
• Nineteen workflows use different APIs, data sources, and result formats.
• Capabilities must be independently added, replaced, or disabled.
• Every result must return through a consistent LINE-compatible message contract.

02

Architecture & decisions

System flow

1. 01 Conversation entry LINE Webhook · message context
2. 02 Intent routing Gemini intent analysis · task contract
3. 03 Main workflow n8n orchestration · error boundary · dispatch
4. 04 19 capability modules RAG · FACT · NEWS · IMAGE · WEB · data tools
5. 05 Response normalization result adapter · message formatting · LINE Reply API

Technology decisions

n8n

Keeps routing, external APIs, error branches, and transformation visible while allowing replaceable subflows.

Gemini intent routing

Handles mixed and incomplete natural-language task descriptions better than keyword-only rules.

Main flow + subflows

The main flow owns entry, routing, and the response contract; modules evolve independently.

LINE Messaging API

Validates the platform through a real conversation channel rather than a back-office demo.

03

My contribution

1. 01

   Designed the main flow, intent categories, subflow dispatch, and response contract.

2. 02

   Integrated 19 modules across RAG, verification, news, images, crawling, and data queries.

3. 03

   Handled LINE webhooks, message formats, API tokens, and service error boundaries.

4. 04

   Published importable n8n workflows and layered technical documentation.

04

Evaluation & outcomes

A capability matrix checks that prompts route to the correct subflow and that success, empty-result, and external-API failure paths all return through the same LINE response contract.

1

Primary entry flow Owns webhook, routing, and response segmentation

19

Modular subflows Separately maintainable and replaceable

5+

Capability groups RAG, verification, news, image, web, and more

05

Failures & corrections

01

Failure

Early capabilities were chained into one workflow, making additions harder to understand and debug.

Correction

Separated entry, intent routing, and capability execution into a main flow and subflows.

Lesson

Agent-platform scalability comes from module boundaries, not node count.

02

Failure

Keyword-only routing misclassified compound or ambiguous requests.

Correction

Used Gemini for a constrained intent result followed by deterministic n8n dispatch.

Lesson

Models handle semantics; workflows execute controlled decisions.

03

Failure

Modules returned incompatible text, image, and error shapes, growing LINE-side branching.

Correction

Introduced a result adapter and unified response contract.

Lesson

Tools can be heterogeneous, but the platform boundary must be consistent.

06

Evidence & further reading

Repository GitHub Repository ↗ Documentation Public workflow documentation ↗ Article Financial GenAI platform engineering → Article Enterprise Agentic AI architecture → Speaking iThome Cloud Summit Taiwan 2026 ↗ Speaking iThome AI Enterprise Summit 2026 ↗

Deep dive

Technical implementation notes

Detailed workflows, implementation decisions, diagrams, and project artifacts.

Context

When LINE is used as a corporate external or internal communication channel, users may raise diverse needs such as technical questions, news inquiries, or image generation. The scenario requires a single entry point to receive messages, automatically route them to the corresponding capability (RAG, fact-checking, news, image, scraping, etc.) based on the content type, and format the responses to be sent back to LINE.

Challenge

• If a separate Bot is built for each type of need, maintenance and user experience become fragmented; if a single workflow handles all types, the logic becomes too massive and difficult to scale.
• AI is needed to identify intent and route it to the correct sub-workflow, and the response must conform to LINE’s display constraints (e.g., automatically segmenting long text into a maximum of 5 messages).

Solution

Provide a smart LINE auto-reply bot: After a user sends a message, Google Gemini analyzes the content type and modularly routes it to the corresponding sub-workflow for processing, covering technical document summarization, fact-checking, RAG knowledge retrieval, news and stocks, image generation, web scraping, etc. Finally, it formats the response and sends it back to LINE (supports automatic segmentation of long text, up to 5 messages).

Architecture Overview

Main Workflow [MAIN] LINE CHATBOT: Receives LINE Webhook → Calls Gemini to analyze the message → Routes to sub-workflows based on content type → Aggregates AI responses → Sends segmented messages back to LINE.

The 19 Sub-Workflow Modules are divided into:

• AI Agents: 1399 RAG, MCP RAG, RAG Pipeline, ITR, FACT, CB, DR
• Information Processing: NEWS, News Agent Scrape, STOCK
• Image Processing: IMAGE Generator, Food Image, Image Editing, Image Module
• Web Processing: WEB, LINE CHATBOT Crawl
• Tool Support: SUBS Module, Database Query Tool, FACT linebot workflow

LINE Webhook → [MAIN] LINE CHATBOT (Gemini Intent Analysis) → Route Dispatch
    ├── RAG (Knowledge base retrieval)
    ├── FACT (Fact checking)
    ├── NEWS / STOCK (Real-time data)
    ├── IMAGE (Image generation & editing)
    └── WEB / CRAWL (Web scraping)
    → Result Adapter Normalization → Segmentation (≤ 5 messages) → LINE Reply API

Representative Path: Technical Document Q&A (RAG)

Tracing a user prompt such as “How do I deploy this documentation?”:

1. Webhook Ingestion: The main flow parses the incoming LINE POST request, extracting message text and replyToken.
2. Intent Classification: Gemini performs semantic classification, outputting a TECH / RAG dispatch payload.
3. Subflow Execution: The 1399 RAG subflow queries the backend knowledge base and receives grounded context.
4. Adapter Normalization: The Result Adapter converts raw answers into formatted Traditional Chinese under 500 words, chunked into up to 5 LINE chat bubbles.

Error Handling Boundaries and Author Responsibility

• Implemented Safeguards:
  • External API timeout guards and fallback messages.
  • One-time verification of LINE Webhook tokens to avoid duplicate processing.
  • Credential isolation: All API keys and secrets are injected via environment variables.
• Production Enhancements Required:
  • Cross-module distributed tracing (currently reliant on n8n execution history).
  • Automated exponential backoff and circuit breaking.
  • Human-in-the-loop escalation handoff.
• Responsibility Limits: I was responsible for the n8n topology, intent dispatch contracts, modular subflow boundaries, and LINE Messaging API integration. The underlying foundation models (Gemini, Jina, etc.) are consumed as third-party APIs.

If independent tracing is later introduced outside the workflow, permissions, writer identity, retention, and failure behavior must still define who can alter the audit evidence. The study of LLM agents tampering with their own traces provides concrete experiments for assessing that trust boundary.

Workflow Diagram (Can be paired with n8n course flowchart)

The following illustrates the conceptual levels of the n8n workflow; the actual main and sub-workflow diagrams can be viewed on the GitHub Showcase Site.

n8n Workflow Level 1

n8n Workflow Level 2 Example 1

n8n Workflow Level 2 Example 2

Tech Stack & Highlights

• n8n — Visual workflow design and execution
• Google Gemini — Message analysis and response generation
• LINE Messaging API — Webhook receiving and replying
• RAG / MCP RAG / FACT — Knowledge retrieval and fact-checking
• Modularization — Each function has an independent sub-workflow, making it easy to maintain and expand
• GitHub Pages — Workflow documentation and flowchart showcase site: poirotw66.github.io/n8n_workflow

Impact and Boundary Notes

• Topology Metric: 1 Main Workflow (LINE Webhook → Gemini Intent Analysis → Routing) + 19 Sub-Workflows, isolating failures across disparate AI capabilities.
• Unified Delivery Contract: A single conversation interface serves multiple specialized tasks through a shared Result Adapter.
• Operational Boundary: This project validates architectural modularity and routing logic; it does not claim enterprise uptime SLA or high-concurrency production load figures.

Extension

• Add more sub-workflows (e.g., order tracking, form filling, appointment scheduling) to continuously expand capability boundaries.
• Change the main workflow’s intent analysis to trainable or configurable rules, reducing reliance on a single model.
• Integrate internal APIs or CRM to complete business actions directly from conversations in one stop.

Related Links

• Repository: github.com/poirotw66/n8n_workflow
• Showcase Site (Flowcharts and documentation): poirotw66.github.io/n8n_workflow