Por que apagamos nosso servidor MCP e o reconstruímos — Abhi Arya, Reducto

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: Why We Deleted Our MCP Server and Rebuilt It — Abhi Arya, Reducto · Canal: AI Engineer · 16:36 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Engenharia de prompts e contexto

Resumo

Abhi Arya, da Reducto, explica como a equipe substituiu um servidor MCP com muitas ferramentas genéricas por ferramentas mais estruturadas, alinhadas ao funcionamento real do produto. A mudança buscou evitar que o agent criasse pipelines incorretos com confiança e sem que as pessoas pudessem entender ou verificar o que aconteceu. A equipe também tornou as incertezas explícitas, incentivou o agent a fazer perguntas e manteve a revisão final nas mãos do usuário. Com a instrumentação das sessões, o sistema passou a aproveitar o uso real para melhorar suas orientações ao longo do tempo.

Pontos-chave

• Agent-first é sobretudo uma questão de arquitetura: é preciso decidir quem percebe e assume as consequências quando o agent erra.
• Um MCP com muitas ferramentas genéricas pode levar o agent a montar workflows que nem ele nem o usuário conseguem explicar.
• Ferramentas estruturadas, que incorporam padrões do produto e encadeiam etapas conhecidas, reduzem a necessidade de o agent adivinhar.
• Uma ferramenta de snapshot permite consultar o estado atual do pipeline e seus erros, em vez de depender de nomes de variáveis presumidos.
• A incerteza deve ser legível: quando houver ambiguidade, o agent deve perguntar ao usuário em vez de fazer suposições silenciosas.
• Evals e orientação do harness foram usados para recompensar perguntas de esclarecimento e penalizar suposições frágeis.
• A revisão humana ajuda a manter o julgamento final com quem responde pelo trabalho feito para o usuário.
• O registro de sessões, intervenções humanas e perguntas alimentou orientações que ajudaram o sistema a melhorar na construção de pipelines.
• A confiança no agent depende de ele ser verificável e útil para as pessoas envolvidas, não apenas de estar conectado a ferramentas.

Capítulos

Início	Capítulo	Resumo
00:01	Reducto e o desafio dos documentos em produção	Abhi apresenta a plataforma e explica por que documentos empresariais desorganizados tornam difícil obter resultados confiáveis com modelos.
03:38	O que significa criar software agent-first	A apresentação compara autonomia sem supervisão, interfaces centradas no usuário e capacidades do agent estruturadas para servir ao usuário.
06:13	Reconstrução do servidor MCP com ferramentas estruturadas	A equipe apaga a implementação inicial e adota menos ferramentas, mas mais alinhadas aos padrões e ao estado real do produto.
08:47	Tornar a incerteza visível e envolver o usuário	A Reducto usa informações sobre falhas e orienta o agent a fazer perguntas quando não consegue interpretar algo com segurança.
12:25	Instrumentação, melhoria contínua e confiança	O registro das sessões ajuda a aprimorar as orientações do sistema, enquanto o uso pela equipe demonstra o valor de um agent verificável.
15:04	A responsabilidade humana no trabalho com agents	Abhi conclui que o essencial não é apenas conectar o agent a ferramentas, mas descobrir quem percebe seus erros e com que rapidez.

Citações

Quem paga quando o agent está errado? — 02:38

Não eram mais ferramentas. Eram, em sua maioria, menos ferramentas, mas que carregavam a estrutura do trabalho real. — 06:13

Ao tirar o contexto do prompt e colocá-lo na estrutura, o agent parou de adivinhar e começou a consultar referências. — 07:46

Quando seu agent está muito confiante e errado, quem descobre — e com que rapidez? — 15:34

Conceitos e entidades

