Pare de dizer aos agents como fazer — Dan Barrett, Raymond Weitekamp e Jose Montes de Oca, OpenProse

Ver no idioma original →

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: Stop Telling Agents How — Dan Barrett, Raymond Weitekamp & Jose Montes de Oca, OpenProse · Canal: AI Engineer · 49:25 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Engenharia de prompts e contexto, Open source e ecossistemas de software

Resumo

Dan Barrett apresenta o OpenProse como uma forma declarativa de expressar objetivos e contratos para agents, em vez de prescrever cada etapa de execução. Raymond Weitekamp explica que a ferramenta é baseada em Markdown e permite criar workflows multi-agent acionados por eventos, usando diferentes harnesses. As demonstrações mostram a criação de uma revisão de pull requests e a geração de documentação regulatória para modelos quantitativos. Os palestrantes também discutem composição de contratos, verificadores, controle de custos e casos de uso que exigem processos repetíveis, confiáveis e auditáveis.

Pontos-chave

• OpenProse expressa o resultado desejado como um contrato, deixando o harness determinar como alcançá-lo.
• A linguagem é baseada em Markdown e pode ser lida e editada por pessoas, inclusive por quem não programa.
• O projeto enfatiza workflows multi-agent acionados por eventos, não conversas de chat.
• Contratos podem ser compostos para representar processos complexos e controlar etapas intermediárias.
• Uma execução bem-sucedida pode ser codificada como um workflow mais específico e previsível, reduzindo custos.
• A versão hospedada permite configurar jobs acionados por webhooks e cron jobs.
• Sessões independentes de revisão podem comparar o trabalho com um contrato e reduzir o viés de autorrevisão.
• O OpenProse pode ser usado com diferentes harnesses e modelos, inclusive em instalações locais ou empresariais.
• Entre os casos de uso apresentados estão revisão de pull requests e documentação de modelos quantitativos para compliance.
• A ferramenta é mais adequada a tarefas recorrentes, confiáveis e auditáveis do que a explorações pontuais.

Capítulos

Início	Capítulo	Resumo
00:01	Por que declarar a intenção	Dan Barrett apresenta o desafio de comunicar objetivos a sistemas cada vez mais capazes e introduz a ideia de contratos declarativos.
04:20	Declarar o resultado, não o método	A equipe explica como padrões de engenharia de software e composição podem ajudar a expressar resultados sem fixar cada procedimento.
06:00	OpenProse em Markdown e orientado a eventos	Raymond descreve o OpenProse como texto legível para pessoas e uma forma de criar workflows multi-agent acionados por eventos.
11:10	Jobs, triggers e workflows para GitHub	A apresentação mostra como contratos podem ser iniciados por cron jobs ou webhooks, incluindo eventos de issues e pull requests.
14:51	Como ajustar o nível de especificidade	Os palestrantes explicam como começar com um objetivo aberto e depois tornar o processo mais específico a partir de uma execução bem-sucedida.
19:11	Criar um workflow por meio de um agent	Raymond demonstra um agent que gera um programa OpenProse para revisar novos pull requests como um desenvolvedor cético em relação a código gerado por IA.
24:38	Revisões independentes e decision models	A equipe discute a verificação de resultados contra contratos, o uso de sessões independentes e o possível papel de decision models.
29:26	Ativação de jobs e uso empresarial	Raymond conclui a demonstração do job de revisão, e Dan apresenta o uso do OpenProse em ambientes locais e empresariais.
31:01	Documentação de modelos quantitativos	Dan demonstra no Codex um workflow para gerar documentação regulatória de um modelo quantitativo usando um kernel e um contrato.
36:26	Resultados e limites do caso financeiro	A equipe comenta a avaliação da documentação gerada, os custos envolvidos e a importância de validação por especialistas e auditores.
41:17	Quando usar OpenProse e como compor contratos	Os palestrantes distinguem workflows recorrentes e auditáveis de tarefas exploratórias e explicam como compor múltiplos contratos.
44:01	Compor workflows multi-agent	A equipe ilustra como contratos intermediários podem organizar agents de pesquisa, redação e revisão, além de padrões como fan-out e revisão adversarial.
48:52	Usos em engenharia e encerramento	Os palestrantes citam aplicações em engenharia de software, operações e gestão de produto antes de encerrar a apresentação.

Citações

Ainda precisamos comunicar nossa intenção à máquina. — 01:06

Diga o que fazer, não como fazer. — 04:55

É tudo texto e estamos fazendo workflows multi-agent orientados a eventos, não conversando. — 06:00

O que funciona bem são workflows que você precisa executar muitas vezes, com confiabilidade, repetibilidade e auditabilidade. — 41:17

Conceitos e entidades

• OpenProse (ferramenta): Linguagem e framework baseado em Markdown para declarar contratos e compor workflows multi-agent.
• Dan Barrett (pessoa): Criador do OpenProse e palestrante que apresenta a abordagem declarativa da ferramenta.
• Raymond Weitekamp (pessoa): Membro da equipe do OpenProse que demonstra seus workflows e a versão hospedada.
• Jose Montes de Oca (pessoa): Integrante da equipe do OpenProse, apresentado como colaborador e engenheiro.
• run.prose.md (ferramenta): Versão hospedada do OpenProse apresentada para criar e executar jobs.
• Codex (ferramenta): Coding agent usado na demonstração de um workflow para documentar modelos quantitativos.
• Claude Code (ferramenta): Harness citado como uma das opções para executar workflows do OpenProse.
• Exa (empresa): Serviço de busca que Raymond cita como opção preferida para pesquisas em seus workflows.
• DSPy (ferramenta): Framework usado como comparação para explicar uma abordagem de abstração e execução diferente da do OpenProse.
• Jev (modelo): Decision model mencionado como possível verificador rápido e barato para avaliar se um resultado satisfaz um contrato.
• contract (conceito): Declaração do resultado desejado e das condições que um workflow precisa satisfazer.
• event-driven workflow (conceito): Workflow iniciado por eventos, como um agendamento, um webhook ou a abertura de uma issue.
• Harness (conceito): Ambiente que fornece a execução e os recursos usados pelos agents, e que o OpenProse procura não substituir.
• composição de contratos (conceito): Organização de contratos menores e etapas intermediárias para formar um workflow maior.
• documentação de modelos quantitativos (conceito): Processo de produzir e atualizar documentação regulatória para modelos quantitativos.

Tradução completa (pt-BR)

00:01 [música] >> Meu nome é Dan. Sou o criador do Open Pros. Este ano é Raymond… Estou acompanhado por Raymond e Jose, dois colegas de equipe e de trabalho fabulosos, criadores e engenheiros simplesmente fenomenais. Vou apresentá-los um pouco melhor daqui a pouco. Só um pouco de contexto sobre o que estamos prestes a mostrar aqui.

00:33 Há 5 anos, em abril de 2021, fui eleito o melhor prompter nos bastidores do Discord do EleutherAI, uma habilidade que, na época, achei que seria tremendamente valiosa por muitos anos. Na verdade, acho que ela durou uns dois ou três anos, talvez esse tenha sido o tempo de vida daquela habilidade. E digo isso porque, obviamente, muita coisa mudou nos últimos 5 anos, como todos vocês sabem. Mas uma coisa não mudou, e

01:06 Participei de muitas oficinas hoje. Temos muitas palestras incríveis pela frente. Mas a única coisa que parece estar sempre presente em todo o trabalho que fazemos, e que não muda com o harness mais recente nem com o modelo mais recente, é que todos ainda precisamos comunicar nossa intenção à máquina. Não importa o quanto ela fique inteligente, ainda existe o desafio de tirar da minha cabeça aquilo que quero e passar isso para a superinteligência, que simplesmente vai

01:40 levar isso adiante e fazer tudo por mim. O Open Pros é uma linguagem, é um framework; começou como um projeto baseado no meu próprio amor pela linguagem e na minha forte convicção de que a linguagem é uma força de criação realmente poderosa. Sei que isso é um pouco clichê, mas digo isso no sentido mais literal, com as capacidades que temos agora. Você pode escrever uma frase, e as coisas simplesmente tornam essa frase verdadeira. Então a pergunta passa a ser: qual

02:14 é a frase que você escreve, agora que tem essa máquina tremendamente poderosa para torná-la verdadeira? A habilidade de escrever prompts de 5 anos atrás é bem diferente da habilidade que hoje gostamos de considerar como criação ou composição de contratos. Quando você lidava com um modelo que simplesmente completava o próximo token, havia bons e maus padrões para escrever prompts. Alguns anos depois, você preenchia o contexto manualmente, pegava resultados de RAG, tool calls e outras coisas e

02:48 resultados de busca e os colocava na context window, e chamava isso de engenharia de contexto. Depois, o harness começou a fazer isso por você, e você estava construindo um harness e o via como essa máquina que preenchia o contexto para você. E, nos últimos 8 ou 10 meses, vimos vários artigos serem publicados, elevando tudo mais um nível de abstração, e os próprios harnesses estão mudando diante dos seus olhos. Hoje de manhã, vimos uma ótima apresentação da Anthropic

03:18 sobre fluxos, e essa é a ideia de uma topologia de harness que se modifica sozinha e gerencia subagents de uma maneira que simplesmente não era concebível nem há um ano. Então, se o [inaudível] está resolvido, o contexto agora está resolvido e os harnesses também estão resolvidos, qual é o próximo passo? É sobre isso que gostaríamos de falar um pouco hoje e mostrar algumas das coisas que temos construído para dar suporte a isso. Gosto de pensar que, quando você consegue nomear o que quer,

03:49 qualquer harness pode se moldar sozinho, expandir em várias frentes e executar qualquer tipo de loop para chegar lá. A questão é: quais são as melhores práticas para nomear aquilo que você quer? E pensamos nisso como algo declarativo. Vamos pegar conceitos da engenharia de software clássica. Sou engenheiro de software há 12 anos. Jose e Raymond também têm bastante experiência. Jose estava no início do Google Cloud e influenciou várias das maneiras como pensamos sobre isso. Raymond é simplesmente fenomenal. Ele me disse para apresentá-lo como um… Ele me disse para apresentá-lo

04:20 como um craque em vibe coding, mas isso fica muito aquém dos talentos dele. Ele tem doutorado, fundou duas empresas e trabalha com engenharia de harness há basicamente tanto tempo quanto qualquer pessoa que conheço. Então, a ideia é pegar padrões antigos de engenharia e aplicá-los a este novo mundo. Queremos escrever nossos prompts de forma composicional. Queremos composição em vez de herança. Queremos escrever nossos prompts de forma declarativa, em vez de procedural ou imperativa. Queremos dizer o que fazer, não como fazer, porque o

04:55 harness, com sua sabedoria infinita e sua inteligência infinita, vai descobrir isso. E, se dissermos a ele como fazer as coisas, estaremos deixando custo e inteligência na mesa, porque poderíamos executar isso com um modelo mais barato. Um modelo mais inteligente consegue descobrir como fazer. Então, a ideia é escrever o que você quer, declarar o que você quer: o resultado, o objetivo, o estado final. Pensamos nisso como um contrato. E escrevê-lo de um jeito que permita compor esses elementos, porque, quando você constrói um sistema, quando constrói um framework aberto como este, quando constrói um sistema com muitas partes, talvez distribuídas pela

