De 36% a 100%: como agentes que se aprimoram escrevem suas próprias skills — Rafal Wilinski, Runlayer

Autoria: AI Engineer · 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: From 36% to 100%: How Self-Improving Agents Write Their Own Skills — Rafal Wilinski, Runlayer · Canal: AI Engineer · 18:28 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA

Resumo

Rafal Wilinski apresenta uma abordagem para transformar as experiências de agentes em skills reutilizáveis, que preservam procedimentos úteis e orientam execuções futuras. Ele propõe distribuir essas skills pela empresa usando MCP e uma biblioteca centralizada, tornando o conhecimento acessível a diferentes clientes e equipes. No exemplo apresentado, a taxa de sucesso de uma tarefa subiu de 36% para 100% após a criação automática de uma skill a partir de uma execução bem-sucedida. O palestrante defende que esse ciclo de aprendizado coletivo pode reduzir custos, aumentar a confiabilidade e preservar o conhecimento operacional da empresa.

Pontos-chave

Skills são playbooks que um agente pode consultar quando o conhecimento descrito é relevante; esse carregamento seletivo é chamado de progressive disclosure.
Execuções longas ampliam tanto as capacidades dos agentes quanto o risco de persistirem em uma linha de raciocínio equivocada.
Muitas skills são locais e difíceis de compartilhar, e a criação manual de playbooks exige tempo e intenção.
MCP pode funcionar como uma camada centralizada de distribuição e governança de skills para diferentes clientes e equipes.
O projeto Voyager mostrou como descobertas de agentes podem ser convertidas em procedimentos reutilizáveis.
A Runlayer descreve um processo que analisa execuções e usa um modelo de fronteira para destilar skills, incorporando sucessos e falhas.
Em uma tarefa de execução de um fork do Chromium no AWS Lambda, a taxa de sucesso relatada passou de 36% para 100% após a adoção de uma skill reutilizável.
Skills podem reduzir o espaço de busca, o número de chamadas a ferramentas e o consumo de tokens e dinheiro.
Um ciclo organizacional de aprimoramento pode acumular conhecimento interno e ajudar a empresa a depender menos das capacidades variáveis dos modelos.

Capítulos

Início	Capítulo	Resumo
00:01	A ideia de uma empresa que aprende	Rafal apresenta a visão de transformar a resolução de problemas em conhecimento compartilhado e introduz as skills como playbooks para agentes.
04:13	Limites e distribuição das skills	O palestrante explica por que o conhecimento interno é valioso e aponta dificuldades de criação, compartilhamento e suporte a skills.
09:57	De descobertas a skills reutilizáveis	Com o exemplo do Voyager, Rafal descreve como converter execuções e aprendizados de agentes em procedimentos que possam ser reutilizados.
13:07	Um exemplo de aprimoramento automático	Uma skill destilada de uma execução bem-sucedida elevou de 36% para 100% a taxa de sucesso relatada na tarefa com AWS Lambda.
15:13	O ciclo organizacional e o conhecimento coletivo	Rafal descreve como agrupar execuções, verificar skills e distribuí-las pela empresa para criar uma base de conhecimento em evolução.
17:53	Encerramento	Rafal encerra a apresentação e convida o público a conversar sobre skills, MCP e agentes.

Citações

Uma skill, para mim, é essencialmente um playbook que o agente pode ler quando considera relevante o conhecimento. — 02:06

A exploração deve se transformar em conhecimento procedural reutilizável. — 11:01

A taxa de sucesso subiu para 100%. — 13:07

A inteligência de fronteira é alugada ou emprestada. Ela pode desaparecer. — 14:11

Seu concorrente não consegue copiar sua cultura interna e sua identidade. — 17:20

Conceitos e entidades

Rafal Wilinski (pessoa): Engenheiro fundador da Runlayer que apresenta a abordagem de aprimoramento organizacional por meio de skills.
Runlayer (empresa): Empresa na qual Rafal Wilinski trabalha e que desenvolve uma abordagem para distribuir e aprimorar skills de agentes.
skill (conceito): Playbook reutilizável que um agente pode consultar para aplicar procedimentos relevantes a uma tarefa.
progressive disclosure (conceito): Abordagem em que o agente vê primeiro uma descrição breve de uma skill e carrega seu conteúdo completo quando necessário.
MCP (conceito): Protocolo que, segundo a palestra, pode servir como camada de distribuição centralizada de skills entre clientes.
Voyager (modelo): Projeto apresentado como exemplo de agente que registra descobertas em uma biblioteca de procedimentos reutilizáveis no Minecraft.
METR benchmark (conceito): Benchmark citado para medir por quanto tempo agentes conseguem trabalhar de forma independente com chance razoável de concluir uma tarefa.
AWS Lambda (ferramenta): Serviço usado no exemplo de uma tarefa para executar um fork do Chromium.
Sonnet 4.6 (modelo): Modelo usado na tarefa de executar um fork do Chromium no AWS Lambda.
Zapier (empresa): Empresa na qual Rafal Wilinski diz ter liderado equipes de agentes e de IA antes de entrar na Runlayer.

