Pular para o conteúdo
Aprendendo AI

Da fábrica de software à infraestrutura que a sustenta

Edição de quarta, 7 out 2026 · 15 vídeos · 4 h 44 min de talks

Esta edição acompanha a fábrica de software do desenho à infraestrutura. Primeiro, como times e processos mudam quando agentes escrevem o código, e como segurança e skills acompanham esse ritmo. Depois, os loops de melhoria e as plataformas de eval que dizem se o agente está ficando melhor. Por fim, o que sustenta tudo isso: contexto bem gerido, busca em documentos, conversa entre agentes, sandboxes, cobrança por uso, bancos de dados e speculative decoding na GPU.

Redesigning How Software Gets Built With AI Agents

Agente em escala depende de processo, ferramenta e gente. A confiança sobe em degraus: revisão, bloqueio, autofix, aprovação e merge automáticos.

Carreira e equipes 19:12 nível ●●○○○ Sonar & McKinsey Panel Assistir no YouTube (abre em nova aba)

Em 3 frases

A McKinsey e a Sonar viram que quase toda empresa diz usar agentes, mas menos de um terço escalou e vê resultado de negócio. Quem escala redesenha o processo inteiro, escolhe boas ferramentas e remodela papéis.

Tariq Shaukat (Sonar) conta que times-farol não bastam para espalhar o hábito. Engenheiros precisam tornar explícito o que sabem de cabeça, duvidar das respostas seguras da IA e virar generalistas.

Ali-Reza Adl-Tabatabai (Gitar, agora Sonar) descreve a escada de confiança: revisão de PR, bloqueio por regra, correção automática, aprovação automática e merge automático, cada degrau liberado quando a precisão convence.

Antes de ler

Mais 2 termos

Muita adoção, pouca escala

Segundo a pesquisa citada, de 80% a 90% das empresas dizem ter implantado IA ou agentes, mas menos de um terço escalou ou vê impacto de negócio. A causa apontada são pilotos (POCs) em ambientes pequenos que nunca viram fluxo de ponta a ponta.

00:40 Adoção é alta, mas menos de um terço escalou.

Horizon 2 versus Horizon 3

A pesquisa põe as empresas numa escala de maturidade. A maioria está no Horizon 2, com agentes guiados e validados por humanos em tarefas do ciclo de desenvolvimento. Poucas chegaram ao Horizon 3, com fluxo automatizado de ponta a ponta e supervisão humana.

A maioria das empresas está no Horizon 2, poucas no 3.01:40

Três fatores: processo, ferramenta e gente

Quem escala redesenha o fluxo inteiro em vez de encaixar agentes no processo antigo. Também cuida de agentes, harnesses e camadas de contexto. O fator mais ignorado são as pessoas, porque as fronteiras entre engenheiro, produto e design estão se apagando.

O fator mais esquecido é o papel das pessoas.02:10
Mais 2 ideias deste talk

Times-farol não espalham o hábito sozinhos

Tariq esperava que os outros times seguissem o exemplo dos times-farol quase por imitação. Não aconteceu. O exemplo e a ferramenta levam parte do caminho, mas falta fazer o time entender por que usa o agente e pensar de outro jeito.

05:45 Imitar o time-farol não muda a forma de pensar.

A escada de confiança até o merge automático

Ali descreve o padrão dos usuários do Gitar. Começam com revisões e análise de falhas de CI. Depois bloqueiam PRs por regra, ativam autofix, aprovam sozinhos mudanças de baixo risco e por fim fazem merge automático. Cada passo depende da precisão que o time observou.

A autonomia cresce em degraus, conforme a precisão.17:03
leitura crítica

O talk é um painel moderado pela McKinsey com o CEO da Sonar e um executivo do Gitar, produto agora da Sonar. A escada de confiança descreve o produto que eles vendem, e a afirmação de que times chegarão ao merge automático em um ano não traz dados. Os números da pesquisa são citados de memória, sem amostra, método ou definição de escala. A promessa de 10x de produtividade também vem sem fonte.

O que fazer com isso

  • Meça antes de pôr agente no fluxo: tempo até produção, vazão de PRs, taxa de retrabalho e satisfação dos engenheiros. Sem essa linha de base, você não prova ganho.
  • Escreva as regras que hoje vivem só na cabeça do time (dependências preferidas, estilo de código) em arquivos que o agente leia.
  • Suba a autonomia por degraus. Comece com revisão por IA, só bloqueie quando os alertas forem precisos e só aprove sozinho mudanças em áreas não críticas.
  • Trate a resposta da IA como a de um estagiário confiante. Defina onde questionar e o que checar antes de aceitar.

The Software Factory: From Bug Report to Production Code

Escrever código nunca foi o gargalo. Uma software factory precisa de revisão, testes e docs integrados, começar pequena e medir resultado, não token.

Engenharia de software 18:32 nível ●●●○○ Davis Palmie, Factory Assistir no YouTube (abre em nova aba)

Em 3 frases

Davis Palmie, da Factory, define software factory como um sistema de agentes que recebe sinais (bug reports, feedback) e entrega código em produção, com engenheiros governando em vez de digitar.

Ele defende começar por algo estreito e verificável, como triagem de incidentes, e preparar o código com oito pilares de agent readiness (prontidão para agentes) antes de fechar o ciclo.

Ele critica rankings de tokens como a lei de Goodhart em ação e propõe métricas de resultado, como tempo do sinal à produção, intervenções humanas e custo por PR.

Antes de ler

Mais 2 termos

Codar nunca foi o gargalo

O palestrante pede para olhar as métricas reais: tempo mediano de revisão de PR, tempo para reproduzir bugs, docs desatualizadas, testes. Para ele, o tempo entre código escrito e produção (métrica DORA) supera o de escrever a mudança. Por isso a fábrica precisa de coesão entre times, não só de um agente que programa.

Lista dos gargalos reais além de escrever código05:18

Comece estreito: triagem de incidentes

O agente lê um alerta do Sentry, puxa traces e contexto e posta no Slack. Engenheiros revisam e decidem. Cada diagnóstico correto aumenta a confiança do time. Só depois de ter dono e monitoramento em cada etapa vale fechar o ciclo e ligar a saída ao sinal de entrada.

Primeiro caso de uso sugerido, com humano decidindo07:23

Três princípios da fábrica

Agnóstica de modelo, para escolher o mais barato que resolve cada tarefa. Implantação soberana, do gerenciado ao isolado da rede (airgapped). Integrada ao ciclo de desenvolvimento inteiro, para que docs, código e testes se informem. Fraqueza em um pilar enfraquece o sistema todo.

Princípio de modelo agnóstico e a comparação de preço08:27
Mais 2 ideias deste talk

Oito pilares de agent readiness

Validação (linters, formatadores), build documentado, feedback loops com testes, docs como AGENTS.md, ambientes reproduzíveis, código modular, observabilidade e varredura de segurança. A tese é que preparar o terreno ajuda agentes e humanos igualmente.

Checklist para deixar o código pronto para agentes13:45

Meça resultado, não token

Rankings de tokens e linhas de código são manipuláveis: quem é medido por token gasta token. Palmie propõe tempo do sinal à produção, contagem de intervenções humanas, tempo mediano de reparo, vida útil do código e custo por PR.

Métricas de resultado propostas no lugar de tokens16:57
leitura crítica

O talk é pitch da Factory, que vende a plataforma. A comparação de custo entre GPT 5.2 e Opus em revisão de código aparece sem metodologia, tarefas ou amostra. Os ganhos de 10 a 30 vezes com modelos abertos também não têm fonte. O argumento de que o gargalo não é codar vem de uma suposição ('aposto que'), não de dados. As cinco métricas são sugeridas sem exemplo de resultado real em algum cliente.

O que fazer com isso

  • Meça o tempo mediano de revisão de PR e o tempo do código escrito até a produção no seu time, para saber onde está o gargalo antes de comprar mais IA.
  • Escolha uma tarefa estreita e verificável, como triagem de alertas, e deixe o agente só sugerir enquanto uma pessoa decide.
  • Faça um checklist rápido com os oito pilares no seu repositório principal: linter, CI documentado, testes, AGENTS.md, ambiente reproduzível.
  • Troque métricas de uso de IA por tempo do sinal à produção, intervenções humanas e custo por PR.

Harness Engineering: How to Build a Software Factory

Uma fábrica de software se constrói em ciclos: o time deixa de escrever código e passa a melhorar o sistema que faz o agente escrever.

