Pular para o conteúdo

Os dashboards morreram — Sarah Simionescu, Composio

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: Dashboards Are Dead — Sarah Simionescu, Composio · Canal: AI Engineer · 10:08 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Dados, bancos de dados e embeddings, Ferramentas de desenvolvimento com IA

Sarah Simionescu argumenta que os dashboards estão perdendo espaço porque as pessoas querem respostas, não interfaces e linguagens de consulta específicas para cada ferramenta. Embora o MCP permita que agents acessem aplicativos, servidores mal projetados podem sobrecarregar o contexto, não preservar aprendizados e dificultar tarefas que envolvem vários serviços. A Composio busca resolver esses problemas ao oferecer ferramentas e planos de uso unificados para agents, como demonstra em fluxos que conectam Slack, Sentry, Datadog e outras fontes. A conclusão é que produtos devem ser preparados para uma nova categoria de usuários: agents que avaliam os serviços pela capacidade de concluir tarefas.

  • As pessoas usam dados e serviços para obter respostas, não necessariamente para navegar por dashboards.
  • Cada aplicativo costuma ter sua própria interface e linguagem de consulta, o que exige reaprender fluxos de trabalho.
  • Botões de IA em dashboards ajudam a gerar consultas, mas não resolvem por completo as necessidades dos usuários.
  • O MCP conecta agents a serviços, mas a qualidade da experiência depende de como cada serviço se comunica com eles.
  • Muitos servidores MCP podem sobrecarregar o context window com definições de ferramentas e dificultar a escolha da ferramenta certa.
  • Tarefas que atravessam vários aplicativos exigem coordenação que servidores isolados não oferecem por si sós.
  • A Composio apresenta uma camada que seleciona ferramentas adequadas e fornece planos para executar tarefas entre aplicativos.
  • Agents podem consultar dados de diferentes fontes sem carregar resultados completos no contexto.
  • Produtos devem ser projetados também para agents, que avaliam se conseguem concluir uma tarefa.
Início Capítulo Resumo
00:12 Por que os dashboards estão perdendo espaço Sarah relata que usa Datadog sem abrir o dashboard e explica que as pessoas querem respostas, não interfaces complexas.
02:17 Dos botões de IA aos limites do MCP A palestra acompanha a evolução das consultas assistidas por LLM e apresenta problemas de memória, contexto e coordenação entre servidores MCP.
04:54 Demonstração de uma investigação entre aplicativos Sarah mostra como a Composio ajuda Claude a planejar consultas em Slack, Sentry e Datadog para encontrar a causa de um bug e preparar um PR.
07:01 Aplicativos preparados para agents Duas demonstrações ilustram consultas entre fontes de dados e a palestra conclui que a próxima geração de produtos deve ser fácil de usar por agents.

O dashboard está morto. E acho que isso é uma ótima notícia para todos nesta sala. — 00:43

Você nunca quis um dashboard nem sua linguagem de consulta amaldiçoada. Você queria a resposta. — 02:17

O MCP deu aos agents uma porta para cada aplicativo, mas os deixou em milhares de salas separadas, sem mapa e sem memória. — 04:22

Ele aparece com um objetivo e um conjunto de ferramentas, e é avaliado por uma coisa: se consegue concluir a tarefa. — 09:36

A próxima era pertence a quem criar produtos fáceis de usar por agents. — 10:08

  • Sarah Simionescu (pessoa): Palestrante que apresenta a visão de que produtos devem ser preparados para uso por agents.
  • Composio (empresa): Empresa que desenvolve ferramentas para conectar agents a aplicativos e executar tarefas entre eles.
  • MCP (conceito): Protocolo apresentado como um padrão aberto para conectar sistemas de IA a fontes de dados e serviços.
  • Claude (modelo): Assistente usado nas demonstrações para executar tarefas por meio de ferramentas conectadas.
  • Datadog (ferramenta): Serviço mencionado para consultar logs e dashboards durante a investigação de um problema.
  • Slack (ferramenta): Aplicativo de comunicação usado como fonte de mensagens para investigar um relato de erro.
  • Sentry (ferramenta): Serviço consultado na demonstração para pesquisar problemas e ajudar a identificar a causa de um bug.
  • PostHog (ferramenta): Fonte de dados usada para consultar informações de usuários e suas escolhas durante o onboarding.
  • Metabase (ferramenta): Ferramenta consultada para relacionar dados de usuários com os toolkits utilizados por eles.
  • Composio Remote Workbench (ferramenta): Ferramenta descrita como capaz de gerar dinamicamente uma consulta SQL sem carregar todos os dados no context window.

