Os 6 pilares de um harness agentic para produção — Varun Krovvidi, Resolve AI

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: The 6 Pillars of an Agentic Harness for Production — Varun Krovvidi, Resolve AI · Canal: AI Engineer · 21:02 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA

Resumo

Varun Krovvidi apresenta os desafios de usar IA para operar e corrigir sistemas de produção, uma tarefa que envolve várias fontes de dados, ferramentas e equipes. Ele descreve seis pilares para um harness agentic de domínio específico: orquestração de modelos, engenharia de contexto, raciocínio causal, ações governadas, aprendizado contínuo e evals. A demonstração da Resolve AI mostra agentes investigando alertas, justificando causas-raiz e permitindo que engenheiros questionem as conclusões e colaborem. A tese central é que modelos, por si só, não bastam: é preciso uma arquitetura que os torne confiáveis e úteis em produção.

Pontos-chave

Operar e corrigir software em produção é diferente de gerar código: exige raciocínio em múltiplos domínios, ferramentas e sistemas.
A orquestração deve acompanhar a evolução dos modelos e selecionar o mais adequado para cada tarefa.
A engenharia de contexto busca fornecer a quantidade certa de informação, combinando técnicas e chamadas a ferramentas precisas.
Investigações de produção precisam estabelecer uma cadeia causal de evidências, em vez de apenas apresentar respostas coerentes.
Ações governadas definem limites de acesso e condições para que agentes operem com segurança.
Sistemas de aprendizado devem aproveitar as interações dos usuários e manter contexto entre investigações.
Evals ajudam a avaliar caminhos de investigação, desempenho e calibração de confiança, inclusive quando modelos ou arquiteturas mudam.
A demonstração apresenta agentes que analisam alertas, correlacionam código, infraestrutura, bases de conhecimento e observabilidade, e colaboram com equipes.

Capítulos

Início	Capítulo	Resumo
00:01	Apresentação e contexto	Varun apresenta a Resolve AI e explica por que operar sistemas de produção é um desafio diferente de gerar código.
02:36	O trabalho de manter sistemas em produção	O palestrante divide as tarefas de produção em manutenção cotidiana, incidentes críticos e trabalho contínuo para manter a saúde dos sistemas.
06:44	Limites dos modelos e falhas ao escalar	Ele descreve problemas como vieses, contexto insuficiente ou excessivo, falta de raciocínio causal e necessidade de guardrails e aprendizado.
11:58	Os seis pilares do harness	A apresentação detalha orquestração de modelos, engenharia de contexto, raciocínio causal, ações governadas, aprendizado e evals.
15:35	Demonstração da Resolve AI	Agentes investigam um alerta, correlacionam dados de várias fontes e apresentam causa-raiz, evidências e hipóteses descartadas.
17:08	Investigação colaborativa de incidentes	A demonstração mostra como questionar as conclusões do agente e envolver colegas para investigar causas alternativas em conjunto.
20:17	Encerramento	Varun conclui observando que colocar IA diante de usuários também exige uma plataforma robusta.

Citações

70% do nosso tempo é gasto do outro lado: não gerando software novo, mas operando e corrigindo software. — 02:05

A última milha é, na verdade, a milha mais longa que temos de percorrer com a IA. — 05:12

Em incidentes de produção, o que você procura é uma cadeia causal de evidências, como um detetive. — 09:50

O que importa é a quantidade precisa de contexto de que a IA precisa para resolver aquele problema específico. — 12:59

Conceitos e entidades

Resolve AI (empresa): Empresa que desenvolve agentes para operar e corrigir software em produção.
Varun Krovvidi (pessoa): Integrante da Resolve AI que apresenta a arquitetura de agentes para sistemas de produção.
agentic harness (conceito): Arquitetura que adapta modelos de uso geral a tarefas específicas de operação e correção de software.
model orchestration (conceito): Seleção e coordenação de modelos conforme a tarefa, acompanhando a evolução das capacidades disponíveis.
context engineering (conceito): Definição e fornecimento do contexto necessário para que a IA resolva uma tarefa com precisão e eficiência.
causal reasoning (conceito): Raciocínio que estabelece uma cadeia de evidências para explicar a causa de um incidente.
governed actions (conceito): Regras de acesso e limites que controlam quais ações um agente pode executar.
evals (conceito): Avaliações sistemáticas do desempenho, do processo de investigação e da confiança de um sistema de IA.
Slack (ferramenta): Ferramenta de colaboração usada na demonstração para receber alertas e envolver colegas na investigação.
Grafana (ferramenta): Plataforma de observabilidade cujos alertas aparecem na demonstração.

Tradução completa (pt-BR)

00:01 [música] Alguém consegue me ouvir? Ótimo, excelente. Muito obrigado por participarem da sessão. Meu nome é Vun. Faço parte da equipe da Resolve AI. Estamos criando IA para produção. Basicamente, estamos criando agents para operar e corrigir seu software. Nesta sessão, vamos abordar quais são os seis

