n8n In The Loop 2026: Inside n8n's Next Chapter | David Roberts

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: n8n In The Loop 2026: Inside n8n’s Next Chapter | David Roberts · Channel: n8n · 38:11 · Watch on YouTube

Topics: AI agents, Task and workflow automation, AI evaluation and benchmarks, Software engineering with AI, AI governance and regulation

Summary

David Roberts reviews n8n’s recent AI-focused developments, including standalone agents, an AI assistant, MCP-based workflow building, and credential setup through n8n Connect. He outlines how improving models are shifting automation from workflows toward agents, while emphasizing that trust, deterministic logic, auditing, and testing remain essential for reliable production use. He then presents plans across the automation lifecycle: a redesigned workflow engine, cross-instance observability through Manifest, and expanded governance and security capabilities. The talk closes with a recap of upcoming work and an introduction to a new product from n8n Labs.

Key points

Standalone agents are easier to create, support skills and MCP, and are more likely to reach production than the previous style of agents.
The AI assistant has become the default way to build workflows in n8n, while MCP lets users build workflows through coding agents such as Claude or Codex.
As models improve and become cheaper, agent-first automation is expected to grow, but workflows remain valuable for tasks that are repetitive, predictable, and reliability-sensitive.
Trust develops in stages: agents can suggest actions, act with human approval, or operate within a budget set by a person.
The automation lifecycle includes building, auditing, deployment, monitoring, and management or governance.
Agents are useful for varied, changing tasks; deterministic workflows are often faster, cheaper, and more reliable for repetitive tasks.
Auditing is increasingly important as AI makes building faster; n8n distinguishes inspection of logic from testing through evaluations.
A new workflow engine is planned, with features including progress saved after each step, reconciliation of stuck jobs, safe retries, sandboxed code, worker pools, and resource limits.
Manifest is a planned separate app for observability across multiple n8n instances, initially focused on n8n automations.
Planned governance work includes agent identities, policies and limits, workflow testing, and security improvements.

Chapters

Start	Chapter	Summary
00:07	Introduction and recent product developments	Roberts previews the talk and highlights new standalone agents, the AI assistant, MCP workflow building, and n8n Connect.
04:17	Models, trust, and the future of agents	He discusses improving models, the balance between workflows and agents, approval fatigue, budget limits, and challenges when agents cross company boundaries.
09:32	The automation lifecycle and choosing workflows or agents	Roberts presents the lifecycle of building, auditing, deploying, monitoring, and governing automations, then compares deterministic workflows with agents.
15:15	Building automation and the auditing bottleneck	He describes agents as an entry point to automation, upcoming improvements to building, and the growing need to audit AI-generated systems.
20:23	Inspection, testing, and evaluations	Roberts explains why users value the workflow canvas for inspection and why evaluations can improve agent reliability despite being difficult and tedious.
24:34	Deployment and the new workflow engine	He introduces a ground-up rewrite of the execution engine and outlines reliability features such as saved progress, safe retries, sandboxing, and resource isolation.
29:14	Monitoring and governance	Roberts presents Manifest for observability across n8n instances and discusses governance needs as automation and agent access expand.
32:24	Security plans and roadmap recap	He covers security advisories and planned capabilities for agent identity, limits, workflow quality, and sandboxing, then recaps upcoming work.
36:36	New product reveal and closing	After a brief product reveal, Roberts identifies it as a new n8n Labs product and invites attendees to join its waitlist.

Quotes

trust is essentially the limit on how much we hand over to these models. — 06:24

when intelligence is abundant being sure is what’s scarce. — 13:41

you can build something 40 seconds and then spend 40 minutes checking it works. — 18:52

the canvas is not going anywhere. — 21:25

Concepts and entities

n8n, David Roberts, Agent, workflow, MCP, Claude Code, Codex, n8n Assistant, n8n Connect, evals, Manifest, n8n Labs, Novo workflow engine

Full transcript (original language)

00:07 [music] Good morning, Berlin. How are you doing? [applause] >> That was pretty good. You guys are probably not from here, I’m guessing. [laughter] Okay, so I’m here to talk about um NM’s next chapter. Um and uh there’s four steps to this, four stages. First of all, a lightning recap of some of the highlights of the last 12