05:29 sua empresa ou pela sua equipe, você quer fazer as coisas de uma maneira que permita uma composição elegante e que possibilite gerenciar a complexidade de forma mais localizada. Com isso, vou passar a palavra para Raymond, que vai explicar um pouco como funciona, e depois vamos mostrar algumas demonstrações. Vamos abrir para perguntas durante a apresentação. Então, por favor, levantem a mão se tiverem perguntas e interrompam à vontade. >> Incrível. Obrigado, Dan. Certo, então…

06:00 Queria apenas ajudar vocês a entender o Open Pros e situá-lo em um quadrante. Se vocês só lembrarem de duas coisas, quero que se lembrem destas: é só Markdown. Às vezes gostamos de chamá-lo de linguagem de programação para agents. Às vezes, chamamos de framework, mas tudo é apenas texto. É só um prompt gigantesco. A segunda coisa que pode ajudar a encaixá-lo na categoria certa é que ele é orientado a eventos. Não é um chat. Não ficamos conversando com essas coisas. Vou conversar com um agent que vai criar

06:33 programas de Open Pros mais tarde, mas, se vocês só lembrarem de duas coisas sobre nós, é isso: é tudo texto e estamos fazendo esses workflows multi-agent orientados a eventos, não conversando. Ele é open source; vocês podem executá-lo localmente com NPX skills. Vou apresentar a versão hospedada que criei, run.pros.md, e também podemos fazer isso para vocês. Se quiserem entrar em contato, podemos ajudar. Então, uma pergunta rápida: quantas pessoas aqui são da área financeira?

07:03 Certo, ótimo. Quantos são engenheiros de IA ou desenvolvedores? Certo. E quantas pessoas talvez sejam mais da área de gestão de produto ou profissionais que usam IA, mas não sabem programar? Certo, menos pessoas, mas… Ótimo. Então, vou explicar por que isso deveria interessar a esses três grupos. Para os pequenos setores regulados, uma das coisas que vimos deixar alguns bancos e outras empresas de serviços financeiros animados é o que eu disse antes: é tudo texto. Então, nós

07:34 não precisamos do departamento de compras nem do departamento de TI. Vocês podem usar o coding agent que quiserem, a inference que quiserem, as guardrails que já tiverem e a stack que tiverem. Podemos ajudar a criar esses workflows multi-agent sem fazer nenhum deploy para vocês, além de alguns arquivos Markdown. Esse é um dos aspectos ou benefícios de ser tudo texto. Para quem não escreve código, basicamente, se consegue ler inglês lógico, consegue ler Open Prose. Então, vamos…

08:05 especificamente, não entrar na sintaxe da linguagem. Tecnicamente, é uma linguagem de programação e tem uma sintaxe, mas ela foi feita mais para ser lida e editada por pessoas do que para ser escrita à mão, do zero, por pessoas. Não queremos que os usuários precisem se preocupar em aprender o schema. Então, você pode descrever o trabalho, pedir ao seu agent que escreva o programa Prose, que talvez lhe dê mais ideias de como você pode querer editá-lo, ou talvez você veja algo que queira mudar,

08:35 e então esse programa Prose se torna o workflow reutilizável. Para os engenheiros de IA e desenvolvedores, acho que o motivo para usar isso é que, sabe, é um framework que não é um framework — e já vamos falar um pouco disso —, mas até o compilador do framework, até a máquina virtual do framework, é só um prompt gigante. Você literalmente está implantando código no código para compilar o programa para você, implantando

09:06 o Codex para fazer isso. Dá para expressar workflows multi-agent muito, muito complexos, parecidos com o que a Anthropic chama de workflows dinâmicos de agent — acho que seria uma analogia. Dá para fazer isso em qualquer agente de programação, usando apenas nosso contrato em markdown. Certo. Então, primeiro, sobre essa ideia de que é só markdown: isto pode ser um programa completo, só como exemplo. E, de novo, não quero me prender

09:36 tanto à sintaxe, mas basicamente você pode dizer: “Ei, aqui está o objetivo e aqui está o contrato que este programa mantém. Aqui está a definição do que esse contrato mantém.” E, de novo, é um exemplo bem simples e meio bobo. A ideia aqui é: o que você pode declarar? De novo, não quero entrar no schema, nos tipos e na sintaxe, mas o que você ou

10:06 seu agent pode declarar em seu nome, usando o CLI, chama-se função pros write. No nosso app, é basicamente o agent que conduz o app inteiro para você. Você pode criar subagents. Pode atribuir skills específicas a esses subagents específicos. Pode disponibilizar ferramentas específicas. Por exemplo, para buscas, adoro o Exa. Acho que eles são incríveis e não quero que ele faça uma busca comum na web. Quero sempre que use o Exa, porque é mais rápido e mais barato para mim. Você pode dizer: “Aqui está a skill para isso. Aqui está o CLI para isso.” Se não conseguir encontrar essas coisas,

10:37 simplesmente não execute o programa. Não vamos fazer do outro jeito. Você pode ter skills específicas da sua empresa ou organização. E, essencialmente, dá para pensar nisso como conectar as partes do programa e, se ele não tiver todas as dependências, não compile, certo? E, obviamente, quais são as entradas deste programa e quais são as saídas que este programa — este contrato — precisa entregar? E, de novo, isso pode ser algo para quem quiser conversar com Dan sobre como ele construiu isso. O próprio runtime também é só um prompt gigante,

11:10 também. Então, algumas das minhas frases favoritas na skill ou no prompt são: “Você é o compilador.” Isto não é uma analogia. Você é o compilador. E parece funcionar. Então, sim, essa ideia de ser orientado a eventos. Queremos deixar para trás a ideia de que tudo é uma conversa, que tudo é um chat, e construir sistemas orientados a eventos. Então,

11:40 de novo, só para comparar essas diferentes árvores de workflow: algo acontece, pode ser apenas um cron job agendado, a abertura de uma nova issue no GitHub ou a criação de um novo PR, ou algum sistema de webhook, certo? Sei lá, o Stripe não está funcionando, seja lá o que for. Aí você pode acionar o workflow que definiu para resolver toda a situação de ponta a ponta e cumprir o contrato. E essa ideia de começar a

12:14 construir em torno de jobs: você pode configurar isso por conta própria, com seus próprios agents no seu próprio sistema. O que construí em run.prose.md é essa ideia de que um job é um contrato mais um acionador. De novo, o acionador pode ser algo muito simples, como um agendamento. Então, aqui estou basicamente dizendo: “Certo, execute isto todos os dias.” Mas, no momento, os dois principais acionadores que já implementamos no app são webhooks, que realmente

12:45 abrangem muitas coisas diferentes — um app inteiro do Slack é só webhooks, o GitHub também usa só webhooks — e cron jobs. Teremos prazer em adicionar mais, se vocês quiserem nos dar feedback sobre quais poderíamos facilitar para vocês. E, de novo, a partir desse acionador, vocês fazem a triagem desses workflows. Assim, podem começar a construir essas, sabe, fábricas de código, criando jobs permanentes dos programas Prose. O que quero mostrar — e já vou chegar lá

13:15 daqui a pouco — é uma das coisas que venho desenvolvendo para garantir que fique pronta a tempo deste evento: webhooks e o uso específico de eventos do GitHub. E tenho me obrigado a usar o programa para desenvolver o próprio programa. Um dos exemplos que temos agora na issue do sistema é o seguinte — na verdade, há dois principais. Um é: para qualquer issue do GitHub que chegar, você escreve um programa Prose para definir como ele tentará resolver a issue. Você pode torná-lo tão complexo ou tão

13:49 simples quanto quiser. Ele pode ser um workflow multi-agent. Pode exigir skills específicas ou usar modelos específicos. Então, basicamente, a entrada é o que quer que seja aquela issue e a saída é um commit. E ele precisa ir até o fim e concluir essa tarefa para você. E, de modo parecido — vou mostrar este exemplo com mais detalhes —, dá para fazer isso com revisões de PR. Assim, você pode fazer esse tipo de revisão adversarial orientada a eventos. Não sei se vocês ouviram, em uma das coisas que achei interessantes esta manhã, na oficina da Anthropic, eles

14:20 estavam falando sobre os desafios da autorrevisão. Você está no Claude Code e diz: “Certo, vou deixar você fazer o deploy em produção, mas pode só conferir mais uma vez para mim?” E ele tende a achar que fez um bom trabalho. Os humanos também são assim, certo? Então, vou mostrar um workflow em que, basicamente, os agents que estão construindo isso recebem essa contrapressão do próprio app, por meio de pull requests.

14:51 Certo. Enquanto passamos para isso, alguém tem alguma pergunta enquanto mudamos para o app web? >> Por favor, não existe pergunta boba demais. Isso é uma mão levantada ou um celular? Não consigo ver as luzes daqui. >> Talvez ninguém. >> Sim, pode falar. >> Tem alguém ali. >> [limpa a garganta] >> É uma ótima pergunta. Vou responder. >> Sim, você devia responder. >> Sim. Na verdade, temos essa ideia de que, como mencionei antes, o “o quê” e o “como” são duas coisas diferentes, duas

15:23 ideias diferentes. Declare o resultado e deixe o “como” um pouco em aberto; deixe o agent descobrir. Nesse espectro, como você observou, há situações em que você realmente quer opinar sobre o “como”. E, na verdade, temos um recurso, uma sintaxe que permite fixar o “como”. Então, você pode começar declarando algo bem aberto. Pode deixar um agent muito inteligente executar e descobrir como chegar ao resultado que você declarou. E, quando

15:55 faz isso, você pode dizer: “Aqui está o rastreamento do agent. Vamos pegar esse rastreamento e, de certa forma, codificá-lo ou, não sei, empacotá-lo como um “como fazer”. E o que isso nos permite fazer é, na verdade, reduzir o custo de concluir o workflow. Então, você começa com um modelo muito caro, que descobre como fazer, e depois, como você diz, torna isso mais específico, mais determinístico. Então, é como se você estivesse deslocando o espectro de um “o quê” totalmente aberto para um “como”, um “como fazer”. E o custo diminui à medida que

16:28 você faz isso. Então, quando dizemos que é tudo Markdown, é aí que você pode começar, mas depois pode avançar para instruções mais específicas, procedurais e imperativas também. >> Sim, acho que tenho alguns comentários sobre isso. Primeiro, temos um sistema em que você pode pegar uma sessão exemplar e dizer: “Transforme isto em um workflow reutilizável”. Tipo: “Esta foi a melhor sessão do Claude Code que já tive. Eu queria fazer isso, porque recebemos esse pedido o tempo todo, né?” E acho que

17:00 há uma parte disso em que essas coisas não são determinísticas. Acho que muitos dos endpoints que as pessoas chamam de “fixos e estáveis” acabam mudando, como já demonstraram, porque todas essas empresas estão com restrições de capacidade computacional. Mas também acho que existe essa questão das expectativas em constante mudança, né? É como na primeira vez que você experimentou, sei lá, o Fable ou algo assim, isso explodiu sua cabeça e você pensou: “Quero isso. Esse workflow é incrível. Quero isso sempre.” E aí você meio que vai se acostumando e passa a ter expectativas diferentes

