O sinal
da feira.

A grande ideia: um agente de IA é um modelo de raciocínio congelado mais um harness: a memória, as ferramentas, o conhecimento semântico e a percepção que você envolve ao redor dele. Você aluga o modelo e não pode controlar suas saídas não determinísticas; o harness é a parte que você engenheira para transformar a aleatoriedade de mesma-entrada-saída-diferente em resultados confiáveis e repetíveis.

Por que importa: para 99,9% das equipes, mudar os pesos do modelo está fora de cogitação, e enfiar janelas de contexto cada vez maiores sai pela culatra: a atenção escala de forma quadrática, então contextos lotados degradam em context rot. A verdadeira alavanca está na engenharia de memória: esquemas, políticas de ciclo de vida, recuperação e governança tratados como uma disciplina formal em vez de algo deixado para depois.

Como funciona: a memória se divide em curto prazo (o contexto de trabalho), longo prazo (memória episódica, procedural, semântica e de toolbox) e memória compartilhada entre agentes que colaboram. Sobre armazenamento, Martinez rejeita a briga arquivos-contra-bancos-de-dados: arquivos são fáceis por serem POSIX, mas não têm consistência transacional, então ele propõe um híbrido: memória de curto prazo em arquivos, promovida para um banco de dados ACID via Oracle DBFS. O pacote OAMP da Oracle então comprime toda a manutenção numa única chamada: context_card devolve um bloco delimitado e pronto para o prompt com tópicos, um resumo em andamento, fatos e preferências relevantes, e mensagens recentes.

O que roubar: o padrão skillbox. Destile os fluxos de trabalho que se provaram confiáveis em artefatos SKILL.md versionados e armazenados com embeddings, aposente a receita crua e use recuperação em dois níveis: um manifesto enxuto a cada turno, o corpo completo da skill só quando o agente o invoca. O padrão irmão toolbox faz busca vetorial de esquemas de ferramentas por turno para que só as ferramentas relevantes cheguem à janela de contexto. Ambos entregam aprendizado contínuo no espaço de tokens, sem retreinamento.

A ressalva: este é um workshop de patrocinador, e as respostas convergem para a Oracle: o banco de dados convergente, o DBFS, os embeddings dentro do banco e o OCI Generative AI como um open router empresarial para modelos do Google, Meta, OpenAI e xAI. Os padrões generalizam; o tooling pronto para uso pressupõe que você compre o stack da Oracle.

A grande ideia: a AWS conduziu um speedrun prático para construir agentes de produção sobre trilhos open-source. O Strands Agents, um harness construído pela AWS e mantido pela comunidade com suporte a MCP, cuida do loop do agente, e o Amazon Bedrock AgentCore leva o resultado do protótipo em notebook para a produção serverless.

Por que importa: o argumento central do workshop é o determinismo. Prompts são sugestões probabilísticas, enquanto hooks, skills e handlers de steering são código, e código é aplicável. Essa é a diferença entre um chatbot de demonstração e um agente de atendimento ao cliente em que você pode confiar para fazer reembolsos.

Como funciona: sete módulos constroem um único bot de atendimento ao cliente. O Módulo 1 conecta o loop do agente: entrada, raciocínio do LLM, seleção de ferramentas via funções decoradas com @tool como lookup_customer e get_order_history, e então uma resposta fundamentada. Os hooks interceptam antes ou depois da invocação, das chamadas ao LLM e das chamadas de ferramentas para validar entradas, bloquear dados sensíveis ou aplicar limites de taxa. As skills carregam arquivos de conhecimento em markdown só quando uma consulta os exige. Os handlers de steering adicionam um agente parceiro em cada checkpoint para fazer cumprir o formato e o tom, e o AgentCore Runtime então faz o deploy de tudo numa única ação.

O que roubar: o padrão RateLimiterHook, um callback do HookRegistry que zera um contador por requisição e para em seco um agente que enlouquece em loop nas chamadas de ferramentas antes que ele queime tokens. Também a jogada do Agent Control: mantenha as regras de steering num banco de dados que o motor lê na invocação, de modo que uma nova regra de negócio (bloquear reservas de mais de cinco pessoas) nunca toque o código do motor.

Os números: sete módulos em 2 a 3 horas, provisionados para cerca de 250 participantes com links do workshop válidos por 2 a 3 dias. As sessões do AgentCore rodam de 15 minutos a duas horas em micro-VMs isoladas, a memória de longo prazo persiste além de oito horas, e o limitador de taxa da demo limita as chamadas de ferramentas a três por requisição.

A ressalva: o Wi-Fi do local caiu, forçando uma explicação passo a passo no palco e links reserva. As contas temporárias do Workshop Studio são efêmeras (mantenha dados confidenciais fora), e o hook da demo bloqueia as chamadas de ferramentas sem encerrar o turno do agente, então você precisa projetar sua própria parada em seco ou o loop continua repetindo.

A grande ideia: a engenharia de IA existe porque os agentes são não determinísticos: o sistema pode parecer perfeitamente saudável enquanto cada resposta está errada ou apenas medíocre. A resposta do Langfuse é um loop: trace e monitore online, construa datasets e rode experimentos offline, e só faça o deploy quando os resultados melhoram sem regressões.

Por que importa: uma vez que um app escala, ninguém consegue ler cada conversa. Dashboards agregados, feedback de usuários e avaliadores automáticos existem para trazer à tona as cinco ou seis falhas genuinamente complicadas escondidas entre 500 perguntas rotineiras, e para direcionar a atenção humana para lá.

Como funciona: o veículo prático é o "Specs", um agente de suporte técnico estilo pai: um app em TypeScript sobre o OpenAI Node SDK chamando o GPT-4o, com ferramentas para contexto do dispositivo e uma busca na biblioteca de ajuda. Cada turno do usuário vira um trace: uma observação raiz do agente com chamadas aninhadas de ferramentas e de modelo carregando custo, latência, tokens e versão do prompt. Os participantes conectam três avaliadores ao vivo: um LLM-as-judge que sinaliza a discordância do usuário ("esse botão não está aí"), um detector de caixa alta baseado em regras para frustração na última mensagem do usuário, e uma verificação de fora-de-escopo que compara o system prompt com a requisição. Mapeamentos de caminhos JSON miram cada avaliador exatamente na fatia do trace de que ele precisa.

O que roubar: não copie e cole templates de avaliadores. Projete os monitores em torno de como o seu app específico falha. Versione seus datasets e as configurações dos avaliadores, calibre os avaliadores LLM-as-judge contra julgamentos humanos para que as pontuações continuem sendo sinal em vez de ruído, e instale a skill da CLI do Langfuse para que um agente de codificação possa consultar traces, pontuações e datasets diretamente.

Os números: apontado para cerca de 120 traces parecidos com produção vindos de 70 casos de teste, o relatório em Markdown do agente de codificação trouxe à tona uma ferramenta search_help_library falhando em silêncio ao devolver candidatos ruidosos, falhas de recuperação correlacionadas com o custo, lacunas de cobertura de avaliadores ao longo do tráfego, e desalinhamento de versões de prompt, e então propôs correções conscientes do repositório.

A ressalva: o Langfuse fica fora do caminho crítico: ele analisa sinais depois dos fatos e se integra com frameworks de guarda-corpos separados se você precisar bloquear requisições de vez. E os avaliadores automáticos, por mais escaláveis que sejam, deixam passar os modos de falha inéditos que você nunca antecipou; o feedback humano e a anotação permanecem no loop exatamente por essa razão.

A grande ideia: a superfície de agentes da Anthropic evoluiu em três passos. A Messages API era tokens de entrada, tokens de saída. O Claude Agent SDK empacotou o harness do Claude Code, mas deixou a hospedagem, o escalonamento e os segredos no seu colo. O Claude Managed Agents move todo esse stack de produção para a nuvem da Anthropic, de modo que as equipes só são donas do seu produto, da sua tarefa e do seu contexto.

Por que importa: os harnesses codificam suposições sobre o que um modelo não consegue fazer, e essas suposições apodrecem rápido. A equipe construiu contornos de reset de contexto para a "ansiedade de contexto" do Sonnet 4.5. Então o Opus 4.5 chegou sem esse comportamento, e as correções viraram puro peso morto que degradava o agente. Um harness rígido construído em torno do modelo do ano passado pode levar semanas ou meses para migrar, tornando o harness o gargalo da capacidade de fronteira.

Como funciona: a arquitetura desacopla o cérebro (um loop de agente persistente na nuvem) das mãos (sandboxes criados sob demanda para acesso a arquivos e execução de código). Três primitivas compõem tudo: Agent (modelo, prompts, ferramentas, skills), Environment (a definição do contêiner) e Session (um recurso durável na nuvem). Cada evento aterrissa num log de sessão, então um sandbox morto é substituído e reexecutado, um loop caído relê o log e retoma, e o harness pode puxar de volta fatias de contexto passado para a janela em vez de perder os turnos descartados.

Os números: desacoplar o raciocínio da inicialização do contêiner cortou o time-to-first-token em 60% no p50 e mais de 90% no p95. Na demonstração ao vivo, um agente SRE Investigator rastreou um pico de p99 no checkout de 298 ms para 3.120 ms (erros de 0,3% para 14,2%) através de 1.204 timeouts upstream e quatro deploys recentes até o commit a3f9c21, que havia removido um decorador de cache e disparado consultas N+1 ao banco de dados, e então recomendou o rollback.

