Seu agente de IA não tem sistema nervoso — Matt Gibiec, Dynatrace

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

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

Idioma original: inglês

Vídeo original: Your AI Agent Has No Nervous System — Matt Gibiec, Dynatrace · Canal: AI Engineer · 15:34 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Engenharia de software com IA

Resumo

Matt Gibiec argumenta que agentes de IA precisam de contexto sobre o ambiente em que operam para tomar decisões úteis e evitar tarefas repetitivas, alucinações e impactos indesejados. Ele apresenta o Blue Box, da Dynatrace, como uma forma de levar dados de produção, dependências entre serviços e histórico operacional aos agentes e desenvolvedores. Com esse contexto, seria possível testar mudanças com mais segurança, detectar problemas antecipadamente, orientar correções e planejar funcionalidades antes de escrever prompts. A proposta também preserva a supervisão humana, permitindo que as pessoas decidam se as mudanças devem chegar à produção.

Pontos-chave

• Agentes podem ficar presos em ciclos repetitivos quando não conseguem adaptar sua abordagem com base nos resultados.
• Sem contexto suficiente sobre sistemas, dependências, permissões e uso das aplicações, os agentes podem tomar decisões inadequadas.
• O Blue Box, da Dynatrace, fornece contexto do ambiente aos agentes de codificação e a outros agentes.
• O mapeamento de serviços e dependências ajuda a avaliar se mudanças locais podem afetar outros componentes em produção.
• Dados históricos podem ajudar a identificar desvios do comportamento normal e alertar sobre problemas antes que afetem usuários.
• O contexto de alterações no repositório pode ajudar a relacionar uma falha a uma mudança recente.
• O contexto também pode orientar a correção de problemas sem introduzir novos impactos no restante do ambiente.
• Planejar antes de escrever prompts ajuda a esclarecer o que uma funcionalidade precisa entregar aos usuários.
• A automação deve manter o controle humano sobre a decisão de publicar uma funcionalidade ou correção.

Capítulos

Início	Capítulo	Resumo
00:01	Por que agentes precisam de contexto	O palestrante apresenta o problema dos agentes presos em ciclos e a necessidade de contexto para avaliar seu valor e suas decisões.
03:41	Contexto como sistema nervoso dos agentes	A palestra relaciona a falta de dados e contexto a decisões equivocadas e introduz o Blue Box, da Dynatrace.
06:57	Testes e dependências com Blue Box	O Blue Box é apresentado como meio de levar contexto de produção aos testes locais e avaliar o impacto de mudanças entre serviços.
10:38	Detecção e correção de problemas	O palestrante explica como contexto operacional e histórico pode ajudar a detectar problemas, relacioná-los a mudanças e orientar correções.
13:16	Planejamento, automação e controle humano	A palestra aborda o planejamento antes de escrever prompts, a automação com supervisão humana e o convite para testar o Blue Box.

Citações

Os agentes operam em alta velocidade, mas sem visão. — 04:11

Contexto é essencial. — 06:24

Planeje antes de escrever o prompt. — 12:43

Queremos ajudar os agentes a enviar para produção código em que você confia. — 14:19

Conceitos e entidades

• Dynatrace (empresa): Empresa que oferece uma plataforma de observabilidade e apresenta o Blue Box na palestra.
• Matt Gibiec (pessoa): Diretor regional de engenharia de soluções para IA nativa na Dynatrace e palestrante.
• Bernd (pessoa): CTO citado por Matt Gibiec ao introduzir a ideia de agentes rápidos, mas sem visibilidade.
• Blue Box (ferramenta): Solução apresentada pela Dynatrace para fornecer contexto de produção e dependências a agentes e desenvolvedores.
• Claude (modelo): Assistente citado como exemplo de agente que pode repetir ações quando não obtém o resultado esperado.
• observabilidade (conceito): Prática de compreender o comportamento de aplicações e ambientes, incluindo serviços, erros e desempenho.
• Contexto de produção (conceito): Dados e informações do ambiente real que ajudam a orientar testes, decisões e correções.
• human-in-the-loop (conceito): Abordagem em que uma pessoa mantém controle e participa de decisões importantes da automação.
• SDLC (conceito): Ciclo de vida de desenvolvimento de software, no qual a palestra propõe integrar o Blue Box.

Tradução completa (pt-BR)