00:12 Olá, pessoal. Meu nome é Sarah e tenho uma confissão a fazer. Tenho usado Data Dog todos os dias nos últimos seis meses. Outro dia, um colega veio falar comigo e disse: “Ei, Sarah, posso dar uma olhada neste alerta?” Eu respondi: “Claro.” Então, abri o Data Dog e estava desconectada. Foi meio constrangedor, então tive que entrar na conta, e ele ficou olhando por cima do meu ombro. Eu fiquei extremamente consciente de tudo o que estava fazendo no computador. E abri o dashboard do Data Dog…

00:43 …e simplesmente travei. Não fazia ideia de onde estava nada. E isso, na verdade, não é uma crítica ao Data Dog. O problema era que eu nunca tinha aberto o dashboard de verdade. Eu o usava todos os dias sem nunca olhar para ele. Então, hoje, quero defender uma ideia que parece meio insana e depois mostrar que ela é óbvia. O dashboard está morto. E acho que isso é uma ótima notícia para todo mundo nesta sala, exceto provavelmente para mim, porque eu — minha equipe — é responsável pelo

01:15 dashboard da Composio. Enfim, como chegamos até aqui? Acho que cabe uma retrospectiva. Vamos lá? Estamos em 2022. São os tempos sombrios. Alguém me chama no Slack e diz: “Ei, aparece este erro quando tento pesquisar por produção.” Eu teria aberto imediatamente cinco janelas diferentes. Lido o contexto no Slack. Escrito uma consulta no Data Dog. Verificado o PostHog para esta sessão. Corrigido o bug no VS Code. Aberto o PR no GitHub. Isso

01:46 são cinco ferramentas e cinco UIs que preciso aprender e reaprender sempre que lançam um novo redesign. Mas, francamente, os redesigns são o menor dos meus problemas, porque cada ferramenta tem sua própria linguagem de consulta. O Data Dog tem sua própria sintaxe de consulta. O Jira tem JQL, e a busca do Slack tem seus modificadores de pesquisa. E fica pior, porque, mesmo quando essas ferramentas afirmam falar a mesma linguagem, digamos, SQL, elas nem sequer concordam sobre o SQL. Todo dashboard que você já usou, toda

02:17 linguagem de consulta estranha e obscura já escrita era um dispositivo de tradução entre você e seus dados, porque as máquinas do outro lado não conseguiam entender o que você realmente queria. Você nunca quis um dashboard nem sua linguagem de consulta amaldiçoada. Você queria a resposta. E, em 2023, tudo mudou. O botão com brilhinhos. O botão com brilhinhos surgiu. Com um clique nesse botão mágico, um LLM escrevia uma consulta, às vezes correta, para encontrar a resposta de que você precisava. Isso, desde que

02:49 sua pergunta não exigisse mais de duas junções de banco de dados. E logo esses botões com brilhinhos estavam por toda parte. Então, os dashboards se tornaram nativos de IA. Problema resolvido, certo? Bem, não exatamente. Em novembro de 2024, a Anthropic anunciou o protocolo MCP com a promessa de criar um padrão aberto para conectar sistemas de IA às suas fontes de dados — e foi isso que ela fez. Em vez de usar um botão com brilhinhos, seu próprio agent, o Claude, que você já usava todos os dias,

03:19 poderia gerar a consulta para você, executá-la em seu nome e fornecer a resposta diretamente. E talvez você esteja pensando: problema resolvido, certo? Este é o fim da história. Bem longe disso, porque MCP é um protocolo. É um canal de comunicação entre agents e seu serviço. E cabe a você, o serviço, escolher como se comunicar com o agent. E acontece que isso faz toda a diferença. Se você já conectou de fato uma dúzia de servidores MCP, sabe que, na realidade, a situação é uma bagunça por

03:50 três motivos. Agents não aprendem. Toda conversa começa do zero. Eles não se lembram de como ontem se atrapalharam ao formatar links corretamente no Slack, então vão se atrapalhar de novo hoje. Tentamos corrigir isso com skills, mas skill é só um paliativo, porque os agents ficam mais burros quanto mais contexto você fornece. Carregar mais ferramentas e mais skills exige mais contexto. E, se você conectar servidores suficientes, estará despejando milhares de definições de ferramentas diretamente na context window. Quer dizer, nosso conjunto de ferramentas para GitHub, sozinho, tem mais de 200 ferramentas. O modelo simplesmente