00:39 months. Secondly, I’m going to talk about some strategic themes that we spend a lot of time thinking about inside NA10 and then how these themes have shaped our thinking about the role we play and and what comes in the future. And then finally, what we do have planned, what’s coming next. Okay. So, what have we been up to? N is a very different company to its early days. Um, and one thing we pay a lot of attention to is moving with the times

01:10 because the times are changing so fast. Nense started as a workflow company obviously and while that’s not going away, there’s so much more to automation these days. One example of that is agents. Um, and while agents were always available inside workflows, we’ve taken agents out of the workflows and put them on the same level. Um, because they are just such an important part of the future. And this was rolled out fully last

01:42 month. Uh, they’re easier to create, they support skills, they support MCP more easily, and they also have richer integrations with tools like Slack. Now, these agents are about 20% more likely to get to production compared to the old style of agents. Um, so they are definitely a step in the right direction and there’s going to be lots more content on this throughout the day.

02:12 Okay. [snorts] There’s also the assistant. So, we’ve had uh AIS help in building workflows for a while, but it’s really come into its own in the last 6 months or so. In fact, it’s become the default way of building workflows in N10. Now, uh the assistant’s had over 1.6 million conversations. It’s built over 800,000 workflows and eight out of 10 users that we surveyed rate it good or very good. And it’s available everywhere. It’s

02:44 available on cloud. It’s available and self-hosted and it’s coming to enterprise very soon. It’s not the only way of building an NAN though with AI. Um while we’ve supported MCP for a long time, this year saw us add the ability to build workflows with it. So you can now hook up Claude or Codeex or your favorite coding agent um to N and build workflows that way. And this is a real power user feature because people who use this feature are

03:14 about 3.4 times more likely to get to success with NA10 and they create three times more workflows than the average user. So word on the street is it just works which I think is kind of dangerous to say about any AI feature to be honest but um it it’s definitely a strong addition uh to NAS. And then finally, we’ve got NAS Connect. Um, setting up credentials is perhaps the most painful thing about automation. And NAS Connect removes that pain by

03:46 doing it for you for selected credentials. It launched recently, but it’s already being used by a quarter of our users and it makes them about 25% more likely to get to success. That’s just a little sample of some of the things we’ve been up to. There’s much more in our change log on our docs website if you’re interested. But now let’s move a little bit into how we’re thinking about the world and I’ve got five themes here for you. So first of

04:17 all, we all know models are getting better and better and what the best ones can do today would have felt like magic just 12 months ago and we’re getting more and more models. Open source has stayed consistently on the tail of the major labs so far and we believe that LLMs are expensive today basically because of limited supply. You know that’s going to change especially if you’re okay with something that’s a tiny bit behind the frontier. Uh and this has lots of implications. I

04:50 think one of the ones we think about a lot is designing for the exponential. So when we’re thinking about prioritizing features, we ask ourselves the question, if models get 10 times better, will this feature also get 10 times better? Like can we harness this uh this trend that we’re all riding? And today you have to build scaffolding around models, especially weak ones need a lot of help in order to do a job. As models get better, that scaffolding has to be removed because if it isn’t, you’re

05:21 actually making the model’s life harder and you’re not realizing its true potential. And of course, when thinking is cheap, we do more of it. There are going to be many more agents than humans in the businesses of the future. And the questions are going to shift from can we do it with an agent to are we allowed to do it with the correct result. Now most automation today is workflow first. And so what that means is a

05:52 person or an AI decides the steps in advance and they map them out. Now some of these steps could be agents but they be within a workflow and this is the majority of what runs in production today. Now a smaller but faster growing share of that is agent first of course and there you’re giving the system a goal and it’s free to decide how to reach that goal and it’s growing because models keep getting better and they keep getting cheaper but workflows are not going to disappear and I’ll say a bit

06:24 more on that later what is very clear is that the balance is going to change and as agents become more capable we move from can I do it to do I trust it to trust is essentially the limit on how much we hand over to these models. [snorts] So if you have a capable agent but you don’t have the trust you’re just going to use it for drafts and for summaries but a trusted agent can do real work.