00:01 [música] >> Certo, são 11h10, então oficialmente chegou a hora da nossa sessão. Muito obrigado a todos por participarem. Sei que este é o último dia da conferência, então agradeço muito a todos vocês que quiseram vir na quinta-feira e ouvir sobre o nosso tema. Meu nome é Matt Gibiits e sou o

00:33 diretor regional de engenharia de soluções para IA nativa na Dynatrace. Levantem a mão: alguém sabe o que é a Dynatrace? Certo, temos algumas mãos levantadas. Somos uma plataforma de observabilidade, uma plataforma de observabilidade com IA, mas hoje não vamos falar muito sobre a Dynatrace. O que queremos abordar hoje é um tema um pouco diferente. Como vocês viram no título da sessão, o tema é: seu AI agent não tem sistema nervoso. Provavelmente é um título intrigante, e vocês estão

01:04 pensando: bom, é claro que não tem sistema nervoso, não é uma pessoa. Mas, se vocês pensarem em como os AI agents estão sendo usados hoje, estamos usando esses agentes para substituir coisas que as pessoas costumavam fazer. E, muitas vezes, para isso, precisamos de raciocínio. Quando pensamos bem, se precisamos de raciocínio, precisamos que esses agentes consigam não necessariamente se comportar como humanos, mas receber informações suficientes para entender o que precisam fazer e realmente nos ajudar na organização, em vez de apenas automatizar coisas que não estão

01:36 necessariamente funcionando muito bem hoje. Dito isso, vamos destrinchar o assunto. Levantem a mão novamente: quantos desenvolvedores temos aqui na sala? Certo, ótimo. Algum líder de equipe? Certo. E a última talvez seja um pouco mais difícil: temos algum chefe de engenharia aqui? Você se consideraria chefe de engenharia? Certo, ótimo, temos uma pessoa. Se vocês olharem para essas perguntas, não vamos passar por todas. Só temos mais 18 minutos aqui. Mas, se olharem para essas

02:07 perguntas, algum de vocês já se perguntou, ou alguém já perguntou, por que estou preso em um loop com meu agent? Quantos de vocês já usaram, por exemplo, o Claude, e ele continua repetindo a mesma coisa sem parar, consumindo tokens e não entregando o resultado que vocês querem? Alguém já passou por isso? Todo mundo, né? Agora, pensando do ponto de vista humano, se vocês, como pessoas, fizerem uma pesquisa e obtiverem resultados que não são os que querem, mudarão de abordagem. Vão tentar por outro ângulo.

02:41 Mas os nossos AI agents de hoje não são inteligentes o suficiente para fazer isso. Certo, vamos passar para outra pergunta. Gosto da pergunta do meio, em “líder de equipe”: como posso lidar com problemas operacionais? Vocês já estão pensando nisso hoje ou, neste momento, ainda estão empolgados com a ideia de simplesmente fazer o deploy, colocar as coisas para funcionar e resolver todo o resto depois? Alguém aqui está tendo problemas operacionais com seus agentes? De vez em quando, talvez. Certo, vou acrescentar uma reviravolta.

03:11 E quanto às preocupações com segurança? Essa foi fácil, né? Acho que todo mundo levantou a mão aqui. Então, novamente, essas são perguntas muito importantes que precisamos nos fazer. E a última que quero tentar com vocês: vamos olhar para a seção de chefe de engenharia. Gosto novamente da pergunta do meio: nosso aplicativo ou nosso agent traz valor para os usuários? Acho que entramos tão depressa no mundo e na era da IA que, muitas

03:41 vezes, vejo clientes — e passei três dias aqui conversando com as pessoas —, todo mundo está empolgado com a IA, com esse entusiasmo em torno dos AI agents. Mas como vocês medem o valor? Já têm instruções sobre como medir o valor dos seus AI agents? Não, né? E quase acho que, por mais que queiram avançar depressa e chegar lá, precisamos fazer uma pausa e entender o que realmente estamos tentando alcançar e como podemos medir o sucesso dos nossos agentes. Porque, se estamos usando nossos recursos de engenharia, tempo, esforço,

04:11 e dinheiro para criar esses agentes e utilizá-los de uma forma que acreditamos ajudar nossa organização, precisamos definir métricas que nos ajudem a fazer isso. Com todas essas perguntas, espero ter preparado um pouco o terreno para entrar no próximo tópico que quero discutir, introduzido aqui por uma citação do meu CTO, Bernd. Não vou ler tudo, mas vou destacar o que está em azul aqui. Os agentes operam em alta velocidade. Todos concordam? Eles são bem rápidos? Mas sem visão.