O que roubar: mantenha as credenciais num vault e decripte-as só no runtime de execução de ferramentas, de modo que o modelo nunca veja um token. Nunca bloqueie o raciocínio na inicialização do contêiner: rode a configuração em paralelo ou pule-a. Exponha os logs de sessão tanto como transparência voltada ao usuário quanto como traces de engenharia. Então feche o loop: o Dreaming processa em lote transcrições e memória para sessões futuras mais inteligentes, e o Outcomes roda um agente avaliador contra a sua rubrica, repetindo até que o trabalho realmente passe.

A ressalva: a proposta pressupõe que você entrega o harness à Anthropic: o cérebro vive na nuvem deles. Para empresas atentas à segurança, as saídas de emergência são os sandboxes auto-hospedados, que mantêm a execução de ferramentas dentro da sua própria VPC sob as suas políticas, e os túneis MCP, que deixam os servidores MCP permanecerem numa rede privada e se conectarem só para fora.

A grande ideia: enviar IA na base da intuição (rode três consultas, acene, faça o deploy) desmorona porque a saída do LLM é não determinística e os testes unitários não têm uma string esperada contra a qual afirmar. O modelo mental de substituição de Voss: os traces são logs para a IA, as evals são testes para a IA, e juntos transformam a qualidade do agente em um número que você pode rastrear, comparar e usar como portão no CI.

Por que importa: os agentes multiplicam a superfície de falha. Cada chamada de ferramenta e cada decisão é uma nova chance de descarrilar, e os erros se propagam em silêncio: seu agente de demo perguntou sobre a Tesla montadora de carros, recuperou o inventor do século XVIII e escreveu um relatório bonito e confiantemente errado em que nenhum passo isolado estava incorreto. Sem evals você joga acerte-a-toupeira: uma correção de tom dispara alucinações em outro lugar, e trocar de modelo significa semanas de reteste manual em vez de horas.

Como funciona: Voss construiu o ciclo ao vivo: um agente de análise financeira sobre o Claude Agent SDK, instrumentado no Arize AX com duas linhas de código de OpenTelemetry/OpenInference. Depois o passo que a maioria dos tutoriais pula: leia os traces e categorize as falhas à mão (codificação aberta, depois codificação axial) antes de escrever uma única eval. Só então empilhe defesas no estilo queijo suíço: evals de código determinísticas para verificações baratas como se-o-ticker-apareceu, juízes LLM integrados em seguida, e uma rubrica de acionabilidade personalizada com um papel de juiz definido, critérios observáveis, dados marcados em XML e opções binárias definidas externamente.

O que copiar: prefira a fidelidade à correção para agentes de dados ao vivo. Seu juiz de correção deu nota zero a cada relatório porque não podia conhecer fatos de 2026, enquanto a fidelidade deu ao juiz as mesmas fontes que o agente usou. Avalie o resultado, não o caminho: o agente de tau-bench da Anthropic fez upgrade legal de uma passagem econômica para primeira classe a fim de remarcá-la e foi marcado como errado. Construa um avaliador por dimensão, nunca uma eval-Deus, e meta-avalie os juízes contra um dataset dourado rotulado por humanos e dividido em dev e test. Depois feche o ciclo: alimente as explicações do juiz ao Claude Code, deixe-o reescrever os prompts e verifique com experimentos controlados.

Os números: duas linhas de código para instrumentar. A fidelidade sinalizou 7 de 13 relatórios de demo como não fundamentados; uma reescrita de prompt guiada por explicações levou o conjunto de falhas de cerca de metade errada para 100% passando. De 12 a 20 exemplos dão um sinal direcional, mas mire entre 200 e 400 antes de decisões de envio. Os anotadores humanos deixam passar até 50% dos defeitos por fadiga, e a confiabilidade entre avaliadores especialistas pode ficar em 0,2 a 0,3, então um juiz que às vezes discorda de você não está quebrado.

O porém: os juízes LLM carregam viés de posição, comprimento, confiança e autorreferência (use um modelo diferente para julgar e para gerar), e os prompts de eval são tão frágeis quanto o código da aplicação, então precisam do próprio ciclo de teste e iteração. Automatizar antes de entender suas falhas só constrói métricas para o que é fácil de medir em vez do que realmente importa.

A grande ideia: os agentes estão engolindo a implementação, então a definição de engenharia muda de "conseguimos construir?" para "vale a pena construir?". Dodds, que passou uma década vendendo cursos de React e de testing, abre admitindo que o próprio produto está obsoleto: engenheiros experientes não precisam mais de um curso de framework quando um agente cuida da sintaxe. O que sobrevive, ele argumenta, é o julgamento. Sua metáfora do tiro com arco: os agentes transformaram todo mundo em atirador certeiro, então o diferencial não é mais acertar o alvo, é escolher qual alvo importa.

Por que importa: um engenheiro que só transforma tickets em implementações parece um time de agência intercambiável, e Dodds diz sem rodeios que engenheiros sem senso de produto ou de design serão fáceis de substituir conforme os agentes melhoram. Enquanto isso os agentes amplificam o desleixo: eles não vão resistir ao scope creep, então os produtos se degradam em silêncio a menos que os humanos permaneçam intencionais sobre o que é adicionado.

Como funciona: o engenheiro de produto conecta o entendimento do cliente às escolhas técnicas, decidindo modelos de dados, o formato do fluxo de trabalho, a observabilidade, os modos de falha e pequenas fatias com contexto rio acima. Isso significa viver metade na tecnologia e metade no mundo do cliente, questionar os protótipos feitos com vibe coding e reimplementá-los com verdadeiro pensamento de sistemas. A propriedade é a função forçosa: um engenheiro que espera o chamado às 2h da manhã projeta com muito mais cuidado, e escolher as primitivas erradas cedo torna até as ótimas soluções caras de desfazer.

O que roubar: o exercício de entrevista do The Mom Test, rodado ao vivo sobre um app votado pela plateia para pular as filas dos workshops da conferência. Nunca pergunte "você usaria isso?": as pessoas escapam da conversa te elogiando. Pergunte em vez disso sobre a última vez que o problema aconteceu, o que fizeram no lugar e quanto custou o contorno. Usuários que já gastam tempo ou dinheiro em um contorno valem ouro; usuários que não conseguem lembrar do problema são um não educado.

Os números: um time imobiliário australiano gastou 1,2 milhão de dólares australianos (quase 900 mil dólares americanos, pela própria conversão de Dodds) e um ano inteiro construindo uma plataforma dimensionada para cada australiano fazer login ao mesmo tempo. Zero pessoas usaram. Um teste manual de duas semanas teria respondido a pergunta primeiro. Mesma lição na história do Burbn: o Instagram surgiu ao descartar tudo exceto a única funcionalidade que os usuários de fato tocavam, o compartilhamento de fotos.

A pegadinha: a velocidade agora corta nos dois sentidos. Você pode construir a coisa errada incrivelmente rápido e se sentir enormemente produtivo fazendo isso, e as camadas de superfície que parecem funcionais escondem casos de borda faltantes e um miolo que não escala. Os agentes também não vão te avisar; o trabalho humano é ir mais devagar, colocar guarda-corpos como testes e critérios de aceitação, e construir um playground onde os colegas agentes possam ter sucesso com segurança.

A grande ideia: o prompt caching reescreve as regras da engenharia de contexto. Os provedores reaproveitam o KV cache pré-computado, então reenviar uma conversa inteira custa uma fração dos tokens novos, enquanto qualquer summarization ou compactação transforma o contexto, invalida o cache e força um recálculo a preço cheio. Para vencer o desconto, a compressão precisa superar cerca de 50x, o que é difícil sem destruir o detalhe.

Por que importa: a maioria dos stacks de agentes resume por padrão, e o tutor de IA em produção da Towards AI também fazia isso: limpar as saídas das ferramentas passados 5.000 tokens, resumir passados 30.000. Esses padrões não comprovados perderam feio para uma linha de base simples de histórico completo: limpar as saídas das ferramentas só forçava o agente a recuperar de novo informação que já tinha, somando chamadas de ferramentas, tokens e custo.

Como funciona: o tutor é um simples loop ReAct construído com middleware do LangChain sobre um corpus de 8 bilhões de tokens de lições de cursos e documentação de bibliotecas. A recuperação é híbrida (embeddings da Cohere mais BM25, mesclados e reordenados aos cinco melhores trechos) ao lado de uma ferramenta bash em sandbox que navega por um wiki da base de conhecimento gerado com o Claude Code. O time construiu um harness de evals com 60 pares reais de perguntas e respostas de estudantes e sessões multiturno semeadas com fatos enterrados, avaliados por checagens de código e LLM-as-judge, e então rodou 11 presets mantendo fixos o modelo, o prompt e as ferramentas.