Tradução completa (pt-BR)

00:01 [música] Olá, pessoal, sou Rafal. Hoje quero falar sobre agents que se aprimoram, mas não no modo para um único jogador, em que apenas um agent fica mais inteligente. Quero falar sobre como podemos aplicar esse conceito e combiná-lo com efeitos de rede para criar uma empresa que se aprimora sozinha — ou talvez até uma organização que se aprimora enquanto você

00:33 dorme. Imagine o melhor engenheiro com quem você já trabalhou, ou um vendedor ou advogado. Aquele que, sempre que resolvia um problema realmente difícil, anotava exatamente como fez e entregava o manual à equipe. Assim, quando enfrentassem um problema parecido, não precisariam resolvê-lo do zero, certo? E imagine que isso acontecesse automaticamente, sempre que surgisse um problema difícil em qualquer lugar da sua empresa. Isso seria um

01:04 sonho, certo? Mas quase nunca funciona assim. Mesmo quando resolvemos um problema realmente difícil, muitas vezes todo o conhecimento, toda a depuração, todo o raciocínio por trás disso simplesmente desaparece. Ah, desculpem. Todo esse raciocínio simplesmente desaparece quando passamos para a próxima tarefa ou encerramos a sessão. Mas quero convencer vocês de que isso é realmente possível e que já temos todos os elementos necessários

01:34 para fazer isso acontecer. Se parece interessante, deixa eu me apresentar de novo. Oi, sou Rafal. Sou engenheiro fundador da Runlayer. Estamos criando o caminho recomendado para IA na sua empresa. Antes disso, eu liderava os agents da Zapier e diferentes equipes de IA. Mas, de modo geral, meu trabalho anterior era fazer com que agents não fossem apenas demonstrações chamativas, mas soluções confiáveis em produção. Antes de entrarmos nas partes interessantes, quero dividir meu tema em três partes distintas e começar simplesmente por

02:06 aprimorar agents. Há muitas maneiras de fazer isso. Podemos usar modelos melhores. Podemos usar ferramentas melhores de prompting, harnesses e coisas do tipo. Mas hoje quero me concentrar apenas em skills, porque elas são muito acessíveis, certo? Pelo menos em teoria. Para garantir que estamos todos na mesma página: para mim, uma skill é um manual que o agent pode ler quando considera que aquele conhecimento é relevante. Do ponto de vista técnico, isso se chama divulgação progressiva e significa que, no início, o harness ou o

02:38 cliente vê apenas um resumo da skill ou uma breve descrição dela. Mas, quando considera que o conhecimento contido na skill pode ser útil, pode ler a skill inteira, inseri-la no contexto principal e, com base nesse conhecimento, mudar a trajetória do agent. Por que isso é tão importante? Bem, se você não passou os últimos 6 ou 12 meses debaixo de uma pedra, seu workflow provavelmente mudou bastante. E isso aconteceu porque os agents ficaram muito melhores. Na verdade, os modelos ficaram muito

03:08 melhores. E não é só impressão: isso pode ser medido. Aqui vocês podem ver um gráfico que provavelmente já viram vezes demais. Para quem não conhece, é o benchmark METR. Ele mede por quanto tempo os agents conseguem trabalhar de forma independente e ainda manter uma chance razoável de concluir uma tarefa. E a palavra “chance” é essencial aqui. Daqui a pouco vamos voltar a isso. Mas a tendência é clara. As capacidades de ponta, a inteligência de ponta, estão melhorando cada vez mais. Os agents estão melhores em trabalhos profundos com várias etapas. Há

