Projeto do ambiente de execução de agentes: escolha do modelo certo

O roteamento de modelos é um problema de controle operacional, não uma competição de rankings. Os requisitos de privacidade e residência dos dados definem primeiro o conjunto de modelos admissíveis; o sucesso da tarefa e a qualidade da saída determinam o que funciona nesse conjunto; só então as equipes devem otimizar tokens, latência e custo. Modelos locais podem ser eficazes, mas geralmente precisam de uma decomposição mais rigorosa, recuperação de informações e verificação determinística.

O ambiente de execução é a unidade produtiva

Um agente empresarial não é um modelo com um longo prompt de sistema. É um ambiente de execução de agentes (agent harness): recebimento da solicitação, montagem do contexto, critérios de passagem definidos por políticas, execução do modelo, acesso a ferramentas, estado, verificação, lógica de novas tentativas, observabilidade e encaminhamento ao responsável. O modelo é um componente substituível dentro desse sistema.

Comparações feitas fora desse ambiente frequentemente não preveem os resultados em produção. Um modelo pode ir bem em um benchmark e ter dificuldades com os formatos, permissões, vocabulário ou fluxos de trabalho da organização. Outro pode parecer mais fraco em conversas abertas, mas funcionar de modo confiável quando a tarefa é decomposta, as evidências são recuperadas e as saídas são verificadas com restrições determinísticas.

Portanto, escolher “o melhor modelo” é a abstração errada. Escolhemos um caminho de execução admissível para uma tarefa definida. Ele pode usar um modelo, várias chamadas especializadas, um modelo local, um modelo hospedado ou nenhum modelo. Só há sucesso quando a tarefa alcança um estado de negócio verificado.

A arquitetura deve explicitar essa possibilidade de substituição. Uma camada de operações de IA baseada em threads separa o contexto do usuário do executor, mantendo estáveis o roteamento, o estado, a autorização e a verificação quando o modelo muda.

Primeiro critério: privacidade, residência e admissibilidade contratual

O roteamento começa antes dos testes de qualidade. A primeira pergunta é se um endpoint de modelo está autorizado a receber os dados e executar a ação.

Criamos um perfil de admissibilidade para cada classe de tarefa. Ele cobre:

classificação dos dados e presença de informações pessoais, confidenciais, reguladas ou sujeitas a controle de exportação;
regiões exigidas para processamento e armazenamento;
termos de retenção, registro de logs, uso para treinamento e exclusão;
subprocessadores e restrições a transferências internacionais;
requisitos de criptografia, identidade e controle de acesso;
obrigações de registro de auditoria e notificação de incidentes;
possibilidade de as ferramentas lerem ou alterarem sistemas de produção;
possibilidade de documentos recuperados saírem de um ambiente controlado.

São restrições de roteamento, não um parágrafo de política acrescentado após o lançamento. Se uma tarefa contém dados restritos, o roteador deve excluir os endpoints que não atendem ao perfil. A remoção de informações sensíveis pode gerar uma tarefa derivada menos restrita, mas precisa ser confiável, registrada e testada para os formatos envolvidos. Substituir um nome e manter um número de conta único ou uma combinação comercialmente sensível de fatos não é anonimização efetiva.

A residência dos dados também se aplica ao ambiente de execução: usar um endpoint regional aprovado não resolve o problema se rastros de execução, índices vetoriais, logs de erros ou filas de revisão humana ficam em outro lugar. Inspecionamos todo o percurso dos dados: recebimento, arquivos temporários, recuperação, inferência, resultados das ferramentas, observabilidade, backups e acesso de suporte.

Esse critério produz rotas permitidas, não escolhe uma vencedora. Um modelo local pode ser obrigatório para uma tarefa, opcional para outra e inadequado para uma terceira. A política restringe a escolha; as evidências a completam.

Segundo critério: sucesso da tarefa, depois qualidade

Dentro do conjunto admissível, a primeira pergunta de avaliação é o sucesso da tarefa: o fluxo de trabalho alcançou o estado pretendido? Em uma pesquisa, isso pode significar uma resposta fundamentada com citações cujas fontes podem ser acessadas. Na extração, um registro válido segundo o esquema, vinculado a trechos da fonte. Em uma ação operacional, um plano válido de simulação sem execução, uma alteração aprovada e uma verificação bem-sucedida dos resultados.

