O modelo não é o produto: arquitetura, validação e a nova engenharia da IA

Nos últimos meses, boa parte da conversa sobre inteligência artificial girou em torno da mesma pergunta: qual é o melhor modelo?

É uma pergunta legítima, mas cada vez menos suficiente.

Dois trabalhos publicados nos últimos dias chamaram minha atenção porque atacam o problema por outro ângulo. Em vez de perguntar apenas qual modelo é mais inteligente, eles analisam como o sistema é montado ao redor do modelo.

E os resultados apontam para algo que considero muito importante para quem desenvolve software, cria SaaS ou automatiza processos:

A qualidade de um sistema com IA depende tanto da arquitetura quanto do modelo. Em alguns cenários, depende mais.

Um estudo comparou diferentes estruturas de agentes usando MCP e CLI e encontrou variações enormes de custo mesmo quando a tarefa era a mesma. Outro mostrou um agente de analytics com modelo de 7 bilhões de parâmetros superando um baseline direto de 32 bilhões quando regras determinísticas, camada semântica e validações eram colocadas no caminho da resposta.

Ao mesmo tempo, o WordPress 7.1 se aproxima do lançamento com uma evolução da Abilities API, um mecanismo justamente para expor de forma estruturada o que um site pode fazer para ferramentas e agentes de IA.

Minha leitura é que esses movimentos fazem parte da mesma mudança.

Estamos saindo da fase de simplesmente conectar um LLM a uma aplicação e entrando na fase de engenharia de sistemas com IA.

1. MCP contra CLI talvez seja a pergunta errada

O Model Context Protocol, ou MCP, cresceu rapidamente como uma forma padronizada de conectar modelos e agentes a ferramentas externas.

Banco de dados, GitHub, arquivos, APIs, serviços internos e praticamente qualquer outro recurso podem ser apresentados ao agente por uma interface comum.

Isso é extremamente útil.

Mas um estudo publicado no arXiv em 9 de agosto tentou medir algo muito específico: quanto custa executar uma mesma tarefa usando MCP em comparação com ferramentas tradicionais de linha de comando?

Os pesquisadores executaram uma tarefa fixa de software, envolvendo seis operações em um repositório Git privado, usando:

• sete estruturas diferentes de agentes;
• cinco modelos de linguagem;
• interfaces MCP e CLI;
• verificação real do estado final do repositório.

Esse último ponto é importante.

Eles não perguntaram ao agente se a tarefa havia sido concluída. Verificaram o resultado no repositório.

E o principal achado não foi simplesmente "MCP é caro" ou "CLI é melhor".

Foi algo mais interessante:

o scaffolding do agente teve mais impacto que a interface usada para acessar as ferramentas.

Em algumas comparações, estruturas diferentes executando pela CLI ficaram entre 5 e 28 vezes mais baratas que outras estruturas capazes de usar MCP.

Em um modelo local de 27 bilhões de parâmetros, o custo variou 139 vezes entre scaffoldings, mesmo com a tarefa sendo concluída em todos os casos.

Quando os autores compararam MCP diretamente com CLI, os resultados também ficaram muito dispersos. As razões de custo variaram de 0,43x até 29x.

Ou seja: não existe um número simples que permita dizer "MCP custa X vezes mais".

O que é scaffolding nesse contexto?

É toda a estrutura operacional que envolve o modelo:

modelo
  ↓
prompt do sistema
  ↓
planejamento
  ↓
seleção de ferramentas
  ↓
contexto enviado
  ↓
loops de execução
  ↓
tratamento de erro
  ↓
verificação
  ↓
resposta final

Dois agentes usando o mesmo modelo podem se comportar de formas completamente diferentes dependendo dessa estrutura.

Um pode chamar uma ferramenta duas vezes.

Outro pode chamar quinze.

Um pode enviar milhares de tokens desnecessários em cada etapa.

Outro pode manter contexto mínimo.

Um pode perceber rapidamente que terminou.

Outro pode continuar raciocinando e chamando ferramentas depois que o objetivo já foi atingido.

É aí que o custo explode.

2. O problema não é MCP — é engenharia ruim ao redor da IA