17:31 e, de repente, isso não acontece de novo. E parte disso é simplesmente confiabilidade. Então, uma coisa que você pode fazer é pegar uma sessão muito boa e codificá-la. Mas outra coisa, para dar um pouco mais de crédito ao Dan por criar o framework, é que os arquivos Markdown que você vê são só a ponta do iceberg do que ele está usando. Da última vez que conferi, o system prompt completo, ou skill, ou seja lá como você quiser chamar — quer dizer, é uma skill, é um system prompt — tinha quase 70 mil, 80 mil tokens de comprimento, com…

18:05 >> mais ainda. Estamos tentando enxugar. Estamos tentando… >> Sim, bem, agora que os agents são mais inteligentes, podemos deixá-lo um pouco mais curto. Mas, basicamente, temos todo esse sistema de tipos, em que substituímos o Markdown por um sistema de tipos muito, muito claro e um prompt bem específico sobre como o agent vai entregar esse produto incrivelmente complexo com vários agents na saída. Mas, para deixar claro o que não alteramos: o Claude Code, quando é executado, tem seu próprio sistema para subagents. Não queremos mexer nisso. Não queremos que nosso prompt

18:38 seja, de forma alguma, específico para o Claude Code, porque o Codex tem um conjunto de subagents totalmente diferente. Então, somos, sei lá, um meta-harness. >> [risos] >> Seja lá o que isso for. Somos uma camada. Queremos que você traga seu próprio harness. Não queremos ser o harness. Queremos ser essa coisa que é compilada pelo harness. Então, acho que esses são alguns pontos… >> Isso responde à sua pergunta? >> Certo. Então, se quiser experimentar, está aqui: o QR code, run.prose.md. O QR code leva até lá. Se quiser começar a testar. O que eu quero fazer

19:11 para demonstrar isso é mostrar algumas coisas. Então, a primeira coisa é… Este é um programa Prose no modo de edição, certo? Tecnicamente, é Markdown, e o Dan substituiu os cabeçalhos H3 por todos os tipos dessa coisa. Mas fazer alguém aprender essa

19:42 sintaxe e escrevê-la do zero não é bem o objetivo. Então, o que queremos fazer é… Mesmo que tudo o que executa este programa esteja aqui — e, na verdade, para os verdadeiros nerds da plateia, dá para ver que peguei o front matter do arquivo Markdown, e isso corresponde a tudo o que está acontecendo na nuvem — eu poderia pegar este programa e exportá-lo como um arquivo Markdown puro

20:15 e enviá-lo para um amigo, e ele vai carregá-lo na nuvem dele exatamente da mesma maneira, para que continue sendo composável e fiel à ideia de que usamos somente Markdown. Enfim, a ideia toda é que, embora isso seja o programa e queiramos que vocês leiam, esse não é o ponto de entrada. Em vez disso, criei um agent que, espero, vai conversar comigo aqui. >> Oi, sou o Prose. O que você espera realizar hoje? >> Certo, então, sempre que eu tiver um novo pull request, quero que você escreva para mim um

20:53 programa Prose no meu repo run-prose que o revise como se você fosse um desenvolvedor sênior rabugento que não gosta de código gerado por IA. >> Claro, posso fazer isso. Só um instante. >> Certo. Vou me silenciar. Ele está falando. Vai tentar descobrir como fazer isso. E a ideia toda é que qualquer coisa…

21:24 Então, qualquer coisa que possa cobrar ou gastar dinheiro precisa ser confirmada. Acho que isso é uma boa prática. Ah, sim. Ótimo. Tive que confirmar porque essa ação custa dinheiro. Essa é a função de taxa do Prose. Basicamente, ela pega minha consulta e vai gerar um novo programa a partir dela, incluindo toda a conexão entre as partes. Esta etapa vai demorar um pouco mais. Enquanto isso está sendo executado, vou mostrar como fazer isso manualmente, na aba de jobs. Não sei por que isso está

21:56 falhando. Na aba de jobs, podemos vir aqui e criar um novo job. A opção “por agendamento” é simplesmente um cron job. Temos um web hook aberto, sem uma finalidade específica. Então, você ou seu agent podem usar nosso web hook específico ou conectar nosso sistema para escutar o seu web hook. Mas, para GitHub… vou fazer a mesma coisa. Facilitamos isso para pull requests do GitHub. Vamos fazer isso no run.prose. Eu já conectei este contrato. É como dizer: “Certo, você vai revisar

22:29 o meu conteúdo”. Depois posso escolher qual modelo usar entre os que eles têm. Vamos adicionar mais depois. No momento, temos os três principais da OpenAI. Aí é só criar e fazer o deploy. Outra coisa que quero mostrar enquanto este está funcionando é como venho usando isso como pressão de retorno. O principal… Não se prendam demais ao conteúdo aqui em cima. Mas o

22:59 que quero mostrar aqui é o volume. Isso tudo vai até três dias atrás, mas, se eu for aqui, estes ainda são de três ou quatro dias atrás. Então, num intervalo de poucos dias, isto está fazendo dezenas e dezenas e dezenas de PRs. E, sempre que peço um novo recurso para essa funcionalidade de webhooks do GitHub que eu queria deixar pronta para este evento, cada um deles aciona uma série

23:33 de agents de revisão. Alguns são simples, tipo: “Certo, este claramente parece ter funcionado de primeira”. Então, houve apenas uma rodada. Alguns tiveram, sabe, 14 rodadas de revisão até os agents revisores parecerem alinhados e deixarem passar. E, ainda hoje, notei algo de que não gostei na forma como estava fazendo isso, e consegui basicamente dizer: “Certo, no nosso servidor de staging, sabe…”

24:06 não mexa na produção. Estou prestes a dar uma palestra. No servidor de staging, quero que você, tipo, altere as coisas exatamente das maneiras como isso será acionado, mas você mesmo precisa usar o sistema. Então, tanto nossa versão de desenvolvimento quanto nossa versão de produção estão dando avaliações diferentes. E agora o agent que está rodando aqui, cujas diferentes tarefas podemos ver na aba de execuções, basicamente não pode considerar o trabalho concluído até que…

24:38 os meus agents de desenvolvimento tenham que levar esse feedback em conta. >> E, só para enfatizar o que há de diferente em algo assim em relação a qualquer outro fluxo baseado em chat ou em agent que vocês tenham visto: todos esses resultados são comparados com um contrato. Então, dá para pensar nisso como uma sessão nova a cada vez, avaliada em relação a esse contrato que você escreveu de forma declarativa. Como Raymond mencionou antes, isso tira os modelos daquele ciclo de autoconfiança, em que você não quer que o mesmo modelo verifique o que foi feito. Então,

25:09 você inicia novas sessões e as compara com um contrato, o que é simplesmente um padrão melhor para fazer isso. Sim, pode falar. >> Sim. >> Mas não parece uma ótima oportunidade para classificadores de uma só etapa, como o Jev? >> Sim. Eles… >> Temos muitas coisas boas a caminho. Então, a ideia de verificar em relação a um contrato e validá-lo… Desculpe, Raymond. >> Sim. >> Isso é muito empolgante nesses decision models, em que você tem um contrato, que é algum estado ideal, e depois tem seu estado caótico do mundo real

25:41 e pode aplicar uma classe geral de decision model, como o Jev, para dizer: isso foi aprovado ou não? >> Então, acho que… >> neste caso, mas isso está a caminho. >> Sim, e acho que, sem… Dan, de novo, estamos nos desviando bastante do roteiro, mas é uma ótima pergunta, e a grande Jev-ificação está chegando. Então, precisamos falar disso. Acho que Dan e eu temos pensado bastante nisso e percebemos que o próprio OpenProse, a linguagem que é toda em

26:14 Markdown, acho que não tem lugar nenhum no universo do Jev, porque não são generativos. A ideia toda da linguagem, de gerar uma linguagem e entender uma linguagem, não é isso. Mas acho que há dois lugares em que pensamos que isso se encaixaria muito bem, em particular com o run.pros hospedado: um deles é no backend. Então, a desvantagem, ou o ponto fraco, do OpenProse é que você está deixando o agent dizer: “Cumpri o contrato. Aqui está.” Certo? E muitas vezes vou

26:48 dizer às pessoas que a intenção por trás do OpenProse é parecida com algo como DSPy: você quer ter uma camada de abstração por meio da qual possa expressar workflows muito complexos. A implementação é exatamente o oposto de DSPy. No DSPy, cada chamada de LLM é uma caixa-preta, e você isola completamente essa coisa. É tudo código determinístico. São interfaces tipadas que só deixam a caixa-preta fazer aquela coisa. A abordagem de Dan com o OpenProse é exatamente o oposto,

27:18 que é: a IA está ficando inteligente o bastante para ser o compilador. Deixe tudo ficar em terreno nebuloso. Mas o ponto fraco disso é que, se você executar no Haku ou no Fable, vai obter um resultado bem diferente, e também está deixando o sistema dizer “terminei”. Então, acho que um lugar muito natural para o Jev, ou esses novos decision models, ou como quisermos chamá-los, os modelos System 1, é, como você disse, como verificador no fim do trabalho: muito, muito rápido e barato. E a outra coisa que quero criar, relacionada a isso, é um roteador.

27:52 Então, por que eu teria que clicar no botão que diz: “Ah, issues vão para o trabalho de issue, mas PRs vão para o trabalho de revisão de PR”? Por que eu não posso simplesmente dizer: “Certo, todos os eventos do GitHub que chegarem: resolvam as issues, revisem os PRs”, certo? Outra pergunta. >> Não dê mais ideias a eles sobre o jogo. >> Certo. >> Eu sei, eu ia dizer… >> [risos] >> Obrigado. Isso está muito em pauta na esfera do Twitter neste exato momento: por que você simplesmente não faria RL disso? Se tenho todas essas execuções ótimas aqui em relação ao contrato, por que não estou simplesmente fazendo RL disso?

28:22 >> Então, voltando à questão da linguagem, uma das ideias é: por que estamos fazendo isso em linguagem, afinal? A motivação original, do lado humano, é que você pode fazer commit disso no Git, controlar as versões ou, sabe, usar no Notion ou no Jira, e qualquer pessoa da sua equipe pode usar. Mas, do ponto de vista da engenharia, o fato de ser tudo texto é perfeito e maravilhoso para RL. Então, não estamos fazendo isso agora, mas é algo sobre o qual estamos absolutamente conversando com vários possíveis clientes:

28:56 quando você tem tudo escrito como texto, isso fica… >> Sim. >> muito melhor para RL. >> Sim, ainda não chegamos a volumes em que isso seja importante, mas, se você estiver hospedando o modelo e tiver esse prefixo de cerca de 100.000 tokens, pode simplesmente… ou, sabe, criar representações mais eficientes em tokens. Então, se alguém quiser usar um trilhão de tokens no OpenProse, teremos prazer em simplesmente… para você. Então, enfim, voltando ao assunto,

29:26 obrigado. Essas são muito boas. Agora temos nossa revisão de pull request feita por um veterano mal-humorado. E, de novo, a ideia principal é que o agent fez tudo isso por nós. A ideia principal aqui é que, ao implantar esse job, ele começará a gastar dinheiro sempre que recebermos um PR novo, então preciso clicar nisso. Vou confirmar. E, depois que for implantado, quando eu voltar aos meus jobs, ele vai… vai aparecer exatamente como… vamos ver.