Agentes 20:31 nível ●●●○○ Dru Knox, Tessl Assistir no YouTube (abre em nova aba)

Em 3 frases

Dru Knox, da Tessl, define software factory (fábrica de software) como um sistema em que agentes produzem todo o produto e os engenheiros constroem a fábrica. Ele mede o avanço por autonomia, automação e qualidade.

A disciplina para chegar lá é o harness engineering (engenharia do arcabouço do agente), feita em três ciclos: interno (antes do PR), externo (depois do PR) e meta (que observa os erros e corrige os outros dois).

Ele propõe três camadas, nesta ordem: control plane (plano de controle), infraestrutura pronta para agentes e ciclos de melhoria. A segunda metade do talk apresenta os produtos da Tessl como atalho.

Antes de ler

Mais 2 termos

Autonomia, automação e qualidade

Autonomia mede quantas vezes um humano precisa corrigir o agente. Automação mede quanto o agente pode rodar sem revisão direta. Qualidade é o resultado para o usuário. A ordem proposta é subir autonomia, depois automação, sempre com a qualidade constante.

As três métricas que definem o quanto de fábrica um time já tem.03:21

O ganho final é qualidade, não só velocidade

Para Knox, a maioria vê a fábrica como forma de entregar mais rápido, aceitando um pouco de lixo. Ele defende que o backlog (fila de pendências) some e sobra capacidade para testes, refatorações e correções. Por isso a qualidade deveria subir depois da transição.

A tese central: fábrica serve para elevar qualidade, além de velocidade.04:53

Ciclo interno, externo e meta

O ciclo interno roda barato e o tempo todo, enquanto o agente prepara o PR, e melhora a autonomia. O externo roda checagens caras uma vez, quando o PR sobe, como QA agêntico e teste de mutação. O meta fica fora do desenvolvimento, lê logs, PRs e feedback, e realimenta os outros dois.

Cada ciclo atua numa fase diferente e o meta corrige os outros dois.06:59
Mais 2 ideias deste talk

Por que harness engineering é difícil

Knox aponta três motivos. O campo muda toda semana e o time vira pesquisador. O trabalho não é planejável e compete com o prazo das funcionalidades. Os sinais úteis ficam presos em logs locais e na cabeça das pessoas.

Os obstáculos são sobretudo de tempo e organização, não de ferramenta.09:08

Três camadas, nesta ordem

Primeiro o control plane: issues, revisão no PR e distribuição de skills, para que todo contato com o agente fique registrado. Depois deixar a pilha pronta para agentes (CLI, APIs, logs, ambiente de execução). Por fim os ciclos de melhoria, onde ele diz que o time gasta mais tempo.

O roteiro de construção da fábrica, em ordem de execução.11:33
analogia

Mutation testing (teste de mutação). Mutation testing é como um professor que coloca erros de propósito numa prova já corrigida para ver se o corretor percebe cada um deles.

  1. Testes automáticos são pequenos programas que conferem se o código faz o que deveria. Mas ninguém confere se os próprios testes são bons.
  2. O teste de mutação (mutation testing) cria cópias do código com um defeito pequeno de propósito, como trocar um sinal de maior por menor ou apagar uma linha.
  3. Cada cópia defeituosa se chama mutante. A ferramenta roda todos os testes contra cada mutante.
  4. Se algum teste falha, o mutante foi pego e o teste cumpriu seu papel. Se todos passam, existe um buraco na suíte de testes, porque um erro real passaria despercebido.
  5. A porcentagem de mutantes pegos mede a qualidade dos testes. Como o processo é caro, Knox sugere rodá-lo uma vez no ciclo externo, quando o PR (pedido de alteração) sobe.
CÓDIGO ORIGINALVersão que passa em todos os testes
CRIAR MUTANTESCópias com um defeito pequeno cada
RODAR OS TESTESToda a suíte contra cada mutante
CONTAR OS PEGOSMutante que passa revela buraco
NOTA DA SUÍTEPercentual de mutantes detectados

Ajuda saber antes: Testes automatizados, Suíte de testes, Pull request (PR), Outer loop

leitura crítica

O palestrante é head de produto da Tessl e a metade final é pitch dos produtos (skills registry, Tessl Agent, Tessl Launch). Ele admite que as três camadas são termos dele, não padrão. Não há dados de clientes nem medição que sustente a tese de que a qualidade sobe com a fábrica. O trecho de 40% do caminho é ilustrativo. As métricas sugeridas são plausíveis, mas ele não mostra valores de referência.

O que fazer com isso

  • Registre três métricas por mês no seu fluxo com agentes: quantas vezes você assumiu a tarefa manualmente, quantos comentários humanos o PR recebeu e quantos PRs começaram sem intervenção humana.
  • Mova o pedido ao agente para um lugar rastreável, como uma issue que gera um PR, em vez de sessões locais. Assim os erros ficam visíveis para análise.
  • Quando o agente errar duas vezes do mesmo jeito, atualize a skill ou o arquivo de instruções do repositório para que o erro não volte.
  • Escolha uma tarefa repetida, como caçar testes instáveis toda semana, e automatize só essa antes de pensar na fábrica inteira.

AI Hackers Are Faster Than Your Pen Test

Se o código sai a cada PR e o atacante usa IA, o teste de invasão precisa rodar a cada PR também, com agentes que provam o exploit.

Engenharia de software 19:28 nível ●●●○○ Eli Cohen, Snyk Assistir no YouTube (abre em nova aba)

Em 3 frases

Eli Cohen, da Snyk, diz que agentes de código geram mais código e boa parte dele é insegura, enquanto atacantes usam modelos de ponta para encadear falhas pequenas em críticas.

Scanner estático, scanner dinâmico e pen test humano (teste de invasão) cobrem partes diferentes do problema, e o pen test, o único que entende regra de negócio, acontece poucas vezes por ano.

A proposta é um time de agentes (orquestrador, reconhecimento, caçadores de falhas, juiz de exploit, correção e relatório) rodando em cada PR, e ele fecha com quatro perguntas para qualquer fornecedor.

Antes de ler

Mais 2 termos

Mais código e mais código inseguro

O palestrante cita 218% mais linhas de código por desenvolvedor e 62% da saída de LLMs insegura ou quebrada. A conta dele é que o backlog (fila) de falhas de segurança cresce mais rápido do que qualquer time consegue corrigir.

Os números que sustentam o argumento de que o backlog de segurança só cresce.01:46

Atacantes também usam IA

Segundo Cohen, atacantes encadeiam vulnerabilidades de baixa severidade até formar uma crítica, e mexem justamente onde o contexto da aplicação importa. Ele cita ataque bem-sucedido em 4 minutos no melhor caso e 43% dos servidores MCP com falhas.

O tempo de ataque caiu para minutos, e o pen test anual não acompanha.03:53

O que cada teste enxerga

SAST (análise estática) acha SQL injection e XSS no código. DAST (teste dinâmico) manda payloads contra a aplicação rodando e acha falhas de configuração e de autorização como BOLA. Só o pen test humano entende a lógica de negócio, mas custa caro e acontece uma a três vezes por ano.

Cada ferramenta tem um ponto cego, e a lógica de negócio fica com o humano.06:16
Mais 2 ideias deste talk

Um time de agentes faz o pen test

O orquestrador planeja e comanda subagentes. O de reconhecimento mapeia endpoints e APIs. Os caçadores buscam falhas conhecidas e inéditas. Um juiz tenta provar que a falha é explorável, o que corta falso positivo. Por fim, um agente propõe a correção e outro monta o relatório.

A cadeia de agentes e o papel do juiz que valida o exploit.12:43

Contexto e quatro perguntas ao fornecedor

Cohen diz que o LLM rende conforme o contexto, então alimenta o pen test com dados de SAST e DAST. Ele recomenda combinar as técnicas e perguntar ao fornecedor se roda de forma contínua, se raciocina sobre o contexto da aplicação, quanto contexto extra aceita e se prova a exploração.

17:30 O checklist de compra que o palestrante deixa para a plateia.

analogia