00:32 pilares de um agent harness de que você vai precisar em um sistema criado para corrigir e operar seu software. Antes de começar a sessão, só quero fazer uma rápida pergunta, levantando a mão, para entender quem está na plateia. Imagino que a maioria de vocês seja de engenharia. Quantos já estiveram de plantão? Levantem a mão rapidamente. Ótimo. Vocês já tentaram usar IA para ajudar durante o plantão? Levantem a mão. Ótimo. Para quem levantou a

01:03 mão, podem me dizer que 90% do trabalho de plantão de vocês é feito por IA? Dá para afirmar isso com segurança? Ótimo. Sim, foi isso que percebemos quando começamos a empresa também. Esse é um problema muito difícil de resolver. Então, nesta sessão, quero compartilhar nossa jornada. Como foi a evolução pela qual passamos? Quais foram alguns dos aprendizados que tivemos, especificamente ao criar esse tipo de agent harness? Antes de começar, quero contextualizar o que estamos vivenciando hoje. Então, a

01:33 primeira onda de IA realmente se concentrou em programação e, para ser sincero, acho que, para a maioria de nós, a forma de programar mudou fundamentalmente. Também queria explicar por que isso aconteceu. Primeiro, o código é, por si só, autodocumentado. É fácil para a IA analisar e entender o que está ali para ajudar você na próxima etapa. Segundo, o código é inerentemente muito modular. Então, é fácil para a IA dividi-lo em partes e

02:05 avançar para a próxima etapa, além de ajudar você a expandi-lo, desenvolvê-lo e construir a partir dele. Terceiro, e mais importante, o código pertence a um único domínio. Você não precisa ensinar vários domínios à IA para que ela raciocine entre eles. Ela consegue avançar facilmente para a próxima etapa, e essa é uma das razões pelas quais também temos benchmarks tão bem definidos. É possível avaliar objetivamente a qualidade da IA para resolver esse problema para você. Mas, na realidade, 70% do nosso tempo em engenharia é gasto do outro lado, não

02:36 gerando software novo, mas sim em sistemas de produção, basicamente operando e corrigindo software. Isso abrange uma ampla variedade de problemas. Operar e manter software costuma ser algo que dá para dividir em três grandes categorias. Pense na analogia com a área da saúde; é a maneira mais fácil como gosto de pensar nisso também. Uma delas é o plantão e a manutenção de rotina. Pense em pequenos problemas regulares que aparecem no seu caminho.

03:07 Talvez você precise de Tylenol para alguma dor, talvez precise de Advil. São alertas comuns de plantão com os quais você precisa lidar. A segunda categoria são os incidentes, em que todos precisam se mobilizar. É como uma cirurgia. Os sistemas estão parando. É preciso que todos os envolvidos ou responsáveis deem atenção e venham resolver o problema. E a terceira categoria é mais como suas vitaminas diárias. Há muitas coisas que você precisa fazer regularmente para manter a saúde do seu sistema

03:39 em dia. Isso inclui coisas como analisar sua infraestrutura, analisar seus custos ou talvez algum trabalho de engenharia de plataforma para ganhar escala. Esses problemas são fundamentalmente difíceis porque não são exatamente como código. Eles abrangem vários domínios e ferramentas diferentes. E essas são as repercussões que estamos começando a ver agora que a euforia inicial com a IA começa a passar. É isso que vocês estão vendo nas notícias neste momento. Fala-se muito mais sobre a quantidade de problemas que talvez o código gerado por IA esteja começando a causar em produção e

04:10 sobre quais são os frameworks certos para lidar com esses problemas no código. Em segundo lugar, acabou a era da IA sem limites; a IA ilimitada já não está disponível. Cada vez mais, vemos conversas sobre tokens, otimização de tokens e eficiência no uso de tokens. Como melhorar essas arquiteturas, essas arquiteturas de engenharia rigorosas de que você precisa para usar a IA de forma eficiente e precisa? E, em terceiro lugar, essa conversa provavelmente ficou popular por causa de Satya Adela,

04:41 CEO da Microsoft, que começou a falar sobre a arquitetura necessária sobre os modelos comuns para que a IA específica de cada domínio funcione. Há uma classificação ampla, certo? Quando você considera tarefas de geração, não tem uma saída ou um resultado específico em mente. Você não quer especificar para a IA exatamente como uma imagem, um blog ou um site deve ser. É aí que surge a euforia. Mas, quando você pensa no outro lado de uma tarefa, em que existe uma única resposta correta que você quer que a IA alcance,

05:12 é aí que a decepção começa a aparecer. Na maioria dos casos, as pessoas chamam isso de última milha, mas essa é a milha mais longa que você tem de percorrer com a IA. Por isso, você precisa dessas arquiteturas para se concentrar em um problema específico. Além de tudo isso, operar sistemas de produção também é um problema que envolve várias pessoas e vários sistemas. Você não faz isso sozinho. Com o tempo, precisa envolver pessoas de equipes diferentes. Todos nós nos especializamos em diferentes áreas da engenharia. Somos distribuídos em equipes diferentes.