03:41 apenas uma ressalva: desde que essa inteligência de ponta não esteja sendo tirada de você. E eu sou falível, provavelmente como você. Mas há um porém. Com grandes poderes — ou horizontes de tarefas longos — vêm grandes responsabilidades. Se um agent consegue raciocinar por muito mais tempo, isso também significa que ele pode entrar num buraco de coelho realmente, realmente profundo. Pode fazer centenas de chamadas de ferramentas tentando defender uma tese errada, raciocinar por horas, e o próximo agent pode fazer exatamente a mesma coisa, ou talvez até

04:13 fazer algo ainda pior. Então, a trajetória inicial importa muito, e é por isso que as skills são tão importantes: elas orientam o agent na direção certa. Caso contrário, você desperdiça tempo, tokens e, o mais importante, dinheiro. Skills valiosas são os rituais que ninguém quer ter de redescobrir. Esse conhecimento muitas vezes não é glamoroso. Provavelmente está profundamente enraizado na sua empresa. E, se os agents tentarem redescobrir esse conhecimento do zero,

04:44 por exemplo, a sequência de scripts e feature flags necessária para fazer uma reversão segura, ou qual é exatamente a formulação e a linguagem a usar ao lidar com aquele cliente corporativo irritante que está prestes a cancelar, é provável que fracassem ao tentar descobrir isso do zero. E, muitas vezes, esse fracasso pode custar muito caro. Por isso, acredito que tantos projetos de prova de conceito de IA fracassam: vocês não estão dando aos agents o contexto relevante e os manuais de como agir dentro da empresa.

05:17 Então, as skills são ótimas, mas acho que não estão livres de problemas. Há três problemas mais importantes. O primeiro é que elas priorizam o uso local e são centradas em desenvolvedores. Com isso, quero dizer que, quando você olha para o ecossistema de skills, encontra arquivos Markdown, arquivos JSON, comandos CLI e repositórios Git. Se você é desenvolvedor, ótimo. Mas, se é vice-presidente de IA ou responsável pela adoção de IA, precisa pensar de forma mais

05:48 empática em como implementar a estratégia de IA em toda a empresa, incluindo as pessoas sem conhecimentos técnicos, certo? O desafio é como essas pessoas podem criar e compartilhar skills. Adoro este meme. Aqui está o desenvolvedor júnior ou a pessoa sem conhecimentos técnicos descobrindo o comando npx skills, que é o comando mais importante, o mais popular para instalá-las. É o único comando que conheço que instala não só uma skill, mas também injeções de prompt gratuitas. É só

06:18 um script maluco que exige permissões de root e a chave de API de outra pessoa, tudo numa única execução. Acreditem: na Runlayer, analisamos milhares de skills todos os dias, e há coisas muito estranhas nelas. Certo. O segundo problema é que acho que todos nós adoramos a situação em que enfrentamos um problema difícil e já existe um manual sobre como lidar com ele, certo? Mas, muitas vezes, não há manual, porque

06:48 leva tempo, esforço, intenção e energia refletir sobre um problema e deixar algo útil para a posteridade. E o terceiro problema é que nem todo cliente de LLM oferece suporte a skills, certo? Se você está no ecossistema Claude, provavelmente está tudo bem. Se é desenvolvedor, provavelmente consegue se virar, mesmo que o suporte a skills seja estranho, dependendo do cliente que usa. E, mais uma vez, se pensar em marketing, RH, jurídico e finanças, esses departamentos

07:19 provavelmente ainda estão usando o ChatGPT ou algum outro cliente de LLM estranho, e talvez não haja suporte a skills. Há algum tempo, houve um grande debate acalorado quando as skills foram introduzidas. Algumas pessoas proclamaram: “Graças a Deus, MCP finalmente morreu, porque não quero lidar com OAuth. Agora posso codificar diretamente um monte de comandos CLI, colocar minha chave de API diretamente num arquivo Markdown e chamar isso de progresso”, certo? Mas acho que todo mundo perdeu o ponto. As skills podem fornecer o conhecimento sobre como fazer

07:51 algo, e as ferramentas nos dão capacidades. As ferramentas do MCP nos dão a capacidade de fazer essas coisas. Mas o MCP também pode ser usado como um protocolo para fornecer conhecimento, para fornecer skills. Podemos usar o MCP como camada de distribuição. Assim, em vez de instalar skills localmente, você pode criar um servidor MCP remoto, que pode se tornar a fonte de verdade em toda a empresa. Os clientes podem se conectar a ele. Podem buscar as skills certas. O servidor pode aplicar políticas e garantir que todos