Exploit validation (validação de exploit, o agente juiz). Exploit validation é como o inspetor da defesa civil que vai até a casa e testa a parede rachada antes de mandar interditar o prédio inteiro.

  1. Um programa de segurança procura falhas no sistema e gera uma lista de suspeitas. Muitas dessas suspeitas são alarme falso.
  2. Um exploit (ataque que aproveita uma falha) é a prova prática de que a falha existe e pode ser usada por um invasor.
  3. Na exploit validation (validação de exploit), um agente de IA recebe cada falha suspeita e tenta explorá-la de verdade, de forma controlada.
  4. No talk, esse agente faz o papel de juiz. Os agentes caçadores entregam as falhas encontradas, e o juiz decide se cada uma é real e explorável.
  5. Só passam adiante as falhas confirmadas. Isso corta falsos positivos, reduz a carga de análise do time e deixa para os agentes de correção e de relatório só o que importa.
CAÇADORES DE FALHASAgentes listam falhas suspeitas
JUIZ DE EXPLOITTenta explorar cada suspeita
FILTRODescarta o que não é explorável
FALHAS CONFIRMADASSeguem para correção e relatório

Ajuda saber antes: Vulnerabilidade, Falso positivo, Pen test, Orquestrador de agentes

leitura crítica

O talk é pitch do Snyk Evo, e o palestrante diz que os princípios valem para qualquer fornecedor, mas mostra só a própria solução. Não há dado sobre taxa de falso positivo, custo por PR nem comparação com pen test humano. Os números de ataque (218%, 62%, 4 minutos, 43% de MCP) vêm sem fonte ou metodologia, e o tempo médio sai ambíguo na legenda automática. Cohen é ex-fundador de empresa comprada pela Snyk, então tem interesse comercial.

O que fazer com isso

  • Liste quais testes de segurança rodam hoje a cada mudança de código (SAST, DAST) e quais só aparecem uma vez por ano, como o pen test.
  • Ao avaliar um fornecedor de pen test com IA, use as quatro perguntas do talk e peça uma demo em que ele prove a exploração, sem apenas listar alertas.
  • Se você usa agentes de código, trate o código gerado como não confiável e passe por revisão e scanner antes do merge.
  • Verifique se os servidores MCP que você conecta aos agentes foram revisados quanto a permissões e falhas.

From 36% to 100%: How Self-Improving Agents Write Their Own Skills

Se cada tarefa difícil resolvida por um agente vira uma skill compartilhada via MCP, a empresa acumula conhecimento que o modelo sozinho não dá.

Agentes 18:31 nível ●●●○○ Rafal Wilinski, Runlayer Assistir no YouTube (abre em nova aba)

Em 3 frases

Skills são playbooks em texto que o agente lê quando precisa, e importam mais conforme os agentes trabalham por horas, porque um começo errado custa tokens e dinheiro.

O palestrante propõe entregar as skills por um servidor MCP central, o que alcança também quem não é desenvolvedor, e deixar um modelo de ponta destilar skills a partir de execuções (traces) que deram certo ou errado.

Em um teste interno da Runlayer, uma tarefa subiu de 36% para 100% de sucesso depois que uma skill destilada entrou nas execuções seguintes, e a tese final é que essa biblioteca de skills vira o diferencial da empresa.

Antes de ler

Mais 2 termos

Skill é um playbook lido sob demanda

O agente enxerga só um resumo curto de cada skill. Quando julga o conhecimento útil, lê o texto inteiro e injeta no contexto. Essa técnica se chama progressive disclosure (revelação progressiva) e muda o rumo do agente no começo da tarefa.

02:10 Skill como playbook que o agente carrega só quando precisa.

Tarefas longas aumentam o custo do erro inicial

O gráfico do METR mostra por quanto tempo agentes trabalham sozinhos com chance razoável de acabar a tarefa. Quanto mais longa a tarefa, mais fundo o agente cava um caminho errado, com centenas de chamadas de ferramenta. A skill orienta a trajetória logo no início.

O horizonte de tarefa dos agentes cresce, e o erro inicial fica mais caro.03:15

MCP como camada de distribuição de skills

Em vez de instalar skills em cada máquina, a empresa mantém um servidor MCP remoto como fonte única. Ele aplica política, entrega a melhor versão por papel do usuário e funciona em clientes de chat comuns. Isso ataca os problemas de skills feitas para devs e de clientes sem suporte.

07:55 Um servidor governado substitui a instalação local de skills.

Mais 2 ideias deste talk

Destilar skills de execuções, inclusive das que falham

Inspirado no artigo Voyager (Minecraft), o agente guarda o que descobriu como receita reutilizável. Na Runlayer, um modelo de ponta lê o trace de cada execução e escreve a skill. As falhas mostram a proteção ou o caso de borda que faltava.

Sucessos dão confiança à skill e falhas a deixam mais robusta.11:59

Resultado e flywheel organizacional

Rodando um fork do Chromium no AWS Lambda com Sonnet 4.6, a taxa de sucesso era de 36%. Depois que uma skill destilada passou a valer para as execuções seguintes, foi a 100%. Execuções semelhantes são agrupadas, checadas contra prompt injection e dados pessoais e servidas pelo gateway MCP a todos.

Uma skill destilada levou o sucesso de 36% a 100% no teste da Runlayer.13:10
leitura crítica

O talk é também um pitch da Runlayer, que vende o gateway MCP e o destilador. O resultado de 36% para 100% vem de uma única tarefa (Chromium no Lambda), sem número de execuções, sem grupo de controle e sem dizer se a skill já estava perto de uma resposta copiável. Faltam dados sobre skills destiladas erradas ou desatualizadas, sobre custo do destilador e sobre revisão humana, que o palestrante diz dispensar. A afirmação de que a economia de tokens vem das skills também não traz medição.

O que fazer com isso

  • Registre, após cada tarefa difícil resolvida por um agente, os passos que funcionaram e peça ao modelo para transformá-los em uma skill curta (um arquivo de texto com quando usar e como fazer).
  • Teste a ideia em escala pequena. Escolha uma tarefa que seu agente falha com frequência, meça a taxa de sucesso em várias execuções, adicione a skill e meça de novo.
  • Antes de instalar skills públicas, leia o conteúdo e as permissões. O palestrante cita scripts que pedem root e chaves de API de terceiros.
  • Se você lidera a adoção de IA, avalie centralizar skills em um ponto governado, para que áreas sem cliente de desenvolvedor, como RH e jurídico, também usem.

The Self-Improving OSS Agent Stack

Quem melhora agentes bem deixa a IA cuidar do trabalho braçal do loop e guarda para si a definição de metas, datasets e critérios de eval.

Evals 17:06 nível ●●●○○ Marc Klingen, Langfuse Assistir no YouTube (abre em nova aba)

Em 3 frases

Marc Klingen, cofundador da Langfuse, descreve a stack de referência para agentes: tracing online ligado a datasets, experimentos e evals (avaliações) offline.

Hoje a IA já propõe correções, mantém datasets e sugere critérios de avaliação, mas o time humano ainda revisa os limites contra os quais o agente se otimiza.

Numa demo, um coding agent lê os traces de um redator de changelog, acha vazamento de jargão interno, atualiza os evals e testa uma V2 contra a V1 antes de publicar.

Antes de ler

Mais 2 termos

O loop junta produção e testes offline

Observabilidade (tracing e monitoramento) mostra como usuários usam o agente. Datasets e evals offline testam mudanças antes do deploy. Sem juntar os dois, o benchmark usa dados desatualizados ou o monitoramento nunca vira teste. Por muito tempo, esse ciclo exigiu trabalho manual de olhar traces toda semana.

O ciclo online + offline que sustenta a melhoria de um agente.02:06

Camadas de loops e onde o humano fica

Klingen mostra loops empilhados, do próximo token até a definição de metas humanas. Os modelos atuais permitem automatizar os loops de nível médio. Os humanos seguem alinhando o dataset com o uso real e definindo como avaliar, porque a IA pode se ajustar demais ao dataset e perseguir falhas irrelevantes.

As duas etapas azuis do loop 3 continuam com humanos.04:13

IA mantém datasets e critérios de eval

O uso mais comum é a IA propor correções do agente, com hill climbing (subir degrau a degrau) contra os datasets. Há cerca de um mês, mais times usam IA para atualizar datasets conforme o uso real e propor novos evaluators a partir de padrões de erro. O time revisa, porque esses critérios definem o alvo da otimização seguinte. Sem revisão, o risco é gerar mais lixo (slop).

Onde a IA já atua no loop e onde o humano valida.05:46
Mais 2 ideias deste talk

Menos tempo investido, qualidade maior

O quadrante manual dá qualidade alta, mas custa muito tempo da equipe. A automação total custa pouco tempo, mas gera muitos tokens sem sentido. O ponto ideal combina o humano definindo direção e a IA fazendo o trabalho tedioso, olhando muito mais casos de erro do que uma pessoa aguentaria. Sinais implícitos do uso, como edições e aprovações, alimentam o processo.