Os números: no Gemini 3.5 Flash, o histórico completo atingiu 100% de recall nos fatos enterrados contra 38% dos padrões de produção, e foi mais barato e mais rápido. No DeepSeek, onde o desconto do cache chega a cerca de 50x, o preset que enviava mais tokens foi o mais barato de rodar: 97% de tokens em cache, 95% de recall contra 32% após a summarization. A busca semântica densa despencou para 0% de recall por volta dos 400k tokens, enquanto o BM25 se manteve em 100%. A recuperação de fatos distintos permaneceu sólida até cerca de 800k tokens, e só a primeira rodada de experimentos custou mais de $500.

O que roubar: não compacte por padrão: nomeie a restrição que você realmente tem e então escolha a técnica. Sempre teste uma linha de base de não-fazer-nada com histórico completo antes de qualquer coisa engenhosa. Use busca híbrida, não puramente semântica. Construa skills pequenos e precisos que se referenciem entre si e carreguem de forma progressiva. E registre tudo (taxa de acerto do cache, custo, latência, tempo até o primeiro token) com OpenTelemetry para que as decisões venham de dados, não de vibes.

A pegadinha: o histórico completo para de vencer quando o hardware limita a janela. Os modelos locais bateram no teto de um contexto de 32k no banco de testes MacBook, os benefícios do caching quebraram e o recall em conversas longas caiu para cerca de 33%, embora o RAG local sobre documentos colados tenha pontuado 100%. E a ferramenta de navegação de arquivos que parecia esperta foi 50% mais lenta sem ganho de qualidade nas perguntas reais dos estudantes.

A grande ideia: a geração de código de IA pessoal quebra a infraestrutura de nuvem tradicional. Kenton Varda, que criou o Cloudflare Workers em 2017 e ainda o lidera, diz que o modelo de uma-única-versão-abençoada-do-app-no-servidor-do-desenvolvedor que definiu 25 anos de arquitetura web não consegue sustentar um futuro em que o agente de IA de cada usuário personaliza os apps só para ele.

Por que importa: o pipeline da torre de marfim falha com todo mundo. Os usuários abrem pedidos de funcionalidades que os product managers enterram no Jira, os desenvolvedores se esgotam adicionando if-statements de nicho, e então somem numa reescrita de sistema de plugins que dura anos enquanto os usuários concluem que o produto foi abandonado. No mobile é pior: Varda brinca que, depois de 15 anos de controle da Apple e do Google, é quase mais fácil comprar uma arma nos EUA do que instalar software não assinado no seu próprio celular.

Como funciona: o Fungy, seu projeto paralelo construído sobre o Cloudflare Workers, parece o Google Docs, mas gerencia "gadgets" em vez de documentos, cada um uma instância de app de propósito único com seu próprio código, como um gadget por apresentação de slides. Os blueprints permitem que os usuários compartilhem o código do gadget sem os dados. Como cada gadget mapeia exatamente para uma coisa compartilhável, a plataforma (não o app) faz cumprir o compartilhamento e o controle de acesso. Cada gadget se integra com agentes de IA: na sua demo, o Claude construiu os slides da conferência a partir de um Google Doc e, ao saber que podia estender o próprio app, adicionou tachado, centralização e inserção de SVG arbitrário, e então gerou um diagrama como SVG.

O que roubar: a arquitetura de segurança. A UI feita com vibe coding roda num iframe sandbox de origem nula sob uma CSP estrita que bloqueia cookies e rede de saída; seu único canal é postMessage para uma sessão de Web RPC do Cap'n Proto encaminhada ao código de servidor do gadget, um Durable Object rodando num sandbox de worker dinâmico igualmente isolado. O cliente e o servidor só podem falar entre si, então um bug de XSS em código gerado por IA não tem nada para vazar: nenhum bug de segurança no código do gadget importa.

Os números: o Workers atende milhões de desenvolvedores e trilhões de requisições por dia, e no entanto toda a demo de 18 minutos rodou localmente no laptop dele via workerd, o runtime open-source do Workers, sem contêineres, sem banco de dados tradicional, apenas workers dinâmicos e Durable Objects, e é por isso que a internet caída do local não importou.

A ressalva: a liberação open-source prometida não aconteceu. O entusiasmo interno tornou o projeto paralelo sério, e dias antes da palestra um colega da Cloudflare argumentou contra jogá-lo direto no GitHub em favor de um lançamento disciplinado. O código do Fungy chega "em breve": por enquanto você pode auto-hospedar o workerd, mas não a plataforma.

A grande ideia: as fábricas de software agênticas que eliminam a revisão de código humana fracassam, porque os modelos de codificação são treinados para fazer os testes passarem, não para manter uma base de código manutenível. Nenhuma quantidade de engenharia de harness ou de maximização de tokens consegue remendar o que é, no fundo, um problema de treinamento do modelo.

Por que importa: as rachaduras já são visíveis. Desde que as equipes adotaram amplamente as ferramentas de codificação de IA, um relatório do setor constatou que a qualidade da revisão de PRs caía, centenas de PRs eram publicados sem revisão nenhuma, e os incidentes e bugs por desenvolvedor subiam. Horthy fez ele mesmo o experimento sem supervisão em julho de 2025: os agentes esbarraram em problemas que não conseguiam resolver, sua equipe teve que voltar a fuçar em código que ninguém tinha lido em meses, e os usuários engoliram a indisponibilidade.

Como funciona: o RL de codificação se parece com o SWE-bench: tarefas de cerca de 15 minutos em repos open-source com recompensas binárias por consertar o problema alvo sem quebrar outros testes. Nada nesse loop penaliza blocos try/catch gratuitos, hacks de cast de tipos ou design de cirurgia de espingarda. Pior, o custo da arquitetura ruim aparece meses ou anos depois, tarde demais para propagar um sinal de recompensa de volta ao episódio de codificação que o causou. Os laboratórios que fazem RL de um modelo dentro do mesmo harness que publicam (a cartilha do Claude Code) dominam os construtores de só-harness, que é exatamente por isso que o harness sozinho não consegue te salvar.

O que roubar: acenda as luzes de novo. As tarefas pequenas continuam indo direto para os agentes, mas o trabalho maior recebe estrutura antecipada: uma revisão de produto que crava o problema, o comportamento e os mockups; uma arquitetura de sistema com contratos de componentes, modelos de dados e restrições; um design de programa que especifica as camadas de abstração e os grafos de chamadas; e então fatias verticais que sequenciam a implementação pelos repos. Os humanos ainda leem cada linha. A IA só comprime o planejamento e o alinhamento.

Os números: cerca de 30 minutos de planejamento prévio podem economizar horas de revisão. O primeiro agente de codificação de CLI treinado por um laboratório cavalgou essa vantagem de harness+pesos de zero a 4 bilhões de dólares (agora cerca de 9 bilhões) de receita em menos de um ano. E mesmo 20% de retrabalho de PRs, generoso para código gerado por IA, é um imposto emocional e intelectual tanto para o revisor quanto para quem submete.

A ressalva: verificadores melhores estão a caminho: tarefas de benchmark de 400 horas, evals sobre repos fora do conjunto de treinamento, tarefas de PR que penalizam testes que passam antes do patch, modelos juiz que fazem cumprir regras de qualidade. Mas um modelo juiz só levanta o piso: se um modelo de fato soubesse como é um bom código, ele o teria escrito de saída. A proposta de Horthy: o HumanLayer, um IDE de IA e espaço de trabalho colaborativo para exatamente esse fluxo, gratuito para equipes pequenas.

A grande ideia: agora todo agente é um usuário. A infraestrutura dimensionada para centenas de milhões de humanos está entrando em colapso sob um tráfego de agentes imprevisível e de alta vazão, e o painel argumenta que a solução não é um remendo: os fundamentos da computação precisam mudar.

Por que importa: a adoção corporativa emperra em confiança e cultura, não na capacidade do modelo. As equipes precisam trocar o instinto de culpar a pessoa por ciclos de aprender-com-o-agente, e os engenheiros têm que aceitar a mudança de construir para gerenciar e dar suporte aos agentes que constroem.

Como funciona: o painel esboça uma stack nativa de agentes. Frameworks que compilam artefatos em tempo de build cedem lugar a software gerado e serializado em tempo de execução; GUIs bonitas e caras em tokens cedem lugar a APIs eficientes focadas em texto; e ferramentas padronizadas mais o investimento em experiência de desenvolvimento colocam todo construtor de agentes em pé de igualdade.

O que copiar: trate um agente em produção como qualquer app bem arquitetado. Ele força as boas práticas que você já deveria ter. Converta cada incômodo em uma verificação de CI para que o agente nunca repita um erro. E continue dirigindo o trabalho você mesmo: o bom gosto humano é o que separa a magia do slop homogêneo.

Os números: um painelista projeta 600 bilhões de agentes implantados que odeiam imagens (o suficiente para arrastar a internet móvel, primeiro de imagem e vídeo, de volta ao texto), enquanto outro limita seu enxame de agentes autoorquestrados a 500, e centenas de bilhões de dólares perseguem um raciocínio de modelo cada vez melhor.

O porém: os modelos ainda carecem do que um painelista chama de cérebro de macaco: coerência de longo horizonte, guiada por crenças. As sessões não conseguem se manter na tarefa por três dias, os humanos se adaptam mais devagar do que a tecnologia muda, e a dependência excessiva de IA converge a saída de todos para o mesmo meio medíocre.