05:44 Precisamos conversar para resolver problemas em sistemas de IA. Desculpem, em sistemas de produção. Em resumo, nossa empresa, a Resolve AI, começou com uma única tese. Acreditamos de verdade que a maior parte de todo esse trabalho que vocês fazem em sistemas de produção, como corrigir problemas ou operar seu software no dia a dia, deveria ser feita por agents. Essa é uma das razões pelas quais perguntei se vocês podem afirmar com segurança que 90% ou mais do seu trabalho é feito por agents e

06:14 que os engenheiros deveriam apenas operar esses agents, enquanto eles cuidam de corrigir e operar seu software. Foi por isso que criamos a Resolve AI com três categorias de agents. Há agents de plantão para corrigir os problemas de software que surgem no dia a dia. E há agents de incidentes, que ajudam a conduzir os canais de incidentes e a levar você de um incidente complexo até a causa raiz e a solução. Por fim, há agents de segundo plano, sempre ativos, que ajudam nas tarefas de produção. Isso inclui coisas como monitoramento de deploy, qualquer

06:44 análise que você precise executar ou qualquer condição que você acione quando quiser que uma investigação específica aconteça. Por trás de tudo isso está a mesma arquitetura do agent da Resolve. É sobre isso que vamos falar hoje e sobre o que é preciso para chegar lá e criá-la. Então, vamos começar com uma pergunta: por que isso é necessário? Por que não podemos simplesmente apontar o maior modelo para os dados de produção? Os modelos estão, é claro, melhorando; a capacidade de raciocínio está melhorando. Para corrigir problemas no seu software, isso realmente funciona bem em demonstrações

07:14 quando você se concentra em um caso de uso específico e cria seu harness em torno dele; o resultado é uma demonstração muito boa. Mas, aos poucos, quando você começa a expandir para vários casos de uso e equipes, é aí que algumas falhas bastante conhecidas começam a aparecer no sistema. Então, que tipos de falhas vimos à medida que o produto foi crescendo? A primeira coisa que você vai notar é que os modelos têm, é claro, viés de ancoragem. Esse é um problema muito sério que você precisa tratar nos próprios harnesses. Eles foram projetados para dar uma resposta coerente.

07:46 E, antes de tudo, à medida que novos modelos começam a surgir com melhores capacidades de raciocínio, você também precisa acompanhar essa evolução. Você também precisa avaliar continuamente, primeiro, qual modelo é adequado para a tarefa e atualizar o modelo certo para seu caso de uso. E, segundo, há um aspecto um pouco negligenciado. Sempre associamos um modelo a um workflow ou a um resultado, mas todo workflow tem centenas de tipos diferentes de tarefas. Há tarefas de raciocínio,

08:17 há tarefas determinísticas pelas quais você passa, há coisas como geração de imagens, raciocínio sobre imagens ou raciocínio que envolve imagens, SQL ou coisas como logs. Todos os modelos — os modelos de ponta que vemos por aí — são bons em uma parte ou em um tipo específico de tarefa. Então, o mecanismo de orquestração que você precisa imaginar para alternar entre esses modelos em um workflow, primeiro, precisa acompanhar a evolução dos modelos e, segundo, precisa conseguir associar o melhor modelo à

08:48 melhor tarefa. E o segundo modo de falha são, claro, as context windows. Sei que elas estão se expandindo, mas as context windows não são apenas o problema para resolver um problema complexo como esse. A segunda parte é que, se você fornecer contexto suficiente, os modelos começam a explorar demais. Eles começam a formular hipóteses que nem sequer existem ou que, às vezes, podem não levar à resposta certa. Agora, se você fornecer um contexto muito limitado, é claro que eles

09:18 exploram de menos. Não conseguirão chegar a — na verdade, não terão visibilidade sobre quais outros caminhos existem ou quais outras hipóteses potenciais podem existir para resolver um problema. Isso se torna um enorme problema, especialmente em incidentes de produção, porque a telemetria é literalmente infinita. Você pode criar quantas linhas de log quiser, quantas métricas quiser. E, quando começa a combinar isso com seu código e sua infraestrutura, é aí que começam a aparecer as verdadeiras rachaduras no sistema. O terceiro, e o meu favorito, é

09:50 definir o raciocínio causal. Os modelos existem para agradar você. Quer dizer, todos nós já nos deparamos com casos de uso em que, se você pressionar o modelo o bastante, ele começa a concordar com você em todas as direções. Os modelos são projetados especificamente para dar respostas coerentes, mas não para estabelecer causalidade. Já em incidentes de produção, a única coisa que você procura é uma cadeia causal de evidências, como um detetive. Quais foram as etapas que levaram a um determinado incidente, para que você possa corrigir o problema certo em vez de criar um remendo. Então, especialmente quando

10:22 você está resolvendo um problema difícil, como o raciocínio sobre incidentes de produção, precisa haver raciocínio causal incorporado ao modelo, incorporado ao sistema, e não apenas respostas coerentes. O próximo ponto são, claro, as proteções. Não vou me alongar muito nesse assunto, mas todos nós já lemos alguma notícia ou outra sobre uma IA que está apagando um determinado sistema de arquivos ou um banco de dados. Isso também é um recurso, não um bug. A IA pode ter determinado que a solução mais limpa possível é simplesmente excluir aquele trecho de código específico. Você

