How I'd Learn n8n if I had to Start Over in 2026

0:00When I first started learning NAND, I

0:01brute forced my way through the learning

0:03process. And don't get me wrong, in a

0:04year I have learned a lot and become

0:06pretty proficient in Naden. But if I

0:07could start over in 2026, I'd do it

0:09completely differently because back then

0:11I thought the goal was to just build AI

0:12agents as quick as possible. But what I

0:14didn't realize is you can't build good

0:15agents until you understand workflows.

0:18And I think that's where everyone goes

0:19wrong. So in this video, I'll walk you

0:20through exactly how I'd learn Nen and AI

0:22automations in general if I had to start

0:24from scratch today step by step. So

0:26let's get into it. So, if I was starting

0:27from zero right now, the first thing

0:28that I would drill into my head is this.

0:30Do not start with AI. Start with

0:32workflows. Learn the automation

0:33fundamentals before you even think about

0:35building agents. Most beginners skip

0:37past this part because they want to

0:38build AI agents right away because

0:39they're cool and that's what we're

0:41seeing online. But the truth is, you

0:42cannot build good agents if you don't

0:44understand how workflows actually

0:45function. That's essentially trying to

0:46run before you can walk. So, here's how

0:48I would think about the three layers.

0:49You've got workflows. Those are

0:50rule-based, they're predictable, and

0:52they're boring, but in the best way

0:53possible. You know what the inputs look

0:54like, so you know what the outputs will

0:56be, and you can map those variables, set

0:58your own conditions, and it runs the

0:59same way every time. This is classic

1:00[music] business process automation, and

1:02it has already been around for decades.

1:04But it's still one of the strongest ways

1:05to actually produce ROI. Mackenzie found

1:07that standard workflow automation alone

1:09can deliver anywhere from 30% to 200%

1:12ROI in just year 1 with labor cost

1:14savings of 25% to 40%. And most small

1:17businesses still do not have these basic

1:19automations in place. So, I firmly

1:21believe that you could literally

1:22position yourself today as just an

1:23automation agency or an efficiency

1:25agency and build a really solid business

1:27without ever touching AI and drive

1:29massive results for your clients. But AI

1:31automations are then the next step up

1:33because you still have those predictable

1:34workflows, but now you can sprinkle in

1:36some intelligence and some

1:37decision-making. Maybe you just need to

1:38use AI at the end of the workflow to

1:40personalize the email. Maybe you need it

1:42at the beginning to score support

1:43tickets as high or low priority. These

1:45are small controlled decisions inside a

1:47larger rule-based workflow. Mackenzie

1:49also estimates that about 50% of work

1:51activities and processes can be

1:53automated without using AI at all. So

1:55these AI assisted workflows do fit most

1:57use cases that a business will have.

1:58Then finally we have our AI agents which

2:01are the top layer. These systems can

2:02make decisions, reference memory, use

2:04tools and adjust based on context.

2:06They're super powerful, but they're also

2:08much harder to control and they have a

2:09higher likelihood of breaking. This is

2:11where people tend to get lost because

2:12they jump straight into these agentic

2:14workflows before they even learn

2:15variables and JSON data structures and

2:18how a basic workflow behaves. So this

2:19would cause you to get confused, things

2:21would break and then you'd want to quit.

2:22So workflows are deterministic and

2:24they're much more set it and forget it

2:26than AI agents are because AI agents are

2:28nondeterministic. As you have more and

2:30more AI, there's more possibility for

2:32errors which means you need constant

2:34maintenance and upkeep and evaluations

2:35to make sure that the systems are

2:37actually providing value rather than

2:38just becoming a headache. And once you

2:40understand that foundation, you'll want

2:41to learn the core building blocks that

2:43make every workflow actually work.

2:44Everything in NDN comes down to data

2:46coming in and then going out. And once

2:48you understand how the data is shaped

2:49and how it moves, the entire platform

2:51becomes way less intimidating. There's

2:52one thing real quick though I want to

2:53tell you guys about, and it's called the

2:54transition curve. In life, whenever

2:56you're trying something new or you're

2:57trying to learn something, you go

2:59through these phases. And it's good to