A grande ideia: o custo marginal de escrever código despencou para praticamente zero, então este painel argumenta que o trabalho do desenvolvedor se desloca para o que sobra: alinhamento sobre o que construir, validação de que está correto, e o bom gosto para saber que vale a pena lançar.

Por que importa: os organogramas já estão se curvando. O CTO da LaunchDarkly trata cada IC como um gerente de linha de frente tocando quatro times de agentes ao mesmo tempo, espera que recém-formados façam produto, design, especificação e trabalho de TPM, e brinca que os times de duas pizzas agora são times de duas fatias porque os agentes não comem. A curva de experiência também se achata: os juniores usam a IA como guarda-corpos enquanto os seniores alavancam seu julgamento sobre um exército de agentes.

Como funciona: cada painelista chega a uma versão de shift-left. Mova a qualidade para montante com desenvolvimento guiado por evals e por especificação, requisitos comprovadamente corretos (o TLA+ recebe uma menção) e tipos. A ascensão do TypeScript é creditada aos agentes se manterem nos trilhos quando os tipos os restringem. O PR vira um ponto de auditoria em vez do portão de qualidade, e os agentes ganham autonomia por meio de sandboxes na nuvem configuradas ao risco do projeto e pessoal.

Os números: o cofundador da Greptile diz que seus agentes de revisão de PR cobrem cerca de 10 bilhões de linhas de código por mês, que o código escrito por pessoa subiu aproximadamente 10x na mediana em 12 meses e perto de 100x no P90, e que um estudo de 2017 constatou que digitar código é só cerca de 5 por cento do trabalho real de um desenvolvedor.

O que copiar: codifique o contrato com o usuário: faça da documentação de produto voltada ao público a fonte de verdade contra a qual os agentes operam, porque o produto, não a base de código, é a saída da empresa. Compartilhe seus três pressupostos mais arriscados em vez de uma especificação de quatro páginas. Empacote as práticas de um engenheiro de bom gosto como skills compartilháveis para que toda a equipe as herde.

O porém: ninguém construiu ainda ferramentas para escalar equipes. O Conductor e seus clones paralelizam um indivíduo, e a colaboração multijogador em tempo real para desenvolvimento com agentes segue uma questão em aberto. E a IA é probabilística, não tem bom gosto: os humanos mantêm a seleção de problemas, o ofício e a disciplina de cortar o que não está funcionando.

A grande ideia: a engenharia forward-deployed é uma função de transformação profundamente técnica e embarcada no cliente, não serviços profissionais, não staff augmentation, não um time de deploy. Pauline Brunet, que dirige a prática na Cursor após uma década de deploys de IA empresarial, apresentou um manual sem rodeios para montar uma sem desperdiçar seus melhores engenheiros.

Por que importa: as empresas continuam comprando IA de ponta e vendo-a apodrecer na prateleira. O alerta central de Brunet é que a tecnologia sem acompanhamento fracassa: alguém precisa se sentar dentro da organização do cliente, encontrar o caso de uso certo e conduzir as pessoas através da mudança. Ela brincou que o papel está pronto para um perfil de trabalho mais cobiçado de 2026 na Forbes.

Como funciona: posicione cada cliente numa matriz 2x2 de maturidade digital versus customização do produto. Clientes maduros com produtos prontos para uso precisam de docs e autoatendimento; o ponto ideal da transformação embarcada são clientes mais no início da jornada usando um produto altamente customizável. Ancore cada engagement com o comprador econômico ou um champion sênior, amarre-o a um objetivo estratégico e co-desenvolva dentro do codebase do cliente com validação human-in-the-loop.

O que roubar: defina o escopo de forma direcional em fases limitadas no tempo (cerca de seis semanas) para que ambos os lados possam aprender e pivotar antes de terem visto seus dados e sistemas. Defina o sucesso e a linha de base logo de cara, e faça o cliente ser dono dos critérios de sucesso, da medição e da operacionalização. Escreva uma missão de time de uma linha (a da Cursor: co-projetar e co-construir sua fábrica de software de IA) para que todos consigam farejar o staff augmentation e recusá-lo.

Os números: a Cursor contrata engenheiros com cinco ou mais anos de experiência e com a EQ para lidar com clientes (ainda sem recém-formados), e então planeja dividir os papéis e evoluir de generalistas por geografia para pods por indústria com SMEs de área de produto. Uma definição de sucesso da palestra: automatizar um processo de ponta a ponta para que a resolução caia de três horas para vinte minutos. E uma conta de agente de $2.000 por dia deixou de parecer assustadora depois de reformulada como o custo de despachar a pessoa certa para consertar um equipamento.

A pegadinha: a linha entre FDE e o trabalho de body shop é fina. Coloque engenheiros 10x para documentar bugs, dar workshops de produto 101 ou engagements vagos de dois SDRs por seis meses, e eles vão ficar entediados e sair. Dizer não aos casos de uso que não encaixam, e ser honesto sobre onde a plataforma não é a ferramenta certa, é como a função mantém sua credibilidade e seu talento.

A grande ideia: os modelos de IA efetivamente resolveram a execução do trabalho de conhecimento. O próximo gargalo é o quão fundo você consegue ir no negócio de um cliente sem que o quadro de pessoal cresça exponencialmente. O CEO da Kepler, Vinoo Ganesh, apresentou o engenheiro forward-deployed (FDE) como o papel que fecha a lacuna: embarcar dentro do cliente, aprender como o trabalho realmente funciona e reimaginá-lo em torno da IA.

Por que importa: grudar modelos de fronteira em cima de processos quebrados é a razão pela qual a IA empresarial mostra tão pouco retorno. Operadores não técnicos em finanças, vendas ou compras não conseguem manejar um modelo cru como um engenheiro consegue, e cada negócio funciona diferente: um time de vendas de saúde não opera em nada parecido com um de SaaS. As soluções pontuais genéricas perdem o contexto que faz a automação pegar.

Como funciona: os FDEs da Kepler embarcam com um departamento por vez (digamos finanças) e entrevistam os donos dos processos de AP/AR, conciliação e FP&A. Eles documentam não o caminho ideal, mas o que acontece quando as coisas dão errado (Sarah cuida do fluxo até ele quebrar, e então Chris come quatro dias de tempo de ciclo). Depois reengenheiram o processo: alguns passos totalmente autônomos, alguns human-in-the-loop, alguns deixados nas mãos humanas onde o risco é alto demais, tudo implantado em cima do sistema de registro existente do cliente, sem nunca exigir uma migração.

O que roubar: para escalar os FDEs sem contratação exponencial, a Kepler está construindo um Agente FDE interno em três estágios. Um agente de engagement sintetiza notas do Granola, documentação, slides e e-mail para que os FDEs possam consultar o contexto do cliente na hora. Um agente de fluxo de trabalho vive dentro da plataforma e sinaliza os casos de borda que passam batido conforme os fluxos são construídos. Um futuro assistente autônomo vai enviar pedidos menores de mudança do cliente de ponta a ponta. Por baixo: um grafo de dependências da empresa, modelos open source pós-treinados (os modelos de fronteira se mostraram verbosos demais para a análise de nível consultor) e um ambiente de RL que treina ferramentas customizadas de percurso de grafos como resolução de entidades e detecção de violações de DAG.

Os números: cerca de 95 por cento dos pilotos de IA generativa não chegam à produção, e 87 por cento não mostram ROI mensurável. Um cliente da Kepler gastou cinco milhões de dólares e cinco anos migrando para o NetSuite, razão pela qual os discursos de migrar-primeiro morrem na chegada. As soluções pontuais entregam 5 a 10 por cento de ROI; a Kepler afirma que as transformações no nível de departamento retornam entre 25 e 75 por cento entre aumento de receita, economia de custos e mitigação de risco.

A pegadinha: todo o modelo depende de pessoas raras (engenheiros do percentil superior que também são consultores de alta EQ), e Ganesh admite que são brutalmente difíceis de encontrar. O terceiro estágio autônomo do Agente FDE ainda não foi construído, então os humanos ainda absorvem a correria de e-mail de clientes 24/7 que o agente deve apagar.

A grande ideia: construir agora faz parte do trabalho de liderança. Os agentes de codificação que rodam de forma autônoma por horas tornam o calendário picado de um gestor utilizável como tempo de construção. Agrawal entrega de 2 a 10 PRs por semana em meio a 15+ reuniões recorrentes, sete reports diretos e uma criança pequena em casa.

Por que importa: os modelos de fronteira redesenham seus contornos de capacidade a cada poucos meses, e nenhum volume de opiniões substitui o uso prático. Um líder que constrói consegue definir expectativas realistas para os engenheiros, perceber cedo as mudanças de estratégia e ganhar alinhamento com um protótipo funcional em vez de meses de persuasão. E como os líderes têm o maior contexto de negócio, sua direção é, nas palavras de Agrawal, mais impactante por token do que a de um IC.

Como funciona: um loop diário. Uma hora de manhã revisando o que o agente fez durante a noite, blocos curtos de direção entre reuniões, e então um bloco às 17h que dispara a execução noturna. Antes desse bloco, seu agente de trabalho conectado a Slack/Jira/Notion, o Dia, passa 20 minutos pesquisando a funcionalidade e monta um prompt de contexto gigante (metas de negócio, tradeoffs passados, restrições) para colar no Claude Code ou no Cursor. O agente então trabalha de seis a oito horas: testes escritos primeiro, checagens de fluxo de ponta a ponta, PRs amigáveis ao revisor, CI verde, uma passada de revisão de código com IA e um relatório completo esperando de manhã.

