O modelo parou de ser vantagem competitiva — e quase ninguém mudou o orçamento

No primeiro semestre de 2026 aconteceram três coisas ao mesmo tempo, e nenhuma empresa que eu conheço reagiu rápido o suficiente às três juntas: o custo de inferência despencou de novo, os modelos abertos ficaram competitivos o bastante pra maioria dos casos de uso corporativo, e o Model Context Protocol (MCP) deixou de ser "aquela ideia da Anthropic" pra virar o jeito padrão de conectar agente a sistema — com todo mundo, incluindo concorrentes diretos, implementando suporte.

A conclusão que interessa pra quem toma decisão de arquitetura não é "qual modelo é o melhor agora". É que essa pergunta importa cada vez menos.

O fosso de qualidade encolheu — e isso muda o cálculo

Compare o Comparacao abaixo com a conversa que qualquer comitê de arquitetura tinha em 2024, quando escolher entre modelo aberto e fechado era decisão de meses:

Isso não significa que modelo parou de importar. Significa que ele parou de ser a decisão que trava um projeto por três meses. Continua havendo vantagem real de modelos fechados de ponta em raciocínio multi-etapa muito longo e em janelas de contexto que ultrapassam o que a maioria dos modelos abertos sustenta com qualidade estável — mas essa é uma fatia cada vez menor dos casos de uso que uma empresa comum resolve no dia a dia.

MCP ganhou — e trouxe um problema novo

A adoção do Model Context Protocol como padrão de integração entre agentes e ferramentas é a mudança de infraestrutura mais concreta deste ciclo. Em vez de cada fornecedor de agente construir seu próprio jeito proprietário de conectar a um CRM, um banco de dados ou uma API interna, existe agora uma interface comum — um servidor MCP exposto uma vez, consumível por qualquer agente compatível.

O ganho é real: menos código de integração customizado, mais portabilidade entre agentes de fornecedores diferentes, e um ecossistema de servidores MCP prontos que reduz o tempo de conectar um agente a um sistema já existente de semanas para dias.

O padrão resolveu o problema de portabilidade e criou, em troca, um problema de governança que a maioria das empresas ainda não tratou com a seriedade que merece: cada servidor MCP novo é uma superfície de permissão nova, e "dar acesso ao agente" não pode significar "dar o mesmo acesso que um funcionário sênior teria".

O custo caiu — mas não pra onde as empresas acham

O erro de planejamento mais comum que vemos agora não é subestimar o preço do token — isso todo mundo já aprendeu a calcular. É subestimar que um sistema agentico faz múltiplas chamadas por interação (planejamento, chamada de ferramenta, verificação, síntese) e que o custo de operação real está migrando pra orquestração, logging, retries e observabilidade — não pro modelo em si.

import { z } from "zod";

// Definição mínima de uma ferramenta MCP: nome, schema de entrada validado
// e um handler que o servidor expõe para qualquer agente compatível chamar.
export const consultarPedidoTool = {
  name: "consultar_pedido",
  description: "Consulta o status de um pedido pelo número, com escopo restrito ao tenant do chamador.",
  inputSchema: z.object({
    numeroPedido: z.string().min(1),
    tenantId: z.string().uuid(),
  }),
  async handler({ numeroPedido, tenantId }: { numeroPedido: string; tenantId: string }) {
    // Autorização explícita por tenant — não confiar no agente pra respeitar
    // o escopo sozinho é o que separa uma integração segura de um incidente.
    return buscarPedidoAutorizado(numeroPedido, tenantId);
  },
};

Note o tenantId explícito no schema, validado antes do handler rodar. É pouco código, mas é exatamente o tipo de disciplina que falta nos servidores MCP publicados às pressas — e é barato de fazer certo desde o início, caro de corrigir depois que o agente já está em produção com acesso amplo demais.

O que isso muda no orçamento de 2026

Se a diferença de qualidade entre modelos encolheu e o custo por token não é mais o gargalo, o dinheiro que ia pra "escolha de modelo" precisa migrar pra três lugares que ainda são artesanais na maioria das empresas:

• Avaliação contínua: não dá pra confiar em "parece bom" quando o modelo por trás muda a cada atualização silenciosa do fornecedor.
• Governança de permissão de ferramentas: cada servidor MCP exposto é uma decisão de segurança, não um detalhe de implementação.
• Observabilidade de pipeline agentico: rastrear cada chamada, cada ferramenta invocada e cada custo, porque debugar um agente que fez seis chamadas encadeadas sem log estruturado é praticamente impossível.

Esse último ponto conecta direto com o que discutimos no artigo sobre RAG em produção: o padrão se repete — o componente que todo mundo customiza é o modelo, e o componente que todo mundo negligencia é o que decide se o sistema é confiável em produção.

A pergunta certa pra fazer no próximo comitê de arquitetura

Trocar "qual modelo devemos usar" por "qual modelo é bom o suficiente pra essa tarefa, com que latência e a que custo, e quem audita o que os nossos agentes têm permissão de fazer" não é uma frase mais elegante. É a pergunta que efetivamente separa quem gasta 2026 discutindo benchmark de quem gasta 2026 entregando sistema que funciona com o cliente real de qualquer jeito, dado o modelo que estiver disponível naquele mês.

O modelo virou commodity mais rápido do que a maioria dos orçamentos internos se ajustou. Quem ainda trata escolha de modelo como decisão estratégica central está otimizando a variável que já parou de ser o fator limitante.