• Reducto (empresa): Empresa que desenvolve uma plataforma para transformar documentos não estruturados em dados utilizáveis por ferramentas e agents.
• Abhi Arya (pessoa): Pessoa identificada no título do vídeo como palestrante da Reducto.
• MCP (conceito): Protocolo usado na apresentação para disponibilizar ferramentas que ajudam agents a criar e consultar pipelines de documentos.
• Claude Code (ferramenta): Ferramenta usada para montar uma primeira versão do servidor MCP e cujas sessões foram analisadas pela equipe.
• agent-first software (conceito): Abordagem de arquitetura que organiza as capacidades do agent para atender às necessidades do usuário e permitir a verificação do trabalho.
• pipeline (conceito): Sequência de etapas para processar documentos, como análise, classificação, divisão em seções e extração.
• snapshot tool (ferramenta): Ferramenta que retorna o estado atual do pipeline, incluindo o contexto do fluxo e erros identificados.
• evals (conceito): Avaliações usadas para penalizar suposições frágeis do agent e favorecer perguntas de esclarecimento.
• Harness (conceito): Estrutura ao redor do modelo que oferece orientações e recursos para ajudar o agent a produzir resultados verificáveis.

Tradução completa (pt-BR)

00:01 [música] >> Sou Avi e trabalho com produto aqui na Reducto. Antes de começar de imediato, queria dar a vocês um pouco mais de contexto sobre o que é a Reducto. Somos uma plataforma de documentos baseada em agentes, o que basicamente significa que ajudamos equipes a transformar documentos desorganizados e não estruturados em dados que suas ferramentas e seus agentes de IA

00:33 conseguem entender. Vou falar dos próprios agentes daqui a pouco, mas primeiro gostaria de falar rapidinho sobre onde estamos. Nos últimos 3 anos, processamos mais de 3 bilhões de documentos para clientes como Harvey, Scale AI, além de cinco das maiores empresas de tecnologia do mundo e fundos de hedge. Operar nessa escala significa que já vimos basicamente todas as maneiras como um documento pode dar errado em produção, e iteramos nosso produto e nossos modelos para lidar com praticamente qualquer coisa que vocês possam jogar neles.

01:04 E fazer a IA funcionar com um documento limpo usando um modelo de ponta já não é tão difícil. Basicamente, dá para jogar algo na nuvem e talvez chegar a uns 60% do resultado. Mas a parte difícil é a produção: documentos digitalizados, páginas giradas etc. E o modelo começa a alucinar, porque a grande maioria dos dados empresariais não é estruturada. Então, a Reducto é uma camada entre o seu modelo e esses dados. Cuidamos de todos os layouts complexos e do pós-processamento,

01:35 e, assim, acabamos trabalhando com muitos agentes e criando muitos deles enquanto projetamos esses pipelines. Agora que vocês sabem um pouco mais sobre o que fazemos, vou entrar no nosso tema principal com algo que parece não ter relação. Visitei minha namorada neste fim de semana, e ela me deu um adesivo do filme Meninas Malvadas. Basicamente, era uma versão adaptada para agentes. Então, dizia: “Entra, perdedora. Estamos criando software pensado primeiro para agentes.” E, no melhor estilo de engenheiro de software, tive que colar um adesivo desses no meu laptop. Ela ganhou isso no trabalho, mas

02:06 me perguntou: “O que é software pensado primeiro para agentes?”, porque ela não trabalha com IA. E, enquanto tentava explicar, ou enquanto pensava sobre isso, percebi que tinha muitas respostas diferentes. Criar um harness muito bom, criar uma API muito boa, escrever ou iterar em prompts. Nada disso realmente coloca o agente em primeiro lugar. São mais formas de otimizar o modelo. Software pensado primeiro para agentes é, por natureza, um problema de arquitetura. E, por isso, acho que essa estrutura, essa

02:38 arquitetura, se resume mesmo a uma pergunta: quem paga quando o agente erra? Acho que há uns três grupos em que podemos dividir as respostas. Primeiro, temos o modo automático, que otimiza a autonomia: você escreve um prompt e deixa o agente fazer o que quiser. E, quando ele comete um erro — e vai cometer —, você não faz ideia, porque ele está muito confiante no que está fazendo, e quem paga pelo erro são você, seus clientes, seus usuários etc. Depois, temos o foco no usuário.

03:08 É quando você otimiza a interface humana, dá ao usuário todos os controles e, então, constrói sobre um agente que não consegue fazer muita coisa, o que basicamente se resume a uma experiência de chatbot. Você limita tanto o entendimento que o usuário tem do produto, porque ele não pode criar prompts, quanto a capacidade do próprio agente. Por fim, o grupo que acho que vence é a experiência do agente a serviço do usuário. Aqui, os recursos do agente são estruturados para oferecer ao modelo recursos ricos