04:46 E o que queremos dizer com isso é que, hoje, esses agentes são tão bons quanto os dados disponíveis para que possam raciocinar e tomar uma decisão. Se os dados fornecidos ao nosso agent não tiverem contexto, não tiverem detalhes ou não tiverem as permissões necessárias para buscar dados em algumas das ferramentas do seu ambiente, vocês começam a esbarrar na palavra da moda: alucinações. Começam a executar processos e automatizar coisas no

05:16 seu ambiente que provavelmente não agregam valor, porque não há contexto suficiente no ambiente. E se eu dissesse que, na verdade, o que queremos fazer aqui é que o agent não precisa necessariamente ter sistema nervoso nem visão para ser eficiente e produtivo? Há, obviamente, uma pequena brincadeira no título desta sessão. Mas o que ele precisa é do contexto real do seu ambiente. Vocês podem escolher qualquer agent que esteja

05:51 por aí. Podem escolher o cenário simples do Claude e tentar automatizar coisas com o Claude no seu ciclo de vida de SDLC. Ao fazer isso, se o Claude não tiver acesso ao contexto do seu ambiente, se não conseguir entender as dependências dos seus serviços, se não conseguir entender como seus usuários usam seus aplicativos, começará a tomar decisões e dar recomendações que podem parecer corretas naquele momento,

06:24 mas não serão corretas a longo prazo, porque não há contexto suficiente para que esse agent entenda como é realmente o seu ambiente. Então, quero resumir este slide com esta frase: contexto é tudo. E o contexto é o sistema nervoso que vocês podem fornecer aos seus agentes. Assim, enquanto eles se comunicam, enquanto vocês automatizam coisas e criam novos processos, esse tecido conectivo de contexto impulsiona todos os processos que vocês estão automatizando com seus agentes.

06:57 Então, vamos ver alguns exemplos. Tendo isso em mente, o que quero apresentar a vocês é o Blue Box da Dynatrace. O Blue Box é, essencialmente, um agent que poderá ser integrado em qualquer etapa do ciclo de vida do desenvolvimento para fornecer contexto a qualquer um dos seus AI coding agents ou a outros agentes proprietários que vocês estejam desenvolvendo no seu ambiente. Tenho alguns slides para mostrar. Não vou abordar todos os cenários, mas vou destacar as coisas mais importantes que considero úteis.

07:27 Deixem-me apresentar este cenário. Quantas vezes vocês, como desenvolvedores, criaram um recurso, ou talvez até um recurso ou uma skill para um agent, testaram localmente e tudo funcionou muito bem? Localmente, tudo funciona muito bem, certo? Ficamos felizes, é ótimo. Então, fazemos o merge para a branch principal, enviamos para lá e, de repente, outros três serviços param de funcionar. Isso já aconteceu com algum de vocês? O impacto de vocês, mesmo que localmente tenha funcionado bem, depois que foi integrado com

08:00 outros agents, com outras aplicações, agora isso quebrou um processo no seu ambiente. Essa é uma das coisas mais importantes que o Blue Box by Dynatrace pode oferecer aqui. Poderemos trazer, essencialmente, o mapeamento de serviços e dependências para cada um dos seus agents, para cada uma das suas cargas de trabalho de IA. Então, enquanto você desenvolve e faz alterações, não está falando apenas de testar as coisas localmente. Agora poderemos usar o Blue Box para trazer o contexto de produção para os seus testes locais. Assim, você saberá se o recurso que desenvolveu não só funciona localmente

08:33 para você e para o que está tentando automatizar, para o que está tentando alcançar, mas também se ele não vai quebrar nem afetar negativamente qualquer outra coisa à qual o seu agent, à qual a sua carga de trabalho esteja conectado. Vamos dar uma olhada em outro exemplo aqui. Este é, sinceramente, um dos meus favoritos em todo o universo da observabilidade. Trabalho com observabilidade há 8 anos e acho que, se há um objetivo que pergunto a qualquer um dos meus clientes — o que você gostaria de alcançar com a sua estratégia de observabilidade