Direção humana mais execução por IA rende mais qualidade com menos tempo.08:23

Demo: changelog writer que se corrige

Um agente escreve changelog e documentação, e pessoas aprovam ou pedem mudanças em PRs. Um coding agent usa as agent skills da Langfuse, nota que o texto vazava jargão interno e atualiza dataset e evaluators. Depois testa a V2 contra a V1: formato e precisão ficam iguais e a linguagem voltada ao usuário melhora.

Back-test mostra a V2 melhor em linguagem ao usuário sem perder precisão.14:02
leitura crítica

O talk vem do cofundador da Langfuse e funciona também como pitch de produto, sobretudo a parte final sobre dono dos dados e sistema escalável. Não há métrica sobre quanto tempo se economiza nem comparação entre times. A demo é um caso interno e o próprio palestrante a chama de yolo, pois o agente só abre PRs. Afirmações como 'os melhores usuários já fazem assim' não trazem amostra nem dados.

O que fazer com isso

  • Registre traces do seu agente e escolha uma fonte de sinal implícito, como edições, aprovações ou reclamações do usuário, para alimentar um dataset.
  • Deixe a IA propor correções e novos casos de teste, mas revise você mesmo o dataset e os critérios de eval, pois eles definem o alvo da otimização.
  • Antes de publicar uma mudança no prompt ou na skill do agente, rode a versão nova contra a antiga no mesmo dataset e compare por métrica.
  • Defina retenção longa e sem amostragem dos traces, porque agentes vão ler volumes maiores de histórico.

Why Building an Eval Platform Is Harder Than It Looks

Plataforma de eval parece planilha com interface bonita, mas vira problema de sistemas quando entram traces enormes e produção.

Evals 17:46 nível ●●●○○ Braintrust Assistir no YouTube (abre em nova aba)

Em 3 frases

Hossein Niazmandi, da Braintrust, defende que qualidade de agente tem dois pilares: evals (avaliações) antes da produção e observabilidade depois dela.

Ele descreve quatro estágios de maturidade: planilha, interface própria, experimentos lado a lado para PMs e especialistas, e um flywheel que transforma falhas de produção em casos de teste.

No último estágio o gargalo passa a ser dado: traces com centenas de megabytes exigem consultas em tempo real e de longa duração, o que levou a empresa a criar a BTQL, e agentes de código passam a rodar os evals enquanto humanos decidem.

Antes de ler

Mais 2 termos

Dois pilares: eval antes, observabilidade depois

Eval testa o comportamento do agente antes de ir para produção. Observabilidade acompanha as interações reais depois do lançamento. Os dois atacam o mesmo problema, porque o LLM é não determinístico e varia a cada execução.

Qualidade de agente se apoia em eval offline e monitoramento em produção.01:03

O iceberg por baixo da planilha

Um eval básico tem três partes: executar o agente, ver as saídas ou notas, e ter exemplos de entrada. Por baixo disso ficam datasets, sistemas de nota, processo de revisão, ferramentas de debug e a ligação com a produção. Além disso, PMs e especialistas de domínio também rodam evals.

A parte visível do eval é pequena perto do trabalho de suporte.05:13

Quatro estágios de maturidade

Planilha tem barreira zero, mas só documenta. Interface própria inclui PMs, mas vira só relatório. Experimentos lado a lado deixam trocar prompt, modelo e parâmetros. O quarto estágio liga a produção e fecha o ciclo.

O terceiro estágio troca registro de resultados por experimentação.09:58
Mais 2 ideias deste talk

O flywheel de melhoria

O ciclo observa falhas em produção, registra cada passo do trace, define dimensões de sucesso e falha, cria casos de teste a partir delas e itera offline sem gerar regressões. Depois publica e repete. O palestrante cita drift como razão para o ciclo nunca parar.

Falhas de produção viram casos de teste que alimentam a próxima versão.11:01

Traces quebram o data warehouse comum

Traces de agente são JSON semiestruturado e aninhado, com centenas de megabytes por interação, contra kilobytes de observabilidade tradicional. É preciso consulta em tempo real e consultas longas, por isso a Braintrust criou a BTQL. Mais recentemente, agentes de código rodam os evals e humanos revisam.

O volume e o formato dos traces tornam eval um problema de sistemas.12:06
leitura crítica

É palestra de fornecedor. Hossein lidera engenharia de soluções da Braintrust e o argumento de que construir é difícil leva à compra da plataforma. Não há dado de clientes, custo de construir internamente nem comparação com alternativas. As afirmações sobre warehouses que colapsam e sobre insights automáticos de falhas silenciosas não trazem medição. Os estágios são um modelo narrativo, não resultado de pesquisa.

O que fazer com isso

  • Se você ainda usa planilha para avaliar seu agente, mantenha, mas guarde entrada, saída e nota de cada execução para comparar versões.
  • Escolha uma dimensão de falha que você já viu em produção e transforme alguns casos reais em exemplos de teste.
  • Inclua PMs e especialistas de domínio na revisão dos resultados, em vez de deixar só com engenharia.
  • Antes de construir uma plataforma própria, estime o tamanho dos seus traces e se precisará consultá-los em tempo real.

Why Bigger Context Windows Won't Save Your Agent

Janela de contexto maior não salva o agente. Mantenha dados grandes fora dela e entregue só o que cada passo precisa.

Agentes 15:53 nível ●●●○○ Elizabeth Fuentes Leone, AWS Assistir no YouTube (abre em nova aba)

Em 3 frases

Elizabeth Fuentes Leone, da AWS, mostra que agentes quebram quando ferramentas devolvem muitos dados, porque o modelo lembra do começo e do fim do contexto e perde o meio.

Ela organiza a solução em quatro estratégias (externalizar, selecionar, comprimir e isolar) e mostra como aplicá-las com o framework open source Strands Agents.

Os exemplos cobrem gerenciadores de conversa, memória de curto e longo prazo, ponteiros de memória para logs, limite de chamadas de ferramenta e handles assíncronos para ferramentas lentas.

Antes de ler

Mais 2 termos

Janela maior esquece o meio

Um agente que monitora uma aplicação puxa logs a cada chamada, e o contexto só cresce. A palestrante diz que aumentar tokens deixou de funcionar: pela curva de atenção, o modelo guarda o começo e o fim e esquece o meio. Dados demais também podem poluir o contexto e abrir espaço para prompt injection.

O modelo lembra bem das pontas do contexto e perde o meio.02:21

Quatro estratégias de context engineering

Context engineering (engenharia de contexto) é dar ao modelo a informação certa na hora certa. A palestrante resume em quatro verbos. Externalizar move dados grandes para armazenamento persistente. Selecionar recupera só o relevante. Comprimir resume ou compacta. Isolar separa o contexto entre agentes.

As quatro estratégias que organizam o resto do talk.03:27

Gerenciadores de conversa no Strands

O Strands Agents oferece três gerenciadores: janela deslizante (guarda só as mensagens recentes), sumarização (resume as antigas) e a combinação dos dois. No exemplo, o agente preserva as quatro últimas mensagens e resume uma proporção do restante, definida em 50%. A criação do agente leva uma linha de código e troca de modelo exige mais uma.

Uma linha de configuração controla o tamanho do contexto.06:00
Mais 2 ideias deste talk

Ponteiro de memória para logs grandes

Em vez de colocar logs enormes no contexto, uma ferramenta os grava num armazenamento e devolve só um ID. O ID fica no estado do agente. Se o agente precisar dos logs, outra ferramenta usa o ID para buscá-los. Em um swarm (grupo de agentes), o ponteiro passa pelo estado de invocação e evita que um agente despeje lixo no contexto do outro.

Os logs ficam fora do contexto. Só o ID circula.09:11

Limite de chamadas e handles assíncronos

Agentes podem repetir a mesma ferramenta sem parar. A solução mostrada é limitar cada ferramenta a três chamadas e devolver respostas claras. Para ferramentas MCP ou APIs lentas, um handle assíncrono permite iniciar o trabalho e consultar o resultado depois, sem estourar o tempo limite de um gateway.

Um teto de chamadas corta loops infinitos de ferramenta.11:18
analogia