10:54 não pode culpá-la por isso. Só precisa criar proteções ao redor do sistema para que ele funcione da maneira certa. Qual é o acesso de menor privilégio com que a IA pode operar em qualquer cenário? E, por último, os ciclos de aprendizado. Qualquer sistema que você construir deve ser escalável para sua equipe ou, idealmente, para sua organização. Como eu disse no início, sempre que você usa IA em incidentes de produção, trata-se de um problema colaborativo. Há várias equipes diferentes envolvidas, como SR, equipes de plataforma, engenheiros de backend ou engenheiros de serviço; todas essas pessoas

11:24 devem estar envolvidas e, o mais importante, todas devem ter o mesmo contexto. Agora, quando você acrescenta discussões ao longo do tempo, seu sistema de IA deve ter o mesmo contexto da investigação anterior na centésima investigação; caso contrário, você recomeça do zero. Esses são os modos de falha em que vimos as rachaduras aparecerem. Por isso, construímos uma arquitetura de agent que responde exatamente a essas mesmas perguntas. Há seis partes principais em qualquer arquitetura de IA

11:58 que precise funcionar em um domínio específico. Menciono um domínio específico porque os modelos são voltados ao raciocínio de propósito geral. Para aproveitar esses modelos e chegar a uma resposta específica, você precisa cuidar de seis pilares diferentes. O primeiro é a orquestração de modelos. Como mencionei, a orquestração de modelos tem duas camadas. Primeiro, como acompanhar a evolução contínua dos modelos e os modelos mais recentes? E, segundo, como escolher o melhor modelo para a tarefa? É o Gemini para raciocínio específico sobre im — imagens — ou é

12:29 a OpenAI para etapas determinísticas ou o claude para investigações abertas? Você precisa avaliar continuamente qual é o melhor modelo possível para a tarefa naquele momento. Esse é um mecanismo que construímos logo no início. O segundo pilar é a engenharia de contexto. Muitas vezes, a engenharia de contexto é reduzida a algo como o banco de dados ou uma solução de execução. Ah, você está usando um RAG em grafo? Está usando um grafo de conhecimento? Está usando x, y e z? Tudo isso são detalhes de implementação.

12:59 Mas o que importa como objetivo é: qual é a quantidade exata de contexto de que a IA precisa para resolver aquele problema específico? E, na maioria das vezes, trata-se de uma combinação de técnicas. Talvez seja necessário usar uma solução do tipo RAG em grafo para que a IA comece as investigações e, quando você avançar para as etapas seguintes, precisará determinar — precisará definir — chamadas de ferramenta muito precisas para não consumir tokens muito rapidamente ao fazer várias chamadas de ferramenta, na forma de consultas de logs, de métricas, de dashboards ou de consultas de código, etc.

13:31 O terceiro pilar é o raciocínio causal, como mencionei. Esse é um dos primeiros princípios que incorporamos ao nosso sistema na Resolve AI, em que a causa raiz se baseia sempre em uma cadeia causal de evidências. Quais foram as etapas exatas ou precisas que levaram a esse problema específico? Se você não conseguir estabelecer essa cadeia de evidências, temos que apresentar essa informação com um nível baixo de confiança e apontar o usuário em outra direção. Isso vale para qualquer IA de domínio

14:02 específico e também vale para a Resolve AI, que aponta você em outra direção se não encontrarmos os dados além de determinado ponto. O próximo pilar, como eu disse, são as ações governadas. Isso é bem direto. Depende de cada equipe e de cada organização, dos níveis de acesso ou das restrições que você tem, ou talvez do setor em que atua. Quais são as proteções específicas que você precisa definir para a IA operar? Ela pode ler? Pode escrever? E, para escrita, quais

14:33 são as condições específicas? E assim por diante. Por último, um sistema de aprendizado. Pense assim: cada interação que você tem com um sistema de IA é uma oportunidade de aprendizado. O sistema de IA precisa aprender não só com a investigação que está conduzindo, mas também com a forma como o usuário interage com ele. Estou dando a você um reforço positivo? Isso está se tornando um eval positivo? Estou dando algum reforço negativo? Estou orientando você ou direcionando a investigação para uma direção específica?

15:03 Esses são diferentes tipos de evals. Isso nos leva ao último ponto, em que os evals também são uma etapa muito importante. Esse é o ponto de partida e de chegada de qualquer arquitetura de agent. Pensamos nos evals em cinco níveis diferentes, como mencionei. Que reforço positivo você pode dar? Que reforço negativo pode dar? E podemos rastrear seu caminho? Como você chegou a essa solução? Podemos dar uma pontuação a você, como faríamos com um engenheiro? Como um engenheiro excelente conduziria essa investigação? E como você se compara a ele? E, além disso, como

15:35 Você se calibrando como IA? Como está indicando esse nível de confiança? Então, tudo isso são evals sistemáticas de infraestrutura de avaliação que você constrói em uma plataforma e que precisa usar constantemente para testar a arquitetura sempre que há um novo modelo, um novo caso de uso ou uma mudança na arquitetura. Beleza. Já falei o suficiente. Vou mostrar na prática como isso funciona no Resolve. Como mencionei, nossa plataforma está lá especificamente para isso. Existem duas categorias de agents.