03:38 e delimitados, com os quais ele pode fazer o que o usuário realmente quer, ajudando e capacitando essa pessoa, e permitindo também que o humano verifique o trabalho realizado. Essa perspectiva transforma a experiência do agente em algo menos relacionado ao modelo e mais relacionado ao contexto, à capacidade e ao autoaperfeiçoamento geral. E foi assim que descobri esses grupos e cheguei a esse último ponto. Na Reducto, temos criado ferramentas que basicamente automatizam o trabalho com documentos de ponta a ponta por meio de pipelines. Pensem que nós

04:10 primeiro analisamos um documento, depois o classificamos, ou talvez o dividamos em seções, e então extraímos informações dele. Isso é usado em casos como faturamento, gestão de contratos e todas essas coisas que exigem intervenção humana. Uma coisa que percebi logo no início foi que qualquer um dos usuários, especialmente nossa equipe de vendas na Reducto, passava todo o tempo configurando, em vez de se concentrar nos resultados. E esse é um problema mais amplo, porque as interfaces legadas foram projetadas para criar esse tipo de pipeline. Enquanto isso, nesse mundo de trabalho baseado em agentes

04:41 estamos cada vez mais focados no resultado final e em como levar o usuário até lá o mais rápido possível. Então, para nós, a escolha óbvia para chegar a esse ponto foi um servidor MCP. Deixar o agente fazer o trabalho pesado e pedir ao usuário apenas que pense no caso de uso e escreva um prompt. Para validar essa direção, montei um MVP com Claude Code, e dei a cada endpoint de API que fazia nosso app funcionar uma ferramenta MCP, tudo num arquivo enorme. Dei a ele um prompt bem

05:11 específico. Coloquei no Slack e, sinceramente, ficou bem legal. Até certo ponto, deveria ter funcionado naquele contexto. Eu sabia exatamente o que estava fazendo. Estava montando uma demonstração muito bem planejada, e por isso a demonstração isolada não me ensinou absolutamente nada. O verdadeiro teste aconteceu quando dei o MCP para todo mundo da equipe, e ele quebrou na hora. E foi assim. Alguém dava a ele uma descrição incompleta de uma conversa com um cliente ou talvez uma página do Notion, e o agente

05:42 simplesmente começava a agir. Ele criava o workflow inteiro, de ponta a ponta, mas dizia ao usuário com muita confiança que tudo o que tinha feito estava certo, embora nem o usuário nem o agente conseguissem explicar o que aquele workflow realmente fazia. Esse foi o despertar para o modo automático em produção. O agente nunca dizia que não tinha certeza. Ele lidava com tudo usando as ferramentas que tinha, e não havia espaço para um humano validar ou pensar no que estava acontecendo. Criamos algo que conseguia se comunicar com nosso sistema, mas não

06:13 tínhamos criado algo que realmente pudesse trabalhar com ele. E vocês poderiam pensar que a solução seria incluir mais detalhes no system prompt ou dar mais orientação ao modelo, mas, na prática, é uma questão de arquitetura. Apaguei em um único commit o arquivo inteiro que usávamos para nos comunicar com o MCP. E o que entrou no lugar não foram mais ferramentas. Na maior parte, foram menos ferramentas, mas elas incorporavam a estrutura do trabalho de verdade. Por exemplo, em vez de uma única etapa de criação desse workflow para chamar repetidamente e ficar torcendo

06:44 para que o agente montasse o pipeline corretamente, criei ferramentas que entendiam como funcionam nosso painel interno ou nosso produto. Por exemplo, um caso de uso comum da Reducto é direcionar nosso endpoint de classificação, que classifica documentos, para um nó de extração. O que ele faz é basicamente extrair informações na etapa seguinte. Em vez de deixar o modelo adivinhar isso ou descobrir por meio do prompt, transformei isso em uma única ferramenta de classificação para extração. E, depois de cada