O que roubar: escolha projetos de quatro categorias seguras (ferramentas internas, melhorias de qualidade de vida do produto, artefatos de celebração para os colegas e protótipos de visão sobre novas famílias de modelos) e nunca trabalho de caminho crítico que emperra quando você é puxado para um incêndio. Mais duas receitas noturnas: transforme dumps JSON de feedback de usuários em um conjunto de evals mais um harness de otimização que mói até as pontuações subirem (depois salve o fluxo como um skill reutilizável), e dê a um agente dados curados mais acesso limitado à AWS para treinar modelos customizados candidatos. Agrawal acordou com dois classificadores treinados e um relatório de deploy.

A pegadinha: nada disso funciona sem o andaime organizacional (CI confiável, revisores de código com IA, logging, higiene de identidade de agentes, feature flags e uma branch de pré-prod para que os protótipos não possam derrubar a produção). E o fardo da higiene é seu: teste tudo antes de o stack avançar de manhã, mantenha os PRs pequenos e legíveis porque o time copia o que você entrega, e nunca atribua revisores a código que você não leu. Espere ser humilhado; faça mesmo assim.

A grande ideia: a engenharia forward-deployed nunca foi um único trabalho. Natalie Meurer, Head of Agent Engineering na Sierra e ex-Palantir, rastreia o papel safra por safra (DevOps mais integração de dados em 2008-2012, dashboards customizados de Slate em 2016, habilitação de plataforma sobre Foundry em 2020), com cada era empilhando novas responsabilidades por cima em vez de substituir as antigas.

Por que importa: o FDE está de repente em toda parte em 2026. O Google anunciou uma leva de contratação de customer engineers para o GCP, a OpenAI montou uma unidade fortemente financiada para seu avanço corporativo de IA, e a vaga composta agora exige oito anos como staff engineer, seis anos de vendas diretas e quatro anos como arquiteto de soluções. O segredo sujo de Meurer: esse candidato não existe.

Como funciona: o único fio que atravessa cada safra é a responsabilidade perante o cliente, seja o trabalho DevOps, integração de dados, solução customizada ou habilitação. Agora que os agentes de programação tornam barato disparar um prompt e receber algo ótimo de volta, os FDEs podem construir soluções de ponta a ponta em vez de só prototipar, e os engenheiros de produto ficam mais voltados ao cliente em troca. Na Sierra, as linhas estão se borrando ativamente.

O que roubar: entreviste os candidatos de engenharia deployed por safra (2008 sendo "estabilidade de plataforma com toques de pânico") e contrate generalistas que assumam os resultados do cliente em vez de esperar por um currículo unicórnio. Além disso, um spoiler para quem está construindo uma plataforma de dashboards: um dashboard que não consegue escrever de volta em sua fonte de dados perde valor com o tempo.

A pegadinha: o pricing baseado em resultados é para onde Meurer diz que a maior parte deste mercado está indo. O pricing por assento encaixa quando o produto mal é dono do resultado, o baseado em uso (o que você paga aos provedores de modelos base) fica no meio, e os agentes empurram para pagar por consultas resolvidas e vendas fechadas. Ela plota os quatro modelos, uso, resultado, meta e híbrido, numa grade de autonomia do agente versus atribuição, creditando a análise de 'outcomemaxxing' da Sierra. Mas alguém tem que garantir o resultado, e esse trabalho é a engenharia forward-deployed. Daí seu fechamento: o FDE está morto, vida longa ao FDE.

A grande ideia: Na Decagon, a engenharia forward-deployed e a engenharia de produto são a mesma disciplina: o mesmo nível de exigência, a mesma estrutura de reporte, muitas vezes as mesmas pessoas. Cada ponto de dor que um cliente Fortune 500 levanta em campo é tratado como uma funcionalidade de produto a ser construída uma única vez para todos.

Por que importa: Times de campo em todo lugar sentem a tentação de improvisar (prompt-hack) uma correção pontual para uma conta exigente. Rekhi argumenta que a habilidade escassa na era do AI-coding é a contenção: resolver o problema do cliente A de um jeito que chegue a B, C, D e E antes mesmo de eles o expressarem.

Como funciona: A Decagon opera duas trilhas de forward-deployment. Os agent builders configuram o "cérebro do agente" de atendimento ao cliente de cada empresa (instruções, tom, ações, regras de transferência para humanos), em grande parte dentro da UI. Os principais contribuidores ficam na linha de frente dos pedidos de produto e elevam as solicitações recorrentes a capacidades de plataforma para todos os clientes.

Os números: A Decagon cresceu de cerca de 50 funcionários para 500 em um ano, o que forçou a divisão do antigo papel faz-tudo de agent software engineer nessas duas especialidades. E depois de construir à mão sua 26ª integração de CRM sob medida, o time produtizou integrações self-serve em massa e parou de escrever código sob medida. Em um estudo de caso da Chime sobre o Decagon Voice, Rekhi relatou 70% de resolução em chat e voz, 60% menos custos de suporte ao cliente e satisfação de membros 2x, com a COO da Chime, Janelle Sallenave, atribuindo isso à memória multicanal.

O que roubar: Fixe as métricas de sucesso, os canais de suporte e os resultados durante o scoping do negócio, antes de construir. Componha os negócios com especialistas verticais que falem o idioma do cliente. Prove valor rápido em uma fatia estreita e de alto impacto, e depois expanda para parcerias de vários anos. E ingira dados históricos de suporte para poder aconselhar os clientes sobre quais automações trazem o maior ROI, mesmo quando não é isso que eles pediram.

O porém: Agentes que degeneram em uma caixa preta de prompts são frágeis demais para os clientes assumirem. Cada solução manual que um engenheiro executa é uma lacuna de produto: se a correção não volta para o produto self-serve, todo o movimento de forward-deployment para de escalar.

A grande ideia: Os ganhos de produtividade com IA não vêm das ferramentas: vêm de reconfigurar intencionalmente como os times trabalham. Liguori percorre três experimentos internos da Amazon, de um time pathfinder de elite no Bedrock a um sprint do Prime Video e um piloto de 50 times na Stores, e destila o que separou os times que se destacaram em cinco hábitos diários que ela chama de engenharia de fronteira.

Por que importa: No piloto da Stores, metade dos 50 times viu ganhos abaixo de 3x em velocidade de deploy, enquanto a outra metade atingiu uma mediana de 4,5x (alguns passando de 10x) com cerca de 90% deles usando o mesmo tooling interno, incluindo o Kiro. Os perdedores polvilharam IA sobre seu fluxo de trabalho existente; os vencedores mudaram o próprio fluxo de trabalho.

Como funciona: Os cinco hábitos são: investir no contexto do agente (cada erro do agente vira uma atualização das skills e dos steering files), ir mais devagar para ir mais rápido (corrigir as mensagens de erro, construir servidores MCP, reestruturar bases de código, com alguns times até migrando de JavaScript para TypeScript ou Rust para obter feedback do compilador), alimentar os agentes em vez de vigiá-los (dar um objetivo mais critérios de auto-validação, não uma conversa contínua), tornar a intenção explícita (iterar sobre um documento de especificação antes do código, o fluxo que o Kiro constrói) e deslocar os testes para a esquerda (linters, testes unitários e de integração, e serviços mock deterministas rodados localmente que dão aos agentes ciclos de feedback rápidos).

Os números: Seis engenheiros (incluindo dois Distinguished Engineers) construíram o Bedrock Mantle, um data plane de inferência totalmente novo, inteiramente com o Kiro em 76 dias, elevando os commits semanais 20x até 40, de dois, contra uma estimativa original de 30 pessoas por 18 meses. Um time do Prime Video de seis pessoas cortou uma estimativa de projeto de 90 semanas para 24 semanas em um sprint de 10 dias. A meta da Amazon para 2026 é escalar a engenharia de fronteira de 50 times piloto para os próximos 2.000.

O porém: Quase todos os times de alto desempenho primeiro ficaram mais lentos enquanto investiam nos fundamentos, e os líderes que exigem velocidade de features imediata matam a transição. O risco de burnout é real: os engenheiros ajustam prompts até tarde da noite, os agentes em paralelo elevam a carga cognitiva, e os engenheiros em início de carreira acham mais difícil revisar a saída da IA do que escrever código. Uma vez que o código leva semanas em vez de meses, a tomada de decisão e as aprovações de lançamento viram o novo gargalo.

O que roubar: Audite se você está vigiando seu agente ou alimentando-o com tarefas com um patamar de qualidade contra o qual ele possa se auto-validar. Comece com um único time pathfinder em vez de um rollout amplo, provisione a queda de produtividade, e pode as regras obsoletas dos steering files à medida que os modelos melhoram: os do-nots escritos para as peculiaridades do Sonnet 3.7 eram em sua maioria desnecessários no Opus 4.5.

A grande ideia: Leo Mehr, que fez a organização de engenharia forward-deployed da Ramp crescer de dois engenheiros para cerca de trinta em dois anos e meio, reduz a disciplina a dois princípios: sempre estar fazendo scoping, e escalar com tokens. Na Ramp, o FDE fica dentro da engenharia e reforça o produto central para os maiores clientes empresariais; não é, segundo ele, uma espécie de evolução "modo chefe" do go-to-market técnico.