Async handle (handle assíncrono). Um handle assíncrono é como a senha que a lavanderia entrega quando você deixa a roupa: você vai embora, faz outras coisas e volta depois com a senha para buscar o que ficou pronto.

  1. Algumas tarefas demoram, como pedir um relatório a outro sistema. Se o agente fica parado esperando, tudo trava junto com ele.
  2. Num handle assíncrono (async handle, um comprovante de tarefa em andamento), o agente pede o trabalho e recebe na hora só um número de identificação, sem esperar o resultado.
  3. Com esse número, o agente segue a conversa e, mais tarde, pergunta se a tarefa terminou. Quando terminar, ele busca o resultado.
  4. Isso evita o tempo limite (timeout) de intermediários como o API Gateway da AWS, que corta a chamada se a resposta demora demais.
  5. No exemplo do talk, um servidor MCP (Model Context Protocol, padrão para conectar ferramentas a modelos) feito com FastAPI expõe duas ferramentas, start_job para iniciar e check_job_status para consultar.
INICIAR TAREFAAgente chama start_job
RECEBER IDResposta imediata, sem o resultado
CONSULTAR STATUScheck_job_status quando precisar
RESULTADO SEM TIMEOUTAgente usa a resposta sem travar

Ajuda saber antes: Chamada de ferramenta (tool call), API, Timeout, MCP

leitura crítica

A palestrante trabalha na AWS e apresenta o framework da própria empresa, o Strands Agents, então o talk tem traço de pitch. Não mostra medição: diz ter feito muitos testes com handles assíncronos e que a diferença é grande, mas não dá números nem método. A curva de atenção aparece sem fonte citada. A fala também admite que sumarização ingênua pode perder informação necessária, sem mostrar como medir essa perda.

O que fazer com isso

  • Revise suas ferramentas que devolvem textos longos, como logs e consultas. Grave o resultado fora do contexto e devolva ao agente só um ID e um resumo curto.
  • Defina um número máximo de chamadas por ferramenta no seu agente. Isso corta loops infinitos e controla custo de tokens.
  • Ao resumir conversas longas, teste se o resumo mantém os fatos de que o agente precisa. Combine resumo das mensagens antigas com as mais recentes intactas.
  • Para APIs ou ferramentas MCP lentas, separe 'iniciar tarefa' de 'consultar status', para o agente não ficar bloqueado esperando.

Grep or Embeddings? Agentic Search Over Company Documents

Grep basta para código. Com milhões de documentos, o agente precisa de uma bússola indexada e de ferramentas de leitura para fundamentar a resposta.

Dados e RAG 23:21 nível ●●●○○ George He, LlamaIndex Assistir no YouTube (abre em nova aba)

Em 3 frases

George He (LlamaIndex) explica por que o Claude Code dispensou embeddings: código é pequeno, em texto, local e cheio de pistas como imports e testes.

Dados de empresa são grandes, bagunçados, multimodais e com permissões. Ele propõe dar ao agente cinco ferramentas: busca híbrida como bússola, listar, filtrar por metadados, grep e leitura de páginas parseadas com screenshots.

Na demo, um agente monta uma tabela de fluxo de caixa a partir de 135 arquivos de relatórios da Alphabet e cita os arquivos de origem.

Antes de ler

Mais 2 termos

Por que o grep funcionou para código

O Claude Code testou banco vetorial e desistiu. Manter um índice sincronizado com código que muda o tempo todo custa caro. Além disso, um repositório é pequeno, semiestruturado, deixa pistas (imports, testes), tem hierarquia natural e já está no disco. Essas condições raramente existem em dados de empresa.

Lista de motivos pelos quais código dispensa índice vetorial.03:39

A escala decide a abordagem

Com cem a mil arquivos, o agente navega pelo sistema de arquivos dentro do contexto sem gastar muitos tokens. Com milhares ou milhões, ele precisa de uma bússola que indique a região certa antes de ler. Contexto maior também sai caro, e subagentes repetem o contexto completo, o que pesa em tokens e latência.

Escala de arquivos define entre grep local e índice.05:45

Cinco ferramentas em um harness

Em vez de decidir sozinho entre RAG e grep, o sistema entrega ao agente um conjunto de ferramentas. A busca híbrida mostra onde procurar. Listar arquivos, filtrar por metadados e grep reduzem o conjunto. A leitura do documento, em texto parseado e em screenshot da página, fundamenta a resposta e evita alucinação.

As cinco ferramentas que compõem o harness de busca.08:57
Mais 2 ideias deste talk

Busca híbrida com fusão e reranking

Palavra-chave (BM25) e busca semântica falham de formas diferentes. Combinar os dois com pesos e reordenar os 100 melhores resultados com um LLM dá resultados melhores nos benchmarks citados por ele. O palestrante recomenda essa combinação para uso corporativo.

Fusão de keyword e vetor supera cada método isolado.11:25

Demo com 135 arquivos da Alphabet

A interface devolve trechos e screenshots das páginas de origem. O agente usa grep com regex e lê um intervalo de caracteres por offset, como se o armazenamento remoto fosse local. Ao final, monta a tabela de fluxo de caixa de 2021 a 2025 com base em vários arquivos.

Chunks e screenshots de página que servem de base para o agente.19:10
analogia

Multi-tenancy (vários clientes isolados no mesmo sistema). Multi-tenancy é como um prédio de escritórios com várias empresas, onde todas dividem o mesmo elevador e a mesma portaria, mas cada uma só abre a própria sala com o crachá dela.

  1. Multi-tenancy (multilocação) significa que um único sistema atende vários clientes ao mesmo tempo. Cada cliente se chama tenant, ou inquilino.
  2. Todos os inquilinos usam a mesma infraestrutura, o mesmo índice de busca e o mesmo agente. Isso reduz custo, porque ninguém precisa de um sistema exclusivo.
  3. O sistema garante que uma pessoa nunca veja os documentos de outra. Para isso, cada documento guarda uma etiqueta de dono e de permissão.
  4. Em busca corporativa, as permissões vêm de fontes como Google Drive ou SharePoint. O sistema copia essas regras como metadados e filtra cada busca por elas.
  5. O desafio é manter as permissões atualizadas. Se alguém perde acesso no Drive, o índice precisa refletir a mudança logo, sem reprocessar todos os documentos.
PERGUNTA DO USUÁRIOAlguém consulta o agente
IDENTIFICA O INQUILINOSistema vê empresa e permissões
FILTRA O ÍNDICESó entram documentos liberados
RESPOSTA ISOLADASem dados de outros clientes

Ajuda saber antes: Filtro por metadados, Pré-indexação, Controle de acesso

leitura crítica

O talk é de um head de engenharia da LlamaIndex, que vende LlamaParse e pipelines de indexação. A conclusão favorece indexar e parsear previamente. Os benchmarks de busca híbrida são citados de forma genérica, sem nome, números ou fonte. A demo usa 135 arquivos e um único exemplo, sem medir acurácia nem custo contra a alternativa só com grep. Permissões e frescor dos dados aparecem como riscos, mas sem solução detalhada.

O que fazer com isso

  • Estime quantos arquivos seu agente precisa consultar. Até alguns milhares, teste primeiro listar, grep e leitura antes de montar um índice.
  • Se for indexar, use busca híbrida (palavra-chave mais semântica) e adicione metadados como ano, empresa e dono do documento para filtrar.
  • Para PDFs com tabelas e gráficos, guarde o texto parseado e também a imagem de cada página, e exija que a resposta cite o arquivo de origem.
  • Antes de usar com clientes, defina como as permissões do Drive ou SharePoint serão copiadas e como o índice será atualizado.

Why Your AI Agents Can't Talk to Each Other (Yet)

Quem roda dois agentes lado a lado virou roteador de mensagens. Falta uma camada própria para agentes conversarem entre si.

Agentes 17:12 nível ●●●○○ Vlad Luzin, BAND Assistir no YouTube (abre em nova aba)

Em 3 frases

O palestrante diz que quem usa Claude e Codex em sessões separadas já opera um sistema multiagente à mão, copiando saída de um para o outro, e que loop engineering (engenharia de loops) só troca essa pessoa por um script.

Ele argumenta que Slack, Telegram, MCP e A2A não resolvem a conexão, porque conectar agentes é um problema de sistemas distribuídos: transporte ordenado, persistência, vínculo de identificadores de execução, identidade e observabilidade.

A BAND, empresa dele, lança uma camada de interação com registro de agentes e consentimento entre as partes, e mostra em vídeo gravado um Claude Code e um Codex colaborando entre usuários diferentes.

Antes de ler

Mais 2 termos