3:00be aware of them beforehand so that your

3:02expectations are aligned and you have

3:03the highest chance of success. Because

3:05I'm not going to lie to you, when you

3:06start the first time and you go to look

3:07at JSON or setting up an HTTP request or

3:10trying to prompt your agent, you're

3:11probably going to feel overwhelmed. I

3:12know I did. So, the transition curve is

3:14basically the idea that you start in

3:15phase one and you're on the up as an

3:17uninformed optimist because you see the

3:18opportunity, you see people building

3:20cool agents or making money with agents

3:21or whatever it is and you're excited

3:23about that opportunity. But then you

3:24kind of come over this hump and you

3:26become an informed pessimist in stage

3:28two. And this is on the way down because

3:29now you understand the complexities that

3:31go into all of this and you feel

3:32overwhelmed. As you move into stage

3:33three, you hit the crisis of meaning.

3:35And this is where you have a decision to

3:36make. You can either go to stage four

3:37and crash and burn, or you can use that

3:39momentum and go back up into stage five,

3:41which is an informed optimist. [music]

3:43And that's where you want to be. This

3:44isn't just a one-time thing. In the past

3:4512 months, I probably become an informed

3:47pessimist about 17 times. But now that

3:49you understand this whole cycle, it's

3:51much easier to push through the crisis

3:52of meaning and continue on your way up.

3:54So, I just needed to talk about that

3:55real quick before we hop into the next

3:56pieces because everyone feels

3:58overwhelmed when they're getting

3:59started. Anyways, the first thing to

4:00learn is JSON and data types. This is

4:02the language of almost everything that

4:04you'll touch in automation. And at first

4:05glance, JSON might look like code, but

4:07when you actually look closer, it's just

4:08pairs of keys and values. So, think

4:10about online shopping. You click on a

4:12product and you can see color equals

4:13blue, size equals medium, price equals

4:15$99.99. JSON is the exact same thing.

4:18It's just written in a specific

4:19structured format. And once you

4:20understand how you can read it and

4:21navigate it, you stop guessing and you

4:23start knowing exactly what data you have

4:24to work with. Next is APIs and HTTP

4:26requests, which is probably the most

4:28important skill that you'll ever have to

4:29learn in automation. This is how data

4:31moves between different tools. [music]

4:32So if you don't understand APIs, you'll

4:34pretty much always be limited to

4:35whatever integrations that Naden gives

4:37you out of the box. The good news is

4:39Naden has thousands of native

4:40integrations with things like Gmail,

4:41Perplexity, Slack, HubSpot, and so many

4:44more. But once you realize that those

4:45nodes, those native integrations are

4:47actually just pre-built HTTP request

4:49just with a cleaner UI because Eniden

4:51packaged it up all nice for us. But the

4:52point I was making there is once you

4:53realize that, everything starts to click

4:55because you start to understand how you

4:56can connect to platforms that Eniden

4:58[music] does not yet support. You can

4:59open up the API documentation. You can

5:01read about the endpoints. You can make

5:02the request and you can access whatever

5:04you need. And here's a quick pro tip. If

5:05you give something like chatbt or claude

5:07API documentation for any tool that you

5:09need, it can help you set up any request

5:11that you have to [music] make. So it's

5:12really just about getting over that

5:13initial intimidation when you see the

5:14words header authentication. Then we

5:16have web hooks which basically just flip

5:18the flow around. So instead of end

5:20reaching out to another tool, the other

5:22tool reaches out to end and that's what

5:23triggers our web hook. This lets any of

5:25our workflows be triggered based on

5:27real-time events like receiving an

5:28email, getting a new Slack message, or

5:30someone filling out a form on your

5:31website. And finally, you need to

5:32understand logic and error handling.

5:34Learn what an if node does, learn how

5:35loops behave, learn how to route data in

5:37different directions, and understand

5:38what the workflow does when it errors

5:39and how you can change that. This is

5:40what helps you build workflows that are

5:41stable, predictable, easy to improve,

5:43and safe. It also teaches you how to

5:45think about data as it moves step by

5:46step through a workflow. But knowing how

5:48to move data isn't enough. You need to