09:03 com IA agora? —, quando se trata de problemas, acho que todo mundo diria isso: encontrar problemas antes que eles se tornem problemas de verdade, antes que afetem minha organização, antes que afetem meus usuários. É exatamente isso que o contexto que o Blue Box traz para os seus agents poderá fazer por você. E como fazemos isso de verdade? Agora podemos entender, de ponta a ponta, as interações dos seus agents dentro da sua aplicação, do seu ecossistema, da sua organização. E o que podemos fazer é

09:34 usar os dados históricos do seu ambiente, as cargas históricas, para entender como é o comportamento normal. Então, quando as coisas começarem a se desviar do que é normal, poderemos nos antecipar e informar os seus agents — por exemplo, no IDE dos seus desenvolvedores — de que um dos serviços sob responsabilidade deles está ficando mais lento ou, de repente, está apresentando erros que antes não apresentava. O Blue Box também fará

10:06 parte do seu repositório de código. Assim, também teremos o contexto do que foi alterado no seu ecossistema. O que foi alterado na sua aplicação? O que foi alterado na sua carga de trabalho? Assim, poderemos sobrepor esses dados e entender que o problema que talvez esteja ocorrendo no seu ambiente foi causado, na verdade, por uma alteração que alguém enviou. Talvez por um merge que não foi bem-sucedido. Certo? Então, ao entrarmos no próximo cenário

10:38 aqui, descobrimos um problema. Começamos criando contexto, certo? Temos o contexto do seu ambiente. Podemos levar literalmente dados de contexto de produção para os testes locais, para os desenvolvedores nos seus IDEs. Você incorpora o Blue Box aos seus agents de programação com IA. Agora, podemos detectar os problemas mais cedo. Podemos começar a agir de forma proativa. Mas o que vem a seguir? Precisamos falar sobre corrigir as coisas. E aqui está mais um exemplo de como o Blue Box poderá ser incorporado diretamente ao seu SDLC.

11:11 Então, quando detectamos que há um problema, quando conhecemos o seu repo e sabemos quem enviou a alteração, sabemos o que mudou, podemos mais uma vez fornecer o contexto aos seus desenvolvedores e informá-los de que o serviço que está com um problema, o agent que está com um problema, a carga de trabalho que está com um problema podem ser corrigidos seguindo estas etapas. Então, mais uma vez, por que o contexto é tão importante nesse processo? Porque, quando precisamos corrigir um bug que está causando um problema no nosso ambiente, talvez seja necessário alterar uma linha de código

11:41 para corrigir aquele problema específico. Mas, depois de alterar essa linha de código, o que acontece com o restante do seu ambiente? O que acontece com o restante da sua aplicação? Então, mais uma vez, esse contexto e as dependências de todos os outros serviços no seu ambiente são extremamente importantes. Ao pensarmos em corrigir as coisas, não se trata apenas de corrigir o problema que temos em mãos, mas também de garantir que não causemos outros problemas no nosso ambiente. E a última — ou as duas últimas — sugestões que quero apresentar

12:12 é, na verdade, preparar os seus agents antes de começar a desenvolver. Acho que essa é uma das minhas favoritas quando se trata de falar diretamente com os desenvolvedores. Com frequência, vemos desenvolvedores começarem a trabalhar porque alguém teve uma ideia para um recurso, e então eles simplesmente vão lá e o desenvolvem. Mas fizemos alguma pesquisa prévia para entender o que esse recurso realmente precisa oferecer aos nossos usuários? O que estamos tentando alcançar com

12:43 esse recurso específico? É exatamente isso que poderemos fazer aqui. Poderemos planejar antes de usar o prompt. Então, ao criar seus agents, suas aplicações e usar seus agents de programação com IA, mais uma vez, o Blue Box vai trazer todo esse contexto da sua aplicação atual e de todos os agents que você já tem no seu ambiente, para que, ao planejar uma nova versão ou um novo recurso, você tenha dados suficientes para entender o que esse recurso, no qual está se concentrando agora, precisa abranger. E o último cenário que quero compartilhar com vocês

13:16 é que, no fim das contas, fornecer contexto a esses agents pode ampliar ainda mais a automação. Mas, quando falamos em ampliar a automação, tenho certeza de que alguns de vocês começam a pensar no conceito de intervenção humana no processo. No fim das contas, se simplesmente deixarmos os nossos agents fazerem tudo, acho que o mundo ficaria bem caótico, certo? Em algum momento, queremos ter controle sobre o que fazemos nos nossos ambientes. Então, é claro que também será possível fazer isso com o Blue Box. E eu gosto