07:15 etapa, o agente recebe orientação contextual sobre o que vem a seguir, e algumas ferramentas até se encadeiam automaticamente, como esta. Em vez de o agente ter que adivinhar ou pensar no que é certo, ele recebe a resposta. Agora, o agente não pode improvisar nas partes que sabemos serem verdadeiras. E, como os agentes não têm estado, também adicionamos uma ferramenta de snapshot. É uma chamada que basicamente devolve o estado atual do nosso pipeline, desde o contexto do fluxo inteiro até os

07:46 erros que foram apresentados, com códigos de erro bem específicos. Assim, eles podem consultar o que realmente existe, em vez de adivinhar nomes de variáveis, alucinar etc. Ao tirar o contexto do prompt e colocá-lo na estrutura, o agente parou de adivinhar e começou a consultar informações. E, como as ferramentas só permitiam que os pipelines assumissem os formatos que nós, engenheiros de produto, queríamos, o humano conseguia acompanhar exatamente o que aconteceu, e nós podíamos explicar as saídas do agente aos usuários finais dessa

08:17 ferramenta MCP. Então, para evitar o modo automático, você não entrega uma API ao seu agente; entrega ferramentas que incorporam o conhecimento especializado geral, como os padrões corretos, o estado e os validadores, para que o caminho correto também seja o caminho mais simples que o MCP pode seguir. Então, agora conseguimos criar bons pipelines. Terminamos, certo? Não exatamente. Voltando ao modo automático, o agente estava errado com confiança e ninguém conseguia perceber. Isso que acabamos de discutir

08:47 resolvido isso para a construção. As ferramentas tornaram a estrutura realmente legível, e a pessoa conseguia acompanhar o que o agent fazia. Mas agora o problema aparecia em tempo de execução. Quando o próprio resultado que o agent está tentando construir dá errado, quem consegue perceber? Por exemplo, se tivéssemos um schema muito ruim, ou talvez o usuário não tivesse especificado o caso de uso real, como poderíamos saber que o agent fez algo errado? E, com agents, as coisas dão errado silenciosamente. Então, em vez de um erro de segmentação ou algum erro de fato, o pipeline passa por 100 documentos e talvez não detecte uma digitalização na

09:19 página 30, ou talvez o usuário não tenha especificado que tipos de documentos seriam inseridos no pipeline. E, basicamente, essas duas coisas são a mesma falha. O próprio agent está completamente errado, mas com muita confiança, e a incerteza que ele tem é totalmente invisível. Então, tudo o que fizemos para corrigir isso se resumiu basicamente a uma mudança: tornar a incerteza realmente legível. No nosso sistema, ou com a Reducto, as falhas carregam informações. Então, com o Extract, geramos pontuações de confiança, caixas delimitadoras e todas essas informações sobre o que deu errado. Conseguimos criar ferramentas que alimentam essas informações de volta para o modelo, o que ajudou a otimizar o schema de extração ao longo do tempo e a obter resultados mais precisos dos documentos. Mas isso é apenas a incerteza do resultado. O agent também precisa expor a própria incerteza. Quando encontra algo ambíguo, duas maneiras de interpretar um campo ou um tipo de documento que ainda não viu, ele não deve adivinhar, e

09:51 não deve simplesmente parar exatamente onde está. Em vez disso, deve perguntar: “Posso interpretar isso de duas maneiras”, e dizer ao usuário: “O que você quis dizer?”. Então, basicamente, nos nossos evals, começamos a reprovar o agent por fazer suposições frágeis e demos ao nosso harness orientações no prompt para usar as ferramentas de fazer perguntas ao usuário, entre outras, oferecidas pelo Claude Code e por outros harnesses de ponta, em vez de adivinhar. Então, recompensamos perguntar em vez de adivinhar. E o julgamento não está apenas no agent

10:22 sozinho. O usuário ainda supervisiona todo esse pipeline, e a confiança e o raciocínio do agent eram então apresentados como orientações no prompt do MCP. Assim, sempre que você cria algo novo, ele explica ao usuário o que fez e por quê, para que o usuário possa revisar, agindo inerentemente a serviço dele. O agent basicamente atende ao que você escreveu, e não ao resultado que você queria. Então,

