Talvez ela fale mais sobre o fim de uma certa fase do software.

Por muito tempo, as empresas compraram sistemas para ajudar pessoas a executar tarefas.

Um software para contabilidade.
Um software para atendimento.
Um software para auditoria.
Um software para organizar processos internos.

A promessa sempre foi produtividade.

Mas, no fundo, o cliente nunca quis só mais uma tela, mais um login ou mais um painel.

Ele queria o problema resolvido.

A Sequoia trouxe uma tese muito interessante quando falou que “services” podem ser o novo software.

E, sinceramente, isso faz bastante sentido.

A próxima geração de produtos talvez não venda apenas a ferramenta para o contador fechar o mês.

Ela pode entregar o fechamento pronto.

Talvez não venda apenas um sistema para o jurídico revisar documentos.

Entregue o contrato analisado, classificado e encaminhado.

Talvez não ofereça apenas uma plataforma para auditoria médica.

Entregue a inconsistência identificada, a evidência organizada e a trilha de decisão pronta para revisão.

Acho que essa é a mudança mais importante.

Estamos saindo de um mercado em que o software era usado por pessoas para executar processos.

E entrando em um mercado em que o software, junto com agentes, dados, integrações e regras de negócio, começa a executar partes relevantes desses processos.

Isso não significa o fim do SaaS.

Mas certamente muda o lugar dele.

O SaaS fechado, genérico e centrado apenas em funcionalidades pode perder espaço.

Por outro lado, o software que se transforma em capacidade operacional, plugável, auditável e orientada a resultado tende a ganhar ainda mais valor.

No fim do dia, o cliente não quer comprar “mais uma ferramenta”.

Ele quer reduzir fricção, custo, tempo e risco.

Quer menos operação manual.

Quer mais clareza sobre o que foi feito, por que foi feito e com base em quais evidências.

Por isso, eu acredito que o futuro do desenvolvimento de software não está apenas em criar plataformas cada vez maiores.

Está em construir sistemas mais inteligentes, mais especializados e mais próximos do resultado que o negócio realmente precisa entregar.

A SaaSpocalypse não é o fim do software.

Talvez seja o começo de uma nova pergunta:

Você está vendendo uma ferramenta ou está entregando o trabalho pronto?

A primeira decisão de arquitetura para um agente de IA em saúde suplementar não deveria ser qual LLM usar.

Deveria ser outra:

onde esse agente pode rodar, o que ele pode acessar e o que ele não pode tocar sem deixar registro?

Essa pergunta parece menos interessante do que discutir modelo, prompt, RAG ou orquestração. Mas, em uma operadora de saúde, é ela que separa um piloto promissor de uma arquitetura defensável.

Um agente que apoia a análise de pedidos pode lidar com laudos, prescrições, códigos TUSS, histórico de utilização, regras contratuais, dados clínicos e informações sensíveis do beneficiário.

Ele pode acelerar o trabalho do regulador médico.
Pode reduzir esforço operacional.
Pode ajudar a encontrar inconsistências.
Pode trazer ganho real de produtividade.

Mas também pode errar.

E quando isso acontece, a pergunta deixa de ser técnica.

Ela passa a ser institucional.

Vocês conseguem mostrar exatamente o que esse agente leu antes de sugerir aquela decisão?

Não apenas a resposta final.
Não apenas o prompt.
Não apenas um log genérico.

Mas a sequência real da execução.

Quais ferramentas ele chamou.
Com quais parâmetros.
Quais dados retornaram.
Qual era o contexto naquele momento.
Qual credencial foi usada.
Qual humano revisou depois.

É aqui que muitos copilotos começam a mostrar fragilidade.

Na demonstração, tudo funciona. O agente lê documentos, cruza informações e gera uma recomendação. O time técnico vê valor. A liderança enxerga escala. A operação percebe produtividade.

Mas, quando jurídico, auditoria ou governança entra na conversa, a pergunta muda.

Não basta saber se o agente respondeu bem.

É preciso saber se aquela decisão pode ser reconstruída.

O perímetro vem antes da inteligência