06:57 There is a downside though to all of this this human involvement. Um and that’s one [snorts] of in one example is approval fatigue. You know if you’re asked to approve the same thing a h 100 times you are just going to it’s very hard to not just click the button without really thinking about what you’re approving. Um [snorts] and so the the real question here is where is a human’s time worth spending? And the answer to this is constantly changing as the technological landscape evolves.

07:27 And trust gets built in steps. Money is one way to measure those steps. And so here in step one, an agent suggests and the human does. There’s no spending authority with the agent. And most AI usage is here today. In step two, the agent does the work and the human approves any spend. So the agent can act, but it can’t commit funds. And then in step three, the human sets the budget and then walks

07:57 away. And the agent is now an economic actor in its own right. It can commit resources on its own within a limit that someone has set for it. And so the change here is trusting the agent more with each step. And the human job changes from doing to approving to setting limits and then reading a report. And by the way, budget is a potential answer to this approval fatigue thing that I just talked about because instead of requiring a 100 decisions, you can

08:29 just set a threshold that the the agent can’t exceed. It’s not the answer to all approval fatigue, unfortunately, but it is for for some things. Okay. Then the final the final point I wanted to make is that everything I’ve said so far applies within a single company. You have one set of rules. You have one owner. You have one person to call when it goes wrong. And that could end pretty quickly when my agent can negotiate with your agent or my agent

08:59 can place orders with my supplier or my agent can book in your calendar because then you have a company border. And at a company border, you have two sets of rules meeting each other. And the questions get harder. you know whose limits apply? You know, this companies, this companies, is it the the stricter of the two? Um, how do you prove that an agent is allowed to act for me? And who keeps the records? Who’s liable when something goes wrong?

09:32 Today, we answer those questions with humans and with contracts. But when agents move at machine speed, we need something that’s built into the system. uh and we’re going to see new institutions evolving I think um to satisfy these needs. Okay. So what does this all mean for NAS? This is my favorite framework for thinking about automation. Uh it’s the [snorts] life cycle that an automation goes through and the

10:03 engineers in the room will find this very familiar because it’s basically the software development life cycle too. To start off with, you have to build your automation. I mean, that much is obvious. Uh, then you’ve got to get confidence that it works properly, that it’s going to do what you want it to do. That’s the auditing step. Then you’ve got to put it somewhere and run it, which is deployment. And while it’s running, you’ve got to keep an eye on it. You’ve got to check that it’s working properly. You’ve got to investigate any failures, and that’s the monitoring. And then finally, there is

10:34 the whole human or organizational side of running anything in a company. And that’s where management uh and governance come in. So let’s talk about building. So 12 months ago, if you think back, we were on the verge of Opus 4.5 and the explosion of claude code. And I think it’s fair to say the world has changed beyond recognition since then, especially if you’re an engineer.

11:04 And when these things work well, they really do feel like magic. And of course it creates big opportunities for NA10. And I think one interesting way of thinking about what’s changed is that building with a tool used to mean learning that tool’s grammar, learning that tool’s way of thinking, which sometimes was hard. I mean, with Nennet, we we were a pretty good example of that. Um, and that’s changed with with natural language input.

11:35 Okay. And there’s really two aspects to building. Both of which have changed. First of all, you can build new things. And second of all, you can build them in new ways. And I’m going to talk about both. But first of all, let’s talk a little bit about what you build. We’ve talked about these two architectures at a high level. So you have the agent, you have the workflow. And by workflow, I I really mean deterministic logic. It doesn’t have to be a workflow. It could just be code.

12:06 There are risks to both of these sides and they’re different. So if agents can figure things out for you, they m may figure out the wrong thing. And a workflow that does exactly what you said every time also repeats your mistakes. On the other hand, agents, you know, they’re they’re great at handling varied different flexible input formats. They’re great for natural language interfaces. Workflows on the other hand are faster, they’re cheaper, they’re more reliable. And one nice way of of

12:39 thinking about this difference is where does the thinking happen? You know, does it happen once at [snorts] design time? If so, it’s a workflow, or does it happen every time it runs at runtime, in which case it’s an agent? So, which one is better? Yeah, they’re different, right? They’re different. They have different strengths. They have different applications. They’re essentially two puzzle pieces with different shapes. So if your task you need if you need it to