10:52 o que acontece se você tornar a incerteza um pouco mais legível e deixar o julgamento final nas mãos da pessoa, onde ela pode de fato ser responsabilizada? Então, aquela pergunta de esclarecimento faz o trabalho das três coisas: dá contexto ao modelo, capacidade e também inclui uma pessoa no ciclo para realmente exercer esse julgamento e verificar as coisas. Então, voltando a todos esses modos de falha em geral, inicialmente tínhamos um modo automático que ninguém conseguia inspecionar. Tínhamos respostas erradas que

11:23 basicamente chegavam em silêncio. E depois, um agent que passava no teste trapaceando na recompensa ou escondendo o que tinha feito. No fundo, são basicamente manifestações do mesmo problema: o agent tinha mais autonomia e mais acesso do que a pessoa conseguia verificar. E essa inteligência está na construção como um todo. Então, construir o pipeline, gerar o schema e buscar o contexto certo é onde o agent é mais poderoso e onde um erro custa menos, porque a pessoa está bem

11:54 ali. Ao construir para essa interface, também conseguimos aumentar a satisfação dos usuários com o MCP, porque eles podiam realmente ver o que estava acontecendo. E, usando a Reducto para a camada de documentos, podemos garantir análises e extrações precisas nas partes do pipeline em que não podemos confiar nos agents. Onde o agent opera, ele conquista confiança sendo verificável e correto, e construindo confiança a serviço do usuário. E toda essa conversa que tivemos sobre legibilidade é o que realmente

12:25 dá resultado. Agents são apenas inteligência dentro de uma caixa, e o harness ao redor deles é o que lhes dá a capacidade de entregar esses resultados nas etapas seguintes. E, quando chegamos a esse ponto, nos concentramos na instrumentação: registrávamos cada sessão do MCP e os prompts enviados pelo modelo. Também pedimos à nossa equipe de vendas e a outras pessoas da equipe que exportassem suas sessões do Claude Code para entendermos como ele estava se comportando. Em que situações as pessoas substituíam as decisões do agent, onde a confiança do modelo

12:58 ficava baixa e quando ele fazia perguntas. E, como adicionamos toda essa instrumentação, ela alimentava as orientações de longo prazo que o MCP tinha. Assim, o sistema ficou melhor em construir pipelines construindo mais pipelines, sem que precisássemos reescrevê-los manualmente. Isso se tornou um ciclo de autoaperfeiçoamento por organização ou por usuário que estivesse construindo esses pipelines. No geral, a base continuou sendo a mesma decisão: mantivemos o modelo muito orientado e fácil de inspecionar,

13:28 e todo o resto eram as informações ao redor que realmente orientavam o modelo. E algo que me mostrou que estávamos fazendo algo certo com essas melhorias foi que nunca falei explicitamente para a equipe de vendas usar o agent para construir pipelines. Em vez disso, apenas o disponibilizei como ferramentas de produto no nosso Cloud Enterprise. A equipe de vendas e várias outras pessoas da equipe começaram a incorporá-lo aos seus workflows. Então, antes de uma ligação com um cliente, usavam o CircleBack ou o Slack para aprender

14:00 sobre o cliente e, depois, usavam o MCP para fazer perguntas sobre ele e então construir um pipeline para esse cliente nas etapas seguintes. Então, quando a experiência com o agent foi realmente construída a serviço das pessoas que o usavam, não ficamos empurrando as pessoas para ele. Em vez disso, elas foram atrás dele e começaram a usá-lo como um recurso para toda a empresa. E foi aí que também começaram a confiar o suficiente nos resultados para apresentá-los a clientes importantes, porque a demonstração não apenas funcionava: a pessoa de fato

14:32 dizia: “Ei, eu construí isto. Venha dar uma olhada.” E isso realmente deu resultado nessas ligações de vendas. E espero que as reações no Slack também ajudem a avaliar um pouco isso. Então, no geral, alguns meses atrás eu teria dito que agent first significa ter o melhor modelo, a melhor velocidade de inference ou a maior inteligência do modelo. E, com os modelos melhorando, dos proprietários aos open source, dos caros aos baratos, acho que agora significa quase o oposto do que parece. Até certo ponto, o

