In‑Game Event Reminder with n8n & Vector Search

In this guide, you will learn how to implement a robust in‑game event reminder system using n8n, text embeddings, a Supabase vector store, and an Anthropic chat agent. The article breaks down the reference workflow template from the initial webhook trigger through vector storage and retrieval, all the way to automated logging and auditability.

Use Case: Why Automate In‑Game Event Reminders?

Live games increasingly rely on scheduled events, tournaments, and limited‑time activities to maintain player engagement. Managing these events manually or with simple time‑based triggers often leads to missed opportunities, inconsistent messaging, and limited insight into how players interact with event information.

By combining n8n with vector search and conversational AI, you can:

• Automatically ingest and index event data as it is created.
• Answer player questions about upcoming events using semantic search, not just keyword matching.
• Trigger contextual reminders based on event metadata and player queries.
• Maintain a persistent log of decisions and responses for analytics and compliance.

The template described here provides a production‑oriented pattern for building such an in‑game event reminder engine on top of n8n.

High‑Level Architecture of the n8n Workflow

The workflow template connects several components into a single automated pipeline:

• Webhook intake to receive event payloads from your game backend.
• Text processing with a splitter to convert long descriptions into manageable chunks.
• Embeddings generation to transform text chunks into vectors.
• Supabase vector store for persistent storage and semantic retrieval.
• Retriever tool and memory to provide contextual knowledge to the agent.
• Anthropic chat model to drive decision logic and generate responses.
• Google Sheets logging to capture an auditable trail of events and agent outputs.

This architecture enables a loop where event data is ingested once, indexed semantically, and then reused across multiple player interactions and reminder flows.

End‑to‑End Flow: From Event Payload to Logged Response

At runtime, the workflow behaves as follows:

1. The game backend or scheduler sends a POST request to the n8n webhook endpoint for new or updated events.
2. The incoming text (for example, event title and description) is split into overlapping chunks to preserve semantic continuity.
3. Each chunk is converted into a vector embedding using the Embeddings node.
4. These vectors are stored in a Supabase index named in‑game_event_reminder with relevant metadata.
5. When a player or system query arrives, the workflow queries the vector store for semantically similar items.
6. The retrieved context is exposed as a tool to the Anthropic‑powered agent, together with short‑term memory.
7. The agent decides how to respond (for example, send a reminder, summarize upcoming events, or escalate) and returns a message.
8. The final decision and response are appended to a Google Sheet for monitoring and audit purposes.

Key n8n Nodes and Their Configuration

Webhook: Entry Point for Event Data

The Webhook node serves as the public interface for your game services.

• Path: in‑game_event_reminder
• Method: POST (recommended)

Use this endpoint as the target for your game backend or job scheduler when a new in‑game event is created, updated, or canceled. For production use, do not expose the webhook without protection. Place it behind an API gateway or authentication layer and validate requests using HMAC signatures or API keys before allowing them into the workflow.

Text Splitter: Preparing Content for Embeddings

Long descriptions and lore documents need to be split into smaller segments so that embeddings and vector search remain efficient and semantically meaningful. The template uses the Text Splitter node with the following configuration:

• chunkSize = 400
• chunkOverlap = 40

This configuration provides a balance between context preservation and storage efficiency. For shorter event descriptions, you can reduce chunkSize. For long, narrative‑style content, maintaining a small chunkOverlap helps keep references and context consistent across chunks.

Embeddings Node: Converting Text to Vectors

The Embeddings node transforms each text chunk into a numeric vector suitable for similarity search. The template uses the default embeddings model in n8n, but in a production environment you should choose a model aligned with your provider, latency requirements, and cost constraints.

Key considerations:

• Use a single, consistent embeddings model for all stored documents to ensure comparable similarity scores.
• Document any custom parameters (such as dimensions or normalization) so that downstream services remain compatible.

Supabase Vector Store: Insert Operation

Once embeddings are generated, they must be persisted in a vector database. The template uses Supabase with pgvector enabled.

• Node mode: insert
• Index name: in‑game_event_reminder

Before using this node, ensure that:

• Your Supabase project has pgvector configured.
• The table backing the in‑game_event_reminder index contains fields for:
  • Vector embeddings.
  • Event identifiers.
  • Timestamps.
  • Any additional metadata such as event type, region, or platform.

Storing rich metadata enables more refined filters and advanced analytics later on.