16:06 com que trabalhamos. Uma é um agent de plantão, outra é um agent de incidentes e, claro, o agent em segundo plano. Como a maioria de vocês aqui é de engenharia, talvez conheça esse sistema. Claro, a maioria dos alertas de telemetria ou observabilidade dispara em uma ferramenta de colaboração como Slack, Microsoft Teams ou qualquer outra que vocês usem. Neste caso, vemos o Grafana disparando alertas no nosso canal comum do Slack. Então, o Resolve detecta esses alertas automaticamente e inicia uma investigação. O que vocês veem aqui é…

16:37 ele está indicando um erro relacionado a uma skill de logs e começa a apresentar qual é a causa raiz que encontrou para o alerta recebido, além de outros fatores contribuintes ou outras hipóteses que descartou. Ele apresentou rapidamente a causa raiz, as evidências e as recomendações. Mas vamos nos aprofundar. Como eu disse, na maioria dos casos, essa deve ser uma experiência colaborativa. Então, vamos entrar na interface e ver o que está acontecendo nos bastidores. O trabalho começa no Resolve AI.

17:08 quando ele trata o alerta recebido como um prompt. Ele recebe o prompt e inicia vários agents, na verdade, duas categorias diferentes de agents, para realizar o trabalho. A primeira categoria de agents são basicamente investigadores. Eles são treinados para conduzir a investigação, como um engenheiro faria: primeiro, identificar o problema, reunir mais informações de métricas, traces e assim por diante, descobrir onde o problema está ocorrendo por meio de traces e logs e, então, começar a correlacionar isso com eventos de mudança ou qualquer novo…

17:41 deployments que tenham sido realizados, além do seu código e da sua infraestrutura. Essencialmente, ele faz essa tradução ou raciocínio entre quatro tipos de fontes de dados: seu código, sua infraestrutura, suas bases de conhecimento e suas plataformas de observabilidade. Com base em tudo isso, ele começa a apresentar esta causa raiz. O que vimos foi que uma das skills de logs está enfrentando uma taxa de falhas muito alta. Ele rastreou o problema até algumas integrações obsoletas que ainda estão ativas no sistema. O…

18:12 interessante é que ele também mostra algumas hipóteses descartadas. Em geral, começaríamos uma investigação e, ao mesmo tempo, houve uma interrupção no GCP. Então, isso também poderia ser uma correlação perfeita, certo? Voltando à IA projetada para dar respostas coerentes: houve uma interrupção no GCP ao mesmo tempo. Então, é claro, esse poderia ser o problema que estamos vendo, ou poderiam ser outros picos de tráfego que ela está observando, sem uma integração correspondente. Esse seria o outro caminho que você…

18:42 começaria a investigar. Então, digamos que sou um engenheiro novo, estou começando e o Resolve apresentou isso como causa raiz. Claro, também projetamos o sistema para operar com uma política de confiança mínima. Então, digamos que eu possa destacar isso e ele me inclua, para que eu possa investigar melhor. Neste caso, digamos que vamos perguntar ao Resolve: isso está relacionado à interrupção no GCP? Então…

19:13 ele apresenta a resposta aqui, mas há outras perguntas específicas que fiz e quero compartilhar com vocês. Houve outros erros de deployment ao mesmo tempo, e foi isso que eu estava questionando o Resolve. Voltando ao que mencionei: se você pressionar demais uma IA, ela vai começar a concordar com você. Projetamos o sistema para evitar isso. Ele só vai basear as respostas na cadeia causal de evidências que criou. Como consegue estabelecer isso, consegue dar uma resposta muito coerente. Isso também me permite incluir meus…

19:44 colegas de equipe, para que isso realmente se torne uma experiência colaborativa. Digamos que eu possa incluir alguém e perguntar: “Você pode dar uma olhada nisso?” Posso chamar meu colega diretamente pelo Slack para colaborarmos nessa experiência de sala de guerra virtual. Essa foi uma demonstração rápida. Como eu disse, o que temos atualmente e o que abordei hoje é apenas um eixo da arquitetura. Há também o outro eixo da arquitetura, que é simplesmente transformar uma IA em um produto. Se você quiser…

20:17 colocar isso diante de qualquer usuário ou cliente, precisa garantir que funcione em uma plataforma robusta. Esses são os outros aspectos que você precisa considerar, mas são coisas com as quais já estamos familiarizados. Então, esse foi o meu tempo. E, se tiver interesse em saber mais sobre o Resolve AI, quais clientes estão usando o produto atualmente e como o utilizam, visite nosso estande L28, acredito. E, a propósito, antes de irem embora, peguem aquelas bolsas legais que estão logo ali fora. Muito obrigado.

21:02 >> [música]

Transcrição original

[00:01] [music] Uh, can everyone hear me? Okay, awesome. Thank you so much uh for attending the session. Um, my name is Vun. I’m part of the team at Resolve AI. We are building AI for prod. uh basically we’re building agents to run and fix your software. So in this session we’ll cover what are the six