5:49also understand how AI itself thinks.

5:52And that's where [music] LLMs come in.

5:53An LLM or a large language model does

5:55not know your business. It does not know

5:57your clients. It does not know your

5:58internal processes. At its core, all

6:00it's doing is predicting the next word

6:02that would make sense. This is why you

6:03should never just blindly trust whatever

6:05an AI or an LLM tells you. So, in order

6:07to actually get useful outputs, you have

6:09to learn context engineering. This is

6:10one of the most important skills in

6:12modern automation. You've probably heard

6:13of prompt engineering before. Everyone's

6:15talking about it. And that kind of fits

6:16into this bucket of context engineering

6:18because prompt engineering is telling

6:19the model what to do, but context

6:21engineering as a whole is giving the

6:22model the information it needs so it

6:24knows how to think. These systems are

6:25only really as smart as the data and the

6:27subject matter expertise and real

6:29context that you feed them. So here's a

6:31simple analogy that I like to use. A

6:32system prompt for an AI is like studying

6:34the night before an exam. It helps the

6:35model understand the rules, the tone,

6:37and the structure and maybe some base

6:38knowledge. But good context is like

6:40having a cheat sheet during the exam. It

6:42gives you the exact details at the exact

6:43moment that you need them. So if you had

6:45to choose between studying and having a

6:46cheat sheet, most of us would choose the

6:48cheat sheet. But obviously the best

6:49results will come from doing both of

6:50those things. Well, this is how you

6:52should think about LLM's inside Nitn.

6:54The model's not magic. It's not a mind

6:55reader. It's only as good as the context

6:57that you give it. And once you

6:58understand that, you stop expecting the

6:59model to guess things and you start

7:01giving it information that it needs in

7:03order to perform well. And once you've

7:04got that mindset, the next step is to

7:05focus on building automations that

7:07actually matter. So that means ones that

7:08bring real results or save serious time.

7:10So think about it like this. Build

7:12systems that run while you sleep, not

7:13systems that sit there waiting for you

7:15to click a button or for you to talk to

7:16them. Because the whole point of

7:17automation is about leverage. You want

7:19workflows that save time without you

7:20being involved. So there are four

7:22pillars that I like to think about that

7:23help you judge whether something is

7:25worth automating. Repetitive,

7:26timeconuming, errorprone, and scalable.

7:28So if a process does not check at least

7:29two of those boxes, it's probably not

7:31something that's worth automating yet.

7:33And obviously the best automations hit

7:34all four. So a good example of this is

7:36when I released the ultimate personal

7:37assistant video on my YouTube channel. I

7:39had thousands of people reaching out

7:40wanting me to build it for them or

7:41customize it for them in some way. And

7:43while I completely get it because it

7:44would be great to have your own personal

7:46AI assistant that you can talk to, but

7:48that type of system only takes action

7:49when you tell it to do something. It's

7:50not constantly running in the

7:51background, at least the way that I

7:53configured it. So, it's really not

7:54creating a ton of leverage. Now, if you

7:55compare that to a workflow that's

7:57actually triggered by real events, like

7:58a new lead submitting a form or a

8:00payment coming in or a new email hitting

8:01your inbox, these systems wake up on

8:03their own. They take action

8:04automatically. They can run all day and

8:06all night long. And that is where you

8:07get to scale. And that's the type of

8:09work you want to focus on at the start.

8:10And this is something that I'm just like

8:11super passionate about. But if you think

8:13about it, let's say you design a system

8:14that saves the business time and grows

8:16the business. And because of all that

8:17time you're saving and all of the new

8:18growth the business is going through,

8:20that system that you built is going to

8:21get used more. So it basically just

8:23creates like this endless flywheel of

8:24value and exponentially scaling return

8:26on investment. And to consistently find

8:28and build those high ROI workflows, you

8:30have to start thinking like a process

8:31engineer. So what I mean by that is

8:33before you even open up and end, I would

8:34sit down, I would map out the process on

8:36paper. Most people just jump straight

8:37into the canvas and start dragging

8:39around nodes hoping that it will

8:40eventually come together. And that's how

8:42you end up with messy, fragile workflows