13:10 run constantly, if it barely varies, that sounds like a workflow. If it’s rare, if it’s messy, if it’s different every time, then an agent is probably more suitable. On the other hand, an agent doing the same thing 10,000 times a day is just a very expensive workflow. And for all the great stuff about AI, it does have this pesky little quality of non-determinism. So it’s just a little bit unpredictable. And of course, if you want your system to be reliable, you want as little

13:41 unpredictability as possible. And this um gets even worse when when you have multiple steps in a chain. So if you have an agentic step that’s 95% reliable and you do it 10 times, that system is only 60% reliable. So when intelligence is abundant being sure is what’s scarce. So you should take anything any part of your system that can be deterministic and you should make it deterministic because that improves the overall reliability

14:14 because of course trust is slow to build and it’s fast to lose. And this goes even when the agent is the top level architecture of your system. What you want to do there is you want to take parts of the problem, take parts of the process and put them inside deterministic tools and you want to encode as much business logic in those tools as possible because that makes the models choices simpler. So if you think about an IT department trying to automate employee onboarding for

14:44 example, you could give your agent a tool to create a account in Slack. You could give it a separate tool to create an account in Google Workspace or in Salesforce. What you might want to do instead though is just create a single tool for onboarding a user to a given department that does those account creations itself because that kind of task can be deterministic and you’re taking it away from the agent given that it doesn’t need to be nondeterministic. Okay. So, so that’s the what. Let’s talk

15:15 a little bit about the how. Obviously AI has revolutionized this too. We believe that no one will build manually in the future. And so if you haven’t checked out the assistant, if you haven’t checked out MCP, we highly recommend that you do that. But agents are also the front door to automation. They’re like the starting point. So many people when they first come to automation, when they first come to an agent, they’re going to ask for some quick one-off task. I might say if

15:45 I’m feeling ambitious, you know, I’m going to Spain next month. Can you book me a flight, please? And that’s the easy mode for agents because I’m sitting in front of the computer and I can answer any questions. I can steer the agent if it goes wrong. And then maybe it’s successful, it works, and I decid to do this every month. I fly to Spain every month for business. I mean, I don’t. I wish I did, but let’s imagine I did. Um, and and the difference here is not just that it’s a repeating task, it’s that

16:17 I’m probably no longer sitting in front of the agent while it’s doing this stuff. So, it needs to be more independent. And so, the the the quality bar has gone up. And then finally, I may say this is a really important process. This needs to have another level of reliability. And that’s where this hardening, this taking of the logic out of the agent and putting it into deterministic workflows can happen. And of course, if you’re an automation expert like many of you in this room

16:48 are, you may jump straight to step three. Uh you don’t have to go through this entire process. But equally, there are many things, many types of automation that might never get past step one or stop at step two. So the point is it’s all a continuum and agents very often are the front door to automation. And we talked about these two ways of building. Um they’re both important and we’re going to continue to invest in both because N has always been an all-in-one solution. You know that uh

17:18 that life cycle I showed before, we cover all of it and that’s by design and it’s [snorts] always been easy to get started because of that. And that’s exactly why we have the assistant. that’s our front door for uh new users coming in. But on the other hand, we don’t believe in trying to control users or dictate where they do work. And that’s why for people who prefer to live in claude, they can use the MCP instead. So we have lots of plans for the building experience. Um they include

17:50 improving the assistant, improving the MCP, they include making that front door easier to walk through. So, we recently released an automation mining skill to give you ideas for what you can automate, for example. Um, they include bringing your own context because agents perform so much better when they know more about you. And they also include self-healing automations so that you don’t have to be pouring over the uh the executions all the time. Now, building in this process was traditionally the bottleneck. It was

18:21 traditionally the hardest part and the most timeconuming part. And that’s gone. That’s gone with AI. Unfortunately, in any system that’s closed like this, um, when you remove a bottleneck, you get a new one somewhere else. And the bottleneck now is most definitely with auditing. We see this with engineers because they are drowning in PR reviews. They’re drowning in code review that’s been of all this code that’s been generated by agents. And I think auditing is the last part of this system

18:52 that we’re ever going to hand over to AI since it’s about trust. So how do we think about auditing? When the building experience is really fast, auditing can become actually slower. Um so you can build something 40 seconds and then spend 40 minutes checking it works. Anyone can relate to this experience? Yeah, I see a lot of hands. >> [snorts] >> Um, auditing doesn’t always matter though, right? There are certain