Seria fácil transformar esse estudo em uma crítica ao MCP.

Não acho que seja a conclusão correta.

Os próprios autores mostram que a comparação entre MCP e CLI é instável. Em alguns pares o MCP foi mais barato; em outros, muito mais caro.

Além disso, os agentes nem sempre respeitaram a interface que deveriam usar, o que torna qualquer conclusão absoluta ainda mais perigosa.

O estudo também analisa apenas uma tarefa de software. Portanto, não é possível generalizar os números para todo tipo de agente.

Mesmo com essas limitações, o sinal é importante.

Quando alguém diz:

"meu agente usa GPT-X"

isso nos diz muito menos sobre eficiência do que parece.

Eu gostaria de saber também:

quantas chamadas ele faz?

quanto contexto envia por chamada?

como detecta que terminou?

como verifica o resultado?

como recupera de erros?

qual ferramenta escolhe primeiro?

quanto custa uma tarefa concluída?

quantas execuções terminam sem produzir resultado útil?

Essa é a diferença entre experimentar IA e operar IA.

3. Um modelo menor pode vencer quando o sistema sabe dizer "não"

O segundo estudo, publicado em 10 de agosto, aborda outro problema que considero ainda mais importante para sistemas empresariais.

O trabalho analisa agentes que respondem perguntas de negócio consultando bancos de dados.

Imagine perguntas como:

• qual foi nossa receita no último trimestre?
• quantos clientes ativos temos?
• qual foi o churn de julho?
• quais produtos cresceram mais?

Um LLM pode transformar essas perguntas em SQL com relativa facilidade.

O problema é que SQL válido não significa resposta correta.

Uma consulta pode executar perfeitamente e devolver um número totalmente plausível, mas errado.

Por exemplo, a palavra "receita" pode significar receita bruta ou receita líquida.

"Clientes ativos" pode significar clientes com contrato vigente ou clientes que fizeram alguma compra nos últimos 30 dias.

Se o agente simplesmente escolher uma definição, gerar SQL e devolver o número, tecnicamente tudo funcionou.

Do ponto de vista do negócio, falhou.

4. O modelo propõe; as regras decidem

O sistema apresentado no estudo, chamado QueryProof, usa um modelo de 7 bilhões de parâmetros, mas coloca várias camadas determinísticas ao redor dele.

A arquitetura segue uma ideia que eu gosto bastante:

O modelo propõe; as regras decidem.

O sistema possui uma camada semântica com definições de métricas e informações sobre o banco.

Antes de responder, ele pode decidir que uma pergunta precisa de esclarecimento.

Por exemplo:

Usuário:
"Qual foi nossa receita em julho?"

Sistema:
"Você quer receita bruta ou receita líquida?"

Essa resposta pode parecer menos impressionante que gerar uma consulta instantaneamente.

Mas em produção ela é muito mais segura.

O agente também consegue reconhecer perguntas que não podem ser respondidas pelos dados disponíveis ou que deveriam ser recusadas.

Depois de gerar SQL, há validações antes e depois da execução.

Antes:

SQL proposto
   ↓
tabelas permitidas?
   ↓
colunas existem?
   ↓
colunas foram descontinuadas?
   ↓
junções permitidas?
   ↓
a operação é somente leitura?

Depois:

resultado
   ↓
filtros obrigatórios foram aplicados?
   ↓
período correto?
   ↓
resultado vazio?
   ↓
valores impossíveis?

Só então a resposta chega ao usuário.

5. O resultado é provocador — mas precisa ser interpretado corretamente

No teste reportado pelos autores, o sistema com modelo de 7B superou um baseline diretamente promptado com modelo de 32B na métrica de "Business Truth" e teve custo por resposta correta 71% menor.

Isso é interessante, mas existe um detalhe fundamental.

Não estamos comparando simplesmente:

7B vs 32B

Estamos comparando:

7B
+ camada semântica
+ regras
+ validação
+ reparo
+ verificação

vs

32B
+ prompt direto

Os próprios autores deixam essa limitação explícita.

O benchmark também usa warehouses sintéticos e o artigo relata problemas de contaminação em parte do conjunto de teste, além de outras limitações metodológicas.