13:48 desta imagem que temos aqui à direita, certo? Primeiro, vamos observar. Observar o seu ambiente, construir esse contexto, construir o mapeamento de dependências e disponibilizá-lo localmente aos seus desenvolvedores enquanto fazem os testes, fornecendo todos os dados de produção e todos os detalhes de produção de que precisam para testar o código adequadamente. Depois disso, quando detectarmos problemas, poderemos sugerir uma correção — não apenas para o problema específico que está fazendo o agent parar de funcionar, mas usando o contexto do seu ambiente, o contexto da aplicação monitorada e o contexto dos agents monitorados,

14:19 garantindo que a correção realmente resolva o que está acontecendo no seu ambiente. Por fim, poderemos conduzir todo o SDLC aqui, fornecendo a correção e deixando que você decida se quer ou não enviar o recurso para produção, se quer ou não enviar a correção para produção. Dito isso, chegamos ao fim da nossa breve apresentação do Blue Box. E quero terminar dizendo que queremos ajudar os agents a enviar para produção código em que você confia.

14:49 Então, se isso interessa a você, pode acessar bluebox.ai e se inscrever para uma prévia. Assim que fizer isso, entraremos em contato para dar acesso à plataforma. Também tenho algumas coisas no bolso que vocês podem escanear, então vou circular pela sala e entregá-las a vocês. Dito isso, temos 5 minutos. Se alguém quiser fazer alguma pergunta, podemos usar esse tempo para isso também. Ninguém tem perguntas?

15:34 >> Uhum.

Transcrição original

[00:01] [music] >> All right, it is 11:10 so officially time for our session. Thank you so much everybody for joining. I know this is the last day of the conference so I really appreciate for for all of you that that actually wanted to come on Thursday and and listen to our topic. My name is Matt Gibiits and I’m the

[00:33] regional director of solutions engineering for AI native at Dynatrace. With a show of hands, anybody knows what Dynatrace is? All right, we got a we got a couple hands, okay. We are an observability platform, AI powered observability platform, but we’re not going to be talking much about Dynatrace today. Because what we want to address today is a little bit different topic and the topic that I want to address is, as you see the title of the session, that your AI agent has no nervous system. Probably an intriguing title and you’re

[01:04] thinking, well, of course it doesn’t have a nervous system, it’s it’s not a person. Well, but if you really think how AI agents are being used today, we are using these agents to replace things that people used to do. And a lot of times, in order to do that, we need the reasoning. And when we really think about it, if we need reasoning, we need these agents to be able to actually not necessarily behave like humans, but have enough input to understand what they need to do to actually help us in our organization and not just automate things that aren’t

[01:36] necessarily working very well today. So, with that said, let’s let’s break this down. With a show of hands again, how many developers do I have in the room in here? Okay, perfect. Any team leads? Okay. And okay, the last one might be a little bit tougher. Do I have a head of engineering in here? Would would you call yourself a head of engineering? All right, perfect. I got one. So, if you take a look at these questions, we’re not going to go through all of them. We only have 18 minutes left in here. But, if you take a look at these

[02:07] questions, has any of you ever ask yourself a question or been asked a question, why am I stuck in a loop with my agent? How many of you have used, for example, Claude, and it just keeps repetitively doing the same thing over and over, consuming tokens, not giving you the result that you want? Anybody experience that? Everybody has, right? Now, if you think about it from a human perspective now, if you as a human do research, and you get results that that are not what you want, you will change your approach. You approach it from a different angle.

[02:41] But, our AI agents today, they’re not smart enough to do that. All right, let’s let’s shift to to another question in here. I like the one under team lead in the middle. How can I handle operational issues? Are you thinking about that yet today, or right now are you still in the boom of let’s just get things deployed, let’s just get get things going, and we’ll figure out everything else later? Anybody in here having operational issues with your agents? Here and there, maybe. Okay, uh let me throw a twist in here.

[03:11] How about security concerns? That That was a layup, right? I think everybody Everybody raised their hand in here. And so, again, a a very important questions that we have to ask ourselves. And the last one that I want to try with you guys, let’s look at the the head of engineering in here. I love the middle one again. Does our app or does the agent bring value to our users? I think we we jumped in so quickly to the AI world and at the AI era that a