Você é o roteador entre dois agentes

Quem planeja numa sessão e revisa em outra, com Claude ou Codex, mantém dois agentes com estado trabalhando na mesma tarefa. A pessoa copia mensagens de um para o outro, como um roteador de rede. O loop engineering apenas entrega esse papel a um script em Python ou TypeScript.

O humano faz o papel de roteador entre dois agentes.02:04

Por que um agente só não basta

O palestrante cita limites da arquitetura de transformer: viés de confirmação, diluição de atenção, fragmentação e perda de recall do contexto. Segundo ele, contexto de 1 ou 2 milhões de tokens não resolve isso. Por isso se usam vários agentes, um conferindo o outro. Ele afirma sem mostrar medições.

Lista dos motivos citados para dividir o trabalho entre agentes.03:35

Chat de empresa dá só conversa agente-humano

Conectar um agente ao Telegram leva 5 passos, ao Slack 8 e ao WhatsApp 11, segundo o slide. No fim o agente conversa apenas com uma pessoa, não com outro agente. Essas plataformas foram feitas para humanos e bloqueiam bot falando com bot.

Contagem de passos manuais por plataforma de mensagens.04:36
Mais 2 ideias deste talk

MCP e A2A deixam lacunas

Segundo o palestrante, MCP faz chamadas sem estado, então não dá para voltar a perguntar ao agente o que aconteceu. A2A é cliente-servidor de mão única, e quem quer os dois sentidos implementa cliente e servidor nos dois lados. Faltam ainda descoberta e filas. Para ele, protocolo é abstração baixa demais para construir em escala.

05:40 Arquitetura montada só com protocolos, apontada como complexa.

Runtime binding e demo de onboarding

Para ligar LangGraph a Codex ou a CrewAI, é preciso mapear thread ID, session ID, execution ID e run ID entre os agentes. Sem isso eles não trabalham como grupo. Na demo gravada, dois agentes entram na plataforma em segundos, recebem um agent card e só trocam contato após consentimento dos dois lados.

Agentes surgem no registro e se conectam após consentimento bilateral.12:26
leitura crítica

O talk é pitch de produto: o palestrante é cofundador da BAND e lança o produto no fim. A frase de que um agente só sofre de viés de confirmação e atenção diluída vem sem dado ou estudo. As contagens de passos por mensagem e as críticas a MCP e A2A não têm fonte. As demos são gravadas e curtas, sem medição de latência, custo ou falhas. Ele não discute segurança de agentes de empresas diferentes conversando, só cita governança. A frase final sobre uma concorrente é provocação de estande, não argumento.

O que fazer com isso

  • Liste quais tarefas suas já usam duas sessões de IA (planejar e revisar) e anote onde você copia texto à mão. Esses pontos são candidatos a automação.
  • Antes de adotar um protocolo ou plataforma de comunicação entre agentes, pergunte se ele guarda estado, entrega mensagens em ordem e permite ver quais ferramentas cada agente chamou.
  • Ao testar produtos como a BAND, exija que você consiga ler toda conversa entre seu agente e agentes de terceiros, como na demo de visibilidade e humano no loop.

Why AI Agents Should Have Their Own Sandbox

Se o agente roda num sandbox na nuvem, controlado por uma única chamada de API, você deixa de gerenciar infraestrutura e o laptop sai da equação.

Agentes 20:41 nível ●●●○○ Philipp Schmid, Google DeepMind Assistir no YouTube (abre em nova aba)

Em 3 frases

Philipp Schmid, do Google DeepMind, apresenta a Interactions API, que usa a mesma interface para chamar modelos Gemini e agentes, com estado guardado no servidor e tarefas longas em segundo plano.

O agente Antigravity na Gemini API roda num sandbox (ambiente isolado) gerenciado pelo Google, onde executa código, instala ferramentas, guarda arquivos e pode compartilhar o ambiente com outros agentes.

A demo AI Talk Radio mostra que o agente inteiro é um arquivo AGENTS.md mais skills (pacotes de instruções e scripts), e que levar isso do protótipo ao back end é copiar esses arquivos e criar o agente.

Antes de ler

Mais 2 termos

Mesma interface para modelo e agente

A Interactions API usa o mesmo formato de chamada para um modelo Gemini e para um agente. Você passa um modelo ou agente, uma entrada (texto ou multimodal) e ferramentas ou ambiente. O estado da conversa pode ficar no servidor: no turno seguinte você manda só o ID da interação anterior. Tarefas lentas, como gerar vídeo, rodam em segundo plano e você consulta depois.

Chamar modelo ou agente usa praticamente o mesmo código.03:51

De turnos user/model para uma linha do tempo de steps

Nas APIs tradicionais, o resultado de uma função volta num turno com papel de usuário, embora venha do ambiente. Schmid defende trocar os turnos por uma linha do tempo de steps (passos), em que cada ação ou geração tem seu próprio tipo. O resultado de função vira function result, e novos recursos entram sem remendos.

Cada ação do agente vira um step com tipo próprio.07:33

Cada agente ganha um sandbox gerenciado e persistente

No campo environment, a chamada pede um sandbox na nuvem. Ali o agente roda código, cria arquivos, instala dependências e chama APIs, sem que você cuide de infraestrutura. O ambiente persiste entre interações e pode ser compartilhado: vários agentes trabalham no mesmo sistema de arquivos ou subagentes retomam o trabalho de outro.

Uma chamada de API sobe um sandbox na nuvem para o agente.09:05
Mais 2 ideias deste talk

O agente é só arquivos

Na demo, o agente de rádio é um AGENTS.md com as instruções (pesquisar, escrever roteiro, gerar música e fala, mixar) e uma pasta de skills com scripts Python que chamam outros modelos Gemini. O AGENTS.md entra no system prompt (instrução de sistema) e as skills são detectadas sozinhas. Para levar ao back end, basta copiar os arquivos e criar o agente.

As instruções e as skills do agente cabem em arquivos de texto e Python.16:51

Agente empacotado a partir de um ambiente pronto

Com a Agents API, você define o modelo base, a instrução e o ambiente. Um agente pode montar o próprio ambiente (instalar o GitHub CLI, adicionar skills, rodar checagens) e devolver um ID de ambiente. Novos agentes partem desse ambiente pré-configurado, e você compartilha o agente com times ou clientes sem Terraform ou Kubernetes.

Um ID de ambiente vira ponto de partida reutilizável para outros agentes.11:39
leitura crítica

É uma apresentação de produto do Google, feita pelo time que o vende. Não há comparação de custo, latência, limites de uso ou segurança do sandbox com alternativas. As demos são curadas (o programa de rádio já estava gerado) e usam casos leves. O palestrante diz que agentes ficam rodando horas ou dias, mas não mostra um caso real assim. A crítica ao formato user/model também não vem com evidência de que steps melhoram resultados.

O que fazer com isso

  • Pegue uma chave grátis no AI Studio e rode a mesma chamada na Interactions API com um modelo e depois com o agente Antigravity, para ver a diferença na prática.
  • Se você já tem um AGENTS.md ou CLAUDE.md, teste-o num agente gerenciado e confira se as instruções e skills são carregadas sem ajuste.
  • Pergunte ao time de segurança o que o agente pode acessar antes de montar um sandbox com fontes como GitHub ou buckets: segredos, rede e arquivos entram no ambiente.
  • Peça ao agente, no playground, para explorar o ambiente onde roda (sistema, CPU, memória, linguagens) e baixe os arquivos gerados para avaliar o fluxo.

The 6 Pillars of an Agentic Harness for Production

Agente que opera produção precisa de um harness com seis pilares, porque modelo sozinho dá resposta coerente, e incidente exige causa comprovada.

Agentes 21:05 nível ●●●○○ Varun Krovvidi, Resolve AI Assistir no YouTube (abre em nova aba)

Em 3 frases

Varun Krovvidi, da Resolve AI, diz que IA foi bem em código, mas 70% do tempo de engenharia vai para rodar e consertar software em produção, onde há vários domínios e uma única resposta certa.

Ele lista cinco falhas de agentes em escala (viés de ancoragem, contexto demais ou de menos, coerência sem causalidade, falta de limites, falta de aprendizado) e seis pilares do harness para corrigi-las.

Uma demo mostra um alerta do Grafana virar causa raiz no Slack, com teorias descartadas (como uma queda do GCP) e o agente mantendo a resposta quando o usuário insiste.

Antes de ler

Mais 2 termos

Código é fácil para IA, produção não

