Você passou três sprints construindo a tela. Formulários, dropdowns, um wizard de cinco passos com uma barra de progresso da qual você estava estranhamente orgulhoso. Aí um usuário ignorou tudo isso, apontou um agente de IA para a mesma API que sustenta a sua tela, e terminou o trabalho em uma hora enquanto você ainda estava na daily. Este post é sobre o que esse momento realmente significa, e por que ele não é a morte do seu software.
TL;DR: Conectar APIs internas a um agente de IA via MCP transformou fluxos de várias semanas em conversas de uma hora, e isso muda quais partes do seu produto ainda merecem uma tela.
Stack: MCP (Model Context Protocol), agentes de IA, APIs REST internas, serviços de lógica de negócio
Nível: Intermediário
Tempo de leitura: ~5 min
Aqui está o que realmente acontece. Uma tela de SaaS tradicional é um caminho congelado através da sua lógica de negócio: alguém decidiu, meses atrás, quais campos você vê, em que ordem, e quais três dos seus quarenta endpoints aquele caminho tem permissão de tocar. É um ótimo negócio quando o caminho é comum e repetido, e um péssimo negócio no instante em que um usuário precisa de uma rota que ninguém previu. Um servidor MCP expõe essa mesma lógica de negócio como ferramentas combináveis, então um agente consegue montar uma rota na hora, em vez de esperar você publicar uma tela para ela. A pergunta de verdade deixa de ser UI contra API e vira uma mais afiada: quais fluxos merecem um caminho fixo, e quais merecem um caminho aberto. A maioria dos times constrói telas por reflexo, o que significa que despejam o melhor do seu esforço programando na unha rotas que um agente poderia montar sozinho, enquanto as rotas que de fato precisam de trilhos ficam com o tempo que sobrar.
Eu venho liderando essa virada na minha empresa, treinando gente técnica e não técnica para construir com agentes, e entrei com um modelo mental bem arrumadinho de como as pessoas iam usar aquilo. Eu estava errado, do melhor jeito possível. Semana passada um deles refez um processo que normalmente come um par de semanas e terminou em cerca de uma hora, porque o agente conseguia alcançar as nossas APIs internas diretamente e orquestrar a coisa toda de ponta a ponta. Eu nunca ensinei aquele fluxo a ele. Ele inventou no segundo em que a parede entre ele e os dados caiu.
Isso é a alavanca de guitarra de novo. Leo Fender parafusou aquela alavanquinha de trêmolo na Stratocaster nos anos cinquenta para os músicos darem um vibrato suave, uma oscilação de bom gosto no fim de uma nota. Aí o Hendrix agarrou aquilo e fez dive bombs, gritos e sons que os projetistas nunca imaginaram, porque uma boa ferramenta não tem opinião sobre para que serve. A gente construiu os nossos servidores MCP para expor um punhado de endpoints arrumadinhos. Os nossos usuários acharam os dive bombs.
Comece onde as APIs já estão limpas
A gente não tentou ferver o oceano. Começamos pelos sistemas internos que já tinham APIs bem definidas, porque um servidor MCP nunca é melhor do que a API embaixo dele. Embrulhar um endpoint limpo e previsível levou uma tarde. Embrulhar um caquético, cheio de efeitos colaterais surpresa, teria levado um mês e produzido um agente que mente para você com total confiança. Escolha primeiro as APIs chatas e bem-comportadas e conquiste a confiança antes de chegar perto do pântano.
Embrulhe a lógica, não a reescreva
Um servidor MCP não é uma aplicação nova. É um adaptador fino que pega endpoints que você já tem e os descreve como ferramentas que um agente pode chamar, com nomes e descrições escritos para um leitor que não é um dev de frontend. A Anthropic lançou o MCP em novembro de 2024 para matar o problema M vezes N: em vez de construir um conector sob medida para cada par de ferramenta e aplicação, cada lado fala o protocolo uma vez e as integrações encolhem de M vezes N para M mais N. Uma definição de ferramenta é basicamente um nome, uma descrição curta e um schema para as entradas, algo parecido com isto em espírito:
{
"name": "create_invoice",
"description": "Create a draft invoice for a customer from a list of line items",
"input_schema": {
"customer_id": "string",
"line_items": "array",
"due_date": "string (ISO date)"
}
}
O agente lê isso, descobre quando se aplica, e encadeia com a próxima ferramenta sem ninguém nunca desenhar uma tela para a combinação.
Decida o que continua sendo tela
Essa é a parte que pede cabeça fria, porque a conclusão empolgante, derrubar todas as UIs, também é a errada. Telas fixas ainda ganham onde o caminho precisa ser imposto ou repetido: um fluxo de aprovação onde pular um passo é um problema de compliance, uma tarefa diária que cem pessoas fazem exatamente do mesmo jeito, qualquer coisa onde deixar um agente improvisar é como você acaba explicando um incidente para o jurídico. Fluxos abertos com agente ganham na cauda longa: o trabalho exploratório, entre sistemas, de uma vez por trimestre, para o qual você nunca conseguiria justificar construir uma tela dedicada. O trabalho é separar o seu produto nesses dois baldes com honestidade, não tocar fogo em um deles e chamar isso de estratégia.
Trate a API como o produto, não como o encanamento
Quando um agente vira um consumidor de primeira classe da sua API, a API deixa de ser encanamento escondido atrás de um frontend e vira uma superfície que usuários de verdade tocam. Isso deveria mudar como você a projeta. Os verbos ficam mais claros, os erros ficam legíveis, as descrições passam a ser escritas para alguém, ou alguma coisa, que nunca viu o seu código. Um endpoint chamado doStuff que devolve um alegre 200 mesmo quando falhou era sobrevivível quando só o seu próprio app React chamava ele. Deixa de ser sobrevivível no momento em que um agente está lendo aquela descrição para decidir se deveria sequer chamar a coisa.
Onde isso nos deixa
Então, não, isto não é o fim do SaaS. Esse título sempre foi isca. O que acabou foi a suposição silenciosa de que todo fluxo merece uma tela. A gente embrulhou APIs internas limpas como ferramentas MCP, viu usuários orquestrarem rotas que nunca desenhamos, manteve os trilhos onde imposição de fato importa, e começou a tratar as nossas APIs como superfície de produto em vez de fiação de bastidor. O software está bem. Ele só ganhou uma alavanca de guitarra, e os usuários já sabem como tocar.
Próximos passos
- Audite as suas telas: Cace as que existem só porque um usuário um dia precisou de um caminho que a sua UI nunca ofereceu. Essas são as suas primeiras candidatas a virar ferramenta.
- Escreva APIs para um leitor não humano: Nomes claros, erros honestos, descrições de verdade. O agente sabe exatamente o tanto que você se deu o trabalho de contar, e nem um byte a mais.
- Mantenha os trilhos de propósito: Aprovações, compliance e tarefas de alta frequência ainda merecem uma tela fixa. Escolha isso deliberadamente em vez de cair nele por padrão.
- Comece pelas APIs bem-comportadas: Embrulhe primeiro os endpoints previsíveis. Os caquéticos podem esperar até você realmente confiar no padrão.
Dúvidas ou ideias, ou vendo os seus próprios usuários saírem do roteiro? Me acha no LinkedIn ou no GitHub.