WEBVTT 00:00:00.000 --> 00:00:01.960 We've all been there, especially those of us 00:00:01.960 --> 00:00:04.960 building really sophisticated automation. You've 00:00:04.960 --> 00:00:07.919 just mapped out this monster workflow, maybe 00:00:07.919 --> 00:00:11.500 50, 60 nodes deep. You're integrating data cleaning, 00:00:11.960 --> 00:00:14.400 logic gates, and I don't know. three different 00:00:14.400 --> 00:00:17.079 specialized AI models. And you finally hit that 00:00:17.079 --> 00:00:19.519 save button, and the whole editor just locks 00:00:19.519 --> 00:00:22.140 up. Exactly. And you're just watching that little 00:00:22.140 --> 00:00:26.379 progress wheel spin for three, four, maybe five 00:00:26.379 --> 00:00:29.079 agonizing seconds. And you're thinking, did I 00:00:29.079 --> 00:00:31.699 just lose the last 40 minutes of my work? That 00:00:31.699 --> 00:00:34.579 friction, it's such a productivity killer. But 00:00:34.579 --> 00:00:37.320 honestly, worse than the lag is the unreliability, 00:00:37.619 --> 00:00:39.700 especially when you start dealing with complex 00:00:39.700 --> 00:00:43.109 agents. You set up a workflow that needs a human 00:00:43.109 --> 00:00:46.030 to click approve over in Slack. And that approval 00:00:46.030 --> 00:00:48.829 step, it sits inside a sub workflow. Right. And 00:00:48.829 --> 00:00:51.250 in the old system, when that human action finally 00:00:51.250 --> 00:00:54.229 came back, maybe days later with the S, the main 00:00:54.229 --> 00:00:57.149 AI process would just crash. It would hit a total 00:00:57.149 --> 00:00:59.530 dead end. Why though? What was happening? Because 00:00:59.530 --> 00:01:02.049 it couldn't retrieve the context it needed to 00:01:02.049 --> 00:01:04.689 continue the job. The data, the entire state 00:01:04.689 --> 00:01:07.450 was just dropped on the floor, gone. That kind 00:01:07.450 --> 00:01:10.189 of systemic failure, especially in high -stakes 00:01:10.189 --> 00:01:13.209 multi -day automation, is exactly why we are 00:01:13.209 --> 00:01:15.930 doing this deep dive today. The core message 00:01:15.930 --> 00:01:18.909 here is that those pain points, they are now 00:01:18.909 --> 00:01:22.370 fundamentally fixed. We are analyzing the NADen 00:01:22.370 --> 00:01:25.150 2 .0 update. And this isn't just cosmetic. This 00:01:25.150 --> 00:01:28.150 is like a serious engine swap. It's designed 00:01:28.150 --> 00:01:31.769 to stabilize and exponentially speed up complex 00:01:31.769 --> 00:01:34.849 AI -driven workflows. Our mission today is to 00:01:34.849 --> 00:01:37.310 give you the shortcut, really, to the most important 00:01:37.310 --> 00:01:39.890 technical differences between version 1 .0 and 00:01:39.890 --> 00:01:42.670 2 .0. We've synthesized the critical technical 00:01:42.670 --> 00:01:44.750 docs, and we're going to unpack the four pillars 00:01:44.750 --> 00:01:47.510 of change that, honestly, build trust in your 00:01:47.510 --> 00:01:49.730 automation layer. We'll cover the visual overhaul 00:01:49.730 --> 00:01:52.099 and how that impacts your cognitive load. Then, 00:01:52.379 --> 00:01:54.760 the impressive architectural speed boosts. After 00:01:54.760 --> 00:01:57.560 that, the absolutely critical change to sub -workflows, 00:01:57.799 --> 00:02:00.480 which is the big breaking fix that enables robust 00:02:00.480 --> 00:02:02.799 agents. And finally, a new feature called the 00:02:02.799 --> 00:02:05.500 focus panel, which is just the ultimate context 00:02:05.500 --> 00:02:07.819 management tool for iterating on prompts. Let's 00:02:07.819 --> 00:02:09.159 make sure you hit the ground running without 00:02:09.159 --> 00:02:11.759 any migration snags. Let's do it. So let's begin 00:02:11.759 --> 00:02:14.580 with the aesthetics. the user experience overhaul. 00:02:15.080 --> 00:02:18.219 In version 1 .0, the nodes often had this kind 00:02:18.219 --> 00:02:21.819 of chunky, almost 3D look with drop shadows. 00:02:22.060 --> 00:02:25.400 Right, which felt visually heavy, you know. The 00:02:25.400 --> 00:02:27.900 source nodes point to a move to a flatter, more 00:02:27.900 --> 00:02:30.879 modern design, and that shift, it might sound 00:02:30.879 --> 00:02:33.300 small, but when you're zoomed out looking at 00:02:33.300 --> 00:02:35.699 a canvas with hundreds of connections and 50 00:02:35.699 --> 00:02:39.520 nodes, removing that visual clutter, what engineers 00:02:39.520 --> 00:02:42.830 call visual noise, the effect is instant. Okay, 00:02:42.969 --> 00:02:44.629 I appreciate the clean look, but I have to ask. 00:02:45.250 --> 00:02:47.550 Does a simpler, flatter design actually make 00:02:47.550 --> 00:02:50.449 complex workflows easier to debug? It absolutely 00:02:50.449 --> 00:02:53.159 does, and here's why. It's all about cognitive 00:02:53.159 --> 00:02:56.240 load. When you have overlapping shadows and unnecessary 00:02:56.240 --> 00:02:58.520 depth, your brain is just working harder to distinguish 00:02:58.520 --> 00:03:00.960 lines and boundaries. Flatter elements let you 00:03:00.960 --> 00:03:03.060 instantly parse the flow and spot misconnections 00:03:03.060 --> 00:03:05.360 way faster. Got it. So less brain power spent 00:03:05.360 --> 00:03:07.379 on just seeing things. Exactly. OK, here's where 00:03:07.379 --> 00:03:09.960 the usability upgrades really shine for me. The 00:03:09.960 --> 00:03:12.680 execution indicators. Before, when a workflow 00:03:12.680 --> 00:03:14.400 was running, you had to sort of squint to see 00:03:14.400 --> 00:03:17.000 this tiny spinning circle inside the node. Now 00:03:17.000 --> 00:03:19.960 they've gone with a much clearer glowing outline 00:03:19.960 --> 00:03:22.840 around the entire node. perimeter. It turns red 00:03:22.840 --> 00:03:25.400 when the node is working, and then a nice satisfying 00:03:25.400 --> 00:03:27.800 green when it's successful. You can track the 00:03:27.800 --> 00:03:30.159 status of critical bottlenecks instantly, even 00:03:30.159 --> 00:03:33.120 in massive workflows that span the entire screen. 00:03:33.419 --> 00:03:35.520 I also like the small quality of life details 00:03:35.520 --> 00:03:38.400 too. The connection points, those little diamonds 00:03:38.400 --> 00:03:40.979 or circles you click to link nodes, they now 00:03:40.979 --> 00:03:44.300 pop out. and pulse visually when you hover over 00:03:44.300 --> 00:03:47.099 them. That simple tweak dramatically reduces 00:03:47.099 --> 00:03:49.500 connection errors. We've all been there, misclicking 00:03:49.500 --> 00:03:51.340 those tiny targets when you're moving quickly. 00:03:51.560 --> 00:03:54.199 It's just less frustrating. Yeah, for sure. And 00:03:54.199 --> 00:03:56.439 speaking of workflow management, the sidebar 00:03:56.439 --> 00:03:58.800 on the left, where you access your node list 00:03:58.800 --> 00:04:01.259 and settings, it feels much smarter now. It's 00:04:01.259 --> 00:04:03.719 fully flexible. It's collapsible via a small 00:04:03.719 --> 00:04:06.039 arrow, which is great if you're on a laptop screen 00:04:06.039 --> 00:04:08.860 and need maximum canvas space. And crucially, 00:04:08.960 --> 00:04:11.379 you can also click and drag the edge to resize 00:04:11.379 --> 00:04:14.319 it, which is perfect for reading long execution 00:04:14.319 --> 00:04:16.480 logs without having to click into a whole separate 00:04:16.480 --> 00:04:19.839 window. Plus, they move direct settings, access 00:04:19.839 --> 00:04:22.000 for things like environment variables, execution 00:04:22.000 --> 00:04:24.540 limits, and the crucial migration report we'll 00:04:24.540 --> 00:04:27.560 get to later right into that sidebar. That eliminates 00:04:27.560 --> 00:04:29.259 several clicks every single time you need to 00:04:29.259 --> 00:04:32.170 check the plumbing. So in summary the aesthetic 00:04:32.170 --> 00:04:34.550 overhaul is really a functional overhaul, right? 00:04:34.709 --> 00:04:37.089 It reduces cognitive load and visual friction 00:04:37.089 --> 00:04:40.629 and that enables faster air spotting So the functional 00:04:40.629 --> 00:04:43.149 overhaul reduces cognitive load simple as that. 00:04:43.149 --> 00:04:45.970 Yeah. All right. Let's pivot from the aesthetics 00:04:45.970 --> 00:04:50.990 to Raw architectural horsepower the need for 00:04:50.990 --> 00:04:53.329 speed we mentioned the agony of that spinning 00:04:53.329 --> 00:04:56.389 save button was that three to five second delay 00:04:56.589 --> 00:04:59.209 fundamentally a database bottleneck in v1, or 00:04:59.209 --> 00:05:01.050 was something else going on? That's the right 00:05:01.050 --> 00:05:03.389 question to ask. The architectural notes confirm 00:05:03.389 --> 00:05:05.589 that the saving process itself was actually blocking 00:05:05.589 --> 00:05:07.709 the editor. It was a synchronous operation, you 00:05:07.709 --> 00:05:09.810 know, running validation and commit all in one 00:05:09.810 --> 00:05:12.610 go. That massive lag is now fundamentally gone. 00:05:12.689 --> 00:05:16.370 Saving is virtually instant. Whoa. Imagine the 00:05:16.370 --> 00:05:18.910 psychological relief that provides. When you're 00:05:18.910 --> 00:05:21.509 making a dozen small incremental tweaks to a 00:05:21.509 --> 00:05:25.009 complex prompt or a logic branch, that instantaneous 00:05:25.009 --> 00:05:28.720 feedback It just compounds into massive productivity 00:05:28.720 --> 00:05:31.500 gains. It eliminates a major point of context 00:05:31.500 --> 00:05:33.990 switching. You can stay in the flow of building 00:05:33.990 --> 00:05:36.490 without that forced pause. And more importantly, 00:05:36.550 --> 00:05:38.810 this speed boost, it isn't just a convenience 00:05:38.810 --> 00:05:41.910 feature, it's an architectural shift toward non 00:05:41.910 --> 00:05:45.129 -blocking asynchronous operations. And that architectural 00:05:45.129 --> 00:05:46.910 change is foundational for future features, right? 00:05:46.910 --> 00:05:49.089 Exactly. The source notes that instant saving 00:05:49.089 --> 00:05:52.209 is the critical prerequisite for reliable autosave, 00:05:52.389 --> 00:05:55.029 which they're targeting for January 2026. Ah, 00:05:55.029 --> 00:05:57.269 okay. Because saving no longer halts the editor, 00:05:57.350 --> 00:05:59.509 it can run reliably in the background, securing 00:05:59.509 --> 00:06:02.329 against data loss from browser crashes. or just 00:06:02.329 --> 00:06:04.209 accidentally closing a tab. Securing against 00:06:04.209 --> 00:06:06.790 data loss is a huge strategic win, absolutely. 00:06:07.529 --> 00:06:09.589 Another quality of life speed improvement is 00:06:09.589 --> 00:06:12.029 inside the node configuration windows themselves. 00:06:12.850 --> 00:06:15.110 Yeah, the navigation arrows at the top of the 00:06:15.110 --> 00:06:17.819 configuration panel. Those are lifesavers. You 00:06:17.819 --> 00:06:20.360 can quickly jump between nodes in a sequence 00:06:20.360 --> 00:06:23.439 without closing and reopening each one individually. 00:06:23.800 --> 00:06:25.839 So for example, if you're setting up a complex 00:06:25.839 --> 00:06:28.339 LLM agent where you need to configure the model, 00:06:28.800 --> 00:06:31.279 then the memory, then the tools, you can just 00:06:31.279 --> 00:06:33.379 navigate those sequential steps quickly without 00:06:33.379 --> 00:06:34.839 losing your place. You feel like you're staying 00:06:34.839 --> 00:06:37.860 in the zone. The strategic gain is just crystal 00:06:37.860 --> 00:06:41.279 clear, eliminating context switching. OK, so 00:06:41.279 --> 00:06:44.600 instant saving makes background autosave possible. 00:06:44.879 --> 00:06:47.500 which secures against data loss. That's the big 00:06:47.500 --> 00:06:49.639 takeaway. That's it. Now we need to slow down 00:06:49.639 --> 00:06:51.279 a little bit for this next segment because this 00:06:51.279 --> 00:06:53.699 is the most critical technical change in the 00:06:53.699 --> 00:06:56.870 update. If you use sub -workflows, or if you 00:06:56.870 --> 00:06:59.069 build human -in -a -loop AI agents, you need 00:06:59.069 --> 00:07:01.509 to pay absolute attention to these changes in 00:07:01.509 --> 00:07:04.329 reliability and terminology. This is where NAN 00:07:04.329 --> 00:07:06.970 2 .0 really proves its maturity. Let's revisit 00:07:06.970 --> 00:07:10.350 that problem in version 1. If an AI agent, your 00:07:10.350 --> 00:07:12.649 parent workflow, triggered a sub -workflow that 00:07:12.649 --> 00:07:16.089 had an asynchronous node -like waiting for that 00:07:16.089 --> 00:07:19.089 human approval, what exactly failed? The agent 00:07:19.089 --> 00:07:21.709 would pause, which is good. But when the human 00:07:21.709 --> 00:07:24.240 finally approved it, maybe hours or even days 00:07:24.240 --> 00:07:26.120 later, the agent would just lose the thread, 00:07:26.120 --> 00:07:28.939 right? Precisely. In V1, the system would lose 00:07:28.939 --> 00:07:31.360 the necessary execution token or the state handle 00:07:31.360 --> 00:07:33.879 required to reintegrate the sub -workflow's output 00:07:33.879 --> 00:07:37.040 when it returned asynchronously. The agent process 00:07:37.040 --> 00:07:39.379 couldn't retrieve the context, causing the entire 00:07:39.379 --> 00:07:42.420 main workflow to fail silently or hit that data 00:07:42.420 --> 00:07:44.839 -losing dead end we talked about. The documentation 00:07:44.839 --> 00:07:48.420 confirms this is fixed in 2 .0. So agents can 00:07:48.420 --> 00:07:50.810 now reliably trigger that sub -workflow wait 00:07:50.810 --> 00:07:53.290 for the human action, and then successfully receive 00:07:53.290 --> 00:07:55.550 the final result, the approval data, to continue 00:07:55.550 --> 00:07:58.540 the main job. This shift alone, it unlocks a 00:07:58.540 --> 00:08:01.459 whole new tier of complex, high -stakes automation. 00:08:02.120 --> 00:08:04.540 You can now design human -validated approval 00:08:04.540 --> 00:08:06.680 chains and compliance processes that you can 00:08:06.680 --> 00:08:09.540 genuinely trust not to fail mid -process. Now 00:08:09.540 --> 00:08:11.839 in tandem with that fundamental fix, there's 00:08:11.839 --> 00:08:14.040 a mandatory terminology change that will break 00:08:14.040 --> 00:08:16.639 all existing setups if you ignore it during migration. 00:08:16.920 --> 00:08:19.639 Correct. The workflow status terms active and 00:08:19.639 --> 00:08:23.819 inactive are now replaced by published and unpublished. 00:08:24.180 --> 00:08:26.149 And this is more than just semantics. it reflects 00:08:26.149 --> 00:08:28.589 a much stricter state management system. And 00:08:28.589 --> 00:08:30.790 the rule is absolute now. Yeah. A parent workflow 00:08:30.790 --> 00:08:33.330 can only call a sub -workflow if that sub -workflow 00:08:33.330 --> 00:08:36.490 is published. In V1, there were these confusing 00:08:36.490 --> 00:08:38.649 edge cases where you could sometimes call an 00:08:38.649 --> 00:08:41.570 inactive workflow, and it led to really unpredictable 00:08:41.570 --> 00:08:44.490 behavior. Now, if you forget to publish your 00:08:44.490 --> 00:08:47.850 helper workflow, the main process throws an immediate 00:08:47.850 --> 00:08:51.330 hard error. This stricter governance is just 00:08:51.330 --> 00:08:54.470 crucial for reliability. So before anyone updates, 00:08:55.110 --> 00:08:57.509 what is the single most necessary pre -update 00:08:57.509 --> 00:09:00.570 step for every user with existing sub -workflows? 00:09:00.830 --> 00:09:03.370 You need to toggle all existing helper sub -workflows 00:09:03.370 --> 00:09:05.909 from inactive to the new published status. Okay, 00:09:06.070 --> 00:09:08.269 that's it. Toggle all helper sub -workflows to 00:09:08.269 --> 00:09:10.190 publish before migrating. Don't forget that one. 00:09:10.429 --> 00:09:12.289 Let's transition now to a new feature that's 00:09:12.289 --> 00:09:14.690 really tackling the modern complexity of automation. 00:09:15.429 --> 00:09:17.570 Prompt engineering. If you spent any time writing 00:09:17.570 --> 00:09:20.129 system prompts for AI, you know that iterative 00:09:20.129 --> 00:09:24.159 loop can be just maddening. Oh, absolutely. The 00:09:24.159 --> 00:09:26.480 prompts are getting longer, more complex, and 00:09:26.480 --> 00:09:29.220 they rely so heavily on accurate variables drawn 00:09:29.220 --> 00:09:32.200 from many upstream nodes. You're constantly opening 00:09:32.200 --> 00:09:34.659 the node, writing the prompt, closing it, checking 00:09:34.659 --> 00:09:37.159 the canvas for the variable name, reopening the 00:09:37.159 --> 00:09:39.559 node, writing a little more. I still wrestle 00:09:39.559 --> 00:09:42.399 with prompt consistency myself. Just making sure 00:09:42.399 --> 00:09:45.200 I'm referencing the right input key when I'm 00:09:45.200 --> 00:09:48.159 six steps deep in a sequence. It's total workflow 00:09:48.159 --> 00:09:51.159 whiplash. The focus panel is designed to solve 00:09:51.159 --> 00:09:54.039 exactly that context switching problem. It lets 00:09:54.039 --> 00:09:57.200 users pin important lengthy fields like that 00:09:57.200 --> 00:09:59.860 system prompt or maybe a massive configuration 00:09:59.860 --> 00:10:02.360 JSON to the side of the screen. And the elegance 00:10:02.360 --> 00:10:04.460 here is that the pinned panel stays open and 00:10:04.460 --> 00:10:07.559 active while you still see the full editable 00:10:07.559 --> 00:10:10.000 workflow map. You can edit your prompt text in 00:10:10.000 --> 00:10:11.960 real time without obscuring the canvas at all. 00:10:12.120 --> 00:10:14.360 This creates the ultimate environment for prompt 00:10:14.360 --> 00:10:17.480 iteration. The efficiency example is so powerful 00:10:17.480 --> 00:10:19.960 you can copy a variable name directly from an 00:10:19.960 --> 00:10:22.559 upstream node on the canvas, say the output of 00:10:22.559 --> 00:10:25.059 a data cleaning step, and then paste it immediately 00:10:25.059 --> 00:10:27.259 into the pin prompt field without ever closing 00:10:27.259 --> 00:10:30.080 or flipping windows. That just drastically speeds 00:10:30.080 --> 00:10:33.080 up the iterative testing process. It turns what 00:10:33.080 --> 00:10:36.679 was a multi -step chore into a fluid single editing 00:10:36.679 --> 00:10:39.879 process. It's efficiency by continuous visibility. 00:10:40.450 --> 00:10:43.470 It's essentially a dedicated context management 00:10:43.470 --> 00:10:45.409 tool. You're no longer guessing about the flow 00:10:45.409 --> 00:10:47.809 or relying on your short -term memory. You see 00:10:47.809 --> 00:10:50.450 the live data flow while you configure. So does 00:10:50.450 --> 00:10:53.230 the focus panel address any issues beyond just 00:10:53.230 --> 00:10:56.720 text prompts? Yes. It simplifies editing any 00:10:56.720 --> 00:11:00.080 long critical field. Think about writing a massive 00:11:00.080 --> 00:11:03.059 detailed Slack message or building a complex 00:11:03.059 --> 00:11:06.480 HTML email body. You can edit that text while 00:11:06.480 --> 00:11:08.580 you're viewing exactly how the upstream data 00:11:08.580 --> 00:11:10.539 flows into it. So the focus panel simplifies 00:11:10.539 --> 00:11:12.820 editing any long field while viewing data flow. 00:11:13.360 --> 00:11:15.879 That's a great way to put it. Our final crucial 00:11:15.879 --> 00:11:18.940 segment is on safe migration strategies. This 00:11:18.940 --> 00:11:21.039 sounds like a terrifyingly complex update with 00:11:21.039 --> 00:11:23.179 breaking changes, but it sounds like AnyAnne 00:11:23.179 --> 00:11:25.720 has included tools to make the transition pretty 00:11:25.720 --> 00:11:27.500 straightforward and manageable. They definitely 00:11:27.500 --> 00:11:29.960 provided a strong safety net, which is critical 00:11:29.960 --> 00:11:33.139 for enterprise users. The main tool is the migration 00:11:33.139 --> 00:11:35.200 report, which you'll find in the settings under 00:11:35.200 --> 00:11:38.000 that little gear icon. What does that report 00:11:38.000 --> 00:11:42.019 actually... deliver? Does it fix things automatically 00:11:42.019 --> 00:11:44.440 for you? It scans all of your existing workflows 00:11:44.440 --> 00:11:46.860 and then assigns issues a score based on severity. 00:11:47.360 --> 00:11:49.840 It uses three categories. So things that will 00:11:49.840 --> 00:11:52.440 absolutely break, like that inactive sub -workflow 00:11:52.440 --> 00:11:54.879 status medium, which are things that might act 00:11:54.879 --> 00:11:57.059 differently due to deprecations, and then low, 00:11:57.139 --> 00:11:59.080 which are just minor changes. So the recommended 00:11:59.080 --> 00:12:01.620 strategy is clear. Fix the critical issues first. 00:12:02.490 --> 00:12:05.450 If you ignore those, especially the sub -workflow 00:12:05.450 --> 00:12:08.750 status changes, you could deploy an entire mission 00:12:08.750 --> 00:12:11.690 critical business process that just fails silently 00:12:11.690 --> 00:12:14.230 when it hits that required helper function. That's 00:12:14.230 --> 00:12:16.509 the risk. The migration report is designed to 00:12:16.509 --> 00:12:19.590 help you prioritize those fixes. However, if 00:12:19.590 --> 00:12:22.289 you need to manually move a single workflow from 00:12:22.289 --> 00:12:25.289 an older environment to a newer one, the fundamental 00:12:25.289 --> 00:12:27.009 underlying structure hasn't changed all that 00:12:27.009 --> 00:12:29.629 dramatically. Meaning you can still use the standard 00:12:29.629 --> 00:12:32.129 method of, what, krentl plus c and krentl plus 00:12:32.129 --> 00:12:35.710 v to copy workflows between instances. Correct. 00:12:35.730 --> 00:12:38.129 The underlying JSON code that describes the nodes 00:12:38.129 --> 00:12:40.450 remains mostly consistent across the versions, 00:12:40.529 --> 00:12:43.009 which really simplifies manual transfer if you're 00:12:43.009 --> 00:12:44.799 using version control or something. like that. 00:12:45.080 --> 00:12:47.519 And just to confirm for everyone listening, is 00:12:47.519 --> 00:12:51.279 N8n 2 .0 included for both the self -hosting 00:12:51.279 --> 00:12:53.899 community edition and for the cloud users? It 00:12:53.899 --> 00:12:56.039 is available across the board. This functionality 00:12:56.039 --> 00:12:58.779 upgrade is not a paywalled feature. And if a 00:12:58.779 --> 00:13:02.100 user doesn't use AI at all, is migrating still 00:13:02.100 --> 00:13:05.600 necessary? Yes, absolutely, because the new published 00:13:05.600 --> 00:13:08.399 status rule for sub -workflows applies universally. 00:13:09.059 --> 00:13:11.480 Any user calling a helper function from a parent 00:13:11.480 --> 00:13:14.399 workflow has to make that change to prevent errors. 00:13:15.019 --> 00:13:16.820 Okay, let's bring this deep dive home with the 00:13:16.820 --> 00:13:19.580 big idea recap. If you're integrating this into 00:13:19.580 --> 00:13:21.580 your automation stack, I think you need to remember 00:13:21.580 --> 00:13:24.000 the four pillars that build these new levels 00:13:24.000 --> 00:13:26.460 of trust in the system. First up, the visuals. 00:13:27.000 --> 00:13:29.519 A flatter design means drastically less cognitive 00:13:29.519 --> 00:13:32.559 load, and those glowing indicators give you instant 00:13:32.559 --> 00:13:36.179 debugging status. Second, speed. Instant saving 00:13:36.179 --> 00:13:38.580 eliminates the biggest building friction, and 00:13:38.580 --> 00:13:40.740 it's the architectural prerequisite for that 00:13:40.740 --> 00:13:42.919 reliable background autosave that's coming soon. 00:13:43.120 --> 00:13:45.940 Third, and this is the most critical one, reliability. 00:13:46.600 --> 00:13:49.000 AI agents can now correctly handle human -in 00:13:49.000 --> 00:13:51.799 -the -loop weight nodes. This eliminates frustrating 00:13:51.799 --> 00:13:54.440 and expensive dead ends by correctly preserving 00:13:54.440 --> 00:13:57.500 the execution state. And fourth, efficiency. 00:13:57.789 --> 00:14:01.070 The focus panel is the ultimate contact management 00:14:01.070 --> 00:14:03.850 tool, and it drastically speeds up the iterative 00:14:03.850 --> 00:14:06.870 process of complex prompt and long field editing. 00:14:07.009 --> 00:14:09.289 And if you take only one thing away today, remember 00:14:09.289 --> 00:14:12.190 the golden rule. Any sub -workflow you intend 00:14:12.190 --> 00:14:14.889 to call must be explicitly set to published. 00:14:15.289 --> 00:14:18.100 Do not ignore that step. This update really does 00:14:18.100 --> 00:14:20.179 feel like a massive leap in maturity for building 00:14:20.179 --> 00:14:22.799 durable enterprise -grade automation. It feels 00:14:22.799 --> 00:14:25.100 like it transitions an 8n from being a powerful 00:14:25.100 --> 00:14:27.720 tool to being a fundamentally trustworthy platform 00:14:27.720 --> 00:14:31.539 for complex processes. The reliability fix, specifically 00:14:31.539 --> 00:14:34.539 allowing AI agents to wait for and receive human 00:14:34.539 --> 00:14:37.779 validation data without state loss, that's revolutionary. 00:14:38.240 --> 00:14:40.840 It means we can finally design complex multi 00:14:40.840 --> 00:14:43.399 -stage approval chains and compliance flows that 00:14:43.399 --> 00:14:45.679 were previously just too brittle to even think 00:14:45.679 --> 00:14:48.509 about deploying. That raises a final provocative 00:14:48.509 --> 00:14:51.049 thought for you to consider. Knowing that your 00:14:51.049 --> 00:14:53.289 agents can now reliably wait for human input 00:14:53.289 --> 00:14:56.190 and pick up the process days later, how will 00:14:56.190 --> 00:14:58.649 this new level of trust change the kind of high 00:14:58.649 --> 00:15:01.090 -stakes, multi -step approval chains you dare 00:15:01.090 --> 00:15:03.500 to automate in your organization? The best thing 00:15:03.500 --> 00:15:05.960 you can do now is just try it out. If you're 00:15:05.960 --> 00:15:08.240 self -hosting, please remember to make a full 00:15:08.240 --> 00:15:11.340 database backup first, then run that migration 00:15:11.340 --> 00:15:13.539 report immediately. Start with those critical 00:15:13.539 --> 00:15:15.460 items and you'll find yourself running smoothly 00:15:15.460 --> 00:15:18.419 in 2 .0 very, very quickly. Find your migration 00:15:18.419 --> 00:15:20.460 report and let us know what you discover. We'll 00:15:20.460 --> 00:15:21.519 see you on the next deep dive.