08:23 recebam a melhor versão possível da skill, dependendo da consulta e, por exemplo, da função atribuída à pessoa. Temos feito isso internamente na Runlayer nos últimos 6 meses, e tem funcionado muito bem. Mas já não é apenas algo interno. Vemos que o ecossistema MCP mais amplo também está seguindo nessa direção. Já existe um grupo de trabalho chamado skills over MCP e, embora a API exata ainda não esteja definida, a direção é clara. O MCP pode ser usado para fornecer skills, para distribuir conhecimento

08:54 a empresa inteira. Sim, e embora a especificação oficial esteja caminhando para recursos do MCP, o suporte a recursos também é inconsistente. Então, vamos usar tools. E, sim, se vocês se lembram do problema — o primeiro problema que mencionei e o terceiro problema que mencionei —, que é o fato de eles serem específicos de cada fornecedor e da falta de suporte para clientes, o MCP resolve isso como uma camada de distribuição, porque é unificado e funciona em praticamente

09:25 todos os clientes, não apenas nos clientes para desenvolvedores. Então, o problema de distribuir skills para pessoas sem conhecimentos técnicos está basicamente resolvido, certo? Além disso, agora vocês têm uma API centralizada. Assim, como VP de IA ou responsável pela adoção de IA, vocês têm um lugar para governar e gerenciar o conhecimento que está sendo compartilhado e distribuído pela empresa. Certo. Agora sabemos como podemos melhorar os agents, porque temos skills. Sabemos que podemos usar o MCP para distribuir essas skills entre todos os clientes e

09:57 agents. Mas vamos falar de algo mais interessante: como os agents podem melhorar a si mesmos. E, sempre que vejo um novo artigo ou framework que aborda esse tema, sempre volto ao artigo sobre Voyager. Infelizmente, vocês não conseguem ver o vídeo, mas, ao fundo, há uma partida de Minecraft. Então, em 2023, logo depois do lançamento do GPT-4 — há muito tempo —, a pergunta era: por quanto tempo vários agents ou harnesses conseguiriam explorar o mundo de Minecraft, certo? Eles colocaram

10:29 o agent dentro de Minecraft sem instruções. Ele definia os próprios objetivos. O agent simplesmente continuava melhorando sem sequer mexer nos pesos, no modelo ou nos prompts. E, em 2023, acho que isso foi bastante revolucionário. Como eles conseguiram? O principal a notar aqui é a biblioteca de skills. Voyager não apenas explorava o mundo de Minecraft com cuidado e descartava o registro. Quando o agent descobria algo, salvava a receita como código que consistia nas tool calls que levaram o agent à descoberta. Assim,

11:01 mais tarde, quando o agent decidia que precisava criar uma mesa de trabalho ou uma picareta de diamante, não precisava descobrir todo esse conhecimento do zero. Podia simplesmente acessar a biblioteca de skills e recuperar aquilo como código, como uma receita que pudesse ser reutilizada. E isso é muito importante. Essa é a ideia central que quero levar adiante: a exploração deve ser transformada em conhecimento procedural reutilizável.

11:32 E começamos a fazer algo muito parecido na Runlayer. Deixamos os agents fazerem o trabalho de verdade. Quando uma execução é bem-sucedida e há algo interessante nela, com várias tool calls, simplesmente pegamos esse registro e pedimos ao Frontier LM que destile uma skill, certo? E, embora seja muito simples destilar uma skill a partir de uma única execução, acho que nós, humanos, e os agents aprendemos mais com

12:05 os erros, certo? O verdadeiro aprimoramento acontece quando o agent falha. Uma execução que dá errado é, na verdade, o sinal mais rico que se pode obter, porque revela a proteção que está faltando, a biblioteca que está faltando ou algum caso extremo em que vocês não pensaram de antemão. E cada execução, bem-sucedida ou não, alimenta continuamente nosso mecanismo de destilação, melhorando as skills. Os sucessos tornam a skill mais confiável, porque, se o agent

12:35 atingiu o objetivo, isso significa que a skill funciona; e, se não atingiu, a skill fica mais robusta, porque agora sabemos o que está faltando. E tudo acontece de forma totalmente autônoma e assíncrona, sem uma pessoa no processo. E os resultados iniciais foram ótimos. Tínhamos uma tarefa de tentar executar um fork do Chromium dentro do AWS Lambda e estávamos tentando fazer isso usando o Sonnet 4.6. Não é o modelo mais inteligente, mas às vezes ele conseguia. Só que

