Every dental clinic has this problem. A patient gets told they need a crown, a root canal, a deep cleaning. It goes into the system as "planned." Then nobody follows up, and it just sits there. Forever. That's not a small leak. That's diagnosed revenue sitting on the books, unclaimed. So I automated the follow-up. Every morning it checks the practice's treatment plans for anything diagnosed but never scheduled. It emails the patient a reminder, then a firmer one, then a final one. The email never says what the treatment actually is, just "you have something pending, please call us." Privacy stays intact. If a high-value case goes cold after three emails, it stops emailing and tells the front desk to call the patient directly instead. Nothing gets forgotten, and nobody gets a sixth identical email. Every Monday, the practice owner gets one email. How many treatment plans got rebooked that week, and roughly how much revenue that represents. Built on n8n, Google Sheets (or the real Open Dental API), and Gmail. No AI deciding what to say to patients. Just rules and a spreadsheet as the source of truth. If you run a dental practice, or manage one, this exact thing is sitting in your system right now, quietly costing you money. Workflow link in the first comment 👇

A lot of people treat a large context window as memory. It isn't. Context window is working memory. Actual memory is a separate architecture problem, and it matters if you're running agents in production. Here's why bigger context alone doesn't fix it. Bigger context windows don't fix recall. A fact placed in the middle of a long context gets missed more often than the same fact placed near the start or end. So a larger window doesn't solve this, it just gives you more middle for things to get lost in. Context windows also don't know what matters. A critical instruction and a random comment get treated the same way. Nothing filters or ranks importance. And none of it lasts past the session. Once the conversation ends, everything is gone. The agent starts from zero next time, even with the same user, unless memory is built separately. In n8n, the fix is treating memory as its own layer instead of relying on context size. ✅ Simple Memory node handles short-term, per-session buffering. Works fine for single-instance setups. ✅ Postgres Chat Memory or Redis Chat Memory when you're on queue mode and need session isolation across workers. ✅ Chat Memory Manager when you need programmatic control, checking memory size, clearing old entries, or injecting specific context instead of letting the buffer decide on its own. ✅ A connected vector store (Pinecone, Weaviate, Qdrant, or swap in MongoDB Atlas) when you need semantic recall across thousands of past interactions rather than just the current session. ✅ Zep Memory node if you want automatic entity extraction (facts about users and sessions) without building that extraction logic yourself. Each AI Agent node takes one memory sub-node, so if you're combining conversation history with a knowledge base, the memory sub-node handles history and the vector store gets wired in as a separate tool. Source: https://blog.n8n.io/ai-agent-memory/

n8n shipped a new Agents tab. Separate from Workflows. Separate from the AI Agent node you already use. The AI Agent node still works exactly as before, nothing to migrate. Here's what's different: ✅ An agent used to be a node, tied to one workflow, existing only while that workflow ran ✅ Now an agent is defined once: model, instructions, tools, memory, sessions ✅ Reuse that same agent from a chat window, Slack, Telegram, a schedule, or any workflow through the new Message an Agent node What's worth knowing before you touch it: ✅ Your existing workflows can become tools the agent picks from ✅ MCP servers attach directly, no custom wiring needed ✅ Sensitive tools can require your approval before running ✅ Published agents can delegate work to other published agents ✅ The Sessions tab shows every past conversation, which tools ran, and what's pending approval It's a Preview release. Available on n8n Cloud and self-hosted, self-hosted starts from version 2.32.3. Expect it to keep changing. If you're self-hosted: enabling the module gets you the Agents tab. The moment an agent needs to call a tool like web search, you need a separate sandbox service running alongside your main container. That part isn't optional if you want tool use to actually work. Official docs: https://community.n8n.io/t/introducing-n8n-agents-a-new-way-to-build-agents-you-set-up-once-and-use-anywhere/306323 Anyone else tested this yet? Drop what broke for you.

Give it one product photo and a one-line idea for the ad. That's the only input. It writes the ad script for you using DeepSeek. No sitting there trying to figure out a hook. It generates a voiced, vertical video straight from that photo using kie.ai. No camera, no actor, no editor. Works in English or Hindi, so it's not another tool built for the US market and translated as an afterthought. Saves the finished video automatically before the link can expire, so nothing gets lost. Logs every request to a sheet, pass or fail, so you always know what ran and what didn't. Swappable video quality — run it cheap while testing an idea, then bump to a premium model for the final ad. Built this because most AI UGC tools are $100+/month SaaS products you rent forever. This is a workflow you own end to end. Workflow link in the comments below.

Quick clarification because I see this mixed up constantly, including in vendor marketing. DeepSeek, Qwen, Gemma, and Llama are all called "open source" regularly. None of them are. They're open weight, and that's a different thing. Open weight: trained parameters are downloadable, you can run the model on your own infrastructure and fine-tune it. Training code and training data are usually not included. Open source (strict definition, per the Open Source Initiative): weights + full training code + enough documentation on the training data that you could actually rebuild and audit the system from scratch, under a license with no usage restrictions. Very few models clear this bar. Closed model: no weights, no code, access only through an API. Claude, GPT, Gemini. Why it matters if you're building with these models: License terms vary a lot within "open weight." Llama's Community License requires permission above 700M monthly active users, and Meta can refuse it. DeepSeek's recent releases ship under MIT, no such restriction. Reproducibility is different too. Open weight lets you run the model. Open source lets you rebuild it. That distinction matters if you're doing anything where audit or reproducibility is a requirement, not just a nice-to-have. Before picking a model for a production workflow, check the license directly rather than going by the label on the model card. Three questions: are the weights actually available, is the training code available, what does the license permit you to do with it.