[00:32] pillars of an agentic harness that you’ll need in a system that is there to fix and run your software. Uh before I get into the session just a quick show of hands just to understand for me to understand who’s there in the audience. I’m assuming most of you are engineers. Uh how many of you have been on call before? Uh quick show of hands. Awesome. Have you tried to use AI to help you with your on call? Show of hands. Awesome. For the people who raise their

[01:03] hands, uh can you tell me that 90% of your on call work is being done by AI? Uh can you comfortably say that? Awesome. Yes, that’s what we realized when we started the company as well. This is a really hard problem to solve. So, and in this session, I want to share like our journey. What is the evolution we went through? what are some of the learnings we had specifically in building such an agentic harness. Before I get in um I want to set context on uh what we are experiencing today. So the

[01:33] first wave of AI really was focused on coding and uh truthfully I think most of the most for most of us the way we code has fundamentally changed and I also wanted to share context on why that is the case. Uh firstly code in itself is self-documenting. It’s easy for AI to actually parse and understand what’s there to help you out with the next step. Second, inherently code is very modular. So it’s easy for for AI to actually break it down as chunks and

[02:05] navigate to the next step and also help you extend and build and be build beyond it. Third and the most important thing is code is single domain. Um you do not need to teach AI multiple domains to reason across them. it’s easily able to navigate to the next step and that is one of the reasons why we have such defined benchmarks as well. You can objectively assess how good is AI in solving this problem for you. But in reality for engineering 70% of our time is spent on the other side not

[02:36] generating new software but rather in in production systems basically running and fixing software. uh and this ranges through a broad range of issues as well right like operating and running software typically you can actually put it in three broad buckets like one is u think of the healthcare analogy that’s the easiest way I like to think about it as well one is the regular on call and maintenance think of this as regular small problems that are coming your way

[03:07] maybe you need a Tylenol for uh some for some pain that you have maybe you need an Advil so These are the regular on call style alerts that you need to deal with. Second category is the incidents where you need all hands on deck. It’s equivalent to a surgery. Systems are shutting down. You need everyone’s attention who’s uh who’s involved or responsible to come in and fix it. And the third category is more like your daily vitamins. So you need to do a lot of things on a regular basis to keep to maintain the health of your system going

[03:39] on. So be it things like taking a look at your infrastructure, taking a look at your costs or maybe some platform engineering work that you do to scale. So these things are fundamentally hard because they’re not exactly like code. They cut across multiple different domains, multiple different tools and that is the repercussions that we are starting to see when the euphoria of initial initial euphoria of AI is starting to settle in. And that’s what you’re seeing in the news right now. So there’s a lot more talk about the number of issues maybe AI generated code is starting to create in production and

[04:10] there is talk around what are the right frameworks to deal with these uh issues in code. Second uh the era of bottomless AI is over like the unlimited AI is no longer there. You can increasingly see conversations about tokens token optimization token efficiency. How do you basically improve those architectures, those rigorous engineering architectures that you need to efficiently and precisely use AI? And third, uh this is the conversation that is probably made popular by Satya Adela

[04:41] who’s the CEO of Microsoft where he started talking about the architecture you need on top of your regular models for any domain specific AI to work. So there is a broad classification, right? like whenever you look at a generation tasks, you don’t have an output or an outcome in mind. Uh you don’t want you’re not specifying to AI exactly how an image should look like, how a blog should look like or how a website should look like. So that’s where the euphoria sets in. But when you think of a flip side of a task where you have a single correct answer that you want AI to get

[05:12] to that is when the disappointment starts to set in which in most cases most people dub it as a last mile but that is the single longest mile that you have to run with AI that is why you you need these architectures for you to focus on a specific problem. Now beyond all this uh operating production systems is also a multiplayer and a multi system problem. You’re not just doing it on your own. You need to pull inmemes for for different teams over time. All of us have specialized in different categories of engineering. We are put in different

[05:44] teams. Uh we need to talk to to solve to resolve any issues across AI. So sorry across your production systems. All in all uh our company resolve AI started with a single thesis. So we genuinely believe that all of this uh all of this work that you do on production systems like fixing issues or like uh running your software on a day-to-day basis should be done by agents in most part. That’s one of the reasons why I was asking can you confidently tell 90% of your work or more is being done by agents and

[06:14] engineers should just be running those agents where agents take care of like fixing and running your software. So that’s why we’ve built uh resolve AI as three categories of agents. There are on call agents to fix your software issues that come in on a daily basis. And there are incidents agents that will help you drive incident channels and get you get you from a complex incident to a root cause and fix. And lastly, there are ambient background agents that will help you with your production tasks. Be it things like deployment monitoring or any

[06:44] of the analysis that you have to run or any of the conditions that you trigger where you want a specific investigation to happen. underneath all this is the same resolve agent architecture that is what we’ll be talking about today uh and what it takes to get there to build it. So let’s start with a question. So why is this even required right like why can’t we just point the biggest model at production data models are of course getting better the reasoning capacity is getting better uh to fix your software issues it it genuinely demos well