13:07 uma taxa de sucesso de 36% não é, sabe, algo pronto para produção. Então, ativamos o recurso de agents que se aprimoram. Em uma execução, uma das invocações do agent descobriu como fazer, e nosso destilador de skills criou uma skill reutilizável. Ela foi incluída em todas as execuções futuras, e a taxa de sucesso chegou a 100%. Então, sim, isso é ótimo. É como um desenvolvedor com uma atitude melhor em relação à documentação. E a taxa de sucesso é o número mais fácil de mostrar. Mas uma boa skill reduz o espaço de busca. Ela faz o agent explorar menos possibilidades e parar de fazer tool calls desnecessárias, usando menos tokens e gastando menos dinheiro. Mas, deixando de lado a economia e a precisão, acho que também há um motivo mais profundo para destilar skills. O problema é que a inteligência de ponta é

13:38 alugada ou emprestada. Ela pode desaparecer. Acho que todos sentimos falta do Fable. Era um ótimo modelo, certo? Ele pode ser descontinuado ou ficar mais burro. Como reclamamos todos os dias no Twitter e no Slack que o Opus está muito burro hoje, certo? Então, enquanto temos acesso à melhor versão dessa inteligência, devemos usá-la para descobrir e preservar esses procedimentos úteis. Devemos criar um catálogo de como o trabalho é feito dentro da nossa empresa, como uma espécie de subconsciente coletivo.

14:11 E como fazemos isso? Bem, acredito que já temos todas as peças do quebra-cabeça. Temos skills como forma de reter procedimentos, melhorar agents e orientar modelos. Temos o MCP como uma camada unificada de distribuição dessas skills. E também temos um repositório central, a base de conhecimento de todas essas skills, que é constantemente atualizado e alimentado com novos dados. Também temos o ciclo de aprendizado contínuo para um agent. Mas

14:42 o que é interessante é o que prometi a vocês logo no começo: o efeito de rede. O que acontece quando multiplicamos isso por cada agent e cada cliente da empresa inteira? Na Runlayer, chamamos isso de ciclo organizacional de autoaperfeiçoamento. Agrupamos várias execuções semelhantes e tentamos destilar uma skill. Ela passa por várias etapas de verificação, como verificar se não contém algum tipo de prompt injection ou informações de identificação pessoal, entre outras coisas. Quando está pronta, vai para

15:13 nossa biblioteca de skills e, graças ao nosso gateway MCP, é disponibilizada a todos os clientes e agents da empresa. O que acabamos tendo é uma base de conhecimento em constante evolução, sempre atualizada e continuamente alimentada com novas informações e casos extremos recentes. Então, quando um agent resolve um problema realmente difícil, isso é destilado em uma skill, que fica disponível em toda a biblioteca da organização. Assim, sempre que outra pessoa tiver o mesmo

15:44 problema no futuro, não precisará descobrir a solução do zero. Não precisará saber qual é a sequência exata daqueles comandos mágicos que vão reiniciar o banco de dados ou reverter a produção. Basta consultar o manual que tem à disposição. E por que isso é tão importante? Porque acho que cerca de 50% de nós provavelmente já teve uma crise existencial por causa dos modelos. E o raciocínio é mais ou menos assim: certo, os modelos estão virando commodities. Todo mundo aqui tem acesso a eles. O custo do software vai chegar a zero. Qualquer pessoa pode reconstruir meu produto. Pelo menos superficialmente. Na verdade, tanta gente está andando hoje pela feira pensando: “Ei, todo mundo está construindo a mesma coisa, certo? Então, qual é a minha vantagem competitiva?” E acredito que essa vantagem pode estar em construir esse ciclo e destilar o conhecimento por meio dele, porque isso transforma as lições duramente aprendidas

16:16 em um registro governado de como a empresa faz as coisas, sabe? E esse conhecimento fica registrado e se acumula, elevando o nível de todos na empresa e dando a eles acesso ao melhor conhecimento disponível. Também é uma forma de resistir à degradação da inteligência dos modelos e uma ótima maneira de reduzir custos sem nunca trocar de modelo. Então, sim, provavelmente essa é uma coisa que um concorrente não consegue copiar: sua cultura interna e sua identidade.

16:48 E é basicamente isso. Obrigado por virem. Se isso fez sentido para vocês, eu sou Rafal. Trabalho na Runlayer. Estamos descobrindo o caminho ideal para a IA para vocês. Estou à disposição para conversar sobre skills, MCP, agents e coisas do tipo. E é exatamente isso que estamos construindo na Runlayer. Obrigado.