O palestrante explica que código se documenta sozinho, é modular e vive em um único domínio, por isso existem benchmarks claros. Produção mistura código, infraestrutura, telemetria e várias equipes, e exige uma resposta correta. Ele chama essa distância de a última milha, a mais longa.

Por que a IA brilha em código e tropeça em produção.02:05

Cinco rachaduras quando o agente escala

Funciona bem no demo, mas aparecem problemas ao ampliar para mais casos e times: viés de ancoragem e a esteira de modelos novos, contexto excessivo (o modelo inventa hipóteses) ou escasso (explora pouco), resposta coerente sem causa, falta de guardrails e falta de aprendizado entre investigações.

As cinco falhas que o harness precisa resolver.07:14

Os seis pilares do harness

Orquestração de modelos (escolher o melhor modelo por tarefa), engenharia de contexto (a quantidade exata de contexto, em geral com várias técnicas), raciocínio causal, ações governadas (leitura ou escrita com limites), sistemas de aprendizado e evals. Os evals ficam no início e no fim da arquitetura.

Mapa dos seis pilares que sustentam o agente.11:58
Mais 2 ideias deste talk

Cadeia causal de evidências com confiança

A causa raiz só vale se houver uma cadeia de passos comprovados. Sem ela, o sistema informa confiança baixa e aponta outra direção. O palestrante diz que modelos tendem a concordar com quem os pressiona, e que o sistema foi desenhado para resistir a isso.

A causa raiz precisa de cadeia de evidências, não só de coerência.13:31

Demo: alerta, causa raiz e teorias descartadas

Um alerta do Grafana cai no Slack e o Resolve abre uma investigação sozinho. Ele cruza código, infraestrutura, bases de conhecimento e observabilidade, e rastreia o erro até integrações antigas. Também lista teorias descartadas, como uma queda do GCP no mesmo horário.

Demo mostra causa raiz e hipóteses rejeitadas lado a lado.18:12
leitura crítica

O talk é pitch de produto: o palestrante lidera marketing de produto da Resolve AI e termina chamando para o estande. Não há dado de desempenho, taxa de acerto, nem comparação com concorrentes. A demo é única, escolhida pela empresa, e não mostra falhas. A afirmação de que modelos concordam sob pressão e o sistema resiste não vem com teste. Os pilares são coerentes, mas servem de checklist, não de prova.

O que fazer com isso

  • Ao usar IA para investigar um problema, exija a cadeia de passos que levou à causa e peça também as hipóteses descartadas.
  • Peça à IA um nível de confiança e uma direção alternativa quando faltar evidência, em vez de aceitar uma resposta só coerente.
  • Defina o menor acesso possível para agentes (só leitura primeiro) e liste quando a escrita é permitida.
  • Monte um conjunto pequeno de casos de teste e rode-o sempre que trocar de modelo ou mudar o fluxo.

Every AI Company Is Accidentally Building a Bank

Produto de IA que cobra por uso precisa checar saldo antes da inferência e liquidar depois, como um caixa eletrônico.

Infraestrutura 20:08 nível ●●●○○ Dor Sasson, Stigg Assistir no YouTube (abre em nova aba)

Em 3 frases

Dor Sasson, CEO da Stigg, diz que as crises de preço de abril de 2026 em Anthropic, OpenAI e GitHub foram falhas de infraestrutura, porque o uso era checado só depois da fatura.

Ele propõe verificar permissões de forma síncrona antes de gastar tokens e conciliar o gasto de forma assíncrona depois, com ideias de banco: reserva e liquidação, partida dobrada, ordem de créditos e tetos de gasto.

O talk fecha com quatro padrões para vender IA em escala e pede um 'momento Stripe' para o setor, mas o palestrante vende justamente esse tipo de infraestrutura.

Antes de ler

Mais 2 termos

Checar antes, liquidar depois

Hoje muitos times registram o uso depois da inferência e só então conferem limite e cobrança. Sasson defende o caminho inverso: a checagem de direito de uso roda no caminho crítico da requisição, e o acerto de contas acontece depois, de forma assíncrona. Ele compara com o caixa eletrônico, que valida o saque antes de entregar o dinheiro.

Diagrama mostra a checagem movida para antes da inferência.06:27

Crises de preço eram problema de infraestrutura

Em abril, a Anthropic cortou agentes de terceiros como o OpenClaw dos planos de assinatura, a OpenAI mudou o preço do tier Pro e o GitHub encerrou o acesso gratuito ao Copilot. Para o palestrante, a causa comum foi não conseguir separar quem usa API de quem usa assinatura, nem limitar o gasto antes da fatura.

Os três casos citados como emergências de preço em um único mês.01:44

Três traços da arquitetura da OpenAI

Sasson cita um texto da equipe de financial engineering da OpenAI, de fevereiro. Ele extrai três pontos: a avaliação é única e síncrona, a prioridade é determinística (as regras são conhecidas de antemão) e o sistema é financeiro, não só de cobrança, porque decide antes de qualquer fatura.

Mostra a ordem de decisões avaliadas a cada requisição.08:35
Mais 2 ideias deste talk

Concorrência e origem dos créditos

Se 10 mil agentes puxam do mesmo saldo ao mesmo tempo, o saldo visível engana e ocorre gasto duplicado (double spend). Bancos resolvem com reserva (hold), liquidação, idempotência e partida dobrada. Créditos também vêm de fontes diferentes, e é preciso definir qual é consumido primeiro, em vez de usar um único inteiro no banco.

Ilustra o risco de vários consumidores sobre o mesmo saldo.10:40

Quatro padrões para vender IA em escala

Os padrões são: reservar antes da inferência e liquidar o real depois; manter o medidor e o ledger (livro-razão) dentro da própria VPC; checar saldo durante o trabalho de agentes, cujo custo não se conhece de antemão; e dar visibilidade de gasto por modelo, equipe, usuário e agente para CFO e CIO.

Resume os quatro padrões que o palestrante vê se repetirem.14:51
leitura crítica

O talk é pitch da Stigg, que vende essa infraestrutura, e o fecho convida o público ao estande. Os números sobre a Anthropic (150 a 750 de subsídio, sem unidade clara) e os casos de empresa não identificada e Uber vêm sem fonte no vídeo. A tese do 'banco' é uma analogia útil, mas não há dados mostrando que a abordagem evita as crises citadas. A descrição do artigo da OpenAI é resumida pelo palestrante, sem exibir o texto.

O que fazer com isso

  • Cheque limite e saldo antes de cada chamada ao modelo no seu produto ou automação, e registre o consumo real depois.
  • Para agentes cujo custo é imprevisível, reserve um orçamento por tarefa e concilie o gasto real ao final.
  • Defina tetos de gasto por equipe, usuário e agente nas contas de API que sua empresa usa, para um grupo pequeno não esgotar o contrato inteiro.
  • Defina a ordem de consumo dos créditos (promocionais antes dos comprados, por exemplo) e documente a regra.

Move Fast and Don't Break Things: Scaling Databases for the AI Era

Bancos de dados aguentam o tráfego de agentes com isolamento, sharding e back pressure, e boa experiência de desenvolvedor vira boa interface para IA.

Infraestrutura 19:06 nível ●●●○○ PlanetScale Assistir no YouTube (abre em nova aba)

Em 3 frases

Ben Dicken, da PlanetScale, defende que dá para entregar rápido sem derrubar o banco, se o sistema tiver isolamento, redundância, sharding, back pressure e componentes desacoplados.

Agentes de IA multiplicam o tráfego e também podem operar a infraestrutura: eles desenham um esquema de sharding a partir de um arquivo JSON e mudam o schema por meio de branches e deploy requests.

A conclusão é que ferramentas feitas para desenvolvedores humanos, como CLI, API, branching e revert com um clique, servem como primitivas seguras para agentes.

Antes de ler

Mais 2 termos

Isolamento limita o estrago de um deploy ruim

O data plane (onde moram os dados críticos) fica separado de control plane, observabilidade, analytics, apps e MCPs. Esses outros componentes recebem deploys com mais frequência e falham mais. Um deploy ruim no control plane não pode impedir o acesso ao banco.

Cada componente falha sozinho sem derrubar o data plane.03:53

Em escala, falha rara vira rotina semanal

Com um servidor de banco, uma falha acontece a cada alguns anos. Com milhares de servidores, vira falha semanal ou mensal. Por isso o padrão é ter um nó primário e réplicas em outros data centers ou zonas de disponibilidade, prontas para assumir.