Vector Query and Tool: Retrieving Relevant Context

When the agent needs contextual knowledge, the workflow uses a Query node to search the Supabase index for nearest neighbors to the current query.

The Query node:

• Accepts embeddings derived from the user or system query.
• Returns the top‑k most similar vectors along with their associated metadata.

The Tool node then wraps this vector search as a retriever that the agent can call as needed. This pattern is particularly useful when you want the agent to decide when to consult the knowledge base rather than always injecting context manually.

Memory: Short‑Term Conversational Context

The Memory node is configured as a buffer window that maintains a short history of the interaction. This helps the agent:

• Track the flow of a conversation across multiple turns.
• Reference previous questions or clarifications from the player.
• Avoid repeating information unnecessarily.

By combining memory with vector retrieval, the agent can respond in a way that feels both context‑aware and grounded in the latest event data.

Anthropic Chat Model and Agent: Decision Logic

The Anthropic chat node powers the language understanding and generation capabilities of the agent. The Agent in n8n orchestrates:

• The Anthropic chat model for reasoning and response generation.
• The vector store tool for on‑demand knowledge retrieval.
• The memory buffer for conversational continuity.

Typical responsibilities of the agent in this template include:

• Determining whether a reminder should be sent for a given event.
• Choosing the appropriate level of detail or tone for the response.
• Identifying when an issue should be escalated or logged for manual review.

Google Sheets: Logging and Audit Trail

To maintain observability and traceability, the workflow appends every relevant interaction to a Google Sheet.

• Operation: append
• Document ID: SHEET_ID
• Sheet name: Log

This provides a human‑readable record of:

• Incoming events and queries.
• Agent decisions and generated messages.
• Timestamps and other metadata.

While Google Sheets is convenient for prototypes and low‑volume deployments, you should consider a dedicated logging database or data warehouse for production workloads.

Example Scenario: Handling a Tournament Reminder

To illustrate how the template operates, consider a weekend tournament in your game:

• Your backend posts a payload to the webhook with fields such as event title, start time, and description.
• The workflow splits the description into chunks, generates embeddings, and inserts them into the Supabase index.
• Later, a player asks, “What events are happening this weekend?” through an in‑game interface or chat channel.
• The agent converts this question into an embedding and uses the Query node and tool to fetch the most relevant stored events.
• Using the retrieved context and memory, the Anthropic chat model composes a concise, player‑friendly summary of upcoming events.
• The response and associated metadata are appended to the Google Sheet for later analysis.

This pattern generalizes to daily quests, seasonal content, live events, or any in‑game activity that benefits from timely, contextual reminders.

Security, Privacy, and Operational Best Practices

When deploying an automation workflow that touches live game data and player interactions, security and governance are critical.

• Secure the webhook: Validate all incoming requests with signatures or API keys. Reject unauthenticated or malformed payloads.
• Control sensitive data: Avoid storing personally identifiable information (PII) in embeddings or vector metadata unless there is a clear policy, encryption in place, and a valid legal basis.
• Rotate credentials: Regularly rotate API keys for Anthropic, OpenAI (if used), Supabase, and Google Sheets.
• Manage vector growth: Monitor vector index size and embedding costs. Implement retention rules to remove outdated or low‑value vectors periodically.
• Audit agent behavior: Keep logs of agent decisions and responses. Use Google Sheets or a logging backend to support debugging, compliance, and model evaluation.

Scalability and Performance Considerations

As your player base and event volume grow, the performance characteristics of your workflow become increasingly important.

• Batch embeddings: When ingesting large numbers of events, batch embedding requests where possible to reduce API overhead and latency.
• Use upserts: For frequently updated events, use incremental inserts or upserts in Supabase to prevent duplicate vectors and maintain a clean index.
• Optimize vector search: If query latency increases, consider sharding your vectors, tuning Supabase indexes, or migrating to a specialized vector database such as Pinecone or Weaviate while preserving the same retrieval pattern.
• Introduce caching: Cache popular queries (for example, “today’s events” or “weekend schedule”) to serve responses quickly and reduce repeated vector queries.

Testing and Debugging the Workflow

Before exposing the workflow to production traffic, validate it thoroughly using n8n desktop or a Dockerized n8n instance.

Key areas to test:

• Webhook behavior: Confirm that only authenticated requests are accepted and that payloads are parsed correctly.
• Chunking quality: Inspect how the Text Splitter divides content and verify that each chunk remains semantically coherent.
• Embedding stability: Run the same text through the Embeddings node multiple times and confirm that vectors are consistent within expected tolerances.
• Query parameters: Tune the number of neighbors (k) and similarity thresholds to achieve high‑quality retrieval without irrelevant noise.
• Agent prompts: Iterate on system and user prompts used with the Anthropic chat model to ensure safe, consistent, and on‑brand responses for your player base.

Extending and Customizing the Template

The reference workflow is intentionally flexible and can be adapted to various game architectures and communication channels.

• Multi‑language support: Use multilingual embeddings models or language detection to route content to language‑specific pipelines, so players receive reminders in their preferred language.
• Additional notification channels: Integrate with push notifications, email, Discord, or in‑game UI messaging systems to deliver reminders through multiple touchpoints.
• Advanced analytics: Forward logs to a BI platform or data warehouse to track engagement metrics, reminder effectiveness, and event participation over time.
• Automated pruning: Implement scheduled jobs that score vectors by recency and relevance, then remove stale data to control storage and maintain search quality.

Deployment Checklist

Before going live, verify the following configuration steps:

1. Harden the webhook endpoint and confirm that all external credentials are stored securely.
2. Configure Supabase with pgvector, create the in‑game_event_reminder index, and validate the table schema and metadata fields.
3. Set environment variables for Anthropic, OpenAI (if applicable), Supabase, and Google Sheets API keys in your n8n environment.
4. Run end‑to‑end tests using representative event payloads and realistic player queries.
5. Set up monitoring and alerts for API usage, database performance, and cost anomalies.

Conclusion and Next Steps

This n8n workflow template offers a practical foundation for building a context‑aware in‑game event reminder system powered by semantic search and conversational AI. By orchestrating webhook intake, text splitting, embeddings, Supabase vector storage, and an Anthropic agent with memory, you gain a scalable solution that can adapt across different game genres and live‑ops strategies.

To start using this pattern in your own environment, import the template into n8n, configure your API keys and Supabase vector index, and run a set of test events that mirror your production scenarios. From there, you can extend the workflow with custom channels, analytics, and governance features tailored to your studio’s needs.

Call to action: Import this template into your n8n instance, connect your Supabase and Anthropic/OpenAI credentials, and begin automating in‑game event reminders. Subscribe for additional automation patterns and deep‑dive guides for game developers and live‑ops teams.

How One Legal Team Turned Case Law Chaos Into Clarity With n8n & LangChain

On a rainy Tuesday evening, Maya stared at the glowing screen in front of her. As a senior associate at a mid-sized litigation firm, she had spent the last three hours buried in a 120-page appellate decision. Tomorrow morning, she had to brief a partner on the key holdings, relevant citations, and how this case might reshape their strategy.

Somewhere between pages 63 and 87, Maya realized she was reading the same paragraph for the third time. The pressure was not just the volume of work. It was the feeling that important details might slip through the cracks, that a missed citation or misread holding could cost the firm time, money, or credibility.

Her firm had hundreds of similar opinions sitting in folders, PDFs, and email threads. Everyone knew they needed fast, consistent summaries of case law. No one had the time to build such a system from scratch.

That night, Maya decided something had to change.

The Problem: Case Law Everywhere, Insights Nowhere

Maya’s firm prided itself on being data-driven, but their legal research process still relied heavily on manual reading and ad hoc notes. Each new opinion meant another scramble to extract:

• Clear, consistent summaries of judgments
• Key facts and holdings that could affect active matters
• Citations and authorities worth tracking for future use
• A reliable audit trail in case any summary later needed to be reviewed

They had tried tagging documents in a DMS and building spreadsheets of important cases, but the system never scaled. Every new opinion felt like starting from zero again.

When a partner asked, “What did the court actually hold in Smith v. Jones, and which statutes did they rely on?” the answer usually involved a frantic search, a long PDF, and someone flipping between pages trying to remember where a certain passage lived.

Maya needed something better. An automated case law summarizer that could turn long, dense opinions into concise, searchable summaries without losing legal nuance.

The Discovery: A Case Law Summarizer Template Built on n8n

While researching legal-AI tools, Maya stumbled across an n8n workflow template: an automated Case Law Summarizer powered by LangChain-style agents, embeddings, and a Supabase vector store.

It promised exactly what her team needed. A production-ready pipeline that could:

• Ingest new case documents through a webhook
• Split long opinions into manageable chunks
• Generate vector embeddings for semantic search
• Store those embeddings in Supabase for fast retrieval
• Use a LangChain-style agent with OpenAI to draft structured summaries
• Log everything into Google Sheets for audit and review

She was skeptical but intrigued. Could a workflow template really handle the complexity of legal decisions? Could it preserve enough context to support follow-up questions like “What are the cited statutes?” or “Which authorities did the court rely on most heavily?”

There was only one way to find out.

The Architecture Behind Maya’s New Workflow

Before she deployed anything, Maya wanted to understand how the case law summarizer actually worked. The template diagram revealed a clean, modular architecture that felt less like a black box and more like a toolkit she could tune.

At a high level, the n8n workflow connected these pieces:

• Webhook (n8n) – receives new case documents or URLs
• Splitter – breaks long case texts into smaller chunks
• Embeddings (Cohere) – converts text chunks into vector embeddings
• Vector store (Supabase) – stores embeddings and metadata for fast semantic search
• Query + Tool – fetches the most relevant chunks for a given user query
• Agent (LangChain / OpenAI) – composes the final summary from retrieved context
• Memory – maintains short-term context for follow-up questions
• Google Sheets logging – keeps an append-only audit log of requests and responses

The more she read, the more she saw how each part solved a specific pain point she faced daily. This was not a generic chatbot. It was a focused legal-AI workflow designed for case law summarization and retrieval.

Rising Action: Turning a Single Case Into a Testbed

Maya decided to test the template with a single case that had been haunting her inbox: “Smith v. Jones,” a lengthy state supreme court opinion her team kept referencing but never fully summarized.

Step 1 – Ingesting the Case via Webhook

First, she configured an n8n webhook to act as the entry point for new cases. It exposed a POST endpoint where she could send the full opinion text, along with metadata like case name, court, and date.

Her initial test payload looked like this:

{  "case_name": "Smith v. Jones",  "court": "State Supreme Court",  "date": "2024-03-12",  "text": "...full opinion text..."
}

The webhook validated the input and captured the metadata, setting the stage for the rest of the pipeline. For the first time, “Smith v. Jones” was not just a PDF. It was a structured object ready for automation.

Step 2 – Splitting Long Opinions Without Losing Context

Next came the problem of length. Opinions like “Smith v. Jones” were far too long to send to a language model in one go. The template’s text splitter node solved this by breaking the opinion into chunks of around 400 characters, with an overlap of roughly 40 characters.

This overlap mattered. It preserved continuity between chunks so that key sentences spanning boundaries would still be understandable in context. Better chunks meant better embeddings and, ultimately, more accurate summaries.

Step 3 – Generating Embeddings for Semantic Search

Once the text was split, each chunk was sent to an embeddings provider. The template used Cohere, although Maya knew she could switch to OpenAI if needed.

For every chunk, the workflow generated a vector representation and stored essential metadata, including:

• case_id
• chunk_index
• character offsets for reconstruction

This step quietly transformed “Smith v. Jones” from a static document into a searchable, semantically indexed resource.

Step 4 – Persisting to a Supabase Vector Store

The embeddings and metadata were then inserted into Supabase, using Postgres with a vector extension as the underlying vector database.

To Maya, this meant something simple but powerful: she could now run semantic searches across her case corpus, instead of relying only on keyword search or manual scanning. Any future query about “Smith v. Jones” would pull the most relevant portions of the opinion, not just any text that matched a word.

The Turning Point: The First Automated Summary

With the opinion ingested, chunked, embedded, and stored, Maya was ready for the moment of truth. She opened a simple web UI connected to the workflow and typed a prompt:

“Summarize the holding and key facts of Smith v. Jones.”

Step 5 – Querying the Vector Store

Behind the scenes, the n8n workflow took her query and searched the Supabase vector store for the most relevant chunks. It used the embeddings to rank which portions of the opinion best addressed her prompt.

The top chunks were then passed to the next stage as context. No more scrolling through 120 pages. The system had already done the heavy lifting of finding the right passages.

Step 6 – Composing the Summary With an Agent and Memory

The heart of the workflow was a LangChain-style agent orchestrating an OpenAI model. The agent received:

• The case metadata
• The retrieved context chunks from Supabase
• A carefully designed system prompt