17:20 >> [música]

17:53 E é basicamente isso. Obrigado por terem vindo. Espero que tenha feito sentido para vocês. Sou Rafal. Trabalho na Runlayer. Estamos descobrindo o caminho ideal de IA para vocês. Estou à disposição para conversar sobre skills, agentes MCP e coisas do tipo. E é exatamente isso que estamos construindo na Runlayer. Obrigado.

18:28 >> [música]

Transcrição original

[00:01] [music] Hi everyone, I’m Raal. Today I want to talk about self-improving agents but not in a single player mode where just one agent gets smarter. I want to talk about how we can apply that concept and mix it with network effects to get a self-improving company or maybe even an enterprise that self-improves while you

[00:33] sleep. Um, imagine the best engineer you ever worked with or a salesperson or a lawyer. Um, the one that every time they cracked a genuinely hard problem, they wrote down exactly how they did that and handed over the playbook to the team. So whenever they face a similar problem, they don’t have to figure it out from the scratch, right? And imagine that happening for every hard problem across your whole company and that happening automatically uh each time. That’s a

[01:04] dream, right? But it almost never works that way. Um even when you crack a really hard problem um often times the knowledge um all that debugging um all the all the reasoning behind that is just gone. Oh sorry um all that all that reasoning is just gone when you move on to the next the next task or close the session. But I wanted to convince you that this is actually possible and we already have all the primitives in place

[01:34] to make it happen. If it sounds interesting, let me try to introduce myself once again. Hi, I’m Rafal. I’m a founding engineer at rum layer. We are making the golden path for AI at your company. Before that, I was leading Zapier agents and different AI teams. But generally speaking, my previous work was about making agents not just flashy demos, but reliable things in production. Um before we go into interesting parts, I want to break down my topic into three separate pieces and start by just

[02:06] improving agents. There are many ways to do that. We can use better models. We can use better prompting tools, harnesses and whatnot. But I want to focus today only just on skills because they are super accessible, right? At least in theory. um to make sure that we are all on the same page. A skill to me is a playbook that essentially agent can read um when it thinks that the knowledge is relevant from the technical perspective that the term is called progressive disclosure and it means that at the very beginning the harness or a

[02:38] client sees just a summary of the skill or a short description of the skill. But when it thinks that the knowledge inside the skill can be useful, it can read the whole of the skill, inject it to the main context and based on that knowledge, it can change the trajectory of the agent. Why is this so important? Well, if you haven’t been living under a rock for the past 6 or 12 months, your workflow probably has changed a lot. Uh, and that’s because the agents got so much better. Actually, the models got so

[03:08] much better. And and it’s not just vibes, it’s measurable. Um here you can see a chart that probably you have seen too many times already. For those who don’t know, it’s meter benchmark. It measures for how long agents can work independently while still having a decent chance of completing a task. And the word chance is essential here. Um we are going to go back to in a moment. But the trend is clear. The frontier capabilities, the frontier intelligence is getting better and better. They are better at multi-step deep work. There’s

[03:41] only one caveat if that frontier intelligence is not being taken from you. And I’m fable probably just like you. But there is a catch. With great power or long task horizon comes great responsibility. If an agent can reason for much longer, it also means that it can dig a really really uh deep rabbit hole. um it can spend hundreds of tool calls trying to defend a wrong thesis reason for hours and the next agent can do exactly the same thing or maybe even

[04:13] do something wrong worse. Um so the initial trajectory matters a lot and that’s why skills are so important because they guide the agent towards the right target otherwise you’ll waste time, you will waste tokens and most importantly you’ll also waste money. Um, valuable skills are the rituals that nobody wants rediscovered. That knowledge is often not glamorous. It’s probably deeply embedded within your company. And if agents would try to rediscover that knowledge from scratch,

[04:44] like for instance, the sequence of scripts and feature flags in order to make a nice roll back or what’s the exact wording and language to use when dealing with that pesky uh enterprise customer that’s about to churn. Um, yeah, if agents would try to figure out that from scratch, they are likely going to fail. And often times that failure can be really costly. That’s why I believe so many AIP PCs are failing because you’re not giving agents the relevant context and the playbooks how to act within your company.

[05:17] So SKS are great, but I feel like they are not problem free. Um there are three most important problems and the first one is that they are local first and defcentric. What I mean by that is that um when you look at the skills ecosystem, you’re going to find uh markdown files, JSON files, CLI commands, git repositories, and if you’re a developer, that’s great. But if you’re um adop uh VP of AI or AI adoption lead, you need to think more