Existe uma ansiedade natural em escolher o melhor modelo.

Claude, GPT, Gemini, modelos open source, fine-tuning, agentes, frameworks, templates de prompt. Tudo isso importa.

Mas, em saúde regulada, a arquitetura não deveria começar por aí.

Antes do modelo, vem o perímetro.

Onde o dado clínico fica enquanto o agente raciocina?
O que sai do ambiente da operadora?
Quem controla a execução?
Quem limita a credencial?
Quem define a política de rede?
Quem consegue provar o que aconteceu depois?

Essa é a base.

Porque um agente nesse contexto não está apenas respondendo perguntas. Ele está operando perto de decisões que podem impactar custo assistencial, experiência do beneficiário, relacionamento com prestadores e risco regulatório.

A IA pode até responder bem.

Mas, se a arquitetura não permite controle e rastreabilidade, o projeto ainda está incompleto.

O papel do sandbox controlado

O movimento recente da Anthropic com Claude Managed Agents, sandboxes controlados e conexão com servidores MCP privados aponta para uma direção importante.

Agentes corporativos não podem rodar como processos soltos, com acesso amplo e pouco observável.

Eles precisam de contenção.

Um sandbox controlado permite definir onde o agente executa, quais recursos pode usar, quais processos são permitidos, qual política de rede está ativa, quais credenciais existem naquela sessão e por quanto tempo o ambiente permanece vivo.

Para uma operadora, isso muda bastante o desenho.

O agente não precisa receber uma chave ampla para consultar tudo. Ele pode receber uma permissão estreita, temporária e específica para aquele pedido.

Se for induzido por prompt injection a tentar acessar algo externo, a política de rede pode bloquear.

Depois que a análise termina, o ambiente pode ser descartado.

Isso não resolve todos os problemas. Sandbox adiciona complexidade, pode gerar latência e exige engenharia de plataforma.

Mas coloca a conversa no lugar certo.

Antes de perguntar se o agente é inteligente, precisamos perguntar se ele está contido.

MCP privado e acesso auditável ao dado

O segundo ponto é como o agente acessa informação.

Muitos copilotos nasceram com RAG. Documentos são transformados em embeddings, armazenados em um índice vetorial e depois recuperados por similaridade.

Isso pode funcionar em vários cenários.

Mas, em saúde suplementar, especialmente quando falamos de auditoria e rastreabilidade, o RAG ingênuo tem limites.

Nem sempre é simples provar de onde veio a informação, em qual versão, com qual critério de acesso e qual foi o retorno exato usado na decisão.

Com MCP privado, o contrato muda.

Em vez de o agente “procurar algo parecido”, ele chama ferramentas específicas, dentro do perímetro da operadora.

Por exemplo:

get_beneficiary_history
validate_tuss_code
check_authorization_rules
retrieve_claim_documents

Cada chamada pode ser registrada.

Quem chamou.
Quando chamou.
Com quais argumentos.
Qual foi o retorno.
Qual decisão usou aquele dado.

Isso aproxima o agente de um sistema crítico tradicional.

E, em saúde, essa diferença importa muito.

Porque confiança não vem apenas da resposta.

Vem da capacidade de explicar como a resposta foi construída.

A trilha auditável vira parte do produto

Quando juntamos sandbox controlado com MCP privado, o principal resultado não é apenas um agente mais seguro.

É um agente mais defensável.

A trilha auditável deixa de ser detalhe técnico e passa a ser parte do produto.

Ela mostra o caminho da decisão.

Quem iniciou a análise.
Onde o agente rodou.
Quais ferramentas foram chamadas.
Quais dados retornaram.
Qual recomendação foi gerada.
Quem revisou.
Onde o agente convergiu com o humano.
Onde divergiu.
E por quê.

Esse tipo de registro muda a conversa com auditoria, jurídico, governança e liderança executiva.

Sem isso, o agente pode até parecer bom no piloto.

Mas fica frágil quando alguém precisa defender a decisão fora da demo.

O ponto central

Existe uma diferença grande entre construir um agente que funciona e construir um agente que pode ser defendido.

O primeiro impressiona em uma apresentação.