O sucesso da tarefa é mais amplo que a qualidade da resposta. Uma resposta eloquente que não pode ser interpretada pelo sistema, cita evidências indisponíveis ou chama uma ferramenta proibida é uma execução malsucedida. Uma saída breve pode ter sucesso se conclui o processo de modo confiável.

Definimos um conjunto de avaliação com base em trabalho representativo. Cada caso contém a entrada, as evidências permitidas, a transição de estado esperada, as condições obrigatórias de falha e os critérios de pontuação. O conjunto deve cobrir:

casos comuns que predominam no volume;
casos próximos dos limites de política ou qualidade;
entradas ausentes, desatualizadas, duplicadas ou contraditórias;
falhas de ferramentas e dependências;
tentativas de injeção de prompt ou de uso de conteúdo não confiável;
casos que exigem abstenção ou encaminhamento ao responsável;
variações linguísticas ou de formato, quando relevantes.

Avaliamos restrições obrigatórias antes de preferências subjetivas. Validade do esquema, seleção correta de ferramentas, conformidade com autorizações, sustentação das citações e abstenção exigida são critérios de aprovação ou reprovação. Completude semântica, clareza e utilidade podem ser avaliadas com uma rubrica. Prosa mais refinada não compensa uma taxa menor de conclusão verificada.

As skills de agentes específicas de domínio estabilizam essa avaliação ao representar procedimentos e verificações como artefatos explícitos, em vez de redescobri-los em cada conversa.

Terceiro critério: tokens, latência e custo

Só otimizamos a eficiência depois que as rotas atendem aos limites de sucesso e qualidade. A unidade relevante é o custo por tarefa verificada, não o preço por token de entrada.

Um modelo mais barato pode custar mais se exige novas tentativas, revisão ou correções posteriores. Uma primeira resposta rápida pode resultar em latência total ruim se o ambiente de execução precisa corrigir repetidamente saídas inválidas. Uma janela de contexto maior pode incentivar o carregamento indiscriminado de informações, aumentando o custo e a superfície de erro.

Medimos as seguintes dimensões:

Dimensão	Medida do ambiente de execução
Sucesso	conclusões verificadas por tentativa admissível
Qualidade	aceitação na primeira tentativa, gravidade dos defeitos e taxa de defeitos não detectados
Tokens	tokens de entrada, de entrada em cache, de saída e de novas tentativas por conclusão verificada
Latência	tempo mediano e nos extremos da distribuição, do acionamento ao estado verificado
Custo	inferência, recuperação de informações, ferramentas, revisão e retrabalho por conclusão verificada
Estabilidade	variação de desempenho ao longo do tempo, entre formatos e classes de demanda

Índices normalizados tornam as comparações internas legíveis sem sugerir precisão falsa. Definimos a rota atualmente aprovada como Baseline = 100 para o custo ajustado pela qualidade e a latência de ponta a ponta. Uma candidata só é útil se seu índice menor de custo não esconde uma taxa pior de sucesso, mais exceções ou mais tempo de revisão. Mantemos as contagens e definições subjacentes para auditoria, mesmo quando relatórios externos usam valores normalizados.

A otimização então se torna direcionada: cache de prompts pode reduzir a repetição do contexto de políticas; trechos recuperados menores podem reduzir distrações; leituras paralelas por ferramentas podem melhorar a latência; um modelo menor pode classificar enquanto uma rota mais capaz trata sínteses ambíguas; e código determinístico pode eliminar inteiramente uma chamada de inferência.

Encaminhar tarefas, não usuários

O roteamento estático por departamento desperdiça capacidade e dinheiro. Uma pessoa pode pedir um resumo público, uma comparação confidencial, uma conciliação e uma alteração em produção — classes de tarefas com requisitos diferentes de admissibilidade, qualidade e autoridade.

Roteamos com base em um conjunto de campos que descreve a tarefa:

task_type: extract | classify | synthesize | plan | act | verify
data_class: public | internal | confidential | restricted
residency: approved_regions
authority: read | recommend | dry_run | approved_write
evidence: source_ids and freshness requirements
output_contract: schema or rubric version
risk: consequence and reversibility
latency_budget: interactive | asynchronous | batch

O roteador deve ser tão determinístico quanto possível. Classe de dados, residência e autoridade são decisões de política; não devem depender de um modelo adivinhar se uma solicitação “parece sensível”. Um classificador pode ajudar no recebimento, mas a incerteza deve levar à rota mais segura ou a um pedido específico de esclarecimento.

A escolha do modelo ocorre dentro do caminho permitido. Registramos a rota com a versão da política, a versão do modelo, a versão do prompt ou da skill, os identificadores das evidências recuperadas, as chamadas de ferramentas, os resultados dos verificadores e o estado final. Esse registro permite diagnosticar falhas e reproduzir comparações.

Por que os modelos locais precisam de outro ambiente de execução

A inferência local é frequentemente discutida como se bastasse mover o mesmo prompt de um endpoint hospedado para hardware local. Raramente basta. Modelos locais podem oferecer forte controle de privacidade, custo marginal previsível, operação offline e baixa latência em tarefas delimitadas. Também podem ter menor aderência a instruções, seleção de ferramentas, confiabilidade em contextos longos ou consistência multilíngue que as alternativas hospedadas mais capazes disponíveis em determinado momento.

A resposta correta é explicitar essas diferenças e mudar o ambiente de execução.

Decompor de forma mais rigorosa

Dê ao modelo uma transformação delimitada por vez. Separe seleção de documentos, extração, classificação, redação e verificação. Cada etapa deve ter um contrato restrito de entrada e saída. A decomposição reduz o número de instruções simultâneas e cria pontos de verificação em que controles determinísticos podem interromper a propagação de erros.

Uma rota local pode primeiro identificar seções relevantes, depois extrair alegações para um esquema, vincular cada alegação a um trecho da fonte e redigir somente a partir das alegações aceitas. Isso exige mais orquestração que um único prompt grande, mas é mais fácil de avaliar e corrigir.

Recuperar menos e melhor

Despejar um repositório inteiro ou uma coleção de documentos no contexto não é recuperação de informações: transfere ao modelo o problema da seleção. Rotas locais se beneficiam de índices estruturados, filtros de metadados, restrições de atualidade e conjuntos curtos de evidências. A recuperação deve retornar identificadores e trechos das fontes para que verificações posteriores confirmem a fundamentação da resposta.

Os padrões práticos de construção de um assistente de IA local com recuperação de informações e busca na web ilustram por que a inferência local depende de uma camada de ferramentas e evidências, e não apenas da memória do modelo.

Verificar deterministicamente

Use esquemas, analisadores sintáticos, listas de permissões, restrições de banco de dados, cálculos, mecanismos de políticas e verificações dos resultados sempre que possível. Um modelo pode propor uma alteração; o código deve confirmar que os campos exigidos existem, os identificadores são válidos, os totais conciliam, as permissões autorizam a ação e o estado posterior corresponde ao plano aprovado.

Para verificações semânticas que não podem ser determinísticas, use critérios de avaliação e um caminho de revisão independente. Não peça à mesma chamada que gere, avalie e aprove sua própria saída. Se houver um avaliador baseado em modelo, calibre-o com julgamentos humanos e mantenha-o fora do limite de autoridade final.

Cascatas, rotas alternativas e abstenção

Um roteador útil não envia toda tarefa elegível ao modelo mais capaz. Pode usar uma cascata: começar pela rota de menor custo que já atende ao limite de aceitação da classe de tarefa e encaminhar a uma rota mais capaz diante de uma falha observável.

Os sinais devem ser concretos: esquema inválido após correção, evidência ausente, fontes conflitantes, baixa confiança calibrada, ferramenta indisponível, limite de política ou falha do verificador. O número de tokens, por si só, não indica qualidade. Tampouco a declaração verbal de incerteza do modelo, a menos que tenha sido calibrada para a tarefa.