Por que importa: os dois princípios só funcionam juntos. Um time que faz scoping sem piedade mas nunca constrói sistemas agent-native é ultrapassado por concorrentes que constroem; um time que despeja tokens em pedidos mal formulados apenas queima computação no trabalho errado. A afirmação de Mehr é que o futuro do papel de FDE exige os dois ao mesmo tempo.

Como funciona: quando um vendedor manda mensagem numa sexta à noite insistindo que um logo estratégico só fecha com uma integração de SAP S/4HANA, o FDE treinado faz uma pausa em vez de correr para a documentação da API. É o cliente que impulsiona a urgência, ou uma cota de fim de trimestre? Quem de fato usaria isso? Existem soluções manuais? O cliente consegue usar as APIs existentes? Outros prospects no pipeline também precisam disso? Só então decide o que construir.

O que roubar: o intake agent da Ramp. Os vendedores postam os bloqueios em um canal interno do Slack "FDE requests" apoiado por um fluxo de trabalho do Notion, e a qualidade dos pedidos varia enormemente: alguns detalhados, outros de uma linha só. Um agente do Notion V1 que simplesmente lia cada pedido e fazia algumas perguntas de esclarecimento provou seu valor em questão de semanas; a versão atual roda várias rodadas de ida e volta com o remetente até julgar que o pedido está pronto para virar um ticket.

Os números: a latência de resposta aos novos pedidos caiu de horas ou dias para segundos, e Mehr estima que o agente economiza cerca de vinte por cento do tempo que o time gastava com scoping. Enquanto isso, os modelos de fronteira já conseguem resolver de primeira (one-shot) features de tamanho médio, então a última etapa do pipeline (de uma especificação bem formada a um produto funcional) só fica mais fácil.

O porém: o meio do pipeline ainda é intrincado e sem forma, exigindo investimento em agent harnesses, rubricas de qualidade, feedback humano e colocar o contexto certo (dados históricos, conhecimento de produto, skills, memórias, ferramentas) em cada chamada ao LLM. As falhas de scoping também continuam caras: a Ramp certa vez teve dois FDEs aprendendo iOS e Android para enviar uma feature de reembolso mobile em ambas as plataformas, só para descobrir que o cliente exigia dispositivos apenas iOS. E seja lá o que os agentes produzam, o FDE mantém a responsabilidade final sobre o gosto e o julgamento.

A grande ideia: o Fable, que estreia no mesmo dia da palestra, é o momento em que o tutorial acaba e o mundo aberto começa: um modelo cuja amplitude pura exige uma nova forma de trabalhar. Thariq Shihipar, da Anthropic, comprimiu uma série de blog planejada em um guia de campo de quatro partes: solte o Claude, encontre suas incógnitas, lide com o luto e seja irracional.

Por que importa: os modelos ficam mais inteligentes de formas irregulares, e seu harness só reflete seu entendimento atual deles. O GPT-4 não conseguiu nomear os dois Pokemon cujos nomes terminam em '-aw' mesmo conhecendo todos os Pokemon; o Claude, com uma ferramenta de execução de código, simplesmente buscou a lista completa e a filtrou com um script. Esse excesso de capacidade significa que o possível pode mudar da noite para o dia, se você souber onde olhar.

Como funciona: as melhores práticas de prompting não param de se inverter. A era do Sonnet 3.5 premiava prompts de sistema pequenos com muitos exemplos; modelos mais inteligentes premiavam prompts grandes, carregados de instruções, com muitas ferramentas; modelos da classe Fable querem menos de novo: menos exemplos (eles restringem um modelo mais imaginativo do que seus exemplos), menos regras de 'não faça' e contexto sem restrição excessiva. O mesmo arco produziu o próprio Claude Code: ferramentas como o bash superam colar toda uma base de código, porque o modelo constrói e busca seu próprio contexto. O Claude Chat agora estende isso para trabalho proativo e multijogador em que o Claude acorda a si mesmo.

O que copiar: seu prompt é um mapa, mas o território é a base de código real, e o Fable percorre o suficiente para esbarrar em cada lacuna que você nunca especificou. As contramedidas de Shihipar: faça o Fable dar uma passada de orientação sobre uma base de código desconhecida e aponte-o para fontes de contexto como Git e Slack; faça um brainstorm de protótipos HTML bem diferentes para fixar o gosto do sei-quando-vejo; peça ao modelo que te entreviste para extrair restrições implícitas; dê a ele código de referência (mesmo em outra linguagem) como um mapa pronto; faça-o registrar incógnitas no meio da execução para você ver onde as decisões mutaram; e deixe que ele te examine depois para você ainda conseguir representar o trabalho.

Os números: cerca de 80 por cento do prompt de sistema do Claude Code foi apagado. Dois de cerca de mil Pokemon terminam em '-aw', o teste que o GPT-4 reprovou e o Claude, equipado com ferramentas, passou. O próprio deck da palestra foi construído com o Fable em cerca de quatro horas na noite anterior.

O porém: construir é mais fácil, mas gerar valor ainda é difícil: exige muitas tentativas, e os engenheiros de IA supervalorizam processo e configurações. Também há um luto real: o trabalho que levava semanas agora leva horas, o que significa perder a depuração de madrugada, o modelo mental de uma base de código girado à mão, as vitórias e os fracassos. Seu veredito: não há como voltar atrás, e a única saída é atravessar.

A grande ideia: Os LLMs baseados em texto surpreenderam até um veterano de 30 anos de NLP, mas eles ainda só descrevem o mundo. Christopher Manning argumenta que o caminho para a AGI corporificada passa pelos world models, e a Moonlake AI os constrói colocando código embaixo de cenas 3D reconstruídas em vez de gerar pixels mais bonitos.

Por que importa: Aprender políticas de robôs diretamente no mundo real é brutalmente lento: os esforços no estilo QT-Opt do Google X se apoiaram em cerca de 10.000 horas de teleoperação humana. Um simulador com estrutura causal real permite que os robôs planejem, treinem e transfiram para a realidade de forma barata, revivendo ideias de world models que vão de Kenneth Craik nos anos 40 até o robô Shakey da SRI.

Como funciona: A Moonlake pega uma imagem ou um vídeo curto, separa o fundo dos objetos manipuláveis e gera código que renderiza cada objeto e suas propriedades. Um ciclo agêntico (escrever código de renderização, comparar o render com a realidade física, revisar) refina a fidelidade, enquanto buscas web no estilo RAG recuperam fatos ocultos, como os saquinhos de chá dentro de uma caixa de chá fechada. O resultado é neurossimbólico: verificável, editável e controlável de formas que os modelos de vídeo com profundidade de pixel como o Genie 3 não são.

Os números: O Google já tinha um modelo de linguagem de 2 trilhões de tokens em 2007, a mesma ordem de grandeza dos runs atuais de 15 trilhões de tokens. A escala chegou muito antes da arquitetura. Do lado da robótica, Manning contrasta 10.000 horas de teleoperação paga com 10.000 horas de experiência simulada gerada essencialmente de graça.

O que roubar: Julgue um simulador pelo problema que ele resolve, não pelos pixels que ele desenha. Uma cena 3D navegável a partir de uma única imagem serve para turismo, mas um robô que precisa abrir a caixa de chá precisa de semântica e código embaixo de cada objeto relevante. E pule a fidelidade total: como os world models humanos, simule apenas as partes do mundo que a tarefa realmente precisa.

O porém: O vídeo generativo parece bom o suficiente para ser confundido com compreensão, e Manning alerta que esses pixels não dão base para planejar. A transferência sim-to-real só funciona quando a simulação captura o detalhe causalmente relevante, que é justamente a parte difícil. O software de Andreessen nunca engoliu o mundo físico; a simulação verificável e movida a código é a aposta da Moonlake sobre como isso finalmente acontece.

A grande ideia: Os apps feitos por bots compartilham os mesmos sinais reveladores: gradientes roxos, cabeçalhos em itálico, "scroll to explore", botões de pílula em maiúsculas, logos com gradiente, spam de emojis. A solução de El Mghari é nomear esses sinais explicitamente (ele diz que você consegue listar de 20 a 30 deles) e bani-los nas instruções que seus agentes levam para cada projeto.

Por que importa: Ele envia cerca de dez apps de IA por ano, vários com alcance enorme, e credita o design e a UX, não a amplitude de features, como o principal impulsionador de adoção. Dedicar 10 a 20% de esforço extra à UI, ele argumenta, é agora uma vantagem competitiva séria porque os usuários identificam uma página gerada por IA em segundos.

Como funciona: Sua skill de design, a Hallmark, faz duas coisas: "slop gates" que dizem aos modelos o que nunca fazer, e pacotes de temas curados injetados como contexto para que o modelo desenhe a partir de boas referências em vez de seus padrões. As landing pages de primeira (one-shot) com a Hallmark saem visivelmente mais limpas do que as gerações sem assistência, dando a você uma base crível a partir da qual iterar.