[03:41] lot of the times I see customers and and spending 3 days in here talking to folks, everybody has that AI buzz, this AI agent buzz, but how do you measure value? Do you have instructions already today to how to measure value of your AI agents? No, right? And and I almost think that as much as you want to run fast and get there, we have to take a little pause and understand what are we really trying to accomplish and how can we measure the success of our agents? Because if we’re spending our engineering resources, time, effort,

[04:11] money on creating these agents and and and utilizing them in a way that we believe helps our organization, we need to come up with measures that’ll help us do it. Now, with all these questions, hopefully I I I I set up a picture a little bit in here to to to really jump into the next topic that I want to discuss, which is led in here by a quote from my CTO, Bernd. And I’m not going to read the whole thing, but just highlight what we see in blue in here. The agents operate at speed. Would everybody agree with that? That they’re pretty fast? But without sight.

[04:46] And what what we mean by that is these agents today are only as good as the data that is available to them to make the reason to make the reasoning to make a decision. If the data that is provided to our agent is missing context, is missing details, is missing the right permissions to pull the data from some of the tools in your environment, you start entering the the very buzzy word out there like hallucinations. You start doing processes and automating things in

[05:16] your environment that now probably don’t bring in value because there’s not enough context in your environment. So, what if I told you that essentially what we want to do in here is we actually don’t need your agent to necessarily have nervous system or sight to be efficient and be productive. There’s obviously a little twist on the title of the session in here. But what they need is actual context of your environment. You can pick any agent that that that’s

[05:51] out there. You can just pick the the easy scenario of Claude and trying to automate things with um Claude inside of your um SDLC life cycle. And as you do that, if Claude doesn’t have access to the context of your environment, if it is not able to understand the dependencies of your services, if it is not able to understand how your applications are being used by your users, it will start coming up with decisions and advices that might seem right at that point,

[06:24] but they won’t be right in the long term because there’s not enough context for that agent to understand how your environment really looks like. So, what I want to sum up this slide with is this one sentence in here, context is king. And what context is, it is that nervous system that we that you can provide to your agents. So, as they’re communicating, as you’re automating things, as you’re creating new processes, that connective tissue of a context is driving all of the processes that you’re automating with your agents.

[06:57] So, let’s take a let’s take a look at a couple examples. So, keeping that in mind, what what what I want to present to you is Blue Box by Dynatrace. And what a Blue Box is is essentially an agent that will now be able to be integrated in the middle of any of your life development life cycle to provide context to any of your AI coding agents or other proprietary agents that you’re developing in your environment. I have a couple slides that we’re going to go through in here. I’m not going to go through every single scenario in here, but I’m going to point out the most important things that that I

[07:27] believe are helpful in here. Let me Let me run this scenario by you. How many times you as a developer develop a feature, maybe even develop a feature or skill for an agent, and you test it locally, and it works great. Locally, everything works great, right? We’re happy, it’s awesome. And then what we do is we merge to to a main branch, we push it out there, and all of a sudden three other services are broken. Has that happened to any of you? Where your impact, even though locally it worked fine, once it was merged with

[08:00] other agents, with other applications, now it broke a process in your environment. That is one of the most important things that Blue Box by Dynatrace can provide in here. We will be able to bring that essentially services and dependency mapping for every single one of your agents, every single one of your AI workloads. So, as you’re developing and as you’re making changes, you’re not just talking about testing things locally. We’ll actually be able to now use Blue Box to bring the production context into your local testing. So, now you know whether the feature that you develop not only works locally

[08:33] for you and what you’re trying to automate, what you’re trying to achieve, but also that it won’t break and impact negatively anything else that that your agent that your workload is connecting to. Let’s take a look Let’s take a look at another um example in here. I This is honestly one of my favorites just in the entire world of observability. I’ve been doing observability now for 8 years, and I think if there’s one goal that I ask any of my customers, like, what would you like to achieve with your observability

[09:03] strategy with now AI? And when it comes to issues, I think this is everybody will say that. Find issues before they’re real issues, before they impact my organization, before they impact my users. This is now exactly what the context that Blue Box brings into your agents will be able to do for you. And how do we really get that done? We are able to now again understand end-to-end the interactions of your agents within your application, within your ecosystem, within your organization. And what we are able to do is we are