15:04 agent não vem primeiro. E, para construir uma experiência para agents, é preciso considerar o agent no ciclo, junto das pessoas que precisam responder pelo trabalho nas etapas seguintes. Então, a questão não é apenas: a que o agent se conecta? Hoje, o agent de todo mundo se conecta a tudo, e o Claude pode criar um novo conector para você imediatamente. Mas, além disso, quando seu agent está completamente errado, mas com muita confiança, quem descobre e com que rapidez? Se você construir pensando nisso, poderá

15:34 construir algo em que as pessoas realmente confiem para realizar trabalho de verdade. E é isso. Obrigado, pessoal. Além disso, estamos no estande da Reducto, o P8, e temos muitas vagas abertas. Então, venham conferir em reductoai.notcurious. Obrigado.

16:04 >> [música]

16:36 >> [música]

Transcrição original

[00:01] [music] >> So, I’m Avi, and I work on product here at Reducto. And before I dive in right away, I wanted to give you guys some more context on what Reducto is. Uh we’re an agentic document platform, which basically means that we help teams turn messy, unstructured documents into data that your tools and your AI agents

[00:33] can understand. I’ll jump into the agents themselves in a second, but I’d like to talk about where we’re at first really quick. In the last 3 years, we’ve processed over 3 billion documents across customers like Harvey, Scale AI, and top five global tech companies and hedge funds. Running at that scale means that we’ve seen basically every way a document can break in production, and we’ve iterated our product and our models to handle basically anything that you can throw at them.

[01:04] And getting AI to work on a clean document with a frontier model is not super hard anymore. We basically like you can throw something in the cloud, and you might get like 60% of the way there. But the hard part is production. Scanned documents, rotated pages, etc. And the model starts hallucinating because a large majority of enterprise data is unstructured. And so Reducto is a layer that sits between your model and that data. We handle all the complex layouts and post-processing,

[01:35] and that way we end up working with and building a lot of agents ourselves while designing these pipelines. So, now that you know a little more about what we do, I’m going to dive into our main topic with something seemingly unrelated. Um I visited my girlfriend this past weekend, and she gave me a sticker from the movie Mean Girls. And basically, it was an agentified version of it. So, it says, “Get in, loser. We’re building agent-first software.” And in true software engineer fashion, I had to put a sticker like that on my laptop. And she got this from work, but she

[02:06] asked me like, “What is agent-first software?” cuz she doesn’t work in AI. And as as I was like doing so or as I was thinking about it, I realized I have a lot of different answers. Building a really good harness, building a really good API, writing or iterating on prompts. All of these don’t really um land on the agent being put first. They’re more so just optimizing the model. Agent-first software is inherently an architecture problem. And so, I think that structure, that

[02:38] architecture, really comes down to one question, and that is who pays for the agent being wrong. And to that, I think there are like three buckets that you can put this into. So, you have auto mode to start, where you optimize for autonomy, you write a prompt, and you let the agent do whatever it wants. And when it messes up, which it will, you won’t have any idea because it’s really confident about what it’s doing, and you’re the one that’s paying for it being wrong to your customers, your users, etc. Then you have user-first.

[03:08] This is where you optimize the human interface, give the user all the knobs, and then you build on an agent that can’t really do much, which is basically just a chatbot experience. You’ve both capped the user’s understanding of the product because now they can’t prompt it, and the agent’s capability within as well. And lastly, the bucket that I think wins here is agent experience in service of the user. This is where the agent’s capabilities are structured to give the model um rich

[03:38] and scoped capabilities where it can do things that the user really wants, aiding and enabling them, and even where the human can still verify the work that it’s doing. This framing is what turns agent experience into less of a question of the model and more of a question of context, capability, and overall self-improvement. And here’s how I discovered these buckets and came to that last point. At Reducto, we’ve been building tools that basically automate end-to-end document work through pipelines. Think that we

[04:10] first parse a document, then we classify it, or maybe split it into sections, and then extract from it. Um and that’s in use cases like invoicing, contract management, and all these things that require human input. One thing that I noticed early on was that any of the users, especially our sales team at Reducto, was spending all their time in configuration instead of outcomes. And that’s a larger problem across the board because legacy interfaces were designed for kind of building that pipeline. Meanwhile, in this kind of agentic work