8:44that aren't modular, that aren't

8:45scalable, and that need tons and tons of

8:47refinement after you kind of push it

8:48into production. This also makes them

8:50harder to explain when you need to hand

8:52it over to a different engineer or when

8:53you need to explain how it's working to

8:55the team. So instead, just start by

8:56thinking like a process engineer. Break

8:58the business process into clear,

8:59detailed steps. Who does what? When does

9:01it happen? What triggers this? Where's

9:02the data coming from? What do we do with

9:04the data? What is the final outcome we

9:05care about? I think you guys get the

9:06picture. And from there, I like to

9:07wireframe it before I actually build it

9:09and ed it in. And this is exactly what I

9:10teach in my course, 10 hours to 10

9:12seconds. If you want to dive deeper into

9:13this, then you can join my plus group.

9:14The link for that's down in the

9:15description. But here's the key idea. If

9:17you can't explain a process clearly on

9:18paper and get alignment with your client

9:20or your team, then there's no way that

9:21you can go automate that process

9:22clearly. It's essentially like you're

9:24dumping out a bag of Legos and then just

9:26tossing away the instructions. And

9:27you're trying to build the car from

9:28memory from the picture that you saw on

9:30the box of the Legos. You could

9:31eventually get something that kind of

9:33works, kind of looks like it, but it's

9:34going to take a lot longer and probably

9:36not be right. So, slow down at the

9:38start, map the process, get the steps

9:39right, get agreement from everyone

9:41involved, and then go into edit end and

9:42build it. That small bit of planning up

9:44front will save you a huge amount of

9:46time and headaches later. I always think

9:47of the a blinking quote. If I had 6

9:49hours to chop down a tree, I would spend

9:50the first four sharpening the axe. So,

9:52once you've got all that figured out,

9:53now it's time to test and refine it in

9:56practice. If I could teach every

9:57beginner one mindset, it would be this.

9:58Your first version will break. And

10:00that's completely normal. You don't know

10:01what you don't know. The goal in the

10:02beginning is to fail fast, learn from

10:04it, and make the system better each

10:05time. And I don't mean just your first

10:07workflow ever. I mean your first

10:08workflow of every process you try to

10:10automate. Every time that I go and build

10:11a new system for a YouTube video or for

10:13me or for a client or whatever it is, I

10:15always get tons of failures and it

10:16breaks right away. But all of that is

10:18data that you can use to make it better.

10:20It's the same reason why Facebook ad

10:21experts or YouTube experts or whatever

10:23type of expert you have, even though

10:24they know what they're doing, they still

10:25split test everything and they still use

10:27all that data and findings to help

10:28continuously iterate in the future. So

10:30that's why we build PC's, proof of

10:32concepts, and MVPs, minimum viable

10:34products. They simply exist so that you

10:35can get something working, even if it's

10:37not perfect. Then you can monitor it and

10:38see where it breaks and fix those weak

10:40spots. In fact, you should honestly try

10:42to break your own workflows on purpose

10:43as much as you can. Push them to their

10:45limits, feed the edge cases, and just

10:46see what happens. Because the more

10:47weaknesses that you find early on, the

10:49stronger the final system will be. And a

10:51major part of this is actually tracking

10:52and logging. So every workflow that you

10:54build should have some sort of audit log

10:55on every execution. These will be stored

10:57in nadn, but it might not be permanent

10:59based on your setup. So, if you can have

11:00every execution feed into a Google sheet

11:02or an air table, that's really going to

11:04help you because you can find patterns

11:05and those failures, you can spot errors,

11:07and you can build guard rails that

11:08protect against those patterns so that

11:10they don't happen again. And your job

11:11isn't to build something once and then

11:12just walk away. Your job is to build

11:13something stable that stays working over

11:15time. And remember, of course, the more

11:17AI [music] that you have in a workflow,

11:18the more that you need to monitor it.

11:20New chat models come out, APIs update,

11:22and then releases new nodes, new

11:23versions. AI does not behave the same

11:25way forever. So stay [music] close to

11:26your systems, run regular checks, and

11:28make small improvements as things

11:29evolve. That is how you build