[07:14] whenever you focus on a particular use case and you build your harness on top of it shows up with a very good demo but slowly as you start to scale across use cases and teams that is where uh some that is where very familiar cracks start to appear in the system so what are the kind of cracks that we have seen as you start to scale in the product along the way, right? First thing you’ll notice that of course models will have anchoring bias. This is a very strong thing that you have to deal in your harnesses itself. They they’re designed to give you like a coherent answer. Um

[07:46] and first of as and when new models start to come out with better reasoning capabilities, you also need to maintain the treadmill. uh you also need to continuously change uh which evaluate firstly evaluate which model is suitable for the task and also update uh the right model for your use case and second and a little bit of an overlooked item. So we always associate a model to a workflow or an outcome but every workflow has hundreds of different types of tasks. So there are reasoning tasks,

[08:17] there are deterministic tasks that you go through, there are things like image gener image reasoning or you’re reasoning across images, you’re reasoning across SQL or things like logs. Now all the models frontier models that you see around each of them is good at a specific part or a specific uh kind of task. So the orchestration engine that you need to imagine for uh moving across these models for a workflow first of all needs to keep pace with how models are evolving and second it needs to be able to marry the best model for

[08:48] the best task and second failure mode uh is of course the context windows. I know the context windows are expanding but context windows context windows are not just the problem uh for for solving for for solving a complex problem like this. The second part is if you provide large enough context, models start to overexplore. It’ll start to come up with hypothesis that don’t even exist or sometimes might not even get you to the right answer. Now, if you supply very limited context, of course, they

[09:18] underexplore. They won’t be able to get to they won’t actually have visibility into what other pathways exist or probably what other potential hypothesis can exist in solving a problem. Especially for production incidents, this becomes a huge issue because telemetry is literally infinite. You can start to create as many log lines as you want, as many metrics as you want. And now when you start to marry that with your code and infrastructure, that is when real real cracks in system uh starts to appear. Third and my and my most favorite one is

[09:50] uh defining causal reasoning. So models are there to please you. I mean, we’ve all come across these use cases where you push the model hard enough, uh, it’ll start to agree with you in every different direction. So, models are specifically designed to give you coherent answers, but not causality. But production incidents, the only thing you’re looking for is a causal chain of evidence like a detective. What are the steps that took place that led to a particular incident so that you can actually fix uh the right issue instead of creating a patch. So especially when

[10:22] you’re solving a hard problem like production reasoning you need causal reasoning built into the mod built into the system not just coherent answers. And the next one is of course guardrails. I won’t harp on this topic too much but all of us have read uh some news or the other where let’s say AI is going and deleting a particular file system or like a database. Uh so AI it’s also this is a feature right not a bug. uh AI might have determined that the cleanest possible fix is just deletion of that particular code snippet. You

[10:54] can’t fault it for it. You just have to build guard rails uh around the system so that it works in the right fashion. What is the least privilege access that AI can operate with in any given scenario? And lastly, learning loops. Any system that you build should be scalable across your team or your organization in the best case. Every time you’re using AI for production incidents, like I said at the starting, it is a multiplayer problem. You have multiple different teams like SR, platform teams, uh backend engineers or service engineers, all of these people

[11:24] should be involved and most importantly all of these people should have the same context. Now when you add temporal discussions on top of it like uh your AI system should have the same context of a previous investigation in the 100th investigation or else you’re starting the wheel from the same time again. So these are the failure modes where we’ve seen the cracks appear. So that’s why we’ve actually built an agent architecture that answers these same questions exactly. So there are six major parts uh for any AI architecture

[11:58] that has to work in a specific domain. The reason I’m mentioning it as a specific domain is models are there for general purpose reasoning. Now when you want to harness these models into a specific answer, you need to take care of six different pillars. The first one is model orchestration. Like I mentioned, uh model orchestration is two layers. one, how do you keep up with the model treadmill with the latest models? And second, how do you match the best model for the task? Is it Gemini for im uh image specific reasoning or is it

[12:29] OpenAI for deterministic steps or is it claude for open-ended investigations? You need to constantly keep evaluating what is the best uh possible model for the task at that point in time. So this is an engine that we’ve built uh up front very early. Second is context engineering. Now context engineering is often minimized to like uh the database or an execution solution. Oh, are you using a graph rag? Are you using a knowledge graph? Are you using x y and z? Those are all implementation details.

[12:59] But what matters as a goal is what is the precise amount of context AI needs to solve that specific problem. And more often than most often than not, it’s a combination of techniques. you might have to use a graph rag kind of a solution for AI to start investigations and when you actually further go into the next steps you need to determine you need to define very precise tool calls so that you don’t burn through tokens very quickly when you’re making multiple tool calls in in form of log queries in form in form of metrics or dashboards or

[13:31] code queries etc. The third one is causal reasoning like I mentioned. So this is one of the first uh principles that we’ve built into our system at resolve AI where uh the evident the root cause is always based on a causal chain of evidence. What are the exact or precise steps that happened that led to this particular issue? If you’re not able to establish that chain of evidence, we have to give out that information with a low confidence level and point the user in a different direction. This is true for any domain