The system prompt looked something like this:

System prompt:
You are a legal summarizer. Given the case metadata and provided context chunks, produce:
1) A one-paragraph summary of the holding (2-4 sentences).
2) A bulleted list of key facts.
3) A list of cited authorities (if any).
4) A confidence score (low/medium/high).

Include chunk references in parentheses when quoting.

Maya appreciated how explicit this was. It asked for a structured output, required chunk references, and could be extended with examples for even more consistent formatting. Importantly, the instructions told the model to respond with “Not present in provided context” if a fact could not be verified from the retrieved chunks, which helped reduce hallucinations.

The agent then synthesized a concise summary, extracted holdings, listed citations, and even proposed a suggested search query for deeper research. The memory component kept track of the conversation so that when Maya followed up with, “What are the cited statutes?” the system could answer without reprocessing everything from scratch.

Step 7 – Logging for Audit and Review

Finally, the workflow appended a new row to a Google Sheet. It captured:

• The original request
• The generated summary
• Case metadata
• Timestamps and any relevant IDs

For Maya’s firm, this log quickly became an informal audit trail and a review queue. If a partner questioned a summary, they could trace it back to the original request and context.

Refining the System: Prompt Design and Configuration Tweaks

With the first few summaries working, Maya began tuning the workflow to better match her firm’s needs. She focused on three areas: prompt design, configuration, and compliance.

Prompt Design That Lawyers Can Trust

Prompt engineering turned out to be crucial for reliable legal summaries. Maya refined the system prompt to:

• Enforce concise holdings in 2 to 4 sentences
• Require bulleted key facts
• List cited authorities clearly
• Include a confidence score for quick risk assessment

She also experimented with providing example summaries inside the prompt. This helped the model keep formatting consistent across different cases and practice areas.

To limit hallucinations, she made sure the instructions clearly stated that if a fact was not supported by the retrieved chunks, the model must respond with “Not present in provided context.” That simple rule dramatically improved trust in the outputs.

Key Configuration Tips From the Field

As more cases flowed through the summarizer, Maya adjusted several technical settings:

• Chunk size and overlap – She tested different chunk sizes between 200 and 800 characters, balancing context depth with embedding cost and retrieval quality.
• Embedding model choice – While the template used Cohere for embeddings, she confirmed that OpenAI embeddings also worked well for semantic relevance.
• Vector indexing strategy – By storing metadata like case_id and chunk_index, the team could reconstruct the original ordering of chunks whenever they needed to review exact passages.
• Rate limiting and batching – For bulk ingestion of many opinions, she batched embedding requests and configured retries with backoff to handle API limits gracefully.
• Access controls – She locked down the webhook and the vector store with API keys and least-privilege roles to keep the system secure.

Staying Ethical: Privacy, Compliance, and Human Review

As the firm began to rely on the summarizer, Maya raised an important question: “What about privacy and compliance?” Even though many court opinions are public, some filings included sensitive or partially redacted information.

To stay on the right side of ethics and regulation, they implemented:

• Access logs and role-based access control for the summarizer
• Document retention policies aligned with firm standards
• Human-in-the-loop review for high-stakes matters, where an attorney always checked the AI-generated summary before it was used in client work

The n8n workflow made these controls easier to enforce, since every request and response was already logged and traceable.

Measuring Impact: Testing and Evaluation

To convince skeptical partners, Maya needed more than anecdotes. She assembled a small labeled dataset of past cases and evaluated how well the summarizer performed.

The team tracked:

• ROUGE or LU-style metrics to measure content overlap between AI summaries and attorney-written summaries
• Precision and recall for extracted citations and key facts
• User satisfaction based on attorney feedback
• Estimated time saved per case
• False hallucination rate, defined as claims not grounded in the input text

Within a few weeks, the data told a clear story. Attorneys were spending significantly less time on first-pass summaries and more time on analysis and strategy. The hallucination rate was low and dropping as prompts and configurations improved.

Keeping It Running: Operational Considerations

As usage grew, the summarizer needed to behave like any other production system in the firm. Maya started monitoring key operational signals:

• Queue depth for incoming case summaries
• Embedding API errors and retries
• Vector store size growth over time
• Per-request latency from ingestion to final summary

For scaling, she prepared a roadmap:

• Shard vector indices by jurisdiction or year to keep queries fast
• Archive older cases into a cold store with occasional reindexing
• Use caching for repeated queries on major precedents that everyone kept asking about