Portanto, eu não usaria esse trabalho para afirmar que "modelos pequenos são melhores".

A conclusão que considero defensável é outra:

um sistema bem projetado pode extrair muito mais confiabilidade de um modelo menor do que um sistema ingênuo extrai de um modelo maior.

Isso muda bastante a forma como deveríamos pensar produtos com IA.

6. A pergunta muda de "qual modelo usar?" para "qual tarefa entregar ao modelo?"

Quando construímos software tradicional, não delegamos todas as decisões a uma única função mágica.

Criamos validações, contratos, banco de dados, tipos, permissões, testes e regras de negócio.

Com IA deveria ser igual.

Só que durante a primeira onda dos LLMs muita gente fez algo parecido com isto:

entrada do usuário
      ↓
     LLM
      ↓
resposta final

É simples, rápido e ótimo para protótipos.

Mas sistemas reais tendem a evoluir para algo mais próximo de:

entrada
   ↓
classificação
   ↓
contexto autorizado
   ↓
modelo
   ↓
ferramentas
   ↓
validação determinística
   ↓
testes / evidências
   ↓
regra de aprovação
   ↓
resultado

Nesse desenho, o LLM continua sendo extremamente importante.

Mas ele deixa de ser a aplicação inteira.

Ele vira um componente de raciocínio dentro de uma aplicação maior.

7. Isso tem impacto direto na economia de um SaaS com IA

Existe uma consequência de negócio importante aqui.

Se um SaaS simplesmente encaminha tudo para o melhor modelo disponível, seu custo tende a crescer junto com o uso.

Uma arquitetura mais inteligente pode tratar tarefas de formas diferentes.

Por exemplo:

Tarefa simples e determinística
→ código tradicional

Classificação de baixa complexidade
→ modelo pequeno/econômico

Resumo ou extração estruturada
→ modelo intermediário

Decisão complexa
→ modelo mais forte

Operação crítica
→ modelo forte + regras + validação + aprovação

Essa separação pode melhorar três coisas ao mesmo tempo:

1. custo;
2. velocidade;
3. confiabilidade.

É por isso que acredito que uma das competências mais valiosas nos próximos anos será saber rotear inteligência.

Não escolher um único modelo.

Escolher a combinação certa de:

• modelos;
• código;
• ferramentas;
• regras;
• memória;
• contexto;
• validação;
• observabilidade.

8. WordPress 7.1 mostra essa mudança chegando às plataformas

Essa discussão não está limitada a laboratórios de IA.

Ela já aparece na arquitetura de plataformas tradicionais.

O WordPress 7.1 tem lançamento final programado para 19 de agosto de 2026, e o Release Candidate 2 está previsto para 12 de agosto.

Entre as mudanças voltadas a desenvolvedores está a evolução da Abilities API.

A ideia da API é oferecer uma forma estruturada e consultável de informar o que um site WordPress consegue fazer.

Em vez de uma IA precisar adivinhar capacidades ou depender de integrações improvisadas, plugins e o próprio Core podem expor habilidades de maneira definida.

Algo conceitualmente parecido com:

site WordPress
   ↓
Abilities API
   ├── consultar informações do site
   ├── acessar capacidades permitidas
   ├── executar ações autorizadas
   └── fornecer contexto para ferramentas de IA

O roadmap da versão também trabalha em conectores com autenticação mais estruturada e em mecanismos para manter contexto e diretrizes editoriais utilizáveis por humanos e ferramentas de IA.

Isso é significativo.

O WordPress está começando a preparar uma camada onde agentes não precisam apenas "mexer no site".

Eles podem descobrir o que o site permite fazer, sob quais regras e através de interfaces definidas.

Esse é exatamente o tipo de arquitetura que torna agentes mais previsíveis.

9. Plugins e sistemas deveriam começar a expor capacidades, não apenas endpoints

APIs tradicionais normalmente são pensadas assim:

POST /clientes
GET /pedidos
PUT /usuario/123

Para agentes, uma camada adicional pode ser útil:

capability: criar_cliente

entrada:
- nome
- email
- telefone

permissão:
- crm.create_customer