[14:02] specific AI and this is true for resolve AI as well where we are pointing you in a different direction if we don’t see the if we don’t see the data beyond a particular point. The next one like I said is governed actions. This is quite straightforward. Uh it depends upon every team, every different organization uh depending on uh depending on the access levels or probably the restrictions that you have or the industry you operate in. What are the specific guardrails that you need to define for AI to operate under? Is it read? Is it right and under right? What

[14:33] are the specific conditions for right? Uh etc., etc. And lastly, a learning system. So, think of it like this. Every interaction that uh you’re doing with an AI system is an opportunity for learning. So, uh AI system has to learn not just from an investigation it is going through, but from a how from how a user is actually interacting with it. Like am I giving you positive reinforcement? So is this turning into a positive eval? Am I giving you some negative reinforcement? Am I am I guiding you or steering the investigation in a specific direction?

[15:03] Those are different kinds of evals. So that leads into the last piece which where eval is also a very critical step. So this is the starting point and ending point for any agent architecture. So the way we think about evals is in five different levels like I mentioned. What is the positive reinforcement you can give? What is the negative reinforcement you can give? And can we trace your path? How did you come up with this solution? Can we score you like an engineer based on that? How would the how would a best engineer perform this investigation? And how do you compare against it? And on top of it, how are

[15:35] you calibrating yourself as as AI? How are you giving out that confidence level? So all these are systematic eval infra evals that you build into one platform that you constantly have to push the architecture against whenever there’s a new model, whenever there’s a new use case or whenever there’s an architecture change. Cool. There’s enough talking. So let me actually show you this in action on how it works in resolve. Like I mentioned our platform uh is specifically there. So there are two categories of agents

[16:06] that we work with. One is an on call agent, one is an incident agent and of course the background agent. So uh since like I’ve since most of you are engineers over here, you might be familiar with the system. Of course most of your telemetry or observability uh alerts are firing into a collaboration tool like Slack or Microsoft Teams or whatever you might be using. In this case, what we are seeing is Graphfana fire firing alerts into our common Slack channel. Um so Resolve automatically picks up those alerts and kickstarts an investigation. What you see here is uh

[16:37] it is throwing an error about a log skill and it starts to provide what is the what are the uh what is the root cause that it found for the uh alert that came in and also the other contributing factors or other theories it rejected. It gave a quick root cause and evidence and recommendations. But let’s actually deep dive. So in most cases like I said this should be a multiplayer experience. So let’s actually go into the UI and see what’s happening here behind the scenes. So uh it the work starts off from resolve AI

[17:08] when it treats the alert that’s coming in as a prompt in itself. So it takes the prompt and it spins up a bunch of different agents actually two different categories of agents uh to get the work done. So first category of agents are basically investigators. So they are uh trained to actually uh go through the investigation just like how an engineer would firstly find out what is the issue gather more information from metrics and traces etc and figure out where the issue is happening from traces logs and now start to correlate that with things like change events uh or any of the new

[17:41] deployments that would have gone in and your code and your infrastructure. So primarily it’s doing this translation or reasoning across four types of data sources. your code, your infrastructure, your knowledge bases and your observability platforms. Based on all that it starts to give out this uh root cause or this root cause what we’ve seen there are so one of the log skill is actually experiencing high high failure rate. It trace the issue all the way down to some stale integrations that are still live in the system. The

[18:12] interesting part is it’s also showing out some other ruled out theories where generally we would start an investigation at the same time there was a GCP outage. So you would actually uh this this would be a perfect correlation as well right going back to AI that is designed to give you coherent answers. So a GCP outage happened at the same time. So of course this might be the issue uh that we are seeing or there are other traffic spikes that it is experiencing uh without missing integration. So uh that would be the other thread that you

[18:42] would start to pull on. So let’s say if I’m a new engineer, if I’m starting in okay resolve gave uh this as a root cause of course it’s we have also designed to go operate with the least trust policy. So let’s say if I I can start to highlight and it’ll start to it’ll pull me in so that I can interrogate this further. uh in this case let’s say uh let’s ask resolve uh is this related to uh GCP outage so

[19:13] it’s giving out the answer here but there is other other precise questions that I ran I want to share with you so there was other deployment errors that happened at the same time so that is what I was pushing resolve on going back to what I mentioned if you push uh an AI hard enough it’ll start to agree with you we’ve designed the system to go against it. It’ll only base its answers based on the causal causal chain of evidence that it created. Since it is able to establish that, it’s able to give out a very coherent answer. So, this uh also lets me actually pull in my

[19:44] teammates so that this truly becomes like a multiplayer experience. Let’s say if I give uh I can pull in, can you take a look at this? This can pull in my teammate directly from Slack so that we can collaborate on this virtual war room experience. This was a quick demo like I said uh the currently and what I talked about today is just one uh axis of the architecture right like now there is the other axis of the architecture where you just need to productize an AI like if you want to

[20:17] put this in uh in front of any user or a customer you need to make sure it runs on a robust platform those are the other aspects that you have to think through but this is something that we are always familiar with so that’s been my time. And uh if you’re interested to learn more about uh about Resolve AI and which customers are currently using us and how are they using it, uh please check us out at the booth L28, I believe. Uh and by the way, before you leave, take out those cool bags uh that are right outside. Thank you so much.

[21:02] >> [music]