29:57 Então, se simplesmente… Opa, alterei isso. Quando carregar, devemos ver. E o mal-humorado está no topo ou embaixo? Sim, aqui está. Revisão de PR por uma IA cética e mal-humorada. Então, dá para ver que eu estava praticando antes. Certo. Então, sobre isso, acho que esses são os pontos principais. Sim, sou responsável pelo run.pros.md, então, se tiverem algum problema, não contem

30:28 ao meu chefe; mandem direto para mim. E meus agents vão cuidar disso para vocês. Mas, sim, estou muito animado com isso como uma maneira simples e fácil de usar para criar esses sistemas baseados em eventos. Se quiserem ver outros gatilhos ou outros recursos, isso vai ser muito divertido para mim. Mas, de novo, vocês não precisam usar o serviço hospedado de jeito nenhum; podem usar a skill em vez disso: NPX skills add open prose prose. Mas agora, com isso, Dan vai

31:01 passar por um exemplo específico para nossos amigos da área financeira, e vamos mostrar esse exemplo no Codex. Depois, ele vai aproveitar para falar um pouco mais sobre como tudo isso funciona por baixo dos panos. >> Isso mesmo. Obrigado. >> Claro. >> Fazer isso funcionar na nuvem é interessante. Um dos casos de uso mais interessantes sobre os quais temos conversado com vários clientes e possíveis clientes é

31:34 Você pode… isto é uma estrutura, uma linguagem ou um padrão que pode ser desenvolvido internamente e executado localmente. A ideia toda aqui é que você pode executá-lo localmente. Não precisa usar nossa versão na nuvem. Adoraríamos que você experimentasse na nuvem e brincasse com ele, para ter uma ideia de como funciona. Mas, se isso é algo que você quer implementar dentro da sua organização, o caso de uso mais interessante que estamos vendo é usar modelos abertos, o seu próprio harness — trazer o seu próprio harness — e então usar isso como uma espécie de

32:06 camada de aplicação por cima disso, o que permite desenvolver toda essa stack internamente. Você não precisa enviar nenhum dos seus dados para os laboratórios. Mais importante do que os seus dados: você não precisa enviar para fora o conhecimento institucional da sua organização. Gostamos de pensar no OpenProse, na verdade, como conhecimento operacional institucional documentado, certo? Pense nele como procedimentos operacionais padrão. Portanto, ainda mais importante do que os seus dados é não querer enviar seus procedimentos operacionais padrão para os grandes laboratórios. E isso se encaixa muito bem nessa stack de código aberto, com uma camada de aplicação

32:37 por cima. Publicamos esse núcleo aberto. Ele tem uma licença permissiva. Você pode incorporá-lo internamente e usá-lo. Temos várias grandes empresas que já estão fazendo isso. E você pode trazer o seu próprio harness. Pode usá-lo com os modelos aprovados que sua empresa já tem. Assim, você não precisa sentir que está jogando dados ou o conhecimento da sua organização para além do muro. Isso é só… Quer dizer, podemos falar um pouco mais sobre isso, e quero abrir espaço para mais perguntas. Este é um workflow que estamos desenvolvendo para

33:09 um cliente interessado em usar OpenProse para documentar seus modelos quant. Para quem conhece o assunto, os modelos quant têm vários compromissos regulatórios, segundo os quais, a cada três anos, a cada ano ou quando ocorrem determinadas mudanças, é preciso atualizar a documentação dos modelos. Pela nossa experiência, esse costuma ser um processo que exige muito trabalho de profissionais de escritório, pessoas muito inteligentes. Talvez

33:43 alguns de vocês passem uma parte do ano revisando e escrevendo documentação. Ela documenta para que o modelo está sendo usado, em que condições foi testado, quem são os outros modelos que o referenciam a montante e uma série de outros requisitos. Esses requisitos são, obviamente, exigidos pelos reguladores, pelos auditores internos e pela área de compliance interna. Esse é um fluxo que descobrimos que funciona bem. É perfeito porque, de certa forma, os documentos regulatórios são como um programa OpenProse, certo? E esses requisitos são escritos em prosa. Então, vou iniciar… Vocês podem ver que estamos no Codex. Vocês podem executar isso no Cloud Code. Poderiam executar no seu próprio harness. A ideia toda é que isso não depende de um harness específico. Então, dizemos apenas para iniciar o kernel. Depois, o Prose é executado, seguido de um programa específico. Vou iniciar isso e, enquanto está executando, posso mostrar como é o kernel e depois como é o próprio programa.

34:17 E essas são as únicas duas coisas que vocês passam como entrada. Basta passar o kernel, que é publicado publicamente. Todos podem baixá-lo agora mesmo e experimentar; depois, escrevam qualquer programa que quiserem, qualquer contrato que exija um conjunto complexo de condições a serem satisfeitas, e os agents simplesmente vão trabalhar. Quanto melhor o harness e o modelo, mais rápido e mais barato eles produzirão o resultado. Mas a ideia é declarar o resultado, em vez de declarar como realizá-lo.

34:49 Vamos voltar ao Chrome. >> Bem ali. >> É esse. Então, este é o kernel. Está em Markdown. Não é feito para ser lido por você, por isso está formatado assim. Originalmente, tínhamos um formato mais bonito, e as pessoas reclamaram. Disseram: “O que é isso?” Ele foi feito para ser lido pelos agents. E é apenas Markdown. São instruções operacionais sobre o que esperar. Você pode pensar nele como algo parecido com um bootloader ou um caminho de resolução, um

35:20 um sistema de índice, uma forma de encontrar outros documentos de que o agent precisa. E o programa em si — e, de novo, é isso a que me referi no Codex — parece muito semelhante. Então, também está em Markdown. Contém uma série de requisitos que os reguladores, a área de compliance e os auditores estão procurando. E especifica, sabe, o estado ideal, ou seja, que o resultado final esteja em conformidade com esse contrato.

35:54 E essas são as únicas duas coisas que vocês passam como entrada. Basta passar o kernel, que é publicado publicamente. Todos podem baixá-lo agora mesmo e experimentar; depois, escrevam qualquer programa que quiserem, qualquer contrato que exija um conjunto complexo de condições a serem satisfeitas, e os agents simplesmente vão trabalhar. Quanto melhor o harness e o modelo, mais rápido e mais barato eles produzirão o resultado. Mas a ideia é declarar o resultado, em vez de declarar como realizá-lo.

36:26 Vamos ver se conseguimos voltar e conferir. Executamos isso com um modelo relativamente barato, para rodar mais rápido. Mas ainda está trabalhando. Ah, parece que está terminando. Então, este é o documento que produziu. Neste caso, estamos criando documentação para a curva Sofa. É um modelo público, então não estamos mostrando nenhum dado interno de banco. E… não sei. Levantem a mão. Tem alguém aqui que trabalhe com quant? Para revisar? O que acham? Sim, [risos], certo. Bom, vamos procurar vocês depois. Mas, como sabem, esta é uma documentação que precisa ser produzida regularmente para cada modelo. Um grande banco tem cerca de 4.000 modelos. Eles precisam ser documentados de novo todo ano, e esse é um problema que vale de 10 a 50 milhões de dólares por ano para alguns desses bancos maiores. E estamos tendo ótimos

36:59 resultados ao fazer isso para eles por um custo muito menor. Claro, há algumas… Fazer isso passar pela área de compliance, pelos auditores e pelos reguladores é outra parte da batalha, obviamente, como tenho certeza de que todos sabem. Mas podemos comparar isso com resultados históricos. Podemos comparar com o tempo que as equipes levam para fazer o trabalho, e temos profissionais de quant que estão no pregão e conseguem avaliar esses resultados e nos dar uma ideia de quão bem os modelos estão se saindo

37:32 nisso. E estamos achando que é, quer dizer, surpreendentemente bom. Por um custo muito menor do que o método manual tradicional. Alguma pergunta? Tipo… >> Os profissionais de quant fazem aquilo em que são bons. >> Criar os modelos. >> Não o trabalho burocrático regulatório, que provavelmente não é muito divertido. Não sou profissional de quant, mas… >> [fungada] >> Alguma pergunta? Ótima pergunta. Sim. Na verdade, o Raymond está mostrando um pouco o agent de chat como parte do kernel, como

38:05 algo que fica escondido no Markdown, em um determinado caminho: temos boas práticas. São os tipos de coisas que você deve fazer ao declarar resultados. E há também antipadrões, coisas que você não deve fazer. Então, sim, existe um cenário em que você não digita o contrato inteiro, mas vai iterando. E era isso que o Raymond estava mostrando: outro agent seguindo nosso guia de boas práticas sobre como criar o contrato. Mas, sim, quer dizer,

38:37 escondidas no Markdown, em um caminho, temos boas práticas. Essas são as coisas que você deve fazer ao declarar resultados. E estas são as coisas a evitar, os antipadrões. Então, sim, existe um cenário em que você não digita o contrato inteiro, mas vai iterando, e é isso que Raymond estava mostrando: outro agent seguindo nosso guia de boas práticas sobre como criar o contrato. Mas, enfim,

39:09 Fazer a intenção sair da cabeça das pessoas é a parte difícil, e acho que isso é uma parte disso. Certamente não é o todo. >> Sim. Tenho um desabafo um pouco mais longo sobre isso, mas não quero me estender demais. Só temos 5 minutos. Acho que isso é uma grande parte do motivo de o chat ter explodido tão rápido: você não precisa saber nada sobre o que está procurando; é só começar a interagir com o ChatGPT e aproveitar a magia da IA generativa, com ela respondendo para você, certo? Então, se isso

39:43 não sei se OpenProse é o melhor lugar para você se ainda está num estágio em que realmente nem sabe bem do que está falando, ou nem tem certeza do que está procurando. E eu sou um usuário de longa data do DSPy, e a minha piada sobre o DSPy era: “Ah, não, agora eu preciso saber o que quero, né?” Porque a ideia toda do DSPy é que você precisa criar a assinatura daquilo que quer. E, quando você vê

40:14 algo assim, pensa: “Isso é incrível.” Aí você se senta e pensa: “Ah, na verdade, eu não sei o que quero fazer, né?” Então, acho que, sabe, o OpenProse é bem menos rígido do que algo como o DSPy, em que você precisava literalmente especificar a assinatura do objeto de retorno, senão nada acontecia. Mas, sim, eu diria que o agent integrado pode ajudar com algumas dessas coisas. Você pode simplesmente ativar a voz e perguntar: “O que você consegue fazer?” E ele pode fazer quase tudo o que você consegue fazer no app, como nós

40:45 sabemos, temos aquelas confirmações codificadas para qualquer coisa que custe dinheiro. Obviamente, queremos que as pessoas cliquem num botão para isso. Mas, sim, acho que também tem a ver com a grande jobificação: o chat não é uma ótima interface, e agents treinados com RLHF para serem parceiros de conversa convincentes não são necessariamente o melhor tipo de IA para

41:17 workflows que não envolvem conversa humana. >> E deixe-me acrescentar uma coisa: os casos de uso. Dizemos às pessoas que não devem usar isto se for algo pontual; para isso, o chat é perfeito. Se você está explorando, também. Isto é bom para algo que você precisa fazer muitas vezes. Precisa ser confiável, repetível e auditável. É para esse tipo de workflow que o OpenProse foi criado e é destinado. Então, há uma expectativa implícita