O que roubar: Mantenha um baú de inspiração com capturas de tela e cole várias em cada prompt de design. Escreva briefings de dois a três parágrafos (ele grava notas de voz de 1 a 3 minutos) cobrindo o usuário, o layout, os componentes e as referências. Persista seu gosto em um arquivo agents.md ou de skill. Erga a base com um modelo pesado, depois itere uma ou duas features por vez com um modelo aberto rápido.

Os números: 85.000 usuários testaram seu criador de logos e 8.000 seu gerador de legendas; a Hallmark atraiu mais de 10.000 usuários em cerca de seis semanas. Em um A/B ao vivo, apenas quatro mãos escolheram corretamente a landing page do GLM 5.2 sobre a do Claude Opus 4.8, e a versão do Opus custou cinco vezes mais e rodou mais devagar.

O porém: A iteração barata só funciona se o modelo pequeno for genuinamente bom em design. O GLM 5.2 passou desse patamar para ele só recentemente. E nenhum arquivo de skill substitui o ciclo humano: seja lá o que o agente produza é andaime, e o polimento no espaçamento, nos logos, nos estados de carregamento e no movimento é por sua conta.

A grande ideia: Quase toda métrica popular de engenharia de IA é uma miragem. Os painelistas relataram que o gasto com tokens, o volume de uso de agentes e a densidade de power-users correlacionavam com mais linhas de código, mas nenhum deles correlacionava com uma entrega de projetos mais rápida. A única coisa que correlacionou: se práticas de engenharia sólidas e ciclos de validação deterministas já existiam na base de código.

Por que importa: Os times que apostam tudo no código gerado por IA enfrentam um problema de slop. A empresa de um dos painelistas enviou software 100% gerado por IA por nove meses, e admitiu que os primeiros dois ou três meses foram slop até tornarem a manutenção da qualidade um esforço metódico e ativo. Deixada por conta própria, a qualidade da base de código se deteriora.

Como funciona: O time de um dos painelistas instrumentou mais de 150 ciclos de validação deterministas dentro das bases de código e os agregou em uma pontuação de prontidão para agentes (agent readiness score); as bases de código que pontuam no nível quatro ou cinco se comportam como linguagem-natural-para-software com taxas de erro muito baixas. Na Vercel, os engenheiros sênior incorporam seu gosto tácito em skills e ferramentas internas, compartilham isso nas office hours de engenharia e impulsionam uma cultura em que apagar e simplificar código vence adicioná-lo.

O que roubar: Trate a qualidade do agente como um problema de dados, não de tom. Construa uma camada de contexto que selecione as fontes certas, as resuma e passe o resultado por verificações antes de ele chegar ao agente. Depois instrumente tudo (latência, recuperação de contexto, quando o agente escolhe fazer perguntas e onde os usuários batem na fricção) e otimize sem piedade, porque você se torna aquilo que mede.

Os números: mais de 150 ciclos de validação deterministas instrumentados por base de código; taxas de prompt-caching mirando 96-98%; nove meses de software totalmente gerado por IA, com os primeiros dois ou três meses produzindo slop.

O porém: Nada disso se sustenta sozinho. Os agentes são sistemas extremamente sensíveis, e até pessoas inteligentes e com gosto derivam sem uma instrumentação rigorosa, e se alguém quer enviar porcaria, os testes estáticos e os scanners de IA sozinhos não vão impedir. Humanos com gosto permanecem no ciclo.

A grande ideia: agentes de navegador são agentes de código disfarçados. A plataforma da Browserbase trata o navegador como um sistema completo (armazenamento, computação, um motor de nós) para que os agentes escrevam e executem código contra ele em vez de apenas clicar.

Por que importa: a maior parte do trabalho de conhecimento acontece na web, e os agentes de hoje são muito melhores em benchmarks de código do que em tarefas do mundo real. Dar um navegador aos agentes de código é a aposta da Browserbase para fechar essa lacuna: sair da recuperação de dados e passar a de fato concluir transações.

Como funciona: um agente de demo chamado "Feed Myself" fez login no Uber Eats com as credenciais e o método de pagamento salvos do apresentador, pediu de novo sua última refeição do The Bird e concluiu o pedido de ponta a ponta. Cada etapa produziu um trace completo: o raciocínio do agente, suas chamadas de ferramenta e os scripts de Playwright que ele executou contra o navegador, ao lado de uma minivisão ao vivo de exatamente o que o agente via.

O que copiar: enquadre as tarefas de navegador como fluxos de trabalho guiados por código, não como sequências de cliques. Uma segunda demo deu ao agente um login salvo e o fez resolver o problema Two Sum do LeetCode inteiramente no navegador (escrevendo o código, executando e enviando), prova de que um único harness cobre tanto os recados quanto a engenharia.

O detalhe: o único slide da palestra contrastava SWE-bench com o remote labor index, um benchmark mais difícil de entregáveis reais como arquivos, apresentações e exposições de trabalho, onde as taxas de resolução continuam bem mais baixas. As demos mostram uma direção para automatizar o trabalho de conhecimento, não uma capacidade acabada.

A grande ideia: os agentes não vão parar em escrever código de aplicação: vão provisionar e gerenciar a infraestrutura por baixo dele. Um palestrante da Neon disse que entre 80 e 90 por cento dos bancos de dados da empresa já são criados ou gerenciados de alguma forma por agentes via Claude Code e plataformas como Replit, o que significa que a infraestrutura precisa se tornar legível para máquinas: um arquivo declarativo de infraestrutura como código que diga ao agente exatamente o que existe antes que ele gaste um monte de chamadas de ferramenta descobrindo.

Por que importa: o debate CLI contra MCP ignora que a maior parte do atrito dos agentes é a coleta básica de contexto: descobrir o que há na sua conta da Vercel ou no seu projeto da Neon. Uma configuração concisa e codificada colapsa essa etapa. E o stack clássico de IaC (Terraform, Pulumi, SST) é pesado demais para times que enviam SaaS em TypeScript no estilo Vercel; o palestrante argumentou que esse espaço precisa de algo mais leve e nativo de TypeScript.

Como funciona: o fluxo de trabalho é CLI primeiro. O "neon link" vincula um workspace local a um projeto remoto da Neon e traz suas variáveis de ambiente direto para o .env. Depois você declara seu stack num pequeno arquivo neon.ts: bancos Postgres, Neon Auth (construído sobre Better Auth), buckets de armazenamento de objetos compatíveis com S3. Rodar "neon deploy" (alias "neon config apply") compara a declaração com o projeto remoto, provisiona o que estiver faltando e atualiza o .env com exatamente as novas variáveis de que os recursos precisam.

O que copiar: o truque do env tipado. Importe a configuração neon.ts na função parseEnv do neon-env e você obtém variáveis de ambiente tipadas para corresponder com precisão ao que você provisionou: as variáveis do bucket só existem se um bucket for declarado. O gerenciamento do env ainda é uma das superfícies mais desajeitadas para os agentes, e tipá-lo contra a declaração da infraestrutura fecha o ciclo entre o que está implantado e o que o código espera.

Os números: entre 80 e 90 por cento dos bancos da Neon são provisionados ou gerenciados por agentes, e toda a demo ao vivo (vincular um projeto, declarar auth e um bucket de avatars, implantar, obter variáveis de env tipadas e novas) coube num espaço relâmpago de cinco minutos.

O detalhe: o neon.ts só cobre a própria superfície da Neon (Postgres, auth, armazenamento de objetos e uma AI gateway que faz proxy de funções da Databricks AI Gateway). O palestrante vê uma lacuna no mercado para uma camada de infraestrutura genérica em TypeScript e apontou para o infra.ts.dev, um experimento inicial nessa direção, com a ressalva explícita de que não está pronto para produção.

A grande ideia: pare de alugar modelos de fronteira e comece a ser dono dos seus. Jetashree Ravi, da Fireworks AI, argumenta que as empresas estão migrando de Claude e ChatGPT para a "inteligência própria": tratar um modelo de código aberto com fine-tuning como propriedade intelectual própria que melhora continuamente por meio de um loop de treinar, implantar, monitorar e retreinar.

Por que importa: as faturas das APIs de código fechado parecem insustentáveis para uma parcela crescente de times. Ravi abriu perguntando à sala quem as achava caras demais, e mãos se levantaram. Enquanto isso, os modelos abertos fecharam a lacuna; ela sondou a plateia sobre o GLM 5.2 e o apresentou como tendo desempenho quase tão bom quanto o Opus.

Como funciona: a parte difícil é servir modelos abertos em escala de produção. A resposta da Fireworks é o FireAttention, um motor de inferência interno com kernels CUDA personalizados (a camada de tradução entre o modelo e a GPU) ajustados por carga de trabalho para atingir metas específicas de latência e custo para clientes como Cursor, Uber e Notion.

O que copiar: o volante de inércia, independentemente do fornecedor. Faça fine-tuning com SFT, reinforcement fine-tuning ou DPO; implante o checkpoint; observe latência, custo e taxas de acerto de cache em dashboards; colha dados de produção; depois retreine partindo do checkpoint anterior em vez de do zero. A herança de checkpoints é o que faz o loop se compor.