[05:48] empathetically about how you can roll out the AI strategy across your whole company, which includes nontechnical people, right? And the challenge here is how nontechnical people can actually create and share uh the skills. Uh I love this meme. Um this is the junior developer or nontechnical person discovering command npx skills which is the most important the most popular command to install them. That’s the only command I know that installs just uh not

[06:18] just a skill but also free prompt injections. um a wild script that requires root permissions and someone else’s API key all in one run. Trust me at run layer we are scanning thousands of skills every day and there is really weird stuff inside. Okay. Second problem is that I think we all like we all love the situation where we are facing a hard problem and there’s already pray on how to deal with that situation right but often times there’s there’s no playbook right because it

[06:48] time it takes time and effort and intention and energy to reflect on a problem and leave something useful for posterity behind and the third problem is that not every LLM client support skills right if you’re in cloud ecosystem, it’s probably great. If you’re a developer, you’re probably going to manage even if the skills support is weird depending on which client you’re using. Um, and once again, if you think about marketing, HR, legal, finance, those departments are

[07:19] probably still using chat GPT or some other weird LM client and skills might be not supported there. And sometime ago, there was this big heated debate when the skills were introduced. Um, some people proclaimed that thank god MCP is finally dead because I’m not interested in dealing with oath. I can now hardcode a bunch of CLI commands. Um, hardcode my API key inside markdown file and call it a progress, right? Um, but I think everyone missed the point. Skills can be delivering um the knowledge how to do

[07:51] something and tools gives us capabilities. Tools from MCPS give us capability to do those things. But MCV can be also used as a protocol to deliver the knowledge to deliver the skills. We can use MCP as the distribution layer. So instead of installing skills locally, you can create a remote MCP server which can become the source of truth across your whole company. Clients can connect to that. They can they can search for the right skills. Uh server can enforce the policy and make sure that everyone

[08:23] gets the best version of the skill possible depending on a query. and for instance the role that they have assigned. We’ve been doing that internally at run layer for the past 6 months and it’s been working quite well. Um but it’s no longer just an internal thing. We see that the broader MCP ecosystem is also going that direction. Um there’s already a working group called skills over MCP and while the exact API is not final direction is clear. MCP can be used to deliver the skills to deliver the knowledge across

[08:54] your whole company. Um yeah and while the official spec is leaning towards MCP resources the support for resources is also mixed. So we are going with tools. Um and yeah if you remember the problem the first problem I mentioned and the third problem I mentioned which is um the problem that they are defentric and the lack of uh support for clients. MCP as a distribution layer fixes that because it’s unified in and works in almost

[09:25] every single client, not just developer clients. So the problem of devel of distributing skills to nontechnical people is essentially solved, right? Plus you have now a centralized API. So as a VP of AI or like AI adoption, you have one place to govern and manage what’s the knowledge that’s getting shared and distributed across your company. Okay. So now we know how we can improve agents because we have um skills. We know that we can use MCP to distribute those skills across all the clients and

[09:57] agents. But let’s talk about something more interesting which is how agents can improve themselves. And whenever I uh see a new paper or a framework speaking about this topic, I always go back to um Voyager paper. Unfortunately, you cannot see the video, but it’s Minecraft gameplay in in background. So in in 2023, right after GPT4 was released, so ages ago, the question was for how long multiple agents or harnesses can explore Minecraft space, right? Um they dropped

[10:29] the agent into Minecraft with no instructions. They set its own goals. Agent just kept getting better without even touching the weights or or model and the prompts. And in 2023, I think it was pretty groundbreaking. How did they pull it off? Um the key thing to notice here is the skill library. So Voyager did not just explore the Minecraft space care carefully and throw the trace away. When the agent figured out something um it saved the recipe as a code that uh

[11:01] that consisted of the tool calls that lead it that lead the agent to the discovery. So later on when the agent decided that hey I need to create a a crafting table or a diamond pickaxe it didn’t have to figure it out this whole knowledge from scratch. It could simply go to the skill uh library and retrieve it as a code as a recipe um that can be reused. And this is really important. This is the core idea that I want to carry forward is that um exploration should be turned into reusable

[11:32] procedural knowledge. And we started doing something very similar at run layer. Um we let the agents do the real work. And when the run succeeds and when there is something interesting in this run, there’s multiple tool calls. Um we just take that trace and we ask Frontier LM to simply distill a skill, right? And while it’s super simple to distill a skill from a single run, um I think we humans and agents learn the most from