41:51 de que você saiba do que precisa aqui. >> Ah, temos uma pergunta de um quant de verdade. >> E, antes, aludi a isso — e eu não chamaria simplesmente de herança; chamaria de composição. Na verdade, uma característica central do framework e do próprio padrão é que ele foi feito para ser composto. Então, sim, injetar vários contratos na mesma execução, na qual o agent precisa satisfazer todos eles, é uma parte central disso. A outra metade

42:25 é a parte orientada a eventos, que talvez pareça um pouco com herança. Eu penso nisso mais como, não sei se você conhece a memoização no estilo React, em que há determinados componentes. Ainda é composição. Há componentes com dependências anteriores e, quando os dados de um deles mudam, é claro que essa mudança vai se propagar a tudo que está abaixo dele. Esse é outro aspecto em que o Jev é muito empolgante, assim como o decision model, porque tínhamos criado esse

42:56 sistema e tínhamos agents tentando determinar se o estado havia mudado e, se o estado de uma dependência anterior mudasse, se deveríamos iniciar a dependência seguinte. Mas isso é muito caro de executar, e o Jev passa a ser, de repente, um classificador semântico ou memoizador semântico muito barato. Você pode pensar nele como um cache, e o Jev decide quando algo está desatualizado; então, ele inicia tudo que vem depois. Essa é outra espécie de componente central do framework.

43:27 Tirando a parte do Jev, ainda estamos trabalhando nela, ainda estamos desenvolvendo essa parte. Sim, e não há mágica aqui. É tudo em inglês, é tudo linguagem. Sim, mas é aí que entra a composição, a capacidade de compor. >> Outro ponto, para complementar o que você disse: não se trata apenas de um template. Mesmo antes dos LLMs, ou nos primeiros LLMs, ou até com encoders, você poderia preencher um template. Você coloca um prefixo no template e preenche o conteúdo. Mas aqui a questão é: “O que você pode colocar num template?” E, assim, você pode colocar num template

44:01 o workflow multiagente inteiro. Um exemplo simples que eu dou é: você pode dizer que a saída de que preciso é um artigo. Talvez tenha que ser este tipo de artigo, ter esta extensão, e assim por diante, certo? Algumas restrições desse tipo. E a entrada é o tema. “Continue até ter um bom artigo para mim.” O agent principal decide o que é bom e quando encerrar. Por isso, você vai obter um resultado melhor com um modelo mais forte do que com um mais fraco. Tenho um subagent pesquisador. Esse agent tem meu acesso ao CLI

44:36 e minha skill de como usar um CLI, porque não quero que ele use qualquer pesquisa na web aleatória. Tenho um subagent redator que recebe algo especial meu, como: “Aqui estão os últimos 10 artigos que escrevi e que ficaram muito bons; quero que você escreva desse jeito.” Tenho um subagent revisor, e tudo isso talvez seja só… >> Mas as 100 linhas realmente importantes de Markdown podem levar 10 horas para serem feitas. >> Os pontos importantes a enfatizar são a composição de contratos. Então, você vai para, quer dizer, essas coisas existem há muito tempo. Qualquer…

45:09 Qualquer construtor de workflow, qualquer construtor de workflow de arrastar e soltar. Essa é uma maneira diferente de pensar nisso, porque, quando você pensa nisso como um DAG — grafo acíclico direcionado — de contratos, pode ter etapas intermediárias que você pensa quase como pontos de verificação: essa etapa intermediária atende ao contrato, o processo continua, chega a esse contrato e o satisfaz, e então isso faz com que a próxima etapa continue até que aquele contrato seja satisfeito. Então, de certa forma, você ainda pode declarar como chegar lá

45:42 simplesmente compondo esses contratos intermediários ao longo do caminho e ainda deixando os agents um pouco flexíveis quanto a como realizar essa etapa intermediária. >> Sim, e quanto à estrutura disso. Um exemplo: quando o Claude lançou os dynamic workflows, publicou um post no blog com os seis tipos, certo? Um deles é fan out, fan in, e um map reduce com subagents. Outro é uma revisão adversarial; outro é um loop até que uma condição X seja atendida, certo? E você pode expressar tudo isso num programa em prosa e executá-lo em qualquer agent. Então, pode colocar num template a estrutura do workflow multiagente, sem código. E, de novo, isso só é possível porque os agents são bons em se gerenciar e porque a maioria dos harnesses tem subagents. Então, se você está usando o Pi puro, que não tem subagents, pelo menos da última vez que conferi, vai precisar de subagents para fazer esse tipo de workflow mais complexo. Mas…

46:14 o programa em Prose e depois executá-los em qualquer agent. Então, você pode criar um modelo da estrutura do workflow multi-agent sem código. E, de novo, tudo isso só é possível porque os agents são bons em gerenciar a si mesmos e porque a maioria dos harnesses tem subagents. Então, se você estiver usando o Pie puro e simples, que não tem subagents, pelo menos da última vez que verifiquei, vai querer subagents para executar esse tipo de workflow mais complexo. Mas, tipo

46:46 essencialmente qualquer harness que tenha um dos requisitos, >> Subagents. >> subagents é praticamente o único para a maioria dos >> contextos. >> Sim, tipo, o bash e os subagents são, na verdade, você nem precisa do bash. Também podemos executá-los em ambientes isolados de VM no modo de código. Então, >> Mais alguma pergunta? Podemos devolver 10 minutos a todos. Uh, isso se baseia nos meus muitos anos de experiência em engenharia e em lidar com pessoas que às vezes não são muito boas em expressar requisitos e com outras pessoas que são

47:16 muito boas em expressar requisitos. E também, quer dizer, fazemos benchmark disso internamente e executamos contra… Temos uma espécie de algoritmo evolutivo em que podemos reduzir o kernel verificando se eles conseguem se adequar a ele. Então, isso se baseia na prática e em resultados empíricos. Uh >> Sim, você pode simplesmente usar isso como uma especificação e pode ter, digamos, a especificação do Matt Pocock; sabe, você gosta do Matt… Criei uma engraçada só para provocá-lo, que se chamava Auto Pocock, e basicamente

47:49 era minha maneira de provar que meu jeito de conectar skills funciona. Então, basicamente, você só… Ele tem um workflow chamado “me interrogue”, sabe, e aí você faz todas essas perguntas, depois vem TDD e todas as outras coisas, e você pode colocar tudo isso em um único programa OpenProse e simplesmente dizer: “Siga o workflow do Matt Pocock”; e cada subagent tem que carregar, em cada etapa do programa, a próxima skill da sequência. Um, então, sim, você definitivamente pode… >> As pessoas fazem isso? Eu… Eu não chamava isso de desenvolvimento orientado por espectro, mas, pela própria natureza, é quase desenvolvimento orientado por espectro

48:22 por espectro. Adoraria que você experimentasse. Teste ou venha falar comigo depois e, seja qual for a especificação de desenvolvimento orientado por espectro que você tiver, podemos combiná-la com a execução da prosa do kernel de inicialização e ver como ela se sai. Acho que, na verdade, ela se sairia muito bem. É uma boa inspiração. Ainda não experimentei com os contratos de desenvolvimento orientado por espectro. Adoraria sentar e experimentar para ver se ela prevalece ou se começa a entrar em conflito. >> Seria interessante, tipo… >> Aqui, aqui vai uma coisa

48:52 >> Ver quanto as diferentes skills atrapalham. >> Uma coisa que temos é que engenheiros de software usam OpenProse para desenvolver software. Uh, mais dos nossos usuários usam OpenProse para fazer operações, gerenciamento de produto e documentação de modelos quant, e outras coisas que não são, não sei, engenharia de software. Acho que é justamente a combinação com a documentação em Markdown que acaba sendo mais interessante para quem não é engenheiro. Sim. Mais alguma pergunta?

49:25 Obrigado a todos. Agradeço pelo tempo de vocês. >> [aplausos]

Transcrição original

[00:01] [music] >> My name is Dan. I am the creator of Open Pros. This year is Raymond I’m joined by Raymond and Jose two fabulous teammates, co-workers, just phenomenal creators and engineers all around. I’ll introduce them a little bit in a bit. Uh just a little bit of background about what we’re what we’re about to show you here.

[00:33] Uh 5 years ago in April of 2021, I was named the best prompter in the Eleuther AI back rooms Discord, which was a skill at the time that I thought would be tremendously valuable for many years afterward and actually it lasted I think around like two or three years maybe was the lifetime of of that skill. And I say that because a lot obviously, as you all know, has changed in the last 5 years. But one thing has not changed and

[01:06] I’ve been to a lot of workshops today. We’ve got a lot of amazing talks coming up. But the one thing that seems to be ever present in in all of the work that we do and and that actually doesn’t change with the latest harness or the latest model is we all still need to communicate our intent to the thing and no matter how smart the thing gets, there is still this challenge of how do I get out of my brain the thing that I want and and get it into the super intelligence that is just going to carry

[01:40] it away and and do everything for me. Uh Open Pros is is a is a language, it’s a framework, it’s a started as a project based on my own love of language and my own strong belief that language is this really powerful force of creation and I mean that like I know that’s a little bit cliche, but that’s like in the very literal sense now with with the capabilities that we have. You can write a sentence and the things just make that sentence true. And so the question then becomes like what

[02:14] is the sentence that you write now that you have this tremendously powerful machine to make it true. And the skill of prompting from 5 years ago looks very different from the skill of what we like to think of as contract creation or contract composition today. And when you were dealing with a model that was just completing the the next token, there was there was good patterns and bad patterns for for prompting. A few years later, you were filling out context by hand and you were taking rag results and and tool calls and stuff and

[02:48] search results and stuffing them into into the context window and you call that context engineering. And then the harness started doing that for you and you were building a harness and and and you were you were you thought of the harness as this this machine that was stuffing context for you. And and in the last 8 10 months, we’ve seen a number of papers come out that is just pushing everything up another layer of abstraction and and the harnesses themselves are are changing out from under you. We saw a great presentation by Anthropic

[03:18] this morning on on flows and that’s this idea of this like self-modifying harness topology that is managing sub agents in a way that just was not thinkable even just a year ago. So, if if is solved and the context is now solved and now the harnesses are now solved, like what’s kind of the next step here? And that’s what we’d like to talk a little bit about today and show you some of the stuff we’ve been we’ve been building in in support of that. I like to think of it as as once you can name the thing that you want,

[03:49] any harness can self-shape, can fan out, do any sort of loop to get you there. And the question is what are the good best practices for naming the thing that you want. And and we think of that as as declarative. We’re we’re going to borrow concepts from classical software engineering. I’m a software engineer of 12 years. Jose and Raymond have been around the block with this as well. Jose was early Google Cloud and he’s informed a number of the ways we think about this. Raymond is just a phenomenal uh uh He told me to He told me to introduce

[04:20] himself as a as a vibe code extraordinaire, but that’s way underselling his his talents. He’s a PhD and two-time founder and has been doing harness engineering for basically as long as anybody I know. Um and and so so it’s this idea of borrowing old engineering patterns and applying them into this new world. We want to write our prompts compositionally. We want to compose composition over inheritance. We want to write our prompts declaratively rather than procedurally or imperatively. We want to tell it what what to do, not how to do it because the

