n8n em foco 2026: por dentro do próximo capítulo do n8n | David Roberts
Autoria: n8n · Assistir no YouTube
Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.
Idioma original: inglês
Vídeo original: n8n In The Loop 2026: Inside n8n’s Next Chapter | David Roberts · Canal: n8n · 38:11 · Assistir no YouTube
Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Engenharia de software com IA, Governança e regulação de IA
David Roberts apresenta a evolução recente do n8n e as tendências que orientam seus próximos passos, incluindo agentes, modelos mais capazes e a importância da confiança. Ele explica como agentes e workflows determinísticos se complementam e por que auditoria, testes e evals são essenciais para levar automações à produção. Também anuncia um novo mecanismo de execução, o Manifest para observabilidade entre instâncias e planos de governança e segurança. Ao final, apresenta um novo produto da n8n Labs, sem revelar seu nome na transcrição.
Pontos-chave
Seção intitulada “Pontos-chave”- Agentes passaram a ocupar um lugar próprio no n8n, com suporte a skills e MCP, e têm maior probabilidade de chegar à produção que os agentes do formato anterior.
- A automação tende a combinar workflows determinísticos, mais previsíveis e econômicos, com agentes, mais adequados a tarefas variadas e imprevisíveis.
- A confiança nos agentes pode crescer em etapas: primeiro eles sugerem, depois executam com aprovação e, por fim, operam dentro de limites definidos por pessoas.
- À medida que criar automações fica mais rápido, auditoria e testes se tornam gargalos; evals ajudam a avaliar a qualidade dos agentes.
- A tela visual continua importante para inspecionar o fluxo de dados e entender a lógica das automações.
- O novo mecanismo de execução deverá salvar o progresso por etapa, permitir novas tentativas seguras e isolar recursos.
- Manifest é uma aplicação para observabilidade de automações em várias instâncias do n8n, inicialmente em fase de testes.
- Os planos de governança incluem identidade própria para agentes, limites, políticas, testes de workflows e melhorias de segurança.
Capítulos
Seção intitulada “Capítulos”| Início | Capítulo | Resumo |
|---|---|---|
| 00:07 | O próximo capítulo do n8n | David Roberts apresenta a agenda e destaca mudanças recentes, incluindo agentes, o assistente e a criação de workflows por MCP. |
| 04:17 | Modelos, agentes e confiança | A apresentação aborda a evolução dos modelos, a convivência entre workflows e agentes e as etapas para confiar mais autonomia aos agentes. |
| 09:32 | O ciclo de vida da automação | Roberts organiza a automação em construção, auditoria, deploy, monitoramento e governança. |
| 11:35 | Quando usar agentes ou workflows | Ele compara as vantagens e os riscos de cada abordagem e recomenda manter determinísticas as partes que não precisam de decisões variáveis. |
| 15:15 | Construção e auditoria de automações | O palestrante descreve agentes como porta de entrada para automações e explica por que inspeção, testes e evals ganham importância. |
| 24:34 | Novo mecanismo de execução | O n8n planeja reescrever seu mecanismo de execução com recursos para salvar progresso, recuperar falhas e isolar recursos. |
| 29:14 | Observabilidade e governança | A apresentação introduz Manifest e detalha planos de controle de acesso, limites, qualidade e segurança. |
| 35:33 | Planos futuros e novo produto | Roberts recapitula as iniciativas anunciadas e apresenta um novo produto da n8n Labs, convidando o público a entrar na lista de espera. |
Citações
Seção intitulada “Citações”À medida que os agentes se tornam mais capazes, passamos de “consigo fazer isso?” para “confio nisso?”. — 06:24
Quando a inteligência é abundante, o que é escasso é ter certeza. — 13:41
Você pode construir algo em 40 segundos e depois passar 40 minutos verificando se funciona. — 18:52
O canvas não vai desaparecer. — 21:25
Conceitos e entidades
Seção intitulada “Conceitos e entidades”- n8n (empresa): Empresa e plataforma de automação que apresenta sua estratégia e os produtos planejados para os próximos anos.
- David Roberts (pessoa): Apresentador que explica a estratégia e as iniciativas futuras do n8n.
- Agent (conceito): Sistema que recebe um objetivo e escolhe como executá-lo, com maior flexibilidade, mas também mais imprevisibilidade que um workflow.
- workflow (conceito): Automação de lógica determinística cujas etapas são definidas previamente e podem ser inspecionadas.
- MCP (conceito): Protocolo que permite conectar agentes de programação ao n8n para criar workflows.
- Claude Code (ferramenta): Agente de programação mencionado como uma opção para interagir com o n8n por meio de MCP.
- Codex (ferramenta): Agente de programação citado como opção para criar workflows conectando-se ao n8n por MCP.
- n8n Assistant (ferramenta): Assistente de IA para ajudar a criar workflows no n8n.
- n8n Connect (ferramenta): Recurso que simplifica a configuração de credenciais selecionadas para automações.
- evals (conceito): Avaliações usadas para testar o desempenho e a confiabilidade de agentes.
- Manifest (ferramenta): Aplicação planejada para acompanhar automações e oferecer observabilidade entre várias instâncias do n8n.
- n8n Labs (empresa): Unidade que apresenta um novo produto ao final do vídeo e convida o público a entrar na lista de espera.
- Novo workflow engine (conceito): Mecanismo de execução em desenvolvimento, projetado para aumentar a confiabilidade das automações.
Tradução completa (pt-BR)
Seção intitulada “Tradução completa (pt-BR)”00:07 [música] Bom dia, Berlim. Como vocês estão? [aplausos] >> Muito bom. Imagino que vocês provavelmente não sejam daqui. [risos] Certo, estou aqui para falar sobre o próximo capítulo do n8n. Há quatro etapas, quatro fases. Primeiro, uma recapitulação rápida de alguns dos destaques dos últimos 12
00:39 meses. Em segundo lugar, vou falar sobre alguns temas estratégicos em que pensamos bastante dentro do n8n e sobre como esses temas moldaram nossa visão do papel que desempenhamos e do que vem pela frente. E, por fim, o que planejamos e o que vem a seguir. Certo. Então, o que temos feito? O n8n é uma empresa muito diferente do que era no começo. Uma coisa a que damos muita atenção é acompanhar as mudanças
01:10 porque os tempos estão mudando muito rápido. O n8n começou como uma empresa de workflows, obviamente, e, embora isso não vá desaparecer, hoje há muito mais na automação. Um exemplo disso são os agents. Embora os agents sempre estivessem disponíveis dentro dos workflows, nós os tiramos dos workflows e os colocamos no mesmo nível. Isso porque eles são uma parte muito importante do futuro. E isso foi lançado por completo no mês passado.
01:42 Eles são mais fáceis de criar, oferecem suporte a skills e a MCP com mais facilidade, e também têm integrações mais completas com ferramentas como o Slack. Agora, esses agents têm cerca de 20% mais chances de chegar à produção em comparação com o estilo antigo de agents. Então, definitivamente, são um passo na direção certa, e haverá muito mais conteúdo sobre isso ao longo do dia.
02:12 Certo. [fungada] Também temos o assistente. Já faz algum tempo que a IA ajuda a criar workflows, mas foi nos últimos seis meses, mais ou menos, que ela realmente se destacou. Na verdade, tornou-se o jeito padrão de criar workflows no n8n. O assistente já teve mais de 1,6 milhão de conversas. Criou mais de 800 mil workflows, e oito em cada dez usuários que entrevistamos o avaliaram como bom ou muito bom. E ele está disponível em todos os lugares. Está
02:44 disponível na nuvem e em instalações self-hosted, e chegará à versão Enterprise muito em breve. Mas não é a única maneira de criar no n8n com IA. Embora ofereçamos suporte a MCP há bastante tempo, neste ano adicionamos a capacidade de criar workflows com ele. Agora você pode conectar Claude, Codex ou seu coding agent favorito ao n8n e criar workflows dessa forma. E esse é um recurso para usuários avançados, porque as pessoas que o usam têm
03:14 cerca de 3,4 vezes mais chances de ter sucesso com o n8n e criam três vezes mais workflows do que o usuário médio. Então, o que se diz por aí é que simplesmente funciona. Acho que é meio perigoso dizer isso sobre qualquer recurso de IA, para ser sincero, mas definitivamente é uma ótima adição ao n8n. E, por fim, temos o n8n Connect. Configurar credenciais talvez seja a parte mais dolorosa da automação. E o n8n Connect elimina esse incômodo
03:46 fazendo isso por você para algumas credenciais selecionadas. Foi lançado recentemente, mas já está sendo usado por um quarto dos nossos usuários e aumenta em cerca de 25% as chances de eles terem sucesso. Essa é apenas uma pequena amostra de algumas coisas que temos feito. Há muito mais no nosso registro de alterações, no site da documentação, se tiver interesse. Mas agora vamos falar um pouco sobre como estamos pensando no mundo. Tenho cinco temas para apresentar. Então, primeiro de
04:17 tudo, sabemos que os modelos estão ficando cada vez melhores. O que os melhores conseguem fazer hoje pareceria mágica há apenas 12 meses, e estamos tendo cada vez mais modelos. Até agora, o open source tem se mantido consistentemente atrás dos principais laboratórios, e acreditamos que os LLMs são caros hoje, basicamente por causa da oferta limitada. Isso vai mudar, especialmente se você aceitar algo que esteja um pouquinho atrás da fronteira tecnológica. E isso tem muitas implicações. Acho
04:50 que uma das coisas em que pensamos bastante é projetar para o crescimento exponencial. Quando pensamos em priorizar recursos, fazemos a seguinte pergunta: se os modelos ficarem 10 vezes melhores, esse recurso também ficará 10 vezes melhor? Ou seja, podemos aproveitar essa tendência que estamos vivenciando? Hoje, é preciso criar estruturas de apoio em torno dos modelos; os mais fracos precisam de muita ajuda para realizar uma tarefa. Conforme os modelos melhoram, essas estruturas precisam ser removidas, porque, se não forem,
05:21 na verdade você estará dificultando a vida do modelo e impedindo que ele alcance seu verdadeiro potencial. E, claro, quando pensar custa pouco, pensamos mais. No futuro, haverá muito mais agents do que pessoas nas empresas. E as perguntas vão deixar de ser “podemos fazer isso com um agent?” e passar a ser “temos permissão para fazer isso com o resultado correto?”. Hoje, a maioria das automações começa pelo workflow. Isso significa que uma
05:52 pessoa ou uma IA decide as etapas de antemão e as mapeia. Algumas dessas etapas podem ser executadas por agents, mas eles ficam dentro de um workflow, e é assim que funciona a maior parte do que está em produção hoje. Uma parcela menor, mas que cresce mais rápido, começa pelo agent. Nesse caso, você dá um objetivo ao sistema, e ele tem liberdade para decidir como alcançá-lo. Essa parcela está crescendo porque os modelos continuam melhorando e ficando mais baratos, mas os workflows não vão desaparecer. Vou falar um pouco mais sobre isso depois. O que está muito claro é que o equilíbrio vai mudar e, à medida que os agents se tornam mais capazes, passamos de “posso fazer isso?” para “confio nisso?”. A confiança é, essencialmente, o limite do quanto delegamos a esses modelos.
06:24 Então, se você tem um agent capaz, mas não confia nele, vai usá-lo apenas para rascunhos e resumos. Mas um agent confiável pode fazer trabalho de verdade.
06:57 No entanto, há um lado negativo em tudo isso: o envolvimento humano. Um exemplo é a fadiga de aprovação. Se pedirem que você aprove a mesma coisa umas 100 vezes, vai ser muito difícil não simplesmente clicar no botão sem pensar de verdade no que está aprovando. Então, a pergunta fundamental é: onde vale a pena investir o tempo de uma pessoa? A resposta está sempre mudando conforme a tecnologia evolui.
07:27 E a confiança é construída em etapas. O dinheiro é uma forma de medir essas etapas. Na etapa um, o agent sugere e a pessoa executa. O agent não tem autorização para gastar. E a maior parte do uso de IA está nessa etapa hoje. Na etapa dois, o agent faz o trabalho, e a pessoa aprova qualquer gasto. O agent pode agir, mas não pode comprometer fundos. E, na etapa três, a pessoa define o orçamento e depois se
07:57 afasta. O agent passa a ser um agente econômico por direito próprio. Ele pode comprometer recursos por conta própria, dentro de um limite definido por alguém. A mudança, então, é confiar mais no agent a cada etapa. O trabalho da pessoa muda: de executar para aprovar, depois definir limites e, por fim, ler um relatório. Aliás, o orçamento pode ser uma resposta para essa fadiga de aprovação de que acabei de falar, porque, em vez de exigir 100 decisões, você pode
08:29 simplesmente definir um limite que o agent não pode ultrapassar. Infelizmente, não é a solução para toda fadiga de aprovação, mas resolve alguns casos. Certo. Então, o último ponto que eu queria destacar é que tudo o que eu disse até agora se aplica dentro de uma única empresa. Você tem um conjunto de regras. Tem um responsável. Tem uma pessoa para chamar quando algo dá errado. E isso pode acabar bem rápido quando meu agent puder negociar com o seu agent, ou quando meu agent
08:59 puder fazer pedidos ao meu fornecedor, ou quando meu agent puder marcar compromissos no seu calendário, porque aí existe uma fronteira entre empresas. E, nessa fronteira, dois conjuntos de regras se encontram. As perguntas ficam mais difíceis. De quem são os limites que se aplicam? Os desta empresa ou os daquela empresa? Vale o mais rigoroso dos dois? Como provar que um agent tem permissão para agir em meu nome? E quem mantém os registros? Quem é responsável quando algo dá errado?
09:32 Hoje, respondemos a essas perguntas com pessoas e contratos. Mas, quando os agents passam a operar na velocidade das máquinas, precisamos de algo que esteja incorporado ao sistema. E acho que veremos novas instituições evoluindo para atender a essas necessidades. Certo. Então, o que tudo isso significa para o n8n? Este é meu framework favorito para pensar sobre automação. É o ciclo de vida pelo qual uma automação passa e o…
10:03 os engenheiros aqui na sala vão achar isso muito familiar, porque é basicamente também o ciclo de vida do desenvolvimento de software. Para começar, você precisa criar sua automação. Quer dizer, isso é óbvio. Depois, você precisa ter confiança de que ela funciona corretamente, de que vai fazer o que você quer que faça. Essa é a etapa de auditoria. Em seguida, você precisa colocá-la em algum lugar e executá-la, ou seja, fazer o deploy. E, enquanto ela estiver em execução, você precisa ficar de olho nela. Precisa verificar se está funcionando corretamente. Precisa investigar quaisquer falhas, e isso é o monitoramento. E, por fim, existe…
10:34 toda a dimensão humana ou organizacional de executar qualquer coisa em uma empresa. É aí que entram a gestão e a governança. Então, vamos falar sobre criação. Se você voltar 12 meses no tempo, estávamos prestes a ver o Opus 4.5 e a explosão do Claude Code. E acho justo dizer que, desde então, o mundo mudou a ponto de ficar irreconhecível, especialmente se você é engenheiro.
11:04 E, quando essas coisas funcionam bem, elas realmente parecem mágicas. E, claro, isso cria grandes oportunidades para o n8n. Acho que uma maneira interessante de pensar sobre o que mudou é que, antes, criar com uma ferramenta significava aprender a gramática dela, aprender seu jeito de pensar, o que às vezes era difícil. Quer dizer, com o n8n, éramos um bom exemplo disso. E isso mudou com a entrada em linguagem natural.
11:35 Certo. E há realmente dois aspectos na criação, e ambos mudaram. Primeiro, você pode criar coisas novas. E, segundo, pode criá-las de novas maneiras. Vou falar sobre os dois. Mas, antes, vamos falar um pouco sobre o que você cria. Já falamos, em alto nível, sobre essas duas arquiteturas. Temos o agent e temos o workflow. E, por workflow, quero dizer, na verdade, lógica determinística. Não precisa ser um workflow. Pode ser apenas código.
12:06 Há riscos em ambos os lados, e eles são diferentes. Se os agents podem descobrir as coisas por você, podem descobrir algo errado. E um workflow que faz exatamente o que você pediu, todas as vezes, também repete seus erros. Por outro lado, agents são ótimos para lidar com formatos de entrada variados, diferentes e flexíveis. São ótimos para interfaces em linguagem natural. Já os workflows são mais rápidos, mais baratos e mais confiáveis. E uma maneira interessante de…
12:39 pensar nessa diferença é perguntar: onde acontece o raciocínio? Ele acontece uma vez, no momento do design? Nesse caso, é um workflow. Ou acontece toda vez que ele é executado, em tempo de execução? Nesse caso, é um agent. Então, qual é melhor? Sim, são diferentes, certo? São diferentes. Têm pontos fortes diferentes. Têm aplicações diferentes. São, essencialmente, duas peças de quebra-cabeça com formatos diferentes. Então, se sua tarefa precisa…
13:10 ser executada constantemente, se quase não varia, parece ser um caso para um workflow. Se é rara, confusa, diferente a cada vez, então um agent provavelmente é mais adequado. Por outro lado, um agent fazendo a mesma coisa 10.000 vezes por dia é apenas um workflow muito caro. E, apesar de todas as coisas incríveis da IA, ela tem essa pequena característica irritante de não ser determinística. Então, é um pouco imprevisível. E, claro, se você quer que seu sistema seja confiável, quer o mínimo possível de…
13:41 imprevisibilidade. E isso fica ainda pior quando você tem várias etapas encadeadas. Então, se uma etapa agêntica é 95% confiável e você a executa 10 vezes, esse sistema é confiável em apenas 60% dos casos. Então, quando a inteligência é abundante, o que é escasso é ter certeza. Por isso, você deve tornar determinística qualquer parte do seu sistema que possa ser determinística, porque isso melhora a confiabilidade geral…
14:14 porque, claro, a confiança demora para ser construída e se perde rapidamente. E isso continua valendo mesmo quando o agent é a arquitetura de nível mais alto do seu sistema. Nesse caso, o que você quer fazer é pegar partes do problema, partes do processo, e colocá-las dentro de ferramentas determinísticas. E quer codificar o máximo possível de lógica de negócios nessas ferramentas, porque isso simplifica as escolhas do modelo. Então, imagine um departamento de TI tentando automatizar, por exemplo, a integração de novos funcionários…
14:44 Você poderia dar ao seu agent uma ferramenta para criar uma conta no Slack. Poderia dar a ele outra ferramenta para criar uma conta no Google Workspace ou no Salesforce. Mas, em vez disso, talvez você queira criar uma única ferramenta para integrar um usuário a um determinado departamento, que faça essas criações de contas por conta própria, porque esse tipo de tarefa pode ser determinístico e você está tirando isso das mãos do agent, já que não precisa ser não determinístico. Certo. Então, esse é o “o quê”. Vamos falar…
15:15 um pouco sobre o “como”. É claro que a IA também revolucionou isso. Acreditamos que, no futuro, ninguém vai criar as coisas manualmente. Então, se você ainda não conferiu o assistente, nem o MCP, recomendamos muito que faça isso. Mas os agents também são a porta de entrada para a automação. São como o ponto de partida. Muitas pessoas, quando chegam à automação pela primeira vez, quando chegam a um agent pela primeira vez, vão pedir uma tarefa rápida e pontual. Eu poderia dizer, se…
15:45 eu estiver me sentindo ambicioso: “Vou para a Espanha no mês que vem. Pode reservar uma passagem para mim, por favor?”. E esse é o modo fácil para os agents, porque estou sentado em frente ao computador e posso responder a quaisquer perguntas. Posso orientar o agent se algo der errado. E talvez dê certo, funcione, e eu decida fazer isso todo mês. Eu viajo para a Espanha todo mês a trabalho. Quer dizer, não viajo. Quem dera, mas vamos imaginar que sim. E a diferença aqui não é só que se trata de uma tarefa recorrente; é que…
16:17 provavelmente não vou mais estar sentado em frente ao agent enquanto ele faz essas coisas. Então, ele precisa ser mais independente. E, assim, o nível de qualidade exigido aumentou. Por fim, talvez eu diga: “Este é um processo realmente importante. Ele precisa de um nível ainda maior de confiabilidade”. É aí que pode acontecer esse endurecimento: tirar a lógica do agent e colocá-la em workflows determinísticos. E, claro, se você é especialista em automação, como muitos de vocês aqui na sala…
16:48 são, talvez pule direto para a etapa três. Não é necessário passar por todo esse processo. Mas, igualmente, há muitas coisas, muitos tipos de automação que talvez nunca passem da etapa um ou parem na etapa dois. Então, a questão é que tudo isso é um contínuo, e os agents muitas vezes são a porta de entrada para a automação. E falamos dessas duas maneiras de criar. Ambas são importantes, e vamos continuar investindo nas duas, porque o n8n sempre foi uma solução completa. Você sabe que…
17:18 todo aquele ciclo de vida que mostrei antes é coberto por nós, e isso é intencional. E, por causa disso, sempre foi fácil começar. É exatamente por isso que temos o assistente: ele é nossa porta de entrada para novos usuários. Mas, por outro lado, não acreditamos em tentar controlar os usuários ou ditar onde eles devem trabalhar. É por isso que quem prefere trabalhar no Claude pode usar o MCP. Então, temos muitos planos para a experiência de criação. Eles incluem…
17:50 melhorar o assistente, melhorar o MCP e facilitar a passagem por essa porta de entrada. Por exemplo, lançamos recentemente uma skill de mineração de automações para dar ideias do que você pode automatizar. Isso também inclui permitir que você traga seu próprio contexto, porque os agents têm um desempenho muito melhor quando sabem mais sobre você. E inclui também automações autorreparáveis, para que você não precise ficar analisando as execuções o tempo todo. Tradicionalmente, criar automações nesse processo era o gargalo. Era…
18:21 tradicionalmente, a parte mais difícil e que mais consumia tempo. E isso acabou. A IA eliminou isso. Infelizmente, em qualquer sistema fechado como este, quando você remove um gargalo, surge outro em algum lugar. E agora o gargalo, sem dúvida, está na auditoria. Vemos isso com engenheiros, porque eles estão atolados em revisões de PR. Estão atolados em revisões de código de todo esse código gerado por agents. E acho que a auditoria é a última parte deste sistema
18:52 que vamos entregar à IA, porque isso envolve confiança. Então, como pensamos sobre auditoria? Quando a experiência de construção é muito rápida, a auditoria pode acabar sendo mais lenta. Você pode construir algo em 40 segundos e depois passar 40 minutos verificando se funciona. Alguém se identifica com essa experiência? Sim, estou vendo muitas mãos. >> [fungada] >> Mas a auditoria nem sempre importa, certo? Acho que há certas
19:22 condições para você se importar com auditoria. Por exemplo, sua tarefa precisa ser relativamente complexa, porque, se não houver possibilidade de algo dar errado, a auditoria é menos relevante. Em segundo lugar, ela é muito mais relevante para processos críticos para os negócios, porque é aí que os erros têm consequências. E, por fim, ela é mais importante em ambientes colaborativos, onde há mais de uma pessoa envolvida, porque há mais possibilidade de mal-entendidos e nem todo mundo tem
19:52 o contexto completo. E muitas pessoas constroem esse tipo de coisa com o n8n. Por isso, é muito importante para nós que elas tenham uma solução de auditoria. Há dois tipos de auditoria. Há a inspeção, que significa analisar a lógica e o fluxo dela, e há os testes, que significam executar a coisa e verificar os resultados. A inspeção seria aquela revisão de PR para engenheiros que mencionei antes, mas também seria
20:23 analisar o grafo do workflow do n8n. E os testes são, na verdade, muito mais intuitivos do que a inspeção. É o tipo de coisa que as pessoas fazem naturalmente quando começam a usar IA, mas também é difícil fazer isso de maneira rigorosa. Falando um pouco sobre inspeção: mencionei antes que queremos acompanhar os tempos e, quando a IA ficou muito boa em programar, quisemos garantir que nosso produto não limitasse nosso
20:54 pensamento, que não nos impedisse de avançar. Então, tentamos raciocinar a partir dos primeiros princípios. O que construiríamos hoje se não tivéssemos o n8n? E nos perguntamos: qual é a importância da tela de edição? Então, elaboramos esta pergunta: aqui vai a boa notícia. Você está vivendo neste futuro utópico em que a IA é perfeita. A IA consegue fazer exatamente o que você pede. Mas a má notícia é que você não tem mais a tela de edição. Fizemos uma pesquisa com cerca de mil usuários para saber como se sentiriam
21:25 em relação a isso. E a resposta nos surpreendeu, porque 55% dos usuários que entrevistamos disseram: “Não é só que precisamos da tela de edição; sem ela, o n8n perderia boa parte da razão de existir para nós.” Então, quero reiterar que a tela de edição não vai a lugar nenhum. Seria loucura removê-la. Mas isso só mostra a importância da inspeção. [aplausos] E então perguntamos: certo, por que a tela de edição?
21:57 Por que a tela de edição é importante? Estes foram os três principais resultados. O mais importante: entender como os dados se movem entre as etapas. Isso certamente é uma forma de auditoria. E as outras duas, bem, acho que todas dizem respeito a entender ou auditar. Então, são esses os aspectos em que vamos nos concentrar. Isso é inspeção. Vamos falar um pouco sobre testes. Agora, estes são números sobre o panorama geral dos agents. Não são específicos do n8n. São apenas alguns dados de pesquisa de mercado que eu queria compartilhar.
22:29 Acho justo dizer que os agents ainda não cumpriram sua promessa. Todo mundo os usa, mas apenas metade das organizações tem sequer um agent em produção. E imagino que vocês provavelmente saibam a resposta para isso. Há um motivo muito mais comum do que qualquer outro: a qualidade do desempenho. Esses agents muitas vezes simplesmente não funcionam direito. Eles não chegam à
23:01 produção porque não são bons o bastante para serem úteis. E é aí que entra a auditoria. É difícil inspecionar agents. Então, precisamos depender mais de executá-los, mais dos testes. E chamamos isso de evals. Chamamos isso de avaliações. E elas funcionam. Um relatório constatou que, entre as equipes com evals rigorosos, havia 70% de probabilidade de terem uma confiabilidade excelente. Para aquelas que não tinham, esse número caía para apenas 32%. Então, evals
23:34 não são nenhum segredo. Mas há um problema: ninguém faz isso. Se você olhar esta coluna da esquerda, apenas 15% das empresas ou equipes se enquadram nela. É bem condenatório, não é? Quer dizer, por que as pessoas não fazem isso, se todo mundo fala disso o tempo todo? Acho que há basicamente dois motivos. Primeiro, é complexo; segundo, é tedioso. É muito chato. É complexo porque é difícil
24:04 entender conceitualmente. É difícil escolher as métricas certas. Muitas vezes, é difícil encontrar os dados certos. E é tedioso porque você precisa examinar os resultados em busca de problemas e descobrir a lógica de negócios para casos extremos obscuros. Felizmente, às vezes a IA também consegue resolver os problemas que ela cria. E é nessa direção que estamos indo com as avaliações. É claro que já temos avaliações no produto,
24:34 mas o que estamos fazendo é simplesmente apresentar as decisões de negócio ao usuário e deixar que a IA cuide automaticamente do resto. Então, esperem novidades em breve. Certo, já estamos na metade. Esta parte vai ser mais rápida, prometo. Implantação. Você precisa executar sua automação em algum lugar. Quem tem pouca experiência com automação tende a esquecer isso. Tende a pensar no começo do funil e subestimar a importância de fazer as coisas rodarem com confiabilidade. E, claro,
25:08 a capacidade de executar as coisas está incorporada ao n8n desde o início. Na verdade, é justo dizer que o mecanismo do n8n é o coração do n8n. Foi a primeira parte do n8n, e grande parte dele ainda é código original do Yan, escrito por ele mesmo. Isso porque é o tipo de componente crítico em que você não mexe sem ter um bom motivo. Bem, nós vamos mexer nele. Na verdade, vamos reescrevê-lo completamente, do zero.
25:38 E vocês podem dizer: certo, falamos em voltar à prancheta e não nos deixar limitar pelo n8n existente. Por que não simplesmente executar código? A IA é ótima para escrever código. Executar código é um problema muito bem compreendido. É até fácil. Por que não fazer isso? Nós tentamos, e o que descobrimos foi que, quando começamos a listar os requisitos que gostaríamos de ver atendidos durante a execução do código, acabamos chegando a algo muito parecido com um workflow. E isso acontece
26:08 porque acreditamos que, por exemplo, é muito importante poder ver e entender cada etapa. Quando você executa um workflow no n8n, ele fica iluminado em verde na tela. Você pode abrir cada etapa e ver os dados. Achamos que isso é uma parte muito importante do que torna o n8n especial. E, claro, se você fizer isso, poderá retomar de onde parou. Não precisa começar tudo do início todas as vezes. E isso permite tentar novamente, automaticamente, quando algo falha.
26:39 Daí o novo mecanismo de workflow. Ao pensar no design desse mecanismo, usamos uma estrutura para confiabilidade. Esta é a nossa estrutura. Ela tem seis elementos. Vou explicá-los usando o exemplo de um restaurante, só para facilitar um pouco a compreensão. O primeiro é que você precisa anotar o pedido. O garçom precisa receber o pedido, escrevê-lo no papel e colocar a comanda no trilho dentro da cozinha, porque, se acontecer alguma coisa
27:10 aquele garçom, o pedido não pode ficar preso na cabeça dele. Não pode ficar preso na memória daquele garçom. E o mesmo vale para sistemas. Em segundo lugar, só pode haver uma versão da verdade. Então, se a placa na entrada do restaurante diz que está aberto, o restaurante precisa estar aberto. Em terceiro lugar, todo trabalho precisa chegar ao fim. Não dá para deixar um pedido parado na cozinha, esfriando e empelotando. E, quando algo dá errado, você precisa conseguir conter os danos. Então, se
27:40 um fusível desarmar em uma geladeira, todas as outras geladeiras devem continuar funcionando normalmente. Também precisa ser seguro tentar de novo, e você precisa saber quando é seguro tentar de novo. Então, apertar o botão do elevador duas vezes não tem problema. Ter que pagar duas vezes, [bufa] isso já não é tão bom. E, por fim, é preciso deixar um rastro. Então, até os pedidos que talvez sejam cancelados porque o restaurante ficou sem ingredientes precisam ser
28:11 rastreados. Certo. O que isso significa para o mecanismo? Primeiro, ele vai salvar seu progresso após cada etapa. Isso é opcional no momento no n8n 1.0, mas será essencial no novo mecanismo, pelos motivos que mencionei antes. Em segundo lugar, haverá uma varredura de reconciliação. Ela vai encontrar trabalhos que ficaram presos por algum motivo e repará-los. Também teremos novas tentativas seguras. Só vamos repetir etapas automaticamente se estiverem marcadas como seguras, para não repetir nenhum efeito colateral.
28:42 Vamos executar o código em um sandbox, para que você não precise confiar tanto nele. Teremos pools de workers. Isso significa que você poderá atribuir uma capacidade específica a um ou dois workflows, para que os outros workflows em execução não interfiram neles. Teremos isolamento e limites de recursos, além de espera. Quando seu workflow precisar esperar, ele será um trabalho temporizado armazenado, em vez de ficar na memória. Há muita coisa a caminho com o novo mecanismo. Fiquem atentos nos próximos
29:14 meses. Na área de monitoramento, já temos muita coisa. Temos o Insights, temos streaming de logs e logs de auditoria. Há alguns meses, adicionamos suporte a OpenTelemetry, mas usuários avançados executam mais de uma instância do n8n. Levantem a mão. Quem tem mais de uma instância na organização? Sim, muitas mãos. Talvez vocês façam isso porque têm uma instância de desenvolvimento e uma instância de produção. Ou talvez porque departamentos diferentes precisem de instâncias separadas. Mas o que
29:46 temos ouvido claramente de vocês é que precisam de uma camada de observabilidade que abranja todas elas. Então, apresento a vocês o Manifest. O Manifest é um app separado que funciona no mesmo ecossistema que suas instâncias do n8n e ajuda os usuários com todos os problemas que a automação cria, como saber o que existe e está em execução, quem é responsável por isso e quais sistemas são afetados por quais automações. No momento, estamos fazendo testes com ele. Então, se vocês
30:18 usam várias instâncias e têm interesse em participar deste teste e dar feedback, entrem em contato, porque adoraríamos contar com vocês. No começo, isso será apenas para automações do n8n. Mas queremos ampliar a cobertura para todos os tipos de automação na organização, porque reconhecemos que vivemos em um mundo com várias oportunidades de automação. Certo. E, por fim, vamos à parte de gestão. Essa é a parte humana, organizacional, de operar uma ferramenta
30:49 como o n8n. Muitos de vocês sabem o quanto isso pode ser significativo. E, como a automação está explodindo, os riscos aumentam. Antes, provavelmente lá pelos anos 80 ou algo assim, a TI paralela podia ser uma macro de planilha. Hoje, a situação é muito, muito diferente. Provavelmente há um monte de agents com acesso a sistemas realmente sensíveis. E, na verdade, acreditamos que a governança está se tornando ainda mais relevante do que
31:19 antes. Não apenas para as grandes empresas, que sempre se preocuparam com governança, mas também para as pequenas, por causa do que mencionei antes: provavelmente vocês terão mais agents do que funcionários, e eles talvez sejam tão poderosos quanto. Temos uma pequena estrutura para pensar sobre governança. Ela tem quatro componentes: acesso, limites de proteção, observabilidade e qualidade, e segurança. Acesso diz respeito a quem está agindo e ao que essa pessoa ou esse agent pode acessar. Isso inclui identidade, credenciais e permissões.
31:52 Limites de proteção dizem respeito ao que é restringido e ao que cabe à pessoa decidir. Isso inclui limites de gastos e de uso, políticas, anonimização, etapas de aprovação, encaminhamento de exceções e coisas do tipo. Responsabilidade e qualidade dizem respeito a quem é responsável e se podemos garantir que tudo continue funcionando. Isso envolve gerenciar o ciclo de vida sobre o qual venho falando. Envolve testes, revisão e ambientes. Juntos, esses três princípios
32:24 regem o sistema quando ele funciona como foi projetado. O quarto componente, segurança, diz respeito ao que acontece quando alguém tenta fazer o sistema trabalhar contra você. Isso inclui prompt injection, envenenamento de ferramentas e exfiltração de dados. Já temos bastante coisa nessas áreas. E não se preocupem, não vou explicar tudo neste slide. Só queria dar uma ideia a vocês. Quero fazer uma pausa por um instante no tema da segurança e falar sobre
32:54 avisos de segurança, porque a IA mudou o cenário em muitas áreas, mas em nenhuma tanto quanto na segurança. E, como n8n, vemos muito mais ferramentas analisando bases de código públicas. Além disso, como o n8n tem recebido mais atenção ultimamente, vimos um aumento nos relatos. Cada relato é analisado e corrigido, e enviamos um aviso por e-mail com informações suficientes para que vocês possam agir. E preferimos que
33:26 vocês saibam disso por nós, de forma clara e antecipada, em vez de descobrirem por outro meio. E a boa notícia é que o volume desses casos parece estar se estabilizando com o tempo. Não estamos presumindo que essa tendência vai continuar. Por isso, seguimos investindo nessa área. Mas, no fim das contas, o n8n é código público, o que significa que muita gente está olhando para ele, há muitos olhos sobre o código. As correções podem ser verificadas, então vocês não precisam simplesmente confiar na nossa palavra. E, para ser sincero, esse é um equilíbrio que escolheríamos novamente.
34:00 Certo, de volta a essa estrutura. Quero passar rapidamente por algumas das coisas que planejamos para essas áreas. No que diz respeito ao acesso, a maioria dos agents hoje usa o login de uma pessoa. Então, não é possível saber se foi a pessoa ou o agent que fez aquilo. E o agent recebe todas as permissões que a pessoa tem. Queremos que os agents tenham sua própria identidade, com permissões restritas. Ela permite atribuir ações a um responsável e pode ser revogada. O provisionamento SCIM diz respeito ao que acontece quando uma pessoa
34:31 sai: ela perde o acesso ao sistema ou suas automações continuam em execução? E os grupos de usuários servem para gerenciar usuários, ou para facilitar esse gerenciamento. Na área de limites de proteção, temos políticas e limites. As políticas permitem impedir que as coisas sejam executadas. Os limites restringem os danos depois que algo dá errado. Por exemplo, quando os agents podem entrar em um loop e tentar de novo, às vezes ficam presos. Os custos podem disparar sem que ninguém perceba. Tenho certeza de que muitos de vocês já passaram por isso. Então
35:02 vocês precisam de limites rígidos para definir os parâmetros. Na área de responsabilidade e qualidade, a disciplina de software consiste em aplicá-la à automação e também aos agents. E também em levar o rigor dos evals para o lado determinístico, com testes de workflow. Por fim, sobre segurança, falei um pouco antes sobre execução de código em sandbox. Isso não diz respeito apenas à segurança. Também significa que, quando vocês não precisam confiar no código que estão executando, podem ser muito
35:33 mais liberdade com isso. Assim, por exemplo, você pode carregar bibliotecas aleatórias na sua automação, algo que queríamos adicionar ao N10 há muito tempo. Certo, já falei um pouco sobre o que vem por aí. Mas só queria fazer uma recapitulação bem rápida. Na parte de construção, vamos continuar aprimorando o assistant. Vamos continuar aprimorando MCP e os agents. Mais contexto está a caminho. Também está a caminho a autorrecuperação na parte de auditoria. Queremos
36:05 tornar os evals muito mais intuitivos e fáceis de entender e, basicamente, menos dolorosos. Na parte de deploy, temos esse novo mecanismo a caminho. E, embora hoje não tenhamos um ponto único de falha, também queremos tornar tudo ainda mais robusto com um novo mecanismo. Temos manifest para observabilidade entre instâncias e, então, há uma série de coisas na parte de governança sobre as quais acabei de falar. Certo, ainda vem muita coisa por aí. O ritmo das mudanças está acelerando, e a produção da NA10 está
36:36 aumentando junto com isso, e estamos muito empolgados com o que vem a seguir. E, falando nisso, tenho mais uma coisa para mostrar. Sim. [música] [música] Calor. [música]
37:08 [música] [música] [sino]
37:39 [música] [música] Certo. [aplausos] Este é um novo produto da NAD Labs. Se tiver interesse em conhecê-lo e entrar na lista de espera, tire uma foto e inscreva-se. Adoraríamos que vocês o desenvolvessem conosco. E, com
38:11 isso, muito obrigado pela atenção e por serem uma ótima plateia. Espero que aproveitem o resto do dia e curtam todas as coisas incríveis que preparamos. [música] [música]
Transcrição original
[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]