[04:41] world, we’re increasingly focused on the final deliverable and how can we get the user to that point as fast as possible. So, the clear move to get here for us was an MCP server. Let the agent do the heavy lifting and only burden the user with thinking about their use case and writing a prompt. To get some validation for the direction, I threw together an MVP with Claude code, and every API endpoint that drove our app was given an MCP tool in one massive file. I gave it a really

[05:11] pointed prompt. I put it in the Slack, and honestly, it was pretty nice. Um to some extent, it should have worked in that setting. I knew exactly what I was doing. I was building a really curated demo, and that’s why the standalone demo told me nothing at all. The real test happened when I gave the MCP to everyone on the team, and immediately it broke. And here’s how. Someone would feed it a half-baked description from a customer call or maybe a Notion page, and the agent would

[05:42] just start going. It’d build the entire workflow end-to-end, but very confidently, it would tell the user that everything it did was right, but neither the user nor the agent could explain what the workflow actually did. And that is the root awakening of auto mode in production. The agent never really said that it’s not sure. It handled with every tool that it had, and there was nowhere for a human to really validate or think about what was going on. We built something that could communicate with our system, but we

[06:13] hadn’t built something that could actually work with it. And you’d think that the fix here is more detail on the system prompt or more model guidance, but realistically it’s architecture. The whole file that we used to talk to the MCP, I deleted the entire thing in one commit. And what replaced it wasn’t more tools. It was mostly fewer tools, but they carried the structure of actual work. So for example, instead of one create step of this workflow to uh call over

[06:44] and over, and just praying that the agent assembled right in the pipeline, I built tools that understood how our internal dashboard or our product works. For example, a common use case with Reducto is to route our classify endpoint that classifies documents into an extract node. And what that does is basically extract information downstream. And instead of basically letting the model guess this or figure it out through the prompt, I turned it into a single classify to extract tool. And after each

[07:15] step, the agent gets contextual guidance on what actually comes next, with certain tools even chaining automatically like this one. Rather than the agent having to guess or think about what is right versus being told what’s right. Now the agent doesn’t get to freelance the parts that we know are true. And since agents are stateless, we even added a snapshot tool. So this is one call that basically hands back the live state of our pipeline from the context of the entire flow to the

[07:46] errors that were surfaced with like really specific error codes. And that way they can reference what’s actually there instead of guessing variable names, hallucinating, etc. By moving context out of the prompt and into structure, the agent stopped guessing and started referencing. And because the tools only let pipelines take the shape that we as the engineers on the product wanted, the human could follow exactly what happened and we could explain the agent’s outputs to downstream users of

[08:17] this MCP tool. So, to avoid auto mode, you don’t hand your agent an API, you hand it tools that carry the overall expertise such as the right patterns, the state, and the validators so the correct path also becomes the simplest path that the MCP can take. So, we can build good pipelines now. We’re done, right? Not really. Thinking back to auto mode, the agent was confidently wrong and no one could see it. Um that what we just talked about

[08:47] fixed that for building. The tools made the structure really legible and the human could follow what the agent did. But now the problem showed up at runtime. When the outcome itself that the agent is trying to build goes wrong, who can tell? For example, if we had a really bad schema or maybe the user didn’t really specify the actual use case, how can we tell that the agent did something wrong? And with agents it goes wrong quietly. So, instead of a seg fault or some actual error, um the pipeline runs across 100 documents and maybe it misses scan on

[09:19] page 30 or maybe the user didn’t specify what types of documents were going into the pipeline. And basically both of these things are the same failure. The agent itself is very confidently wrong and the uncertainty that the agent has is completely invisible. So, everything that we did to fix this basically came down to one uh change, which was making uncertainty really legible. In our system or with Reducto, uh failures carry information. So, with

[09:51] Extract, we output confidence scores, bounding boxes, all of this information about what went wrong, and we were able to build tools that feed that information back into the model, which actually helped optimize the extract schema over time, and get more accurate document outputs. But, that’s just the outcome uncertainty. The agent also has to surface its own uncertainty. When it hits something ambiguous, um two ways to read a field or a document type that it hasn’t seen, it shouldn’t guess, and it