O segundo sobrevive a uma auditoria.

Na saúde suplementar, essa diferença é essencial.

Um agente pode errar. A base pode estar incompleta. Uma regra pode mudar. Uma ferramenta pode retornar algo inesperado. O contexto pode ser ambíguo.

A pergunta não é se isso vai acontecer.

A pergunta é se, quando acontecer, a operadora conseguirá reconstruir o caminho.

Por isso, a pergunta mais importante para uma operadora que está avaliando agentes de IA não deveria ser apenas:

qual modelo vocês usam?

A pergunta deveria ser:

vocês conseguem provar exatamente o que o agente fez antes de sugerir uma decisão?

Se a resposta for não, ainda estamos falando de protótipo.

Se a resposta for sim, começamos a falar de arquitetura de produção.

No fim, a maturidade de um agente em saúde não será medida apenas pela fluência da resposta.

Será medida pelo perímetro onde ele roda, pela forma como acessa dados e pela qualidade da trilha que deixa para trás.

Porque, em saúde, confiança não nasce da automação.

Nasce da rastreabilidade.

A maior parte das conversas sobre LLMs ainda gira em torno de modelos maiores, respostas mais rápidas e janelas de contexto cada vez mais longas.

E faz sentido. A janela de contexto é uma parte essencial da evolução desses modelos.

Ela define quanto conteúdo uma LLM consegue “enxergar” de uma vez: instruções, histórico da conversa, documentos, respostas de ferramentas, logs, decisões anteriores e tudo aquilo que o agente precisa considerar para continuar raciocinando.

Mas existe um ponto menos óbvio nessa discussão.

Em agentes de IA, o problema não é apenas quanto contexto cabe na janela. O problema é o que acontece com o comportamento do agente quando esse contexto começa a ficar cheio.

É aqui que entra o conceito de context anxiety.

O termo descreve um comportamento observado em alguns agentes quando eles percebem, ou assumem, que estão próximos do limite da janela de contexto. Em vez de continuar a tarefa com o mesmo nível de rigor, o agente pode começar a acelerar conclusões, resumir demais, cortar etapas, declarar que terminou antes da hora ou evitar aprofundar decisões importantes.

Não é “ansiedade” no sentido humano da palavra. É uma metáfora para um comportamento técnico: o modelo passa a agir como se estivesse ficando sem espaço para pensar.

Provedores como Anthropic e OpenAI têm tratado cada vez mais a gestão de contexto como uma parte central da arquitetura de agentes. A Anthropic chegou a descrever o comportamento conhecido como “context anxiety”, quando um agente pode começar a encerrar tarefas prematuramente ao perceber que está próximo do limite da janela de contexto. Já a OpenAI aborda o tema pelo lado de context engineering e short-term memory management, destacando que mesmo janelas grandes podem ser prejudicadas por históricos mal curados, excesso de ruído e resultados redundantes de ferramentas.

Esse ponto muda bastante a conversa, porque mostra que o desafio não está apenas no tamanho da janela, mas na forma como o sistema administra o que entra nela.

Durante muito tempo, a solução parecia simples: aumentar a janela de contexto.

Se 8 mil tokens eram pouco, passamos para 32 mil. Depois 128 mil. Depois centenas de milhares. Hoje já falamos em janelas de contexto enormes.

Mas janelas maiores não resolvem tudo sozinhas.

Na prática, um agente pode falhar por excesso de informação, não apenas por falta dela.

Ele pode se perder porque recebeu logs demais. Pode dar peso a uma decisão antiga que já não faz sentido. Pode recuperar uma instrução desatualizada. Pode carregar erros de uma etapa anterior para dentro das próximas decisões. Ou pode começar a “fechar” a tarefa cedo demais porque entende que precisa economizar espaço.

Esse é um ponto essencial para empresas que estão criando agentes para processos reais.

Um chatbot simples pode lidar com conversas curtas. Mas um agente que analisa documentos, consulta sistemas, executa tarefas, interpreta regras de negócio, chama APIs e acompanha um fluxo por várias etapas precisa de muito mais do que uma boa resposta.