[12:05] mistakes, right? The real sharpening happens when the agent fails. Um so a roundout goes sideways is actually the richest signal that you can get because it exposes the missing guardrail, the missing library, some kind of edge case that you haven’t thought about up front. Um and every run or or pass or fail just feeds our distiller mechanism constantly making our skill better. Um the successes are making the skill more trustworthy because if the agent

[12:35] achieved the goal it means that hey this skill works and if it doesn’t it actually makes skill more robust because now we know what’s missing in here and it all happens completely autonomously asynchronously without human in loop and the initial results were great uh we had uh this task of trying to run some chromium fork inside AWS Lambda and we were trying to do that using sonet 4.6. So not the most intelligent model but sometimes it succeeded. Um but it was

[13:07] just you know it’s not production ready to have 36% success rate. Um so what we did is we flipped the flag for self-improving agents. Um and once in one run the one of the agent invocations cracked the code our skill distiller create a reusable skill. It was uh then included in all the future runs and the success ratio went to 100%. So yeah, that’s great. It’s like a developer with better attitude towards documentation. Um and the success rate is the easiest

[13:38] number to show. But good skill is narrowing the search space. It makes the agent uh it narrows the search space and agents starts doing uh stops doing tool calls and it’s exploring less branches. it’s w w w w w w w w w w w w w w w w w w w w wing less tokens and and less money. But putting savings and accuracy aside, I think there’s also a deeper reason why you should be distilling skills. Um the problem is that frontier intelligence is

[14:11] rented or borrowed. It can disappear. I think yeah, we all miss Fable. It was a great model, right? It can deprecate it or it can get dumber. Like we complain every single day on Twitter, on Slack that Opus is really dumb today, right? So while we have the access to the best version of that intelligence, we should be using that to discover and persist those use useful procedures. We should be building a catalog of how the works gets done inside our company as a collective subconscious.

[14:42] And how we do it? Well, I believe we already have all the pieces of the puzzle here. Um, we have skills as a way to retain procedures and improve agents and guide models. We have MCP as a unified distribution layer for those skills. And we also have a central repository, the knowledge base for all of those skills, which is constantly being updated and fed with new data. Um, yeah, we also have the continuous learning flywheel for one agent. But

[15:13] what’s interesting is what I promised you at the very beginning, the network effect. Um, so what happens when you multiply that by every agent and every single client in the entire company? At run later, we call it selfimproving organizational flywheel. Um, we group a bunch of similar runs and try to distill a skill. It passes through our various series of checks like whether it’s not containing some kind of prompt injection or maybe PII um and bunch of other stuff. Once it’s good, it’s landing in

[15:44] our skill library and thanks to our MCB gateway, it’s being served to each and every client and agent within the company. What we end up having is a constantly evolving knowledge base which is always up to date, continuously updated with new alpha fed with new age edge cases. So once one agent figure outs a really hard problem, it’s getting distilled into a skill persistent in all or organizational library. So whenever someone else um has the same

[16:16] problem in the future, they don’t have to figure out the solution from scratch. They don’t have to know uh what’s the exact sequence of this magical commands that are going to restart the database or roll back the production. They can simply um reach out to the playbook. they have. And why is this so important? Because I believe like 50% of us probably already had an existential crisis thanks to the models. And the thinking goes along the lines of u okay so models are becoming

[16:48] commodity. Everyone here has access to them. Um cost of software is going to zero. Everyone is can be rebuilding my product. Um at least on the surface. In fact, so many people are walking today across the expo and they are thinking, hey, everyone’s building the same thing, right? So, what is my moat? Um, and I believe the mode can be in building this flywheel and distilling the knowledge through this flywheel because it’s like your own hard one lessons distilled

[17:20] governed of how your company uh does things you know and it’s captured compounding raising the floor for everyone across the company giving them access to the best knowledge available. Um, it is also a way to be resistant against model intelligence deprecation and it’s a great way to lowers your costs without ever changing a model. So yeah, that’s probably one thing that competitor can’t copy your internal culture and your identity

[17:53] and yeah that’s pretty much it. Uh, thank you for coming if it resonated with you. I’m Rafal. I’m working at run layer. We’re figuring out the AI golden path for you. I’m open to talk about skills, MCP agents, whatnot. And this is exactly what we are building at run layer. Thank you.

[18:28] >> [music]