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/

You write a script. Then you go back through it line by line, figuring out where a picture, a chart, or a screenshot should show up. So I built an AI automation that does this for me. I paste the script in, and it reads through every line, decides exactly where a picture is needed, and generates it right there. ✅ Reads your whole script and picks the exact moments that need a picture ✅ Skips the lines that don't need one, so nothing feels forced ✅ Generates the actual picture, not just a suggestion ✅ Remembers how you like things placed, so it gets better every time you use it ✅ If a picture takes a bit longer to generate, it waits and tries again on its own I hand it a script. It hands me back the same script, with each picture placed right after the line it belongs to. Link of the workflow in the comment 👇

Your agent runs. It returns a response. The demo looks clean. None of that tells you if the output is actually correct or safe to use. Working and being good are two different things. Here are the four ways to evaluate an AI agent. 🔧 Code-Based Evals Automated checks that look for exact matches, correct formatting, and valid data. Fast, cheap, and can run automatically every time you make a change. Good at catching broken structure, but can't tell if the answer actually made sense. 🤖 LLM-as-Judge A strong AI model grades the output against a set of rules, like a human reviewer would. Fast and can handle a lot of volume, but it can be biased toward outputs that sound like something it would write itself, even if they're not actually better. 🧑‍⚖️ Human Evals A real person, usually an expert, reviews the output against a strict rubric. Still the best option for judging nuance and complex reasoning. Slow and expensive, so it's best used to double-check that your AI judge is scoring things correctly, not as your everyday method. 👍 User Evals Real feedback from real people using the agent: thumbs up/down, whether they completed what they came to do, survey responses. This tells you what's actually useful. The downside is the feedback can be messy and you only find out something's wrong after it's already live. How these fit together in an n8n build: Automated checks run every time a workflow is updated. The AI judge handles day-to-day evaluation at scale. A small sample gets double-checked by a real person now and then to make sure the AI judge is still accurate. Real user feedback runs in the background the whole time. A workflow can pass every automated check and still be the wrong thing to build. Evaluation isn't one method, it's four, working together.

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.