11:30automations that truly last. And while

11:32you're learning and building, avoid

11:33falling into one of the biggest traps

11:35that slows everyone down. They get stuck

11:36in tutorial hell. They spend all day

11:38watching videos, taking notes, and

11:40consuming content, but they never

11:41actually build anything. You cannot

11:42learn automation by just watching

11:44someone else click buttons. You have to

11:45go and get your hands dirty in NN or

11:47whatever automation platform that you

11:49want to use. So [music] follow the

11:50tutorial, but then rebuild it yourself.

11:52Break things, debug them, try different

11:53variations. This is where the real

11:54learning happens. After a while, you'll

11:56notice something interesting. About 90%

11:58of all workflows will rely on the same

11:5915 or so core nodes, and most errors

12:02fall into the same handful of

12:03categories. Once you master those, you

12:04can build almost anything with

12:06confidence. I even made a full video on

12:07those exact core nodes that I use after

12:09building hundreds of workflows. And I

12:11will link it right up here so that you

12:12can check that out. And once you know

12:13those nodes well and you start to build

12:14consistently, things begin to click.

12:16Automation becomes pattern recognition.

12:18When you hit an error, just try to

12:19understand how to fix it yourself before

12:20you go into a community forum. And then

12:22when you fix it, make sure you

12:23understand why what you did got rid of

12:25the [music] error. That way when it pops

12:26up again, because it will, trust me, you

12:28know exactly where to look and how to

12:29make the workflow green again. And each

12:31time those patterns come up, you just

12:32get faster. [music] So avoid tutorial

12:33hell and get your reps in. The more you

12:35build, the better you get. And when you

12:36finally hit that point of building with

12:37real confidence, the next logical step

12:39is turning what you've learned into

12:40something that you can actually sell. So

12:42if your goal is to build a business with

12:43automation, then you need to learn how

12:44to build systems that people will

12:45actually pay for. And the key to that is

12:47learning to speak in terms of ROI or

12:49return on investment, not [music] in

12:51terms of tech. Clients don't care about

12:52all the tech jargon, the JSON, the

12:54nodes, or how clever your workflow is.

12:55They really care about three things:

12:57time saved, money saved, and better

12:58quality work. And sometimes I also say

13:00focus, but that kind of gets looped into

13:01all the others. So, keep [music] things

13:03simple. Start with MVPs that actually

13:04solve a clear problem. Before you ever

13:06talk about AI agents or voice agents,

13:08make sure you can build something

13:09predictable that delivers measurable

13:10value. You understand the value because

13:12you have been building in the space for

13:13a while, but your clients are not in

13:15this world every day. It's your job to

13:16explain the value to them in a way that

13:17makes sense to them. [music] And this

13:18starts before you build a single node.

13:20You should be able to clearly

13:21communicate the business impact of any

13:23system. What time it saves, what labor

13:24cost it removes, what errors it reduces,

13:26what scale this unlocks. And when you

13:28can actually speak in those terms,

13:29people [music] will understand why the

13:30automation matters. And then, super

13:32important, once the system is live, you

13:34have to collect data. You have to track

13:35how often it runs, how much [music] time

13:36it saves, and what outcome it produces.

13:38Because after a few months, you can then

13:40show them real numbers. And that's how

13:41you build trust. That's how you earn

13:43long-term relationships. You also need

13:44to use all of that data for your case

13:46studies. So, if you're not tracking it,

13:47you're missing out on tons of new

13:48business. And just wanted to stress this

13:49one more time. Your job is not only to

13:51build systems that work. Your job is to

13:53also communicate the value clearly and

13:54prove the value over time. And that's

13:56how you level up from being just a

13:57builder or a developer to being a

13:59long-term business partner. And if you

14:01follow that road map, you'll skip years

14:02of trial and error and go from building

14:04simple workflows to launching full-on AI

14:06systems that people will happily pay

14:07for. But anyways, that's going to do it

14:09for this one. If you enjoyed, you

14:10learned something new, please give it a

14:11like. Definitely helps me out a ton. And

14:13as always, I appreciate you guys making

14:14it to the end of the video. I'll see you

14:15on the next one.