Primário com réplicas em standby cobre a falha inevitável de servidores.04:55

Sharding espalha dados, e cada shard ainda tem réplicas

Um único nó funciona com 10 GB, mas não com terabytes. O sharding divide dados e consultas entre vários servidores, atrás de um proxy (VTGate). Cada shard mantém primário e réplicas, então se recupera sozinho. A PlanetScale usa Vitess para MySQL e Neki para Postgres.

Proxy distribui as consultas entre shards redundantes.07:30
Mais 2 ideias deste talk

VSchema em JSON deixa o agente propor o sharding

O Vitess é complexo por dentro, mas a configuração de sharding é um arquivo JSON chamado VSchema, no qual se define a coluna de shard e o método. Como agentes lidam bem com texto e JSON, o desenvolvedor passa o schema do banco e pede um protótipo de VSchema. Depois a plataforma aplica via deploy, API ou CLI.

A interface de sharding é um JSON simples que o agente consegue escrever.13:05

Traffic Control aplica back pressure por orçamento

O recurso Traffic Control etiqueta o tráfego que chega ao banco e define orçamentos de recursos (CPU, processos de backend) por segmento. Ao estourar o orçamento, o sistema avisa o cliente ou mata as consultas. Perde-se parte do tráfego, mas a aplicação inteira não cai.

O gráfico mostra o tráfego acima do orçamento sendo sinalizado em vez de derrubar o banco.15:09
analogia

Vitess e VSchema (Sistema de sharding para MySQL e seu arquivo JSON de configuração). Vitess com VSchema é como uma agência dos correios que separa as cartas por CEP, seguindo uma tabela simples que diz qual carteiro atende cada bairro.

  1. Quando um banco de dados fica grande demais para um só computador, você divide os dados entre vários servidores. Cada pedaço se chama shard (fatia).
  2. O Vitess é um software livre (open source) que faz essa divisão para o MySQL, um banco de dados muito usado. Cada shard continua sendo um banco MySQL comum.
  3. Na frente das fatias fica o VTGate, um intermediário (proxy). Ele lê cada consulta SQL, descobre em qual shard está o dado e encaminha o pedido para lá.
  4. Para dizer como dividir, você escreve o VSchema, um arquivo JSON (texto organizado em campos e valores). Nele você escolhe a coluna que define a fatia, o método de divisão e quais tabelas ficam em quais shards.
  5. Agentes de IA lidam bem com JSON. Você entrega o schema (a estrutura das tabelas) e pede um rascunho de VSchema. Depois a plataforma aplica a mudança por deploy, API ou linha de comando (CLI).
APP ENVIA CONSULTAPedido SQL chega ao VTGate
VTGATE LÊ O VSCHEMAAcha a coluna e o método de shard
ROTA PARA O SHARDEnvia só para a fatia certa
RESPOSTA AO APPDado volta sem o app ver a divisão

Ajuda saber antes: Sharding, Banco de dados relacional, JSON, Proxy

leitura crítica

É um pitch de produto da PlanetScale, que vende Vitess, Neki, Traffic Control e branching. Não há medição própria nem estudo de caso com dados. O palestrante cita o aumento de 2x a 4x de tráfego do GitHub por agentes de memória, sem fonte. Cursor aparece como cliente, sem detalhes. A parte de agentes projetando shards é afirmada, não demonstrada. Revert sem perda de dados é uma promessa de marketing sem condições descritas.

O que fazer com isso

  • Liste os componentes do seu sistema e cheque se o deploy de um deles (painel interno, analytics, MCP) pode derrubar o acesso ao banco.
  • Defina o que acontece quando o banco passa do limite de CPU ou conexões. Se a resposta é cair, desenhe uma regra de recusa de parte do tráfego.
  • Antes de deixar um agente alterar o banco, exija um fluxo com branch de schema, revisão humana e reversão pronta.
  • Ao desenhar ferramentas para agentes, exponha configuração em arquivos simples (JSON) e comandos de CLI ou API que eles consigam usar.

Is Speculative Decoding Worth It? Profiling vLLM on NVIDIA Blackwell

Speculative decoding acelera a geração quando sobra memória na GPU, o lote é pequeno e a saída é previsível, como JSON ou código.

Infraestrutura 15:17 nível ●●●○○ Akamai Assistir no YouTube (abre em nova aba)

Em 3 frases

Um modelo pequeno (draft model) chuta de 3 a 5 tokens e o modelo grande confere todos em uma única passada, então a resposta final sai igual e mais rápida.

Na demo com vLLM em uma GPU NVIDIA Blackwell, a saída estruturada ficou 1,6 vez mais rápida com alta taxa de aceitação, e a escrita criativa teve aceitação bem menor.

O ganho cai quando a GPU já está cheia de requisições, quando o prompt é longo (como em RAG) ou quando o texto pede variedade.

Antes de ler

Mais 2 termos

Um modelo pequeno chuta, o grande confere

A inferência tem duas fases. No prefill o modelo lê o prompt e monta o KV cache uma única vez. No decode ele escreve um token por vez, e cada token custa uma passada (forward pass) no modelo grande. Com speculative decoding (decodificação especulativa), um modelo menor propõe de 3 a 5 tokens por ciclo. O modelo alvo aprova ou rejeita todos em uma passada e recalcula os rejeitados. Por isso a qualidade da saída continua a do modelo grande.

O modelo alvo verifica vários tokens propostos em uma única passada02:17

O custo é memória para dois modelos

Você hospeda dois modelos e precisa de espaço para o KV cache dos dois. Na demo, o modelo base ocupou cerca de 16 GB de pesos e o draft model 2,5 GB, o que deixou espaço para cache. A palestrante recomenda um draft model de 10 a 50 vezes menor que o alvo, com o mesmo tokenizer e de preferência da mesma família de modelos.

Pesos de 16 GB mais 2,5 GB ainda deixam espaço para KV cache04:28

Saída estruturada ganha 1,6 vez de velocidade

A demo roda as duas configurações lado a lado no vLLM. Na tarefa de saída estruturada, a versão especulativa gerou 1,6 vez mais rápido e produziu mais tokens por segundo (throughput, vazão). A métrica que explica o ganho é a taxa de aceitação: tokens aceitos pelo modelo alvo divididos pelo total proposto pelo draft model.

09:22 Com saída estruturada, o modo especulativo termina 1,6 vez mais rápido

Mais 2 ideias deste talk

Texto criativo derruba a taxa de aceitação

Na aba de escrita criativa, com temperatura alta, a taxa de aceitação cai bastante. Quanto mais variado o próximo token, menos o modelo pequeno acerta o que o grande escreveria. Poesia e brainstorming ganham pouco. Código, JSON e SQL ganham mais.

10:05 Em tarefa criativa o draft model erra mais e o ganho encolhe

Checklist antes de ligar

Speculative decoding acelera só o decode. Em RAG ou análise de documentos longos, o tempo vai quase todo para o prefill, então o ganho é pequeno. O slide final resume quatro perguntas: a saída é estruturada, sobra VRAM, o contexto é curto e os lotes são pequenos? Com alta concorrência, a GPU já está ocupada e a técnica atrapalha mais do que ajuda.

12:02 Quatro critérios dizem se vale ativar a técnica

leitura crítica

A demo mede uma única execução de cada tarefa, sem repetição nem variância, e não diz quais modelos foram usados como alvo e rascunho. A taxa de aceitação da tarefa criativa aparece na tela, mas não é dita em voz. Os limites para contexto longo e alta concorrência são afirmados sem medição. A palestrante trabalha na Akamai e fecha o talk divulgando o GitHub e serviços da empresa, então parte do conteúdo funciona como divulgação. Ela mesma diz que há pouco material público sobre o tema.

O que fazer com isso

  • Se você serve um modelo próprio no vLLM com GPU ociosa, teste speculative decoding nas tarefas que geram JSON, SQL ou código e compare tokens por segundo.
  • Escolha um draft model da mesma família do modelo principal, com o mesmo tokenizer e de 10 a 50 vezes menor.
  • Acompanhe a taxa de aceitação por tipo de tarefa e desligue a técnica onde ela ficar baixa, como em texto criativo com temperatura alta.
  • Em fluxos de RAG com prompts longos, meça primeiro quanto tempo vai para o prefill antes de esperar ganho dessa técnica.

Fim da edição

Termos novos no glossário: Async handle, Exploit validation, Multi-tenancy, Vitess e VSchema, Mutation testing.