Ele precisa de gestão de contexto.

E gestão de contexto não é apenas prompt engineering. É arquitetura.

É decidir o que entra no contexto, o que fica fora, o que vira memória, o que precisa ser recuperado sob demanda, o que deve ser resumido, o que deve ser descartado e o que precisa permanecer intacto.

Na minha visão, esse é um dos pontos mais subestimados na construção de agentes de IA.

Muitas vezes, a discussão fica concentrada no modelo: qual é mais rápido, qual responde melhor, qual tem mais tokens, qual custa menos. Mas, quando falamos de agentes em produção, o sistema ao redor do modelo passa a ser tão importante quanto o próprio modelo.

Pesquisas recentes também caminham nessa direção. O ReadAgent, por exemplo, propõe o uso de “gist memories”, ou memórias resumidas, para permitir que agentes lidem com documentos longos de forma mais robusta. A ideia é que o agente não dependa apenas de carregar tudo na janela, mas consiga comprimir episódios e buscar novamente trechos relevantes quando precisar.

Outro trabalho, o ACON, trata a compressão de contexto como um problema central para agentes de longo horizonte, especialmente porque agentes acumulam histórico de ações, observações e interações ao longo da execução. Nos experimentos descritos, a abordagem reduziu uso de memória em 26% a 54%, preservando grande parte da performance.

Isso reforça uma mudança importante: a próxima fase dos agentes de IA não será definida apenas por quem usa o modelo mais poderoso. Será definida por quem souber construir o melhor sistema ao redor dele.

Um agente confiável precisa saber quando lembrar, quando esquecer, quando pedir mais contexto, quando consultar uma fonte externa, quando criar um resumo e quando reiniciar uma etapa com clareza.

Porque contexto não é memória.

Contexto é o que o modelo enxerga agora. Memória é o que o sistema preserva para que o agente possa continuar operando com coerência ao longo do tempo.

Essa diferença parece simples, mas é crítica.

Quando tratamos a janela de contexto como se fosse memória permanente, criamos agentes frágeis. Eles parecem inteligentes no início, mas começam a degradar em tarefas longas. Perdem coerência, mudam critérios, esquecem decisões, repetem ações ou concluem cedo demais.

O impacto disso em ambientes corporativos pode ser grande.

Imagine um agente de auditoria médica que analisa documentos, regras, histórico de solicitações, evidências clínicas e critérios regulatórios.

Se ele perde contexto, pode ignorar uma evidência importante. Se compacta mal, pode apagar uma exceção relevante. Se entra em context anxiety, pode antecipar uma conclusão sem completar a análise.

Em processos críticos, isso não é apenas uma falha de experiência. É risco operacional.

Por isso, context anxiety deve ser visto como um alerta para qualquer empresa que esteja desenvolvendo agentes de IA em produção.

A pergunta não deve ser apenas: “qual modelo estamos usando?”

Também precisamos perguntar:

Como estamos gerenciando o contexto desse agente?

Quais informações são essenciais para a decisão?

O que pode ser resumido sem perda?

O que precisa ser preservado integralmente?

Quando o agente deve reiniciar com um novo contexto limpo?

Como garantimos rastreabilidade entre uma etapa e outra?

No fim, agentes inteligentes não dependem apenas de janelas maiores. Dependem de contexto bem desenhado.

A janela de contexto pode ser grande. Mas, se estiver cheia de ruído, histórico irrelevante e decisões mal preservadas, o agente continuará vulnerável.

Talvez a grande questão não seja apenas dar mais espaço para o modelo pensar.

É dar ao modelo o contexto certo, no momento certo, com a estrutura certa.

Porque, quando o contexto começa a acabar, o agente revela uma limitação importante: ele não precisa apenas responder bem.

Ele precisa conseguir continuar com coerência.

Referências

Anthropic: Scaling Managed Agents: Decoupling the brain from the hands.

Anthropic: Harness design for long-running application development.

Anthropic: Effective context engineering for AI agents.

OpenAI Cookbook: Context Engineering, Short-Term Memory Management with Sessions from OpenAI Agents SDK.