The beauty of the n8n-based design was that each of these changes could be implemented incrementally without rewriting the entire system.

Extending the Workflow: From One Tool to a Legal-AI Platform

Once the Case Law Summarizer proved itself, the firm began to see it as a foundation rather than a one-off tool. The modular n8n workflow made it easy to add new capabilities.

On Maya’s backlog:

• Adding OCR steps to ingest scanned PDFs that older cases often arrived in
• Running a citation extraction microservice to normalize references and build a structured database of authorities
• Integrating with the firm’s document management system so new opinions were summarized automatically upon upload
• Triggering human review flows for high-risk outputs, such as cases central to active litigation

What began as a single template had evolved into a flexible legal-AI pipeline that could grow with the firm’s needs.

A Day in the Life With the New Summarizer

Several months later, “Smith v. Jones” was no longer a dreaded PDF. It was a structured entry in the firm’s case database, complete with a concise summary, key facts, citations, and an audit trail.

A typical request/response flow now looked like this:

1. A client matter team uploaded a case PDF to the n8n webhook.
2. The splitter chunked the text, embeddings were computed, and everything was inserted into Supabase.
3. A lawyer opened the web UI and requested a summary for “Smith v. Jones.”
4. The system queried Supabase, retrieved top-k relevant chunks, and the agent synthesized a structured summary.
5. The result was logged automatically to Google Sheets for future review and compliance.

What used to take hours now took minutes. Instead of wrestling with text, attorneys could focus on arguments, strategy, and client communication.

From Chaos to Clarity: What Maya Learned

Looking back, Maya realized that the real value of the Case Law Summarizer was not just speed. It was the combination of:

• Accuracy through careful prompt design and vector-based retrieval
• Auditability through structured logging and metadata
• Scalability through n8n automation and a vector store like Supabase

By blending n8n, LangChain-style agents, embeddings, and thoughtful legal prompts,

Build an n8n AI Agent with Long-Term Memory

Conversational AI becomes significantly more useful when it can remember user details, store notes, and reuse that information across sessions. This guide describes a production-style n8n workflow template that implements an AI agent with:

• LangChain-style tool-using agent behavior
• Windowed short-term conversation memory
• Google Docs as long-term memory and note storage
• Optional Telegram integration for real user interactions

The focus is on a detailed, technical walkthrough of the workflow structure, node configuration, and data flow, so you can adapt the template to your own n8n instance.

1. Conceptual Overview

1.1 Why long-term memory in an AI agent?

Short-term context (recent turns in the conversation) is essential for coherent replies, but it is limited to the current session. Long-term memory enables:

• Persistence of user preferences, constraints, and goals
• Recall of recurring reminders or habits
• Re-use of user-provided notes and instructions across sessions

In this workflow, long-term memory is implemented using Google Docs as a simple, low-friction storage backend. One document stores semantic “memories” such as preferences or important facts, and another stores user notes and reminders. This separation keeps personal memory distinct from general note-taking content.

1.2 High-level workflow behavior

At a high level, the n8n workflow performs the following steps for each incoming chat message:

1. A chat trigger receives a new user message.
2. The workflow fetches long-term memories and notes from two Google Docs.
3. All context (incoming message, retrieved memories, retrieved notes) is merged into a single payload.
4. An AI Tools Agent node processes the request, using:
   • A system prompt that defines rules and behavior
   • One or more LLM nodes (for example, gpt-4o-mini and DeepSeek-V3 Chat)
   • A window buffer memory for short-term session context
   • Tools for saving long-term memories and notes back to Google Docs
5. The agent generates a reply and optionally writes new memory or notes.
6. The response is returned through a Chat Response node and can optionally be forwarded to Telegram.

2. Architecture & Components

2.1 Core nodes and roles

• When chat message received – Entry-point trigger (webhook/chat trigger) that receives user messages and session metadata.
• Google Docs nodes:
  • Retrieve Long Term Memories – Reads a dedicated document containing stored memories.
  • Retrieve Notes – Reads another document containing user notes and reminders.
• Merge + Aggregate – Combines the incoming message with retrieved documents into a single context object.
• AI Tools Agent – Orchestrator node that:
  • Invokes LLM nodes
  • Uses a window buffer memory
  • Calls tools for saving memories and notes