19:22 conditions I think you need to to care about auditing. For example, your task needs to be relatively complex because if there’s no scope for things to go wrong, then auditing is less relevant. Secondly, it’s much more relevant for business critical processes because that’s when going wrong has consequences. And then finally, it’s more important in collaborative environments where there’s more than one person involved because then there’s more scope for misunderstanding and not everybody has

19:52 the full context. And many people build these kinds of things with N10. So it’s very important for us that they have a solution for auditing. Two types of auditing. Um there’s inspection which means looking at the logic and how it flows and then there’s testing which means running the thing right and checking the results. Um inspection would be that PR review for engineers that I mentioned before but it would

20:23 also be looking at the workflow graph of NAN and testing is actually much more intuitive than um inspection. It’s the kind of thing that people do naturally when they first start using AI, but it’s also hard to do rigorously. So, talking a little bit about inspection. Um, I mentioned before that we we want want to make sure we move with the times and when AI got really good at coding, we wanted to make sure that our product wasn’t constraining our

20:54 thinking, that it wasn’t holding us back. So, we tried to reason from first principles. What would we build today if we didn’t have NAN? Um, and we wondered, you know, how important is the canvas? So, we devised this question. We said, here’s the good news. You’re living in this utopian future where AI is perfect. AI can do exactly what you ask it to. But the bad news is you don’t have the canvas anymore. And we surveyed about a thousand users about how they would feel

21:25 about that. And what came back surprised us because 55% of the users we surveyed said, “Not only do we need the canvas, if you didn’t have it, NA10 would lose much of its reason for existence for us.” So, I just want to reiterate the canvas is not going anywhere. It would be crazy to remove it. Um, [snorts] but it just goes to show like how important that inspection is. [applause] And we then asked, okay, why the canvas?

21:57 Why is the canvas important? And these were the top three results. Most importantly, understanding how the data moves between steps. Um, which is certainly a form of auditing. Um, and the other two, I mean, I think they’re all about either understanding or auditing. And so these are the things that we’re going to be leaning into. So that’s inspection. Let’s talk a little bit about testing. So these are now figures about the overall agent landscape. This is not NA10 specific. This is just some market research that I wanted to share.

22:29 I think it’s fair to say that agents have not fulfilled their promise yet. Everyone’s using them, but only half of organizations have a single agent in production. And I’m guessing you probably know the answer to this. There’s one reason that is much much more common than any other and that is performance quality. These agents often just don’t work right. They they don’t get

23:01 productionized because they’re not good enough to be useful. And this is where auditing comes in. You know, it’s hard to inspect agents. So, we need to rely more on the the running them, more on the testing. And we call this evals. We call this evaluations. and they work. So, one report found that teams with rigorous evals were 70% likely to have excellent reliability. And for those that didn’t, it dropped to just 32%. So, eval

23:34 this is not a secret. But there’s just one problem. No one does them. So if you take this lefth hand column, only 15% of companies or teams fall into it. It’s pretty damning, right? I mean, you know, why do people not do this when everyone talks about them all the time? I think there’s two parts really. First of all, they’re complex and secondly, they’re tedious. They’re really boring. Um, they’re complex because they’re hard

24:04 to understand conceptually. It’s hard to choose the right metrics. It’s hard to track down the right data very often and they’re tedious because you have to comb through results looking for problems and you have to figure out the business logic for obscure edge cases. Now fortunately the problems that AI creates [snorts] sometimes AI can also solve. Um and that’s where we are headed with evaluations. Um, we already have evaluations in the product of course,

24:34 but what we are working on is just surfacing the business decisions to the user and taking care of the rest automatically with AI. So, expect more on that soon. Okay, we’re halfway through. Um, this part’s going to go faster, I promise. Um, deployment. So, you’ve got to run your automation somewhere. Inexperienced automators tend to forget that. um they they tend to think about the beginning of the of the funnel um and they underestimate how important it is to have things run reliably. And of course

25:08 the the ability to run things is something that’s been built into NA10 from the start. In fact, it’s fair to say the engine of NA10 is the heart of NA10. It was the first part of NA10 and much of it is still Yan’s original code written by his own fair hand. And that’s because it’s the kind of critical thing that you don’t touch unless you have a really good reason to. Well, we are touching it. And in fact, we’re completely rewriting it from the ground up.