pré-condições:
- email válido
- cliente inexistente

resultado esperado:
- customer_id

risco:
- baixo

Isso deixa a integração muito mais semântica.

O agente não precisa compreender apenas como chamar a API.

Ele também entende:

• o que a ação significa;
• quais dados precisa fornecer;
• quem pode executá-la;
• quais condições precisam ser satisfeitas;
• qual resultado deve receber.

Para mim, esse é um dos caminhos mais interessantes para frameworks e plataformas que querem trabalhar seriamente com agentes.

10. O próximo diferencial pode ser o "sistema operacional" da IA

Hoje as empresas disputam atenção falando sobre modelos.

Mas modelos tendem a ficar cada vez mais competitivos entre si.

A vantagem durável pode aparecer em outra camada:

MODELOS
commodity crescente
        ↓
ORQUESTRAÇÃO
quem faz o quê
        ↓
CONTEXTO
qual informação cada tarefa recebe
        ↓
FERRAMENTAS
como o agente interage com sistemas reais
        ↓
REGRAS
limites e decisões determinísticas
        ↓
VALIDAÇÃO
como sabemos que funcionou
        ↓
OBSERVABILIDADE
quanto custou e onde falhou
        ↓
PRODUTO
valor entregue ao usuário

É quase um sistema operacional para inteligência.

E essa camada pode ser mais difícil de copiar do que simplesmente trocar o nome do modelo usado no backend.

11. O que eu aplicaria hoje em um projeto real

Se eu estivesse iniciando hoje um produto com agentes, começaria com algumas decisões simples.

Não colocar regra de negócio crítica apenas no prompt

Preço, permissão, status, limite financeiro, acesso a dados e outras regras importantes devem continuar existindo em código verificável.

Medir tarefa concluída, não quantidade de tokens

Tokens são custo.

O indicador que importa é algo mais próximo de:

custo por tarefa validamente concluída

Um agente barato que falha muito pode custar mais que um modelo caro que resolve rápido.

Verificar o mundo real

Se a tarefa era alterar um repositório, valide o Git.

Se era publicar um post, consulte o WordPress.

Se era criar um pagamento, confira o gateway.

Se era atualizar um banco, leia novamente o registro.

Nunca dependa apenas de:

"Pronto, concluí a tarefa."

Usar IA apenas onde existe incerteza

Código tradicional é excelente quando as regras são claras.

LLMs são excelentes quando precisamos interpretar, raciocinar, classificar, resumir ou trabalhar com linguagem e contexto pouco estruturado.

Misturar os dois é mais poderoso que tentar substituir tudo por IA.

Criar uma camada própria entre produto e modelo

Isso permite trocar fornecedores, usar modelos locais, controlar custo, implementar fallback e escolher modelos diferentes por tarefa.

Quanto mais a inteligência vira infraestrutura, menos sentido faz acoplar a aplicação inteira a um único fornecedor.

12. Minha conclusão: o futuro pertence a quem souber construir o sistema ao redor do modelo

A corrida pelos modelos continuará.

Teremos modelos maiores, menores, locais, especializados, multimodais e cada vez mais capazes de usar ferramentas.

Mas a maturidade da engenharia de IA começa quando paramos de perguntar apenas:

"Qual modelo é mais inteligente?"

E passamos a perguntar:

"Qual arquitetura transforma inteligência em resultado confiável?"

Os estudos desta semana não encerram essa discussão. Ambos têm limitações e não deveriam ser usados como provas universais.

Mas juntos eles reforçam um sinal que vejo ficando cada vez mais claro:

modelo é componente. Produto é sistema.

E um bom sistema precisa saber orientar, limitar, validar e medir o que seus modelos fazem.

Para desenvolvedores e empreendedores, isso é uma ótima notícia.

Porque significa que a vantagem não pertence apenas a quem possui bilhões para treinar um modelo de fronteira.

Existe uma camada enorme de inovação disponível para quem sabe construir arquitetura, ferramentas, workflows, regras, contexto e produtos melhores ao redor desses modelos.

É nessa camada que acredito que boa parte das melhores oportunidades de software com IA vai aparecer.