[09:34] able to use the historical data from your environment, the historical the historical loads to understand what regular what normal looks like. So, when things start to deviate from what normal looks like, we are able to now get ahead of it and inform your agents, let’s say in your IDE for your developers, that one of the services that belongs to them now it’s acting slower or all of a sudden it’s throwing errors that it didn’t throw. Now, what Blue Box will also do will be

[10:06] also integrated in the middle of your code repository. So, as you do that, we will now also have the context of what was changed in your ecosystem. What was changed in your application? What was changed in your workload? So, now be able to overlay that data and understand that the issue that might be happening in your environment was actually caused by a change that somebody pushed out there. Maybe by a merge that wasn’t successful. Okay? So, as we dive into the next um scenario

[10:38] in here, we discovered an issue. We We started with creating context, right? So, we have the context of your environment. We’re able to bring literally production context data to your local testing, to your developers in their IDE. You bake in Blue Box into your AI coding agents. Now, we’re able to detect the issues early. We’re able to start to be product proactive. But, what’s next? We have to talk about fixing things. And here’s yet another example where Blue Box will be able to be directly baked in into your SDLC.

[11:11] So, when we detect that there is an issue, when we know and we have the knowledge of your repo, we know who pushed it, we know what changed, we are now able to again once again provide the context to your developers and let them know that the service that is now having an issue, that the agent that is now having an issue, that the workload that is now having an issue can be remediated in the following steps. So, again, why is the context so important in that process? Because when we need to fix a bug that’s causing an issue in our environment, it is it might be changing one line of code

[11:41] to fix that particular issue. But after you change that one line of code, what happens to the rest of your environment? What happens to the rest of your application? So, again, that context and the dependency of all the other services in your environment is super, super important. So, as we do that, as we think about fixing things, it’s not only about fixing the the issue that we have at hand, but also making sure that we don’t cause any other issues in our environment. Um and the last um um or or two more suggestions that I want to run through

[12:12] is actually briefing your agents before building starts. That’s actually, I think, one of one of my favorites when it comes to directly talking to the developers. I think the way too often we see developers going out there, and somebody came up with a feature, and now the developers just go and develop it. But have we done any research up front to understand what actually that feature needs to deliver to our users? What are we actually trying to accomplish with with

[12:43] that specific feature? That’s exactly what we’ll be able to to do in here. We’ll be able to actually plan before you prompt. So, when you’re building your agents, when you’re building your applications, when you’re using your AI coding agents, again, Blue Bags will bring in all that context from your application today, from all the from all the agents that you already have in your environment today, to understand that as you’re planning for a new release, as you’re planning for a new feature, you’ll have enough data to understand what that feature that you’re now focusing on needs to encompass. And the last scenario that I that I want to share with you guys

[13:16] is that at the end of the day, providing context to these agents can further drive automation. But when we talk about further driving automation, I’m sure some of you start thinking about the concept of human in the loop. Like at the end of the day, if we just let our agents do everything, I think it’ll be a pretty messy world, right? At some point, we want to be able to have control over what we are doing in our environments. So, obviously, with Bluebox, you’ll be able to do that as well. And I I I’d

[13:48] like this picture that we have in here on the right, right? We’ll We’ll first start with observe. Observing your environment, building that context, building that dependency mapping, providing that locally to your developers as they’re testing, given all the production data, given all the production um details that they need to properly test their code. Once you have that, and then we detect issues, we’ll be able to actually suggest fix, but not just fix for the particular issue that’s breaking the agent, but using the context of your environment, using the context of the application that’s monitored, using the context of the agents that are being monitored,

[14:19] making sure that the fix actually addresses what’s happening in your environment. Lastly, we’ll be able to drive the the entire SDLC in here by providing the fix, and giving you the control at the end of it, to make the decision whether you want to push the feature out there, whether you want to push the fix fix out there, or not. So, with that said, um that really brings me to the to the end of our um our a little pitch about uh Bluebox. And And what I like to finish with is we want to help agents ship code you trust to production.

[14:49] So, if this is interesting to you, um you can go ahead and go to bluebox.ai, and you can actually sign up for a preview of it. Um uh as as soon as you do that, we’ll be reaching out to you to give you access to the platform. I also have my back pocket little um things that you can scan, so I’ll just walk around the room now and give them to you. But, with that said, we have 5 minutes. So, if you there’s any questions that that anybody wants to ask, uh we can absolutely use that time for those as well. No questions?

[15:34] >> Mhm.