Os números: a Fireworks afirma mais de 30 trilhões de tokens processados por dia (antes do GLM 5.2), mais de 10.000 clientes e cerca de 280K requisições. O Composer 2 do Cursor foi treinado com a API de treinamento da Fireworks e é servido na plataforma; um modelo v0 da Vercel hospedado ali é citado com latência 40x melhor; a GenSpark roda RLHF na Fireworks para elevar a qualidade da aplicação final.

O detalhe: esta é uma palestra relâmpago de sete minutos de um fornecedor: cada benchmark e número de escala é uma afirmação da própria Fireworks. E a própria proposta admite que os modelos abertos muitas vezes não funcionam de imediato; a inteligência própria só compensa se você investir no loop de treinamento e no servido em nível de kernel que as APIs de modelos fechados abstraem.

A grande ideia: a busca vetorial recupera semelhantes; ela não lembra. O Spectron, uma camada de memória construída sobre SurrealDB, tenta replicar como a memória humana realmente funciona (formar crenças, consolidá-las e rastrear como os fatos mudam ao longo do tempo) para que os agentes mantenham conhecimento duradouro entre sessões.

Por que importa: quase todo stack de agente esquece no momento em que uma nova conversa começa. Enfiar o histórico na janela de contexto queima tokens, e a busca por similaridade não tem opinião sobre o que é verdade. Quando o palestrante perguntou à sala quem estava satisfeito com a qualidade do agente além da janela de contexto, uma mão se levantou.

Como funciona: o Spectron ingere dois tipos de entrada, fontes autoritativas (PDFs, vídeo, áudio, código, JSON) e dados experienciais (cada turno de conversa), e extrai de ambos entidades, verbos, ações e palavras-chave. Processos em segundo plano modelados no sonhar fazem o resto: a elaboração liga memórias distintas em novas, a reflexão as reavalia contra entradas externas, a consolidação funde crenças duplicadas e a reconciliação aposenta fatos obsoletos.

O que copiar: trate o tempo como um fato de primeira classe. O Spectron registra o tempo do sistema para auditabilidade mais um ciclo de vida do fato (quando algo entrou, mudou, passou de incerto para certo e por quanto tempo continua válido), de modo que um CTO que muda para uma nova empresa é atualizado de forma limpa em vez de corromper a base de conhecimento. E nunca apague memórias antigas; substitua-as para que a linhagem da mudança sobreviva.

Os números: os clientes lidam com centenas de terabytes até escala de petabytes de dados transacionais, e o design de memória compartilhada mira centenas de milhares até milhões de agentes por toda uma organização. A integração é apresentada como duas linhas de configuração, com hooks para MCP, Claude Code e Codex.

O detalhe: esta foi uma palestra relâmpago de cinco minutos, não uma sessão de benchmarks; qualidade de recuperação, latência e custo nessa escala ficaram sem comprovação no palco. A demo vive em throughthelobby.com/spectron.

A grande ideia: quando qualquer um pode subir um agente pelo Slack, a frota incha rápido, e a maioria desses agentes acaba subótima ou com bugs. A solução da RunLayer é um metaagente chamado Agent Optimizer que audita, depura e ajusta de forma autônoma todos os outros agentes da plataforma.

Por que importa: a RunLayer opera 482 agentes com apenas 40 pessoas, e os times internos competem num ranking de token-maxing. Nessa proporção, ninguém consegue revisar manualmente cada agente, então tokens desperdiçados e configurações quebradas se acumulam silenciosamente em dinheiro de verdade.

Como funciona: numa cadência semanal, o Agent Optimizer percorre os últimos sete dias de execuções de cada agente (sucessos e falhas), depois audita seu modelo, ferramentas provisionadas, conectores MCP, agendamentos, anexos de memória e arquivos de skills. A partir daí ele aumenta ou diminui o tamanho dos modelos, reescreve prompts, desprovisiona ferramentas não usadas por semanas, repara conectores MCP quebrados e triam as execuções agendadas que falharam.

O que copiar: classifique a automação por níveis de risco. Correções de baixa prioridade e baixo raio de impacto são aplicadas automaticamente; mudanças de risco médio e alto surgem como recomendações que uma pessoa precisa aprovar. E cada recomendação é vinculada a um valor em dólares, o que torna óbvias a priorização e a justificativa de negócio.

Os números: 482 agentes, 40 pessoas. Uma janela de revisão de sete dias de histórico de execuções, uma cadência de otimização semanal, execuções de produção de 15 a 20 minutos por passada e cerca de 65.000 dólares de economia anual, incluindo ganhos de produtividade.

O detalhe: a demo ao vivo foi simplificada de propósito: um agente de aniversário do hall da vergonha queimando um modelo de classe fronteira só para enviar felicitações. Em implantações reais, as decisões mais difíceis ainda são roteadas para as pessoas, e o número de economia de destaque mistura estimativas leves de produtividade junto ao gasto duro em tokens.

A grande ideia: a Exa está construindo um motor de busca projetado para a IA e não para as pessoas: um laboratório de busca de fronteira, pela própria descrição, dono de todo o seu stack, dos modelos de embeddings e do banco de dados vetorial até o rastreamento, a extração e as GPUs por baixo, tudo ajustado para um contexto de baixa latência e alta relevância.

Por que importa: os modelos não conseguem absorver a internet inteira durante o pré-treinamento e ficam estáticos no momento em que ele termina, então precisam de dados da web ao vivo para agir sobre insights reais. O palestrante enquadrou o contexto como a maior alavanca sobre o desempenho do modelo, e janelas de contexto superdimensionadas prejudicam ativamente a qualidade enquanto elevam latência e custo.

Como funciona: o recurso Highlights da Exa inverte o movimento habitual de recuperação. Em vez de despejar uma página inteira no prompt, ele seleciona computacionalmente os melhores caracteres daquela página para a consulta e retorna apenas esses. Peça o aniversário do Einstein e você recebe a única string que o contém, não o artigo inteiro da Wikipedia. Os laboratórios já estão alimentando essa saída sem enchimento em pipelines de RL e pós-treinamento.

Os números: o Exa Agent (um harness de modelo com fine-tuning montado sobre esses primitivos de busca) foi desafiado a conectar Marc Andreessen a Kevin Bacon com uma fonte de domínio distinta por etapa, com IMDb e o Oracle of Bacon proibidos. Ele retornou um caminho de três graus (Andreessen para Rogan para Hartman para Bacon) em 42 segundos, citando evidência tão específica quanto o episódio do Saturday Night Live (temporada 16, episódio 12) onde Hartman e Bacon apareceram juntos. O palestrante estimou que a mesma tarefa teria lhe custado um dia inteiro.

O que copiar: otimize para a eficiência em tokens, não para o token maxing. E ao avaliar agentes de busca, use tarefas do zero que proíbam redes pré-calculadas e exijam uma fonte citada distinta para cada salto: isso força um raciocínio verificável de várias etapas em vez de consultas a um banco de dados.

O detalhe: as vitórias comprovadas de hoje se concentram em nichos: inteligência GTM, finanças, código e dados de RL. O agente de busca generalista que lida com qualquer consulta complexa ainda é uma aposta em que os modelos continuem melhorando, não uma realidade já entregue.

A grande ideia: a MiniMax construiu seu modelo mais recente, o M3, para ser multimodal desde o primeiro passo literal do treinamento e para carregar uma janela de contexto de um milhão de tokens, movida por uma arquitetura própria que o laboratório chama de MiniMax Sparse Attention.

Por que importa: um milhão de tokens de contexto eficiente destrava o raciocínio sobre bases de código inteiras e a compreensão de vídeos mais longos, e a MiniMax apresenta as capacidades de programação e agênticas do M3 como um substituto local dos modelos de código fechado. O laboratório também opera modelos de linguagem, de geração de vídeo e de fala sob o mesmo teto, e quer fundir essas modalidades em aplicações agênticas mais capazes.

Como funciona: a atenção esparsa roda em duas ramificações. Uma ramificação de índice leve faz uma passada barata de atenção completa para sinalizar quais tokens do contexto realmente importam; uma ramificação esparsa então realiza o cálculo pesado de KV apenas sobre esses tokens selecionados, evitando o custo n ao quadrado da atenção padrão. O design foi codesenvolvido deliberadamente entre as equipes de algoritmo e infraestrutura, com a eficiência de decodificação como objetivo de primeira classe.

O que copiar: dois ajustes fizeram a atenção esparsa funcionar com Grouped Query Attention. Primeiro, múltiplos cabeçotes KV acabavam selecionando exatamente os mesmos tokens, então a equipe removeu a agregação das saídas da ramificação de índice para preservar a diversidade por cabeçote. Segundo, mudaram de recuperação em nível de token para nível de bloco porque as GPUs preferem acesso a memória contíguo, cortando a sobrecarga e melhorando a razão entre cálculo e acesso à memória.

A pegadinha: o trabalho anterior não se transferiu de forma limpa. A atenção esparsa da DeepSeek existe, mas não se mapeia para arquiteturas baseadas em GQA, que é exatamente o descompasso que a MiniMax teve que contornar por engenharia. No lado multimodal, as opções fáceis também falharam: injetar visão após o pré-treinamento, após o decaimento ou logo antes do pós-treinamento rendeu abaixo do esperado. Só treinar com imagens e vídeo desde o passo zero produziu mapas de atenção em que os tokens de texto genuinamente atendem aos tokens de imagem.