• LLM nodes:
  • gpt-4o-mini and/or DeepSeek-V3 Chat (or any compatible model)
• Window Buffer Memory – Maintains short-term conversational context keyed by session.
• Save Long Term Memories / Save Notes – Google Docs update operations used by the agent to persist data.
• Chat Response – Formats and outputs the final response for the chat channel.
• Telegram Response (optional) – Sends the response to a Telegram chat via a bot.

2.2 Data flow summary

Data flows through the workflow in a predictable pattern:

1. Input: Chat trigger receives message, sessionId, and any channel-specific metadata.
2. Retrieval: Google Docs nodes fetch the current memory and notes documents.
3. Context assembly: Merge/Aggregate node constructs a single JSON structure containing:
   • The current user message
   • Long-term memory entries
   • Note entries
4. Reasoning: AI Tools Agent node:
   • Loads the window buffer memory for the current session
   • Applies the system prompt and available tools
   • Chooses whether to write new memory or notes
   • Returns a reply text
5. Output: Chat Response node outputs the reply, and Telegram Response can forward it if configured.

3. Node-by-Node Breakdown

3.1 Trigger: When chat message received

Type: Webhook/chat trigger node

This node starts the workflow whenever a new message is received from the chat interface. It typically exposes fields such as:

• item.json.message – The raw user message text.
• item.json.sessionId – A session or user identifier used to scope the short-term memory.
• Optional channel-specific metadata (chat ID, user ID, etc.).

The sessionId is critical for isolating conversations between different users and preventing memory collisions.

3.2 Retrieval: Google Docs for memories and notes

3.2.1 Retrieve Long Term Memories

Type: Google Docs node (Get Document)

This node reads a specific Google Doc that stores long-term memories. Typical configuration:

• Operation: Get
• Document ID: ID of the memory document
• Credentials: Google Docs OAuth credentials configured in n8n

The node returns the document content, which is later parsed or passed as text into the agent context.

3.2.2 Retrieve Notes

Type: Google Docs node (Get Document)

This node is configured similarly to the memory retrieval node, but points to a different document dedicated to notes and reminders. Separating these documents allows the agent to apply different logic to each type of information.

3.3 Merge & Aggregate context

Type: Merge/Aggregate node

The Merge + Aggregate node combines:

• The incoming user message from the trigger
• The long-term memory document output
• The notes document output

The result is a single structured context payload that is passed to the AI Tools Agent node. This ensures the agent receives all relevant information in one place, simplifying prompt construction and tool usage.

3.4 AI Tools Agent and system prompt

Type: AI Tools Agent node

The AI Tools Agent is the central orchestration component. It uses a system prompt plus available tools and memory to decide how to respond and what to store. The system prompt typically encodes rules such as:

• How to interpret user messages and when to store new memories
• When to call the “Save Note” tool instead of “Save Memory”
• Privacy rules and constraints on what should not be stored
• Fallback behavior when information is missing or ambiguous
• Instructions to always reply naturally and to avoid mentioning that memory was stored

Representative responsibilities defined in the prompt:

• Identify and extract noteworthy information, such as user preferences, long-term goals, or important events, and store them via the Save Long Term Memories tool.
• Detect explicit notes or reminders and route them to the Save Notes tool.
• Generate a conversational reply that incorporates both short-term and long-term context.

3.5 LLM nodes

Type: LLM / Chat Model nodes

The workflow can use multiple LLM providers, for example:

• gpt-4o-mini via an OpenAI-compatible node
• DeepSeek-V3 Chat via a compatible chat model node

The AI Tools Agent selects and calls these models as part of its tool-chain. You can substitute or add other models that are supported by n8n’s LangChain/OpenAI wrapper, as long as credentials are configured correctly.

3.6 Window Buffer Memory

Type: Window Buffer Memory node

This node manages short-term conversational context. It stores a sliding window of recent messages for each session, keyed by a session identifier. The key expression usually looks like:

= {{ $('When chat message received').item.json.sessionId }}

This expression ensures that each user or session has its own isolated memory buffer. The buffer is then attached to the agent so the LLM can reference recent conversation history without re-sending the entire chat log.

Configuration typically includes:

• Session key: Expression referencing sessionId
• Window size: Number of messages to keep (to control token usage)

3.7 Long-term storage: Save Long Term Memories / Save Notes

3.7.1 Save Long Term Memories

Type: Google Docs node (Update / Append)