25:38 And you might say, okay, we talked about going back to the drawing board and not being constrained by existing NA10. Why not just run code? AI is great at writing code. Running code is a very well understood problem. It’s kind of easy. Um, why not just do that? And we tried that and what we found was that when we started to list out the requirements of what we’d like to see when the code runs, we started to get something that looked a lot like a workflow. And that’s

26:08 because we believe it’s very important for example to be able to see and understand every step. So when you run a workflow in N10, you know it lights up green across the screen. You can look into every step and you can look at the data. We think that’s really a really important part of what makes N special. And of course, if you do that, then that allows you to resume where you left off. You don’t have to start everything from the beginning every time. And then that allows you to retry failures automatically.

26:39 Hence the new workflow engine. And when we were thinking about the design of this engine, we had a framework for reliability. And this is our framework. It has six things in it. And I’m going to talk you through them using the example of a restaurant just to make it a little bit easier to understand. The first one is you’ve got to write it down first. So a waiter needs to take the order, write it down on paper, put that ticket on the rail inside the the kitchen because if something happens to

27:10 that waiter, the order can’t be stuck in that waiter’s head. It can’t be stuck in that waiter’s memory. And that the same is true of systems. Secondly, there needs to be only one version of the truth. So if the sign on the front of the restaurant says open, the restaurant needs to be open. Thirdly, every job must reach an end. So it’s not okay for an order to get stuck in the kitchen going cold and congealing. And then when things go wrong, you need to be able to contain the damage. So if

27:40 you have a fuse trip on a on a on a fridge, all the other fridges should remain unaffected. It also needs to be safe to try again and you need to know when it’s safe to try again. So pressing the lift button twice is fine. Being asked to pay twice, [snorts] not so fine. And finally, you need to leave a trail. Um so even the orders that maybe are cancelled because the uh the restaurants run out of ingredients need to be

28:11 tracked. Okay. What does that mean for the the engine? First of all, it’s going to save your progress after every step. This is something that’s optional right now in NA10, but this is going to be core to the new engine for the reasons that I gave before. Second of all, there’s going to be a reconciliation sweep. So, that’s going to find jobs that have become stuck for some reason, and it’s going to repair them. We’re going to have safe retries. So, we’re only going to retry steps automatically if they’re marked safe, so that we don’t repeat any side effects.

28:42 uh we’re going to run code in a sandbox so you don’t have to trust that code as much. We’re going to have worker pools. That means that you can assign specific capacity to one or two workflows so that the other workflows you’re running don’t interfere with them. We’re going to have resource isolation and limits and waiting. When your workflow has to wait, it’s going to be a stored timed job rather than living in memory. So, lots to come on with the new engine. Um, stay tuned for that in the coming

29:14 months. With monitoring, we already have a load of stuff in this area. You know, we have insights, we have log streaming, we have audit logs. We recently added open telemetry support a few months ago, but sophisticated users are running more than one instance of NAN. Hands up. Who’s who’s got more than one instance in their organization? Yeah, lots of hands. And you might be doing that because you have a development um instance, you have a production instance. You might be doing that because different departments require separated instances. But what

29:46 we’ve been hearing very clearly from you is that you need an observability layer that sits across all of them. And so with that, I present to you manifest. Manifest is a separate app that runs in the same ecosystem as your NA10 instances and it helps users with all the problems that automation creates like what exists and is running, who owns it, uh which systems are being touched by which automations and we’re currently triing it. So if you

30:18 are a multi- instance user and you’re interested in joining this trial and providing feedback, please do get in touch because we’d love to have you. And at first this is only going to be for NASA automations. Uh but we want to expand this to cover all kinds of automation in the or because we recognize that we do live in a world with with multiple automation opportunities. Okay. And then finally onto the the manage side. So this is the human the organizational side of running a tool

30:49 like NA10. Many of you know just how significant that can be. Um, and because automation is exploding, the stakes become higher. So before, this is probably back in the 80s or something, but you know, shadow it might be a spreadsheet macro. Uh, today it looks very, very different. It’s probably, you know, a ton of agents with access to really sensitive systems. Um, and actually governance we believe is becoming even more relevant for than