04:22 se afoga. Ele escolhe a ferramenta errada ou tem dificuldade para resolver dependências e não consegue descobrir qual precisa chamar primeiro. E, em terceiro lugar, cada app é isolado. Cada servidor MCP conhece a si mesmo e nada mais. Então, quando uma tarefa envolve dois apps — como sempre acontece —, cabe a você juntar as peças. Assim, MCP deu aos agents uma porta de entrada para cada app. Mas deixou-os em milhares de salas separadas, sem mapa e sem memória de já terem estado ali.

04:54 Vou mostrar uma demonstração de protótipo de como eu resolveria esse relato de bug desde o início, como eu o resolveria em 2026. Imaginem que, neste protótipo, meu Claude está conectado ao MCP da Composio. O que eu faria seria simplesmente copiar e colar o link da mensagem do Slack e dizer: “Por favor, use Sentry e Data Dog, encontre a causa raiz e crie um PR preliminar. Não cometa erros.” E a primeira coisa que ele faz é chamar a busca da Composio para declarar a tarefa que quer realizar. Neste caso, ele declarou

05:26 três tarefas. Quer buscar mensagens do Slack. Quer pesquisar issues do Sentry. Quer pesquisar logs do Data Dog. Para cada uma dessas três tarefas, a Composio retorna não só as ferramentas corretas de que ele precisa, mas também um plano de como usá-las. Por exemplo, no Slack, é preciso encontrar o ID do canal antes de começar a consultar as mensagens. Agora que tem todo o contexto necessário, ele tem um plano. Começa buscando a mensagem do Slack para ver qual era a reclamação do usuário. Depois, começa a buscar dados em paralelo. Data Dog, Sentry, e começa

05:58 a analisar o código-fonte. Assim que identifica a causa raiz, o PR com a correção fica pronto em menos de cinco minutos. Não precisei criar um workflow nem escrever uma skill para ensiná-lo a fazer isso. É literalmente só o Claude usando o MCP da Composio. E ficou tão mais fácil fazer as coisas desse jeito que abrir o Claude virou quase uma memória muscular para mim, para fazer literalmente qualquer coisa. E os dashboards que eu costumava abrir todos os dias estão ficando cada vez mais desconhecidos para mim. E o impacto de projetar para agents

06:29 pode ser medido. Estes são alguns resultados preliminares, ainda não divulgados, que comparam a Composio com o MCP nativo de cada app, listado no marketplace do Claude. São as mesmas tarefas, o mesmo modelo, e vemos uma diferença clara. Mas por quê? Por que essa experiência é muito melhor do que a dos MCPs nativos? É porque, na Composio, estamos desenvolvendo uma interface totalmente nova, projetada especificamente para agents. Traduzimos as APIs confusas, mal documentadas e em constante mudança de todos os apps

07:01 que você usa todos os dias em algo que os agents adoram usar. Então, usamos MCP, CLI e ferramentas nativas como base para oferecer aos seus agents uma experiência coesa, unificada e excelente, que lhes permite realizar operações complexas nesses apps sem complicações. Vou mostrar um exemplo mais clássico do que costumo usar no dia a dia. Digamos que eu queira investigar alguns dados de usuários. Quero ver a distribuição dos segmentos de mercado que meus usuários selecionam durante o onboarding. Posso simplesmente perguntar ao Claude. O Claude vai

07:33 usar a busca da Composio novamente. Ele escreverá uma consulta no PostHog e a executará de forma simples. Aqui estão os resultados. Mas e se eu quisesse ir um pouco além? Quero olhar para essa seção de comércio eletrônico. E quero ver quais kits de ferramentas eles gostam de usar. Na Composio, usamos “kits de ferramentas” como outra forma de dizer apps. Vamos ver se o Claude consegue descobrir como buscar esses dados no Metabase, considerando os IDs de usuário no PostHog. Então,

08:03 mais uma vez, ele usa a busca da Composio. Consulta no PostHog os IDs dos usuários que selecionaram comércio eletrônico e, na verdade, os salva sem carregar todos os resultados no contexto. Depois, faz algumas consultas no Metabase para obter o esquema do banco de dados, amostrar alguns dados e ter uma noção de como as coisas estão estruturadas. Quando ganha confiança, usa uma ferramenta muito legal chamada Composio Remote Workbench para gerar dinamicamente uma consulta SQL com uma string de regex para pesquisar todos aqueles usuários

08:33 IDs novamente, sem nunca carregar tudo na context window. E pronto. Podemos ver os toolkits mais populares entre esse perfil de usuário em poucos minutos. E esses são dados extraídos das duas fontes. Se quiser experimentar a versão ao vivo, venha nos visitar no estande da Composio. Adoraria que você experimentasse ao vivo. E, assim, o dashboard morreu. E tenho pensado cada vez mais no que isso significa para o futuro. Muitas startups começaram a tornar suas páginas iniciais e seus sites compatíveis com IA para fins de GEO. Mas poucas realmente prepararam suas aplicações para serem usadas por agents. A Compose começou como uma ferramenta para ajudar desenvolvedores. Pegávamos esses aplicativos populares de que os usuários gostam e os transformávamos em ferramentas que os agents pudessem usar. Mas os humanos estão cansados de dashboards, e seus agents estão cansados de servidores MCP mal projetados. E agora estamos recebendo pedidos de startups dizendo