When the agent decides that a message contains memory-worthy information, it calls this tool. The node appends a structured JSON entry to the memory document. A typical JSON template used in the update operation looks like:

{  "memory": "...",  "date": "{{ $now }}"
}

This structure keeps entries compact and timestamped, which is helpful for later parsing or pruning.

3.7.2 Save Notes

Type: Google Docs node (Update / Append)

For explicit notes or reminders, the agent uses a separate tool that writes to the notes document. The template can follow the same JSON pattern as memories, but the semantics are different: notes are usually one-off instructions or reference items, not enduring personal facts.

3.8 Response & delivery

3.8.1 Chat Response

Type: Chat Response node

This node takes the agent’s generated reply and formats it for the chat channel. In the example workflow, an assignment is used so that the reply content is cleanly passed to downstream nodes. You can also map additional metadata if needed.

3.8.2 Telegram Response (optional)

Type: Telegram node

If you configure a Telegram bot token, this node can send the agent’s reply directly to a Telegram chat. This is useful for:

• Testing and debugging with a real messaging interface
• Deploying the agent for real users on Telegram

4. Configuration & Prerequisites

4.1 Required services

• n8n instance – Self-hosted or n8n cloud, with webhook access enabled.
• Google account – With Google Docs API enabled and OAuth credentials configured in n8n.
• LLM provider – Credentials for OpenAI-compatible or other supported LLMs (for example, gpt-4o-mini, DeepSeek-V3, etc.).
• Optional: Telegram bot – Bot token configured in n8n for sending chat messages to Telegram.

4.2 Key expressions and parameters

• Session key for Window Buffer Memory:

  = {{ $('When chat message received').item.json.sessionId }}

  This ensures each user or conversation has its own short-term memory buffer.

• Google Docs update templates:

  Use a compact JSON structure when appending entries, for example:

  {  "memory": "...",  "date": "{{ $now }}"
  }
  

  You can adapt the key names for notes, but keep them consistent to simplify downstream parsing.

• System prompt design:
  • Describe the agent’s role and tone of voice.
  • Define clear criteria for when to save a memory vs. a note.
  • Explain how to use each tool (Save Long Term Memories, Save Notes).
  • Include recent memories and notes snippets in the prompt context when needed.
  • Explicitly instruct the agent not to reveal that it is storing memory.

5. Best Practices & Operational Guidance

5.1 Memory design best practices

• Keep entries concise and structured: Avoid storing large unstructured blobs of text. Use short JSON objects with clear fields.
• Separate data types: Use distinct documents (or collections) for long-term memories vs. notes to keep semantics clear.
• Control short-term window size: Limit the window buffer memory length to avoid excessive token usage and stale context.
• Sanitize sensitive data: Do not store passwords, tokens, or highly sensitive identifiers. Add explicit instructions in the system prompt to avoid this.
• Audit tool usage: Log and monitor “Save Memory” and “Save Note” calls to understand what is being written to Google Docs.

5.2 Security & privacy considerations

When using long-term memory, treat stored data as potentially sensitive:

• Inform users about what information is stored and why.
• Restrict access to the Google Docs used as storage using appropriate sharing settings.
• Rotate Google credentials periodically and follow your organization’s security policies.
• Consider encrypting particularly sensitive data before writing it to Google Docs.
• If applicable, comply with GDPR, CCPA, or other regional data protection regulations.

6. Troubleshooting & Edge Cases

6.1 Common issues

• Google Docs nodes fail to read or update:
  • Verify the Document ID is correct and matches the intended file.
  • Check that Google Docs credentials are valid and have permission to access the document.
• Inconsistent or low-quality model responses:
  • Refine the system prompt with more explicit instructions and examples.
  • Ensure that the context you pass (memories/notes) is concise and relevant.
  • Increase the context window size if important information is being truncated.
• Too many memory writes:
  • Tighten the rules in the system prompt for what qualifies as a memory.
  • Require explicit user signals or stronger conditions before saving.
• Session collisions or mixed conversations:
  • Ensure sessionId is truly unique per user or conversation (for example, use chat ID or user ID).
  • Confirm that the Window Buffer Memory node uses the correct session key expression.

7. Example Use Cases

• Personal assistant: Remembers recurring preferences such as coffee orders, scheduling constraints, or favorite tools.
• Customer support bot: Recalls non-sensitive account context or past interactions across visits, improving continuity.
•