[04:55] harness in its infinite wisdom and its infinite intelligence is going to figure that out. And if we tell it how to do the thing, now we’re actually leaving cost and and intelligence on the table because we could run it for a cheaper model. A more intelligent model can figure out how to do the thing. So it’s this idea of write what you want, declare what you want, the outcome, the goal, the end state. We think of that as a contract. And and write it in a way such that you can compose these because when you build a system, when when you build an open framework like this, when you build a system that has many parts, maybe across

[05:29] your company or across your team, you want to do things in a way that allows things to elegantly compose and that lets you manage complexity in in a in a more local way. Um with that, I’m going to hand it over to Raymond who’s going to tell you a little bit about how it works and then we’re going to show you some some demos after that. We’ll we’ll we’ll open it up to questions throughout. So, and please do raise uh your hand if you have questions, interject, please. >> Awesome. Thank you, Dan. Okay, so there um

[06:00] I wanted to just help you understand Open Pros and put it in a quadrant. Um so, if there’s only two things that you remember, the two things that I want you to remember are it’s just markdown. So, we like to sometimes call it it’s a programming language for agents. We sometimes call it a framework, but all of it is just text. It’s just one giant prompt. Um and then the second thing to just help you figure out in your mental bucket where this fits is it’s event driven. It’s not chat. We’re not chatting with these things. Um I’ll chat with an agent that will make

[06:33] Open Pros programs later, but if you only remember two things about us, that’s it. It’s it’s all text and we’re doing these event-driven multi-agent workflows, not chatting. Um you can it’s open source, you can run it locally with NPX skills. Uh I’ll walk through the hosted version that I’ve built uh run.pros.md, and uh we also will do it for you. If you want to reach out, uh we’ll help you out. So, uh I guess quick question, like how many people in here are from the the finance side of things?

[07:03] Okay, that’s good. How many are like AI engineers or developers? Okay. Then how many people um are maybe more like PMs or like professionals but and you’re using AI but you don’t know how to code? Okay, fewer but Okay, good. So, I’ve got why should I care for those three audiences? So, for the small regulated industries, one of the things that we’ve seen um some banks and uh other financial services companies be excited about is like what I said before, it’s all text. So, we

[07:34] don’t need the procurement department, we don’t need the IT department. You can use whatever coding agent you want, whatever inference you want, whatever guardrails you already have, whatever stack you have, we can actually like help you um you know, create these multi-agent workflows without deploying anything to you other than some markdown files. Um so, that’s one of the the angles or or benefits of it being all text. Um for the folks that are uh not writing code themselves, uh basically, if you can read logical English, you can read Open Prose. So, we’re going to very

[08:05] specifically not get into the syntax of the language. Technically, it is a programming language and it has a syntax, um but it’s really meant to be more um read by people and edited by people rather than like handwritten from scratch by people. Like you we don’t want users concerned with like learning the schema. And so, you can kind of describe the work, have your agent write the Prose program, you know, that might give you some more ideas for how you might want to edit it, or you might see something you want to change,

[08:35] uh and then that Prose program becomes the reusable workflow. Um and then for the AI engineers and the developers, uh I think the angle where you might want to use this is it’s you know, it’s not it’s a framework that’s not a framework, and we’ll talk a little bit about that in a second, but even the compiler for the framework, even the virtual machine for the framework, is itself just a giant prompt, and you’re literally like incepting cod code into compiling the program for you, incepting

[09:06] Codex into doing that. Uh so, there’s uh you can express very, very complex multi-agent workflows that uh things like the Anthropic um uh dynamic What do they call them? Dynamic agent workflows um would probably be like an analogy. You can do that in any coding agent in just our markdown contract. Uh okay. So, first on this idea that it’s just markdown, um this can be a complete program, just as an example. And again, I don’t want to get uh

[09:36] so hung up in the syntax, um but you can basically say, “Hey, here’s the goal and like here is the the contract that that the that this maintains. Like here’s the definition of what this contract maintains.” Um and again, that’s just like a very silly simple one. Um the uh this idea here of like, well, what is it that you can declare? So, again, I don’t want to get into the schema and the types and the syntax, but what you or

[10:06] your agent can declare on behalf of you with uh in the CLI is called the pros write function. In our app, it’s basically just the agent that drives the whole app for you. You can make sub agents. Uh you can assign specific skills uh to those specific sub agents. You can have specific tools that are available. So, for example, for search, I love Exa. I think they’re amazing and I don’t want it doing regular web search. I always want it using Exa cuz it’s faster and cheaper for me. You can say, “Here’s the skill for that. Here’s the CLI for that.” If you can’t find those things,

[10:37] just don’t run the program. Like we’re not doing it the other way. So, you might have skills that are specific to your company or to your org. And then essentially, you can think of it as like wiring that program together and like if it doesn’t have all the dependencies, like do not compile, right? Um and then obviously that what are the inputs of this program, what are the outputs that this uh program has to deliver, this contract has to deliver. Um and again, like again, this could be something if people want to nerd out and ask Dan about how he built it. Like the runtime itself is just a giant prompt,

[11:10] too. So, um you know, some of my favorite sentences in the uh in the skill or the prompt is like “You are the compiler.” This is not an analogy. You are the compiler. And uh it seems to work. Um So, uh yeah, and then this idea of a event-driven. So, we want to get out of this idea that everything is a conversation, that everything is a chat, um and build event-driven systems. So, um

[11:40] again, like uh just to compare these different workflow trees, it’s like something something happens that might be just like a cron job on a schedule, that might be a new issue is opened in GitHub, or a new PR uh is filed, or you have some webhook system, right? Um that you’re I don’t know, Stripe isn’t working, whatever, then you can now um you know, trigger that workflow that you’ve expressed uh to go handle that entire thing end to end and deliver on the contract. Um and so, this idea of like starting to

[12:14] build towards jobs, so you can set this up yourself with your own agents in your own system, and what I built um in run.prose.md is um this idea of like a job is a contract plus a trigger. So, again, the the trigger can be something super trivial like a schedule, and so here I’m basically saying like, “Okay, every day uh run this.” Um but uh right now, the two the two main triggers that we have implemented in the app as is are um our webhooks, which really

[12:45] uh inevitably cover a lot of different things, like a whole Slack app is just webhooks, GitHub just webhooks. Um and cron jobs. We’re happy to add more if you want to give us feedback on ones that we can make easier for you. Um and again, from from that trigger, then you triage uh these workflows. So, uh you can start to build out these, you know, code factories from um creating these standing jobs um of the Prose programs. Uh what I want to show and I’ll get

[13:15] towards in a second is um one of the things that I’ve been building to make sure that’s ready in time for this event is um is webhooks and using uh GitHub uh events specifically, and I’ve been forcing myself to use the program to develop the program. And so, one of the examples that we now have in the issue in the system is, well, there’s two different main ones. One is like any GitHub issue that comes in, you write a prose program for how it’s going to try to address the issue. So, you can make that as complex or as

[13:49] simple as you want. You can run it could be a multi-agent workflow. It could have specific, um, skills that it has to follow or use models. Um, and so, basically the input is whatever that issue was, the output is a commit. And it has to go all the way to getting that thing done for you. Uh, and then similarly, uh, and I’ll show this one more specifically is like doing it with, uh, PR reviews. So, you can do this event-driven kind of adversarial review. And I don’t know if you guys heard, um, in one of the things I thought was interesting this morning in the Anthropic workshop where they’re

[14:20] talking about um, the challenges with self-review. So, like, you’re you’re in Claude Code and you’re like, “All right. Here, I’m going to let you push to production, but just could you just check like one more time for me?” And like, it’s it’s biased to, you know, think that it did a good job. And so, so are humans, right? And so, um, I’ll show a workflow where essentially the agents that are building this get this backpressure from the app itself um, through through pull requests.

[14:51] Um, okay. So, while we transition to this, are there any questions now while we switch over to the to the web app? >> Please, no question is too silly. Is that a hand or a phone? I can’t see the lights here. >> Maybe none. >> Yeah, go ahead. >> One over there. >> [clears throat] >> It’s a great question. Uh, I’ll field this. >> Yeah, you should take that. >> Yeah. Uh, so, we actually have this idea of earlier I alluded to the what and the how being two two different two

[15:23] different ideas. Declare the outcome and then the how is a little bit you you leave it open, let the agent figure it out. On that spectrum, you actually do, to your point, at at certain places want to weigh in on the how. And in fact, we have a a feature a syntax that lets you pin the how. And so you can initially declare it very loose. You can let a very intelligent agent run and figure out how to get to the thing that you’ve declared. And then once it

[15:55] does that, you can say here’s the agent trace. Let’s take this trace and we will sort of codify it or or I don’t know, shrink wrap it into a how. And what that allows us to do is actually drive down the the the cost of completing the workflow. So you you start with a very expensive model, figures it out, and then you sort of, as you say, make it more specific, more deterministic. So you’re kind of like shifting the the the the the spectrum from totally at just a what to to how how to do it. And and the cost comes down as

[16:28] you do that. So when we say it’s all markdown, that’s where you can start it, but then you can move your way to to uh more specific procedural imperative style instructions as well. >> Yeah, I guess a couple comments on that. So one, we do have a system where you can take like a golden session and like the like say make this into a reusable workflow. Like that was the best cloud code session I’ve ever had. Like I wanted to do cuz that’s this is we get this all the time, right? And I think

[17:00] there’s there’s a part of it where like these things are non-deterministic. I think a lot of the quote-unquote pinned and stable endpoints people have shown actually are changing as all these companies are compute constrained, but I also just think there’s this like changing expectations thing, right? Which is like the first time you tried like whatever it was, like Fable or whatever, like blew your blew your mind and you’re like, I want whatever. This workflow is so amazing. I want this every time. And then you kind of like boil the frog and like have just different expectations

[17:31] and all of a sudden doesn’t happen again and like some of that is just reliability. And so so one thing you can do is like take a really good session and like codify it. But then the other thing, just to give Dan a little bit more credit of like building the framework is like it’s not just literally like the markdowns you see are like the tip of the iceberg of what it’s seeing. So like the last time I checked the full like system prompt or skill or however you there’s I mean it is a skill it is a system prompt is like close to 70,000 tokens, 80,000 tokens of like

[18:05] >> longer. We’re trying to clean it up. We’re trying to >> Yeah, well now that the agents are smarter we can make it a little bit shorter. But we basically have this full type system that’s like we’re overriding markdown with a very very clear type system and a very specific prompt for how the agent is going to deliver this incredibly complex multi-agent um product on the out um but maybe to be explicit about where we don’t mess with it is like um So like Claude code when it runs it it has its own system for sub-agents. We don’t want to mess with that. We don’t want where we don’t want our prompt to

[18:38] be um in any way like specific to Claude code cuz Codex has a totally different like set of sub-agents. So the the we’re like I don’t know, a meta harness, like >> [laughter] >> whatever. We’re one layer we want you to bring your own harness. We don’t want to be the harness. We want to be this uh thing that is compiled by the harness. So I guess that’s a couple pieces of >> Does that answer your question? >> um All right. So if you want to try it, it’s um it’s here the QR code run.prose.md uh the QR code goes to that. If you want to start playing around with it. Um what I want to do