09:05 que seus clientes estão implorando por uma maneira de usar seus serviços por meio de seus agents. Então, esta é uma lição para todos que estão construindo qualquer coisa agora. Vocês estão atendendo a uma nova espécie de usuário. Eles não têm olhos. Não vão clicar no seu botão brilhante. Eles chegam com um objetivo e um conjunto de ferramentas, e avaliam você com base em uma única coisa: se conseguem concluir a tarefa. Durante uma década, construímos produtos para serem fáceis de usar para os humanos. E a próxima era pertence àqueles que são fáceis

09:36 de usar para os agents. Então, imaginem-me de novo. Estou paralisada diante daquele dashboard do Datadog. E, naquele momento, pensei comigo mesma que estava ficando para trás. Mas agora vejo aquele momento como uma prévia do que está por vir. Obrigada. [música] >> [música]

10:08 para os agents usarem. Então, imagine-me de novo. Estou paralisada diante daquele dashboard do Datadog. E, naquele momento, pensei comigo mesma que estava ficando para trás. Mas agora vejo aquele momento como uma prévia do que está por vir. Obrigada. [música] >> [música]

Transcrição original

[00:12] Hello everyone. My name is Sarah and I have a confession to make. So, I’ve been using Data Dog every day for the last six months. And the other day my co-orker comes up to me and he’s like, “Hey Sarah, can I look at this alert?” I’m like, “Okay.” So, I open up Data Dog and I’m logged out. It’s kind of awkward, so I have to log in and he’s like looking over my shoulder and I’m like overly conscious about everything that I’m doing on my computer. And I open up the data the data dog dashboard

[00:43] and I just froze. I had no idea where anything was. And this is actually not a knock on data dog. The problem was I had genuinely never opened the dashboard. I’ve been using it every day without ever looking at it. And so today, I want to make an argument that sounds kind of insane and then show you that it’s obvious. The dashboard is dead. And I think that’s great news for everyone in this room except probably for me because I am my team is responsible for the

[01:15] Composio dashboard. Alas, how did we get here? I believe a postmortem is in order. Shall we? The year is 2022. It is the dark ages. Someone pings me on Slack. They say, “Hey, I get this error when I try and search for prod.” I would have instantly spawned five different windows. Read the context in Slack. Write a query in data dog. Check post for this session. Uh, fix the bug in VS Code. Open the PR in GitHub. That

[01:46] is five tools and five UIs I have to learn and relearn every time they ship a new redesign. But frankly, redesigns are the least of my problems because every single tool has its own query language. So, data dog has its own query syntax. Jira has JQL, search, Slack has its search modifiers. And it gets worse because even when these tools claim to speak the same language, let’s say SQL, they don’t even agree on SQL. Every dashboard you’ve ever used, every

[02:17] weird obscure query language ever written was a translation device between you and your data because the machines on the other end could not understand what you actually wanted. You never wanted a dashboard or it’s cursed query language. You wanted the answer. And in 2023, everything changed. The sparkle button. The sparkle button was born. And with a click of this magical button, an LLM would write a sometimes correct query to get you the answer you need. That is if

[02:49] your question does not require more than two database joins. And soon enough, these sparkling buttons were everywhere. So dashboards became AI native. Problem solved, right? Well, not quite. In November of 2024, Enthropic announced the MCP protocol with a promise to create an open standard for connecting AI systems with its data sources and that it did. Instead of using a sparkle button, your own agent, Claude, whom you’ve already been using every day,

[03:19] could generate the query for you, execute it on your behalf, and give you the answer directly. And you might be thinking, problem solved, right? This is the end of the story. Well, far from it, because MCP is a protocol. It’s a channel for communication between agents and your service. And it’s up to you, the service, to choose how to communicate with the agent. And it turns out that makes all the difference. If you’ve ever actually wired up a dozen MCP servers, you will know the reality is a mess for

[03:50] three reasons. Agents don’t learn. Every conversation starts from zero. It has no memory of how it fumbled formatting links properly in Slack yesterday, and so it’s just going to fumble again today. And we patched this with skills, but skills is just a band-aid because agents become dumber with the more context you provide. And loading more tools, more skills takes more context. And if you connect enough servers, you’re dumping thousands of tool definitions straight into the context window. I mean, our GitHub like toolkit alone has over 200 tools. The model just