31:19 before. Not just for the large companies that have always cared about governance, but also for the small companies because of this fact I mentioned before that you’re probably going to have more agents than you do have employees and they may be just as powerful. So we have a little framework for how we think about governance. It has four things. access, guard rails, observability and quality and security. Access is about who’s acting and what can they reach. So that’s things like identity, credentials, permissions.

31:52 Guard rails is about within that what is limited and what does a person decide. So spend and usage limits, policies, anonymization, approval gates, exception routing, this kind of thing. Ownership and quality is about who owns it and can we keep it can we trust it to keep working. So this is about managing the life cycle that I’ve been talking through. It’s about testing. It’s about review. It’s about environments. And these three principles together they

32:24 govern the system when it’s working as designed. The fourth one security is about what happens when someone tries to make it work against you. So this is things like prompt injection, tool poisoning, data exfiltration. Now we have a lot in these areas already. And don’t worry, I’m not going to talk through everything on this slide. I just wanted to to give you guys an idea. Um I want to just um pause on the security topic for a second uh and talk about

32:54 security advisories because AI has changed the landscape in many areas but no more so than insecurity and as NA10 you know we see so many more tools that scan public code bases. Also, because NA10 gets more attention these days, we’ve seen a rise in in reports and every report gets triaged and it gets fixed and we send you an advisory via email with enough information to uh for you to act on it. And we prefer that

33:26 you hear it from us, you know, clearly and early rather than finding out some other way. And the good news is we’re seeing the volume of these things kind of level off over time. What we’re not assuming is that that trend continues. So, we’re continuing to invest in this. Um, but at the end of the day, NAN is public code and what that means is we have many people looking at it, many eyeballs on it. Fixes are verifiable, so you don’t have to take our word for it. And to be honest, you know, that’s a trade-off that we would take again.

34:00 Okay, back to um this framework. I just wanted to run you really quickly through some of the things we have planned in these areas. So under access, most agents today, they borrow a person’s login. So you can’t actually tell was it the human or the agent doing these things. And the agent gets all of the permissions that the person has. We want to have our own identity for agents which is narrow. It’s attributable. It’s revocable. Skim provisioning is about when a person

34:31 leaves, do they do they lose access to the system or do their automations continue running? And user groups is about managing users or making managing users easier. On the guardrail side, we have policies and we have limits. Now policies allow you to stop things before they run. And limits cap the damage after something goes wrong. For example, when an a when agents can loop and retry, they can sometimes get stuck. Costs can just run away unnoticed. And I’m sure that’s a familiar experience to many of you. So

35:02 you need hard caps to to set the bounds. on the ownership and quality side. Um, you know, software discipline is is about bringing that to automation and bringing it to agents too. Um, and also bringing the, you know, the rigor of evals also to the deterministic side of the house with with workflow testing. And finally with security, I talked a bit before about code sandboxing. That’s not just about security. It’s also when you when you don’t have to trust the code you’re running, you can be much

35:33 freer with it. So you can load random libraries into your automation for example, which is something we’ve wanted to add to N10 forever. Okay, so I’ve kind of talked about this already, what’s next. Um, but I just wanted to give a really quick recap, you know, um, on the building side, we’re going to continue to improve the assistant. We’re going to continue to improve MCP and agents. There’s more context coming. There’s um self-healing coming on the auditing side. We want to

36:05 make evals much more intuitive and easy to understand and basically less painful. On the deployment side, we have this new engine coming. Um and while we don’t have a single point of failure today, we also want to make this even more robust uh with a new engine. We have manifest for cross in cross cross instance observability and then we have a load of stuff on the governance side that I’ve just talked okay so there is a lot to come the pace of change is increasing and NA10’s output is

36:36 increasing with it and we’re very excited uh for what comes next and on that subject I do just have one other thing to show Yeah. [music] [music] Heat. [music]

37:08 >> [music] [music] [bell]

37:39 [music] [music] >> Okay. [applause] So, this is a new product from NAD Labs. Um, if you are interested in checking it out and joining the wait list, please do uh take a photo and join it. We’d love to have you build it with us. And with

38:11 that, you know, uh thank you so much for your attention uh and being a great audience. I hope you have a great rest of your day and you enjoy all the great stuff that we have planned. [music] >> [music]