[19:11] in um showcasing this is to uh show off a couple of things. So, the um the first thing is that um the So, this is the This is a Prose program in the edit mode, right? It is technically Markdown and Dan’s overridden like the H3 headers with all the types of this thing. But, getting someone to like learn that

[19:42] syntax and write it from scratch, it’s kind of a not really the point. Um and so, what we um what we want to do is So, even though everything that executes this program is here, and in fact, I’ve for the real nerds in the audience, you can see that I’ve over I’ve taken the front matter of the Markdown file, and that is actually all of the stuff that’s happening in the cloud. So, I could take this program and export it as a pure Markdown file

[20:15] and go send it to my friend, and they’ll it’ll upload in their cloud this the exact same way um to keep it like composable and keep it true to that idea of that we’re pure Markdown. Um anyways, the whole idea is like even though that is the thing and we’d want you to be reading this thing, it’s not like the entry point. So, what I’ve built instead is um an agent which hopefully will talk to me here. >> Hi, it’s Prose. What are you hoping to get done today? >> Okay, so uh every time I have a new pull request, I want you to um write me a

[20:53] Prose program in my run-prose repo that will review it as if you are a a grumpy senior developer who doesn’t like AI-generated code. >> Sure, I can do that. Hang on. >> Okay. So, I’m going to mute myself. So, it’s it’s talking. It’s going to try to figure this out. And the the whole idea is like anything

[21:24] So, anything that can charge money or spend money, you have to confirm. I think that’s like a best practice. Um Oh, yeah. Great. So, I had to confirm cuz that that action costs money for it to So, that’s the pros rate function. So, it basically takes my query and is going to generate a new program um from that including all the wiring. This step is going to take a little bit longer. So, while that’s running, I’ll show like the manual way of doing that. Which is in the jobs tab. I don’t know why this is

[21:56] cutting out. Um in the jobs tab, we can go here, make a new job. The the uh on a schedule is just a cron job. We have a a web hook that’s open-ended. So, like you can have yourself or your agent um either use our specific web hook or like wire our thing to listen to your web hook. But for Git GitHub, um so, I’ll do the same one. So, for GitHub pull requests, we make that easy. Um we’re going to do it in the run.pros. We’re going to uh I’ve just pre-wired this contract. It’s like, “Okay, you’re going to review

[22:29] my thing.” And then I can pick, you know, what uh model that they have. We’ll we’ll add more uh later. Right now, we have the the like top three from uh OpenAI. Uh and then I would just uh create that and deploy that. So, then the other thing while this um this one’s working that I want to show is how I’ve actually been using that as back pressure. So, the main thing Don’t get too hung up on the um whatever, the content up here. But the

[22:59] thing that I want to show you here is like the the the volume. So, like in whatever that is, like this entire thing is goes back to 3 days ago, but then if I go here, like these are all still from 3 days ago or 4 days ago. Or so, like in the span of a few days, this is doing like dozens and dozens and dozens of PRs, and every time I’m asking for a new feature about this GitHub was webhooks feature that I wanted to have ready for this event, uh every single one of those is firing off like a series

[23:33] of review agents where it’s like so some of them are simple like okay, this one clearly seems to have worked right away. So, there’s only one round. Uh some of these had, you know, 14 rounds of review before uh it felt like the reviewer agents were like aligned and it let this thing pass. Um and even just today, like I noticed something that I didn’t love about um how it was doing it, and I was able to um you know, basically say okay, um on our staging server, you know,

[24:06] don’t mess with production. I’m about to give a talk. On the staging server, I want you to like change the things the exact ways in which this will get triggered, but you have to use the system yourself. So, um like both our dev version of this and our prod version of this are giving different reviews. Um and now the agent that’s running uh here, uh which we can see all the different jobs in the the runs tab here, essentially like cannot consider its job to be complete until it’s like um

[24:38] a a like um like my developer agents have like have to take that feedback into account. >> And just to emphasize like what’s different about something like this from any other chat-based or or agent-based flow that you’ve seen is all of these are getting compared against a contract. So, you could think of it as a fresh session every time is getting benchmarked against this contract that you’ve written declaratively, which as as Raymond alluded to earlier, gets the models out of this like self-confidence loop where you don’t want the same model checking the thing that was done. So,

[25:09] you’re spawning new sessions and and bouncing them off of a contract, which is I just a better uh pattern for for how to do it. Yeah, go ahead. >> Yeah. >> But, doesn’t [clears throat] it seem like a great opportunity for one-shot classifiers like Jeff? >> Yeah. So, they um >> We have a lot of good stuff in the pipe. So, so the idea of checking against a contract and and verifying it. Sorry, Raymond. >> Yeah. >> Uh it it is super exciting on these decision models where uh you you have a contract, which is some ideal state, and then you have your messy real-world

[25:41] state, and you can apply a general class decision model like like Jeff to say, is this is this passing or not? >> So, I think >> in this, but it’s coming. >> Yeah, and I think I think without um like Dan, again, we’re going a lot off script, but it’s a great question, and uh the great Jeff-ification is upon us. So, we need to speak to this. Um is uh I think Dan and I both been thinking about this a lot and realized that like um OpenPros itself, the language that’s all

[26:14] markdown, I think does not have any place in the Jeff land because they’re not generative. Like, so the whole idea of the lang- like it generating a language and understanding a language, like it uh it’s not that. But, I think the the two places where we think it would fit really well, and in particular with the hosted run.pros, is one on the back end. So, the the downside or the weakness of OpenPros is it is you are letting the agent say, “I have met the contract. Here it is.” Right? And so, I’ll often

[26:48] say to people uh like the intent behind OpenPros is similar to something like DSPy where you want to have like this abstraction layer over which you can express very complex workflows. The implementation is the exact opposite of DSPy. DSPy is like every LLM call is a black box and you you isolate the crap out of that thing. It’s all deterministic code. It’s all typed interfaces to like only let the black box do that thing. Dan’s approach with open prose is the exact opposite

[27:18] which is like AI is getting smart enough to be the compiler. Like let everything be in fuzzy land. So the the the weakness of it though is like if you run it on Haku or you run it on Fable you’re going to get a very different result and and you’re also letting it say I’m done. So I think a very natural place for like uh Jev or these new like decision models or whatever we want to call them system one models is like you were saying like as a verifier on the end of the job like very very fast and cheap. Um and then the other thing that I want to build that’s relevant to this this is like a router.

[27:52] So like why would I have to go click the button that like oh issues go to the issue job but PRs go to the PR review job. Why don’t I just say like okay all the GitHub events that come in like you know solve the issues review the PRs right? Another question. >> Don’t give them any more ideas about the game. >> Okay. >> I know I was going to say I was going to >> [laughter] >> Thank you. It’s just topical on the Twitter sphere at the exact moment that like why wouldn’t you just RL this? Like if I got all these beautiful runs here against the contract why am I not just RLing this?

[28:22] >> So So one of the ideas back to the language question is one of the ideas of like why why are we doing this at all in language? Like the original human side of this is like you can commit it to get and you can version control it or you can you know use it in notion or or Jira and and have anybody on your team using it. But from from a engineering side it’s the fact that it’s all text is like perfect and beautiful for for RL. So, we’re not doing that right now, but like that’s absolutely something we’re talking with various prospects about is

[28:56] like once you have all of your stuff written as text, this is like >> Yeah. >> a whole lot better for for RL. >> Yeah, we haven’t hit volumes where this is important, but like if you are hosting the model and you have this 100,000-ish token prefix, then you can like just it or you like, you know, build these um more token efficient representations. So, um Yeah, if someone wants to do a trillion tokens in Open Pros, we’ll happily just it for you. Um So, anyways, to go back,

[29:26] thank you. Those are Those are really good ones. We now have our grumpy senior pull request review. Um and again, like the key idea is so the agent did all that for us. The key idea here is um uh like the by deploying this job, like this will now start spending money when whenever we get a new PR, so I have to click that. So, then I’m going to confirm that. And then once this is deployed, it’ll go when I go back over to my jobs, it will um it will look exactly like uh let’s see.

[29:57] So, if we just Oops, I did switch that. Once this loads, we should see and the grumpy one is at the top or the bottom. Yeah, here we go. Grumpy AI skeptic PR review. So, um you can see I was practicing earlier. Um Okay. So, let’s see what in terms of this. I think those are the main things. Um Yeah, I’m in charge of run.pros.md, so if you run into any issues, don’t tell

[30:28] my boss, you just send it straight to me. Uh and my agents will uh take care of it for you. Um but yeah, I’m really excited about this as just like a a simple, easy-to-use um um way for having these like event-based systems. If you want to see other triggers or other features then that’s really fun for me. But again, you don’t need to use the hosted thing at all and like you can uh you can use the um the skill instead NPX skills add open prose prose. Um but now uh with that Dan is going to um

[31:01] go through a specific example that is for [clears throat] our finance friends um and we’re going to show that one uh in Codex and then he’ll use that as an opportunity to talk a little bit more about how all this works under the hood. >> Yep. Thank you. >> Sure. >> Um so getting that working in the cloud is is interesting. One of the more interesting use cases that we’ve been talking about with various customers and prospects is

[31:34] um you can this is this is a framework or a language or pattern that you can build in house and you can use you can run it on prem. The whole idea here is that you can run it on prem. You don’t need to use our cloud version of it. We’d love you to try it out in the cloud and and and and play with it get a get a feel for that. Um but if this is something that you want to implement uh inside your organization the most interesting use case that we’re seeing is on top of open models on top of your own harness bring your own harness and then use this as kind of the

[32:06] application layer on on top of that and that lets you build this full stack in house. You don’t have to ship any of your data out to the labs. More important than your data, you don’t have to ship out your institutional We like to think of open prose actually as like institutional operational knowledge as documentation, right? Think of it as like standard operating procedures. So even more important than your data is you don’t want to be shipping your standard operating procedure out to the big labs. Um and so so this fits really nicely in this stack of of open open source

[32:37] application layer sits on top. We we publish this open open core. Uh it has a permissive license. You can bring it in house and and use it. We have a number of big companies who are are already doing that. Um and and you can bring your own harness. You can use it with the approved models that your company already has. Uh so you don’t have to feel like you’re throwing data or your organization’s knowledge over the wall. Um this is just I mean a a we can get into this a little bit and I want to field more questions. Um this is a a workflow that we’re building out for

[33:09] a customer um that is interested in using OpenProse to document their quant models. So uh for those of you who are familiar, um quant models have all sorts of regulatory um um commitments whereby every every 3 years or every 1 year or on certain event changes, you need to update the the model documentation for these quant models. So this is normally a process that we found in our experience that is uh human white collar, very smart person intensive, right? These people uh maybe

[33:43] some of you probably spend a a share of your your year going through and and writing documentation. That documents what your model’s being used for, under what conditions was it tested, under um uh who who what other models reference it upstream, and a whole slew of other required These are obviously required by the regulators and your internal auditors and your internal compliance. Um so this is this is a a flow that that we’ve found success running. Uh it’s it’s perfect because in some ways the regulatory docs are like an

[34:17] OpenProse program, right? And so this these are requirements written as prose. Um and and so I’m going to kick off You can see here uh we’re in Codex. You You run this in Cloud Code. You could run this on your own harness. The whole point is that this is harness agnostic. Uh so we we just say boot the kernel. Uh and then pros run and then a specific program. And so I’m going to kick this off and while it runs I can show you like what the kernel looks like uh and then what the program itself

