WEBVTT 00:00:00.000 --> 00:00:02.160 Learning AI automation, especially when you're 00:00:02.160 --> 00:00:05.580 diving into a tool like any T -Day, it can feel 00:00:05.580 --> 00:00:08.699 just incredibly overwhelming. Oh, absolutely. 00:00:08.960 --> 00:00:10.900 It's the sheer volume, right? You walk into this 00:00:10.900 --> 00:00:13.660 giant digital hardware store and you're surrounded 00:00:13.660 --> 00:00:16.539 by hundreds of nodes, connectors, all these specialty 00:00:16.539 --> 00:00:19.079 tools. And every aisle is unmarked. Everything 00:00:19.079 --> 00:00:21.859 looks useful, but you have no idea where to even 00:00:21.859 --> 00:00:24.440 start. You end up spending weeks just researching 00:00:24.440 --> 00:00:26.679 the tools instead of actually building the systems. 00:00:27.059 --> 00:00:29.300 That's the friction point for every serious learner. 00:00:29.879 --> 00:00:32.020 You want to create these intelligent, persistent 00:00:32.020 --> 00:00:34.719 systems, but you get completely stuck in the 00:00:34.719 --> 00:00:37.219 catalog. Our goal today is to just cut through 00:00:37.219 --> 00:00:39.960 all that noise. Yeah, with precision. I mean, 00:00:39.979 --> 00:00:42.359 we've built literally hundreds of these production 00:00:42.359 --> 00:00:44.479 workflows. And what we found is a core truth. 00:00:44.880 --> 00:00:47.359 You don't need 100 tools. You only need a foundational 00:00:47.359 --> 00:00:52.060 set of 10. 10. 10 specific N88 nodes that if 00:00:52.060 --> 00:00:54.759 you master them, cover something like 80 % of 00:00:54.759 --> 00:00:57.820 all. practical real -world AI automation you 00:00:57.820 --> 00:01:00.060 will ever need to build. These are the absolute 00:01:00.060 --> 00:01:03.439 essentials. So our mission in this deep dive 00:01:03.439 --> 00:01:06.620 is to untack these 10 core tools. We're going 00:01:06.620 --> 00:01:09.200 to move through it logically, you know, mirroring 00:01:09.200 --> 00:01:12.140 how a workflow actually runs. Okay, so where 00:01:12.140 --> 00:01:14.760 do we start? First, how we get data into the 00:01:14.760 --> 00:01:17.739 system. Second, how we teach the robot to think 00:01:17.739 --> 00:01:20.519 and connect. And finally, how we manage the flow 00:01:20.519 --> 00:01:22.620 so the system doesn't just collapse on itself. 00:01:22.900 --> 00:01:24.760 Let's start at the beginning then, the foundation. 00:01:25.600 --> 00:01:28.099 getting data in and getting it ready. All right, 00:01:28.120 --> 00:01:31.519 segment one. It's all about the first four critical 00:01:31.519 --> 00:01:34.379 nodes. They establish the start point, the input 00:01:34.379 --> 00:01:38.700 source, and the necessary cleanup process. Okay, 00:01:38.739 --> 00:01:40.739 so the first question has to be, how does the 00:01:40.739 --> 00:01:43.500 system even know when to run? That brings us 00:01:43.500 --> 00:01:45.700 to our first two nodes, the triggers. Number 00:01:45.700 --> 00:01:47.859 one is the schedule trigger. We call it the alarm 00:01:47.859 --> 00:01:49.840 clock. The alarm clock, I like that. It's the 00:01:49.840 --> 00:01:52.819 proactive element. You set a specific fixed interval 00:01:52.819 --> 00:01:55.959 for the workflow to activate. Daily at 6 a .m., 00:01:55.959 --> 00:01:58.599 hourly maybe every Monday morning. You use this 00:01:58.599 --> 00:02:00.260 when the robot needs to do work while you're 00:02:00.260 --> 00:02:02.900 completely offline. That's the perfect tool for 00:02:02.900 --> 00:02:06.079 persistent monitoring. I can program an AI workflow 00:02:06.079 --> 00:02:08.860 to check, say, the top five financial news sites 00:02:08.860 --> 00:02:11.560 every morning at 6 a .m., summarize the key points, 00:02:11.680 --> 00:02:13.719 and have that summary sitting in my inbox before 00:02:13.719 --> 00:02:16.560 I even wake up. Precisely. The pseudonym is working 00:02:16.560 --> 00:02:19.580 proactively on a schedule that you dictate. Now, 00:02:19.639 --> 00:02:22.180 if the schedule trigger is proactive... Node 00:02:22.180 --> 00:02:25.639 2, the event trigger, is purely reactive. This 00:02:25.639 --> 00:02:28.060 is the doorbell. Meaning it doesn't run on a 00:02:28.060 --> 00:02:29.979 schedule. Not at all. It just sits in the background, 00:02:30.240 --> 00:02:33.020 silent, consuming almost no resources. It only 00:02:33.020 --> 00:02:35.379 activates, it only rings when an external event 00:02:35.379 --> 00:02:37.840 happens. Like a new email landing in Gmail or 00:02:37.840 --> 00:02:40.099 a Slack message with a key phrase. Exactly. Or 00:02:40.099 --> 00:02:42.759 a form submission on your website. So mastering 00:02:42.759 --> 00:02:44.879 these two is really about changing your mindset 00:02:44.879 --> 00:02:48.259 from manually checking things to setting up passive 00:02:48.259 --> 00:02:50.520 immediate reactions. You stop hitting refresh 00:02:50.520 --> 00:02:53.090 on your screens. That's the key shift. Now, once 00:02:53.090 --> 00:02:55.310 data is flowing, we need a place to read from 00:02:55.310 --> 00:02:58.629 and write to. That brings us to node three, Google 00:02:58.629 --> 00:03:01.469 Sheets. We call it the digital notebook. Sheets 00:03:01.469 --> 00:03:04.490 is just ubiquitous. Everyone has access. Everyone 00:03:04.490 --> 00:03:07.009 kind of knows how to use it. And that's exactly 00:03:07.009 --> 00:03:09.590 why it's foundational. Your automation needs 00:03:09.590 --> 00:03:12.789 a simple, free, easily accessible place to store 00:03:12.789 --> 00:03:15.569 or retrieve data. Maybe your workflow needs to 00:03:15.569 --> 00:03:18.689 read a list of 500 leads from a sheet or write 00:03:18.689 --> 00:03:21.330 a summarized report back into a new row. I get 00:03:21.330 --> 00:03:23.189 the accessibility, but let me push back a little 00:03:23.189 --> 00:03:25.990 here. Why are we relying on a spreadsheet for 00:03:25.990 --> 00:03:28.349 potentially mission -critical data? I mean, isn't 00:03:28.349 --> 00:03:30.530 that inviting problems down the line compared 00:03:30.530 --> 00:03:33.719 to, say, a real database? That's a great question. 00:03:33.840 --> 00:03:35.879 And yes, for true enterprise scale, you move 00:03:35.879 --> 00:03:38.639 to dedicated databases. But for that 80 % of 00:03:38.639 --> 00:03:41.120 automations you build first, Google Sheets is 00:03:41.120 --> 00:03:44.879 a visual, non -scary database. It's free. It 00:03:44.879 --> 00:03:47.159 requires zero setup beyond logging in. And you 00:03:47.159 --> 00:03:49.360 can visually check the data. So it's the right 00:03:49.360 --> 00:03:51.479 tool for the beginning stage. It's the perfect 00:03:51.479 --> 00:03:54.020 accessible database until your workflow really 00:03:54.020 --> 00:03:56.219 demands more complexity. It just minimizes the 00:03:56.219 --> 00:03:58.180 friction to get started. Fair enough. Now we 00:03:58.180 --> 00:04:00.280 get to node four, which sounds crucial for stability. 00:04:00.969 --> 00:04:04.250 the edit fields node. This used to be the set 00:04:04.250 --> 00:04:06.610 node, right? Yeah. And we call it the label maker. 00:04:07.110 --> 00:04:10.490 This node is absolutely the Swiss army knife 00:04:10.490 --> 00:04:13.250 of data cleanup. And, you know, I'll be honest, 00:04:13.449 --> 00:04:16.009 I still wrestle with messy data input. Oh, me 00:04:16.009 --> 00:04:18.410 too. Sometimes the raw data coming from a trigger 00:04:18.410 --> 00:04:21.990 is just chaotic. Weirdly formatted timestamps, 00:04:22.069 --> 00:04:24.490 inconsistent names. You have to admit, managing 00:04:24.490 --> 00:04:27.050 input data is often the hardest part. I agree 00:04:27.050 --> 00:04:29.550 completely. We've all spent hours debugging a 00:04:29.550 --> 00:04:32.170 workflow only to find out a key field was labeled 00:04:32.170 --> 00:04:35.269 customer mail v2 in one place and email address 00:04:35.269 --> 00:04:38.089 in another. Exactly. This node lets you take 00:04:38.089 --> 00:04:41.430 that messy pile of data and impose order. rename 00:04:41.430 --> 00:04:44.250 fields, changing that awful first name 123 to 00:04:44.250 --> 00:04:46.629 just name. You can remove junk data you don't 00:04:46.629 --> 00:04:48.269 need and you can set the data type correctly. 00:04:48.529 --> 00:04:51.449 So if a later node, especially a picky AI API, 00:04:51.649 --> 00:04:54.069 expects a field called query and my input is 00:04:54.069 --> 00:04:56.870 labeled user prompt, the whole thing just stops. 00:04:57.089 --> 00:04:59.449 It breaks every time. The edit fields node is 00:04:59.449 --> 00:05:01.509 the guarantor of consistent labeling. It prevents 00:05:01.509 --> 00:05:03.509 the robot from getting confused. It ensures stability. 00:05:03.850 --> 00:05:06.050 So how important is that clean labeling really 00:05:06.050 --> 00:05:08.990 for these AI processes? It's everything. That 00:05:08.990 --> 00:05:11.569 consistency is what prevents the system from 00:05:11.569 --> 00:05:14.170 breaking down the line. Right. So with clean 00:05:14.170 --> 00:05:17.310 data in hand, we can pivot to segment two, logic 00:05:17.310 --> 00:05:20.189 and connections. These nodes teach the robot 00:05:20.189 --> 00:05:24.029 how to think and how to talk to the world outside 00:05:24.029 --> 00:05:26.870 and in. Now we start with decision making. Node 00:05:26.870 --> 00:05:29.970 five, the IF node. You call this the fork in 00:05:29.970 --> 00:05:32.009 the road. It's the simplest form of branching 00:05:32.009 --> 00:05:35.750 logic. It asks a single binary question. Is this 00:05:35.750 --> 00:05:39.060 condition true? Or is it false? And based on 00:05:39.060 --> 00:05:40.939 that yes or no answer, the data goes down one 00:05:40.939 --> 00:05:43.060 of two paths. Can you give us a practical scenario 00:05:43.060 --> 00:05:45.740 for that? Sure. A new lead comes from a website 00:05:45.740 --> 00:05:49.019 form. The IF node asks, is the email from a top 00:05:49.019 --> 00:05:52.379 -tier client domain? If yes, path A, it immediately 00:05:52.379 --> 00:05:55.660 texts your sales manager. If no, path B, it just 00:05:55.660 --> 00:05:57.899 saves the lead to Google Sheets for later. I 00:05:57.899 --> 00:06:00.019 love that. It moves the automation from a simple 00:06:00.019 --> 00:06:02.160 straight line into being truly context -aware. 00:06:02.339 --> 00:06:05.319 It prioritizes actions. It does. But sometimes 00:06:05.319 --> 00:06:07.629 two paths aren't enough. What if you need to 00:06:07.629 --> 00:06:09.870 decide between five different actions? That brings 00:06:09.870 --> 00:06:12.629 us to node six, the switch node, or the roundabout. 00:06:12.870 --> 00:06:15.110 So instead of a simple two junction, it's a traffic 00:06:15.110 --> 00:06:18.089 circle with multiple exits. Exactly. The switch 00:06:18.089 --> 00:06:20.629 node handles multiple possible paths based on 00:06:20.629 --> 00:06:23.449 a single piece of input. Imagine you're processing 00:06:23.449 --> 00:06:26.290 uploaded files. The switch node checks the file 00:06:26.290 --> 00:06:30.089 type. Exit one routes PDFs to an OCR agent. Exit 00:06:30.089 --> 00:06:33.709 2 sends images to be resized. Exit 3 handles 00:06:33.709 --> 00:06:36.490 text files. That makes complex workflows so much 00:06:36.490 --> 00:06:38.889 cleaner. I mean, chaining 10 IF nodes together 00:06:38.889 --> 00:06:41.970 would be a visual nightmare. It would. This keeps 00:06:41.970 --> 00:06:44.310 the whole diagram readable, which is half the 00:06:44.310 --> 00:06:46.230 battle when you have to maintain it later. Okay, 00:06:46.310 --> 00:06:49.769 now we get to the powerhouse. Node 7. The HTTP 00:06:49.769 --> 00:06:53.029 request node. You call this the universal translator. 00:06:53.269 --> 00:06:55.529 And this feels like the most powerful concept 00:06:55.529 --> 00:06:58.509 to grasp. It might sound technical, HTTP request, 00:06:58.810 --> 00:07:01.370 but understanding this node is the key to future 00:07:01.370 --> 00:07:03.810 -proofing your automation skills indefinitely. 00:07:03.810 --> 00:07:06.730 Explain that power simply for us. This node lets 00:07:06.730 --> 00:07:09.610 N8n communicate with any software anywhere on 00:07:09.610 --> 00:07:12.389 the planet that have an API. And an API is just 00:07:12.389 --> 00:07:14.889 a defined, structured way for two different computers 00:07:14.889 --> 00:07:17.269 or apps to talk to each other securely. That's 00:07:17.269 --> 00:07:19.850 all it is. And because pretty much every modern 00:07:19.850 --> 00:07:23.149 web service uses an API, this node guarantees 00:07:23.149 --> 00:07:25.529 a connection. Even if a brand new AI service 00:07:25.529 --> 00:07:27.610 launches next week and there's no dedicated button 00:07:27.610 --> 00:07:29.870 for it, you can still connect on day one with 00:07:29.870 --> 00:07:33.009 this node. That is massive. So let's use the 00:07:33.009 --> 00:07:35.850 example from the source accessing a tool like 00:07:35.850 --> 00:07:38.870 Perplexity's API, pretending there isn't a dedicated 00:07:38.870 --> 00:07:42.370 node. How does this node manage that secure connection 00:07:42.370 --> 00:07:45.600 with... Like an API key. Right. So you use the 00:07:45.600 --> 00:07:48.220 HTTP node, you paste in the API's URL, and you 00:07:48.220 --> 00:07:52.259 set the method, usually PPO or GET. For security, 00:07:52.420 --> 00:07:54.439 you define your credentials using the generic 00:07:54.439 --> 00:07:56.879 credential type. And crucially, you use header 00:07:56.879 --> 00:08:00.079 off for the API key. What's header off? Think 00:08:00.079 --> 00:08:02.300 of it like a secret invisible handshake that 00:08:02.300 --> 00:08:04.459 happens before the real conversation starts. 00:08:04.699 --> 00:08:07.019 It keeps your sensitive key hidden from the main 00:08:07.019 --> 00:08:09.579 request. I see. Security is built into the channel 00:08:09.579 --> 00:08:11.540 itself. Then you define the body of the request 00:08:11.540 --> 00:08:13.480 using JSON. This is where you actually ask your 00:08:13.480 --> 00:08:15.639 question. You're composing the prompt, the parameters, 00:08:15.759 --> 00:08:17.959 everything right there inside the node. So I'm 00:08:17.959 --> 00:08:20.620 defining the entire complex instruction set for 00:08:20.620 --> 00:08:23.699 an external AI service, sending it securely and 00:08:23.699 --> 00:08:25.699 getting the structured response back. Exactly. 00:08:25.819 --> 00:08:28.220 You could be getting a complex report from a 00:08:28.220 --> 00:08:31.540 brand new AI or just a random joke from some 00:08:31.540 --> 00:08:36.090 tiny API. The process is identical. Whoa. I mean, 00:08:36.110 --> 00:08:38.529 imagine scaling that. Connecting to a billion 00:08:38.529 --> 00:08:40.629 potential tools we don't even know exist yet. 00:08:40.769 --> 00:08:44.009 That ability to talk to the unknown is kind of 00:08:44.009 --> 00:08:45.789 breathtaking. It future -proofs you completely. 00:08:46.029 --> 00:08:48.210 Knowing this node means your skills won't expire 00:08:48.210 --> 00:08:51.009 when the next big thing launches. So what really 00:08:51.009 --> 00:08:54.070 makes the HTTP node the ultimate future -proofing 00:08:54.070 --> 00:08:56.789 skill? It lets you connect to any API immediately 00:08:56.789 --> 00:08:59.370 without waiting for a pre -built connector. Okay, 00:08:59.409 --> 00:09:02.049 so we've established how to get data in, clean 00:09:02.049 --> 00:09:04.389 it, make decisions, and connect to the entire 00:09:04.389 --> 00:09:07.470 internet. Our final segment, Nodes 8 through 00:09:07.470 --> 00:09:10.710 10, is about structure and flow, making workflows 00:09:10.710 --> 00:09:13.129 scalable and stable. Right, starting with Node 00:09:13.129 --> 00:09:15.909 8, subworkflows. We call these the helper robots. 00:09:16.269 --> 00:09:18.389 This is all about modularity. It reminds me of 00:09:18.389 --> 00:09:20.490 building a house. You don't build the whole thing 00:09:20.490 --> 00:09:23.090 yourself. You hire specialists, a plumber for 00:09:23.090 --> 00:09:25.549 plumbing, an electrician for wiring. That is 00:09:25.549 --> 00:09:28.509 the perfect analogy. A subworkflow is a separate, 00:09:28.629 --> 00:09:30.990 smaller automation that does one specific reusable 00:09:30.990 --> 00:09:34.269 job. Maybe it's a dedicated AI summarizer agent. 00:09:34.590 --> 00:09:37.950 Your main workflow just calls this specialist 00:09:37.950 --> 00:09:40.350 when it needs it. A power is in reusability, 00:09:40.490 --> 00:09:42.409 right? You build it once. Immense reusability. 00:09:42.830 --> 00:09:44.909 Let's say a request comes in from a Telegram 00:09:44.909 --> 00:09:47.399 chat. the main workflow intercepts it and then 00:09:47.399 --> 00:09:50.059 calls the sub workflow the sub workflow does 00:09:50.059 --> 00:09:52.220 all the complex research maybe using that http 00:09:52.220 --> 00:09:54.740 node we just talked about and then sends the 00:09:54.740 --> 00:09:57.100 clean final result back to the main workflow 00:09:57.100 --> 00:09:59.279 to deliver so you never have to rebuild that 00:09:59.279 --> 00:10:01.240 research tool logic again you just plug it into 00:10:01.240 --> 00:10:03.659 any future automation that must speed things 00:10:03.659 --> 00:10:06.019 up a lot it moves you from building these giant 00:10:06.019 --> 00:10:09.100 hard to maintain flows to just assembling reusable 00:10:09.100 --> 00:10:13.019 lego blocks of logic next up is node 9. the loop 00:10:13.019 --> 00:10:15.879 over items node, or the one by one. This one 00:10:15.879 --> 00:10:18.279 solves a really common and expensive mistake, 00:10:18.600 --> 00:10:21.779 rate limiting. This is absolutely critical. If 00:10:21.779 --> 00:10:24.700 your automation gets a list of, say, 100 customer 00:10:24.700 --> 00:10:26.940 emails that need processing, you might be tempted 00:10:26.940 --> 00:10:29.379 to fire all 100 requests to an external service 00:10:29.379 --> 00:10:32.100 like OpenAI at the same time. And what happens 00:10:32.100 --> 00:10:34.600 when I send 100 requests in one millisecond? 00:10:34.840 --> 00:10:37.539 The external service, whether it's ChatGPT or 00:10:37.539 --> 00:10:40.879 any other API, sees a sudden massive spike in 00:10:40.879 --> 00:10:43.240 load. They think it's a denial of service attack 00:10:43.240 --> 00:10:45.960 and they immediately block you or crash the connection. 00:10:46.480 --> 00:10:49.450 That's rate limiting. so this node acts as a 00:10:49.450 --> 00:10:53.190 safety valve exactly it forces sequential processing 00:10:53.190 --> 00:10:56.850 the loop over items node takes that big list 00:10:56.850 --> 00:10:59.669 and processes it one item at a time by setting 00:10:59.669 --> 00:11:02.269 the batch size to one it ensures every item is 00:11:02.269 --> 00:11:04.490 treated correctly without overwhelming the system 00:11:04.490 --> 00:11:07.350 it slows things down on purpose for the sake 00:11:07.350 --> 00:11:10.340 of survival That measured pacing sounds like 00:11:10.340 --> 00:11:12.000 the difference between a system that runs reliably 00:11:12.000 --> 00:11:14.580 for a year and one that crashes on its first 00:11:14.580 --> 00:11:17.919 big test. Precisely. And finally, node 10 is 00:11:17.919 --> 00:11:20.419 split out. We call this the bag of marbles node. 00:11:20.620 --> 00:11:23.460 That analogy instantly clicks. You have one bag 00:11:23.460 --> 00:11:25.659 with lots of individual items and you need to 00:11:25.659 --> 00:11:27.519 separate them. That's the function. It takes 00:11:27.519 --> 00:11:30.379 a single list of data, a big clump, and separates 00:11:30.379 --> 00:11:33.360 it into individual distinct pieces of data. But 00:11:33.360 --> 00:11:35.659 why is that separation necessary if the data 00:11:35.659 --> 00:11:38.129 is already flowing? Because most nodes that come 00:11:38.129 --> 00:11:41.009 after it work best, and sometimes only on single 00:11:41.009 --> 00:11:44.750 items. If you send a raw list of 10 email addresses 00:11:44.750 --> 00:11:48.169 to a standard Gmail node, it gets confused. It 00:11:48.169 --> 00:11:50.730 might try to put all 10 addresses into the to 00:11:50.730 --> 00:11:53.570 field of one email instead of sending 10 separate 00:11:53.570 --> 00:11:56.629 emails. Ah, I see. So the split out node makes 00:11:56.629 --> 00:11:59.909 sure every node gets one single clearly defined 00:11:59.909 --> 00:12:02.690 item to work on. It prevents data confusion. 00:12:03.129 --> 00:12:05.509 It eliminates that confusion entirely. It's the 00:12:05.509 --> 00:12:08.169 final structural cleanup before processing. It's 00:12:08.169 --> 00:12:10.250 amazing how often the stability of a complex 00:12:10.250 --> 00:12:13.090 system comes down to making sure a single clump 00:12:13.090 --> 00:12:15.629 of data doesn't overwhelm the machine. We just 00:12:15.629 --> 00:12:17.649 mapped out the first 10 foundational nodes you 00:12:17.649 --> 00:12:20.230 need. Honestly, the structure you now have is 00:12:20.230 --> 00:12:23.429 incredibly robust. Let's do a quick recap. You 00:12:23.429 --> 00:12:25.490 can trigger automations proactively with a scheduled 00:12:25.490 --> 00:12:27.730 trigger or reactively with the event trigger. 00:12:28.029 --> 00:12:30.649 You can store and clean data easily with Google 00:12:30.649 --> 00:12:33.129 Sheets in the edit fields node. You can introduce 00:12:33.129 --> 00:12:36.590 smart decision -making using IF and switch nodes 00:12:36.590 --> 00:12:40.169 to handle complexity. And the true game -changer, 00:12:40.309 --> 00:12:43.629 the HTTP request node lets you connect to literally 00:12:43.629 --> 00:12:46.149 anything on the internet today and everything 00:12:46.149 --> 00:12:48.710 that launches tomorrow. And you control the flow, 00:12:48.850 --> 00:12:51.990 making it stable, using sub -workflows, ensuring 00:12:51.990 --> 00:12:54.850 smooth processing with loop -over items, and 00:12:54.850 --> 00:12:57.580 eliminating data confusion with split -out. If 00:12:57.580 --> 00:13:01.000 you focus only on mastering these 10 tools, you 00:13:01.000 --> 00:13:03.440 fundamentally shift your whole approach. You 00:13:03.440 --> 00:13:06.059 move away from agonizing over which tool to pick, 00:13:06.139 --> 00:13:08.519 and you focus entirely on the outcome you want 00:13:08.519 --> 00:13:11.379 to create. It changes the conversation. And that 00:13:11.379 --> 00:13:13.299 leads to our final provocative thought for you 00:13:13.299 --> 00:13:15.169 to think about. We've covered the essentials 00:13:15.169 --> 00:13:17.830 of automation, the predictable logical movement 00:13:17.830 --> 00:13:20.269 of data. Yeah, you've built the highway and the 00:13:20.269 --> 00:13:22.730 traffic system. But what separates this powerful 00:13:22.730 --> 00:13:25.009 automation from true intelligence? What happens 00:13:25.009 --> 00:13:27.049 when the system needs to self -correct or adjust 00:13:27.049 --> 00:13:29.690 its own plan or reason about things? That is 00:13:29.690 --> 00:13:32.149 the essential pivot. We've given the system rules, 00:13:32.289 --> 00:13:33.769 but now we have to put a driver behind the wheel. 00:13:33.929 --> 00:13:36.309 That's the next level of complexity. True AI 00:13:36.309 --> 00:13:39.129 agents, dynamic code, high -level aggregation. 00:13:39.529 --> 00:13:41.429 That's where the real complexity and the real 00:13:41.429 --> 00:13:42.450 magic begins.