[10:22] shouldn’t just pause exactly where it is. And rather, it should ask, “I can read this two ways,” and tell the user, “What did you mean?” And so, basically in our evals, we started failing the agent for building any shaky assumptions, and we gave our harness uh prompt guidance to use the ask user question tools, etc., that Cloud Code and other like frontier harnesses offer, instead of guessing. So, we rewarded asking instead of guessing. And judgment doesn’t live in the agent

[10:52] alone. This entire pipeline is still overseen by the user, and the confidence and the reasoning of the agent was then outputted as basically prompt guidance in the MCP. So, now every time you make something new, it explains to the user what it did and why, so the user can then review it, inherently acting in service of the user. The agent basically satisfies what you wrote, and not the um outcome that you wanted. So,

[11:23] what happens if you make the uncertainty basically a bit more legible, and you keep the final judgment where it can actually be accountable in the hands of the human, then that one clarifying question does the work of all three, giving the model context, capability, and also adding a human in the loop to actually build that judgment and verify things as well. So, going back to kind of all of these failure modes overall, we had initially an auto mode that nothing nobody could inspect. We had wrong answers that

[11:54] basically arrived in silence. And then an agent that passed the test by reward hacking or hiding what it did. And underneath, they’re basically one shape where the agent had more autonomy and more access than the human could verify. And that intelligence lives in the construction overall. So, building the pipeline, generating the schema, and pulling in the right context is where the agent is more most powerful and where a mistake is the cheapest because the human is right

[12:25] there. By building for that interface, we were able to also have user satisfaction go up with the MCP because they could really see what was going on. And by using Reducto for the document layer, we can guarantee accurate parses and extractions for parts of the pipeline that we can’t trust agents with. Where the agent operates, it earns trust by being verifiable, correct, and building trust in service of the user. And the whole conversation we had about legibility overall is what inherently

[12:58] pays off. Agents are just intelligence in a box and the harness that you surround them with is what provides them with the ability to deliver these outcomes downstream. And so, once we reach this point, we focus on instrumentation where every MCP session, the prompts that were sent from the model were logged, and we even asked like our sales team and other people on the team to basically export their cloud code sessions to understand how how was behaving. Where humans overrode the agent, where

[13:28] confidence of the model ran low, and where it asked questions. And because we added all this instrumentation, um it flowed back into the long-term guidance that the MCP had overall. So, the system got better at building pipelines by building more pipelines without us rewriting by hand. This then became a self-improving loop per org or per user that was building these pipelines. The foundation became overall the same decision where we kept the model very guided and very inspectable,

[14:00] and the information around it became everything else that actually guided the model. And so, one thing that kind of told me that we were doing something right with these improvements is I never like explicitly told the sales team to use the agent to build pipelines, but rather I just exposed it in our Cloud Enterprise as product tools. And the sales team and various other people on the team started basically wiring it into their workflows. So, before they had a customer call, they would use CircleBack or Slack and basically learn

[14:32] about the customer and then use the MCP to basically ask them questions about the customer and then build a pipeline for that customer downstream. So, when an agent’s experience was built really in service of the users that were using it, we weren’t pushing people directly toward it and rather they reached for it and actually started using it as a company-wide resource. And that’s where they also started to trust the output enough to put this in front of high-value customers because the demo didn’t just work, but the human actually

[15:04] said, “Hey, I built this. Come check it out.” And it actually paid off in these sales calls. And I hope the Slack reactions can also help gauge that a little bit. So, overall, a few months ago I would have told you that agent first is means that you have the best model, the best inference speed or intelligence of the model. And with models getting better from closed source to open source, from expensive to cheap, I think it now means almost the opposite of what it sounds. To some extent, the

[15:34] agent doesn’t go first. And to build for agent experience means you have to consider the agent being in the loop with the people who have to answer for the work downstream. So, it’s not just what does the agent connect to? Everyone’s agent connects to everything nowadays, and Claude can make a new connector for you immediately. But, regard Beyond that, it’s when your agent is really confidently wrong, who finds out and how fast did they find out? If you build for that, then you can

[16:04] build for something that people will actually trust with real work. And yeah, that’s about it. Thank you, guys. And also, we’re at Reducto’s at a booth P8, and we are hiring for a lot of positions. So, please come check it out at reductoai.notcurious. Thank you.

[16:36] >> [music]