[34:49] looks like. Um just go back to Chrome. And then >> Right there. >> It’s uh that one. So this is the kernel. Um it’s markdown. It’s not intended to be read by you which is why it’s formatted like this. We originally had it in a nice looking format and people complained. They’re like, “What is this?” Uh it’s meant to be read by the agents. Uh and it’s just markdown. It’s operating instructions for what to expect. You could think of it a lot like a a bootloader or a resolution path, a

[35:20] an index uh system, a way of finding other documents that you that that the that the agent needs. Um and then the program itself looks and again this is what I referenced in Codex looks very similar. So this is again markdown. It contains a whole slew of the requirements that the regulators and the compliance and the auditors are looking for. Uh and this specifies, you know, uh the ideal state of of the end result is going to comply with this contract.

[35:54] Uh and so those are the only two things you pass in. You just pass in the kernel which is published publicly. You can all download that right now uh and and and try it out and then write any program that you want, any contract that requires some complex um set of conditions to satisfy and then the agents are just going to chug and and the you know, the better the harness, the better the model, the the faster and the cheaper that they will produce the output. Uh but the idea is that that you’re you’re declaring the the result rather than declaring how to how to go about about doing it.

[36:26] Um Let’s see we can poke back and see. We ran this with a a relatively cheap model here so that it would run faster. Uh but it’s still working. Um Oh, it looks like it’s finishing up. So, this is I mean this is the document that it produced. So, in this case we’re we’re we’re um creating documentation for the sofa curve. It’s a public uh model. So, we’re not showing any any uh internal uh bank data here. Um and this I don’t know. Raise a hand. Anybody Are

[36:59] there any like quants in the room? To review it? How does this How does this look? Yeah, [laughter] all right. Well, we’ll come we’ll come we’ll come find you afterwards. Um but but so that you know this is this is this is documentation that has to be produced um regularly for every model. A big bank has 4,000 or so models. They have to be re re re-documented yearly and uh this is a this is a a a problem that is worth anywhere between 10 to 50 million dollars a year uh for some of these bigger banks and and we’re having great

[37:32] success in in um in doing it for them for for much cheaper. Uh granted there are some some um Getting this through compliance and the auditors and the regulators is is another part of the battle obviously as I’m sure you’re all familiar with but um we we can benchmark this against historical results. We can benchmark this against how long it takes the teams to do it uh and we have quant you know quants who are on the floor who are able to to rate these and and give us a sense of how how well the models are doing on

[38:05] this and we’re finding that it’s I mean quite shocking shockingly good. Um for for much cheaper than than traditional uh manual way of doing this. Any questions? Any like >> the quants do the stuff that the quants are good at. >> Making the models. >> Not the regulatory paperwork which probably isn’t very fun. I’m not a quant, but >> [snorts] >> Any questions? Great question. Uh yes. And so, actually, um Raymond showing off the chat agent a little bit as part of the kernel, as

[38:37] buried in the markdown at a at a path, we have uh best practices. The These are the types of things you want to be doing when you’re declaring out out outcomes. Uh these are um and anti-patterns, things that you shouldn’t be doing. And so, yes, there is there is a a world in which you’re not typing the whole contract itself, but you’re iterating, and and that’s what Raymond was showing uh with another agent following our best practice guide on how to on on how to create the contract. But, yeah, I mean,

[39:09] getting getting intent out of people’s heads is like the hard part, and and I think this is a piece of it. It’s certainly not like the whole >> Yeah. I have a slightly like longer uh I don’t want to make this too long. We only have 5 minutes. But, like, a slightly longer rant on this, which is that I do think that this is a big part of why chat like blew up so fast is like you do not need to know anything about what you’re looking for, just start engaging with ChatGPT, and just like the magic of generative AI and like having it like come back to you, right? And so, like, if that’s

[39:43] I don’t I don’t know that OpenProse is the best place if you’re at that stage of something where you re you really don’t even know the shape of what you’re talking about, or you’re not even sure like what it is that you’re looking for. Um and like this go I’m like a very old-school DSPy user, and like my my joke about DSPy was like, “Oh, no, I have to know what I want now, right?” Because like the whole idea of DSPy is like you have to you create the signature of the thing that you want. And if you and you you you like see

[40:14] something like that, you’re like, “This is so awesome.” And then you sit down, and you’re like, oh I I actually don’t know what I want to do I, right? So, I think I think with the you know, Open Prose is a lot less strict than something like DS fire where you like you literally really needed to say the signature of the return object or nothing happens. Um but yeah, I would say like the built-in agent hopefully can like help with some of like you can just turn on the voice and be like, what can you do? Like and it can do almost anything you can do in the app like we

[40:45] you know, we have those hard-coded like confirm things for um for like anything that would cost money. Obviously, we want people like click a button for that. Um but yeah, I think I think it’s um I don’t know, I think it’s also related to like the great jobification is like there are like chat isn’t a great um interface and agents that are like RLF to be convincing chat partners are not necessarily like the best type of AI for

[41:17] workflows that don’t have human conversation as part of them at all. Um >> And let me let me interject, which is just use cases like we tell people you don’t want to use this if if you’re doing a one-off, if you are like chat is perfect for that. You’re if you’re in exploratory mode. What this is good for is something you need to do a lot. It it needs to be reliable, it has to be repeatable, it needs to be auditable. Those types of workflows are what what we’re what Open Prose is built for and meant for and so there is an implicit

[41:51] like you do know what you need in in here. >> Oh, we got a question from a real quant. >> And earlier I alluded to and I I wouldn’t just call it inheritance, I would call it composition. So, we we in fact a core feature of of the framework and and the the pattern itself is it’s built to be composed and so yes, injecting multiple contracts into the same uh run in in which the agent now has to satisfy many of them is is is a a core piece here. The other half

[42:25] the event-driven half uh which maybe looks a little bit you might call it inheritance. I I think of it more like um uh I don’t know if you’re familiar with like React React-style memoization where you have certain components. It’s still composition. You have certain components that have upstream dependencies and when the data on on one of them changes, it’s of course going to trickle down to everything below it. Um that is another place where Jev is super exciting and and the decision model super exciting because we had built that

[42:56] system and we had agents trying to determine has the state changed and if the state on upstream dependency changes, do we kick off downstream dependency? Uh but that’s very expensive to run and Jev becomes suddenly this very cheap like semantic classifier or semantic memoizer, which you could think of it as like a cache and Jev is deciding when something is out of date and now it kicks off everything downstream from that. So, that’s another kind of core component of of the framework.

[43:27] Minus the Jev part, we’re still working we’re still building that part in. Yes, and there is no magic here. It’s all just English. It’s all just language. Uh yeah, it’s but yes, and that’s where the composition composability comes in. >> The other piece to your point is like it’s not just a template. So, like you could obviously even pre-LLMs, you could have um or very let’s say not very early LLMs or even like encoders could like fill a template for you. Like you like prefix the template and like fill the thing. But here it’s like, “Well, what can you template?” And so, you could template

[44:01] the entire multi-agent workflow. So, like this the simple example that I give is you could say like the output that I need is an article. You know, and maybe there’s it’s got like this type of article, it’s going to be this length, whatever, right? Some constraints around that. And the input is like the topic. Like until you’ve got a good article for me, and the parent agent decides good, it decides when to exit, so that’s where you’re going to get a better result with a stronger model than a weaker one. I’ve got a researcher sub-agent. That agent has my access CLI

[44:36] and my access skill on how to use a CLI cuz I don’t want it, you know, using any random web search. I’ve got a writer sub-agent that has my special like here’s the last 10 articles I wrote that are really good, and you I want you to write like this. I’ve got a copy editor uh sub-agent, and that whole thing is just maybe >> But the really important 100 lines of markdown, and it might take them 10 hours to do it. >> important parts to emphasize there is is the contract composition where so you you you go to like, I mean, these things have been around forever. Any Any

[45:09] Any workflow builder, drag-and-drop workflow builder. That’s a different way of thinking about this because when you think about this in terms of that like DAG directed acyclic graph of contracts, you can have intermediary steps that you almost think of them as like checkpoints or like this intermediary step meets the contract, and the thing is going, and it hits this contract and fulfills this one, and then that causes the next one to keep going until it’s fulfilled that contract. So, you can you can still in some ways declare the how to get there

[45:42] just by composing these intermediary contracts along the way and still letting the agents be a little bit flexible on on how to do achieve that intermediary step. >> Yeah, and and the shape of it. So, like one one example like when Claude um the dynamic workflows came out, they had this blog post that’s like, here’s the six types, right? And it’s like one of them’s like fan out, fan in, and like a map reduce with sub agents. One of them’s like a adversarial review, one’s like a loop until X condition is met, right? And all of those things you can express in a

[46:14] prose program and then run them on on any agent. So, you can like you can template the shape of the the multi-agent workflow um with no code. Um and again, the whole it’s only possible because the the agents are like good at managing themselves and because most harnesses have sub agents. So, like if you’re running plain vanilla pie, which has no sub agents at least last time I checked, you’re going to want sub agents for it to do that more complex kind of workflow. But, like

[46:46] essentially any harness that has one of the requirements, >> Sub agents. >> sub agents is pretty much the only one for most >> context. >> Yeah, like um like bash and sub agents are actually you don’t even need bash. We can run these in VM isolates in code mode, too. So, >> Any other questions? We can give 10 minutes back to everyone. Uh it is based on my many years of engineering experience and dealing with people who sometimes are not very good at expressing requirements and other people who are

[47:16] very good at expressing requirements. And it’s also, I mean, we we benchmark these internally and and run them against we we have sort of an evolutionary algorithm where we can shrink the kernel by seeing if if they can conform to that. So, it’s based on practice and empirical results. Uh >> Yeah, you can just have that as a spec and you could have like let’s say you like um uh Matt Pocock’s like uh spec, you know, you like Matt I built a funny one just to like troll him that was like auto Pocock and it basically

[47:49] it was my way of proving that my way of wiring skills in works. So, you basically just he has a workflow that’s like grill me, you know, and then you ask all these questions and then it’s like TDD and then all these other ones and you can put the whole thing in one prose program and just be like do Matt Pocock’s workflow and every sub-agent has to load at every stage of the program you have to load this the next skill in the sequence. Um so yeah, you can absolutely like >> do have people I I wasn’t calling it spectrum driven development, but like almost by its very nature it is spectrum

[48:22] driven development. I’d love you to try this out. Try it or come find me after and like whatever spectrum driven development specification you have, we could compose with the boot kernel prose run and then we’ll see how it does. I I think it would do quite well actually. That’s a good good inspiration. I haven’t tried it with the spectrum driven development contracts. Like I’d love to sit down and and and try it and see if it overrides it or if it starts colliding. >> That’d be interesting like um >> Here’s Here’s one

[48:52] >> See how much different skills like throw it off. >> Here’s one thing we do have and software engineers using Open Prose to develop software. Uh more of our users are using Open Prose to do ops and product management and um quant model documentation and non I don’t know software engineering stuff. Uh I think it’s just the blend of like markdown documentation actually is more interesting to non-engineers um as a result. Yeah. Any other questions?

[49:25] Thank you all. Appreciate your time. >> [applause]