[04:22] drowns. It grabs the wrong tool or struggles to resolve dependencies and it can’t figure out which one it needs to call first. And third, every app is isolated. Each MCP server knows about itself and nothing else. So the moment a task spans two apps and like they always do, it is your job to piece that together. And so MCP gave agents a door into every app. But it left them standing in thousands of separate rooms with no map and no memory of ever being there.

[04:54] I’m going to show you a mockup demo here of how I would solve this bug report uh from the very beginning how I would solve it in 2026. So imagine in this mockup I have my claude connected to the composio MCP. What I would do is I would literally just copy and paste the link to the message from Slack and say please use century data dog find the root cause a draft PR make no mistakes. And the first thing it does is it calls composio search to state the task it wants to accomplish. So in this case it stated

[05:26] three. It wants to fetch slack messages. It wants to search sentry issues. It wants to search data dog logs. And for each of these three, Composeio returns not only the correct tools it needs, but actually a plan of how to use them. So for example, for Slack, you actually have to find the Slack channel ID before you can start quering for messages. Now that it’s armed with all the context it needs, it has a plan. It starts pulling the message from Slack to see what the user complaint was. Then it begins pulling from data sources in parallel. Data dog sentry and it begins

[05:58] scanning the codebase. Once it identifies the root cause, PR is up with a fix in less than five minutes. I didn’t have to build a workflow or write a skill to teach it how to do this. This is literally just claude using Composeio’s MCP. And it has become so much easier to do things this way that opening up Cloud has just become like muscle memory for me to do literally anything. And the dashboards I used to open every day are becoming increasingly unfamiliar to me. And the impact of designing for agents

[06:29] is measurable. So these are some early unreleased uh results comparing Composio against each app’s own native MCP that’s listed in the clawed uh marketplace. So it’s the same tasks, it’s the same model, and we see a clear difference. But why? Why is this experience so much better than native MCPs? It’s because at Composeio, we are developing a brand new interface specifically designed for agents. We translate messy, sparsely documented, everchanging APIs from all of the apps

[07:01] that you live in every day into something that agents really love to use. So, we build on top of MCP CLI and native tools to deliver a cohesive, unified, and excellent experience for your agents that allows them to perform complex operations across these apps seamlessly. I’m going to show you a more classic example of like what I usually use it for every day. So, let’s say I want to dig into some user data. I want to see the distribution of what vertical my users select during onboarding. I can simply just ask Claude. Claude will

[07:33] again run Composio search. It will write a query in Post Hog, execute it nice and simple. There’s my results. But what if I wanted to take this up a notch? So I want to look at that e-commerce section right there. And I want to see what tool kits they like to use. Toolkits is another word for apps we like to use at Composio. So let’s see if cloud can figure out how it can pull this data from metabase uh given the user ids in post hog. So

[08:03] once again it uses composio search. It queries the user ids of those who selected e-commerce from post hog and it actually saves it without loading the full results into its context. Then it makes some queries uh in metabase to get the database schema sample some data get a feel for how things are structured. And once it’s confident, it actually uses a very cool tool called Composio Remote Workbench to dynamically generate an SQL query with a reax string to search for all those user

[08:33] IDs again without ever loading the entire thing into its context window. And there we go. So we can see the most popular toolkits amongst this user persona in less than a few minutes. Uh and that’s data pulled from both sources. If you want to play with the live version, come visit us at the Composio booth. Uh, I’d love to have you play with this live. And so, the dashboard has died. And I’m thinking more and more about what this means for the future. Many startups have

[09:05] begun making their landing pages and their websites AI friendly for GEO purposes. But so few have really prepared their applications to be used by agents. Compose began as a tool to help developers. We were taking these popular apps that users like and turn them into these tools that agents could use. But the humans are tired of dashboards and their agents are tired of poorly designed MCP servers. And now we’re getting requests from startups saying

[09:36] their clients are begging for a way to use their services through their agents. So this is a lesson for everyone building anything right now. You are now serving a new species of user. They don’t have eyes. They are not going to click your sparkle button. It shows up with a goal and a set of tools and it judges you on exactly one thing, whether it can get the job done. For a decade, we’ve built pro uh we’ve built products to be easy for humans to use. And the next era belongs to those that are easy

[10:08] for agents to use. So, picture me again. I’m frozen in front of that data dog dashboard. And I was thinking to myself in that moment that I’m falling behind. Uh, but now I think of that moment as a preview of what’s to come. Thank you. [music] >> [music]