Rotas alternativas precisam de consistência semântica. Se a principal falha por não atender à residência dos dados, a alternativa não pode ignorá-la. Se uma chamada de ferramenta está indisponível, uma rota apenas de conversa não deve fingir que a ação ocorreu. Se as evidências estão desatualizadas, um modelo mais capaz não as torna atuais.

A abstenção é um resultado bem-sucedido quando o contrato exige encaminhamento ao responsável. Incluímos recusas ou encaminhamentos corretos nas métricas de sucesso; caso contrário, a pressão do roteamento recompensa trabalho além das evidências ou da autoridade disponível.

Estado, versões e reprodutibilidade

Modelos e endpoints mudam. Mesmo com o mesmo nome, o comportamento pode mudar com uma nova versão, configuração de serviço, prompt de sistema, índice de recuperação, definição de ferramenta ou política. O ambiente deve versionar todo o contrato de execução.

Registramos, no mínimo:

versões da tarefa e da política;
fornecedor do modelo, região do endpoint e versão do modelo;
versões do prompt, da skill e do esquema das ferramentas;
consulta de recuperação, IDs das fontes e horários de referência da atualidade dos dados;
configurações de amostragem e tempo limite;
versões e resultados dos verificadores;
eventos de novas tentativas, rotas alternativas e revisão humana;
ação final com evidências de verificação dos resultados.

A reprodutibilidade operacional vem de entradas, configuração, ações externas e evidências de verificação, não de acesso irrestrito à cadeia de raciocínio. Rastros sensíveis seguem as regras empresariais de minimização e retenção.

A disciplina de procedimentos descrita no ajuste de um agente específico de projeto é relevante: espaços de trabalho persistentes e procedimentos reutilizáveis só são úteis quando mudanças, concorrência e modos de falha são observáveis.

Um processo prático de seleção

Usamos um processo de seleção em etapas:

Definir classes de tarefas. Separar extração, síntese, planejamento, ação e verificação; não calcular uma única média para todas.
Aplicar critérios de admissibilidade. Eliminar rotas que descumprem requisitos de privacidade, residência, contrato ou autoridade.
Construir o conjunto de avaliação. Usar casos representativos, próximos dos limites, adversariais e de encaminhamento obrigatório, com evidências fixadas.
Executar as rotas no ambiente real. Incluir recuperação de informações, ferramentas, tempos limite, novas tentativas e verificadores.
Verificar falhas em requisitos obrigatórios. Rejeitar rotas que violam requisitos de esquema, evidência, autorização ou abstenção.
Avaliar sucesso e qualidade. Revisar o desempenho médio e os casos extremos de defeitos graves.
Medir a eficiência total. Comparar tokens, latência, custo de inferência, tempo de revisão, novas tentativas e retrabalho por conclusão verificada.
Executar um piloto em avaliação paralela ou simulação sem execução. Observar a variação da demanda real sem permitir alterações não verificadas.
Aprovar por classe de tarefa. Registrar rota, limites, alternativa e data de validade da decisão.
Reavaliar continuamente. Iniciar revisão diante de mudanças de modelo, desvios, novas classes de dados, exceções recorrentes ou mudanças relevantes de preço.

O resultado é uma política de roteamento versionada, não um ranking permanente.

A regra de decisão

A ordem das decisões é central ao roteamento responsável de modelos. Privacidade, residência e critérios contratuais determinam o que é permitido. Sucesso verificado e qualidade determinam o que é capaz. Tokens, latência e custo total determinam o que é eficiente entre as rotas restantes.

Inverter essa ordem causa falhas previsíveis. Priorizar custo envia trabalho sensível a endpoints inadmissíveis ou saídas de baixa qualidade a ciclos caros de revisão. Priorizar o modelo adapta processos a um fornecedor preferido. Priorizar benchmarks otimiza tarefas que a empresa talvez nem execute.

Projetamos o ambiente para que modelos possam mudar sem comprometer política, estado ou evidências. Modelos hospedados, modelos locais e serviços determinísticos têm seus papéis. A escolha certa é o menor sistema admissível que conclui a tarefa definida, respeita o limite de qualidade e comprova o resultado.