Prompts são importantes, mas não são um modelo operacional. Quando um workflow usa múltiplos modelos, ferramentas, validadores e decisões humanas, confiabilidade se torna um problema de arquitetura de software. O sistema precisa de contratos explícitos em cada fronteira.
O problema: políticas invisíveis
Um agente simplista costuma esconder escolhas críticas nos padrões do framework: qual modelo recebe a solicitação, quantas vezes uma chamada com falha é repetida, se fallback é permitido e o que acontece quando uma ferramenta produz um resultado inválido. Isso pode servir em um protótipo. Em produção, torna custo, latência e risco imprevisíveis.
A unidade confiável não é a chamada ao modelo. É o caminho de execução completo e observável.
Política de execução como contrato de primeira classe
No Work Harness que estou construindo, cada etapa declara tentativas, orçamento de tempo, categorias de falha retentáveis, rotas alternativas e classificação de efeitos colaterais. Efeitos inseguros não podem ser repetidos. Operações retentáveis precisam de limite por tentativa e prazo total.
class PoliticaDeExecucao:
max_tentativas: int = 1
timeout_tentativa: float | None
prazo_total: float | None
falhas_retentaveis: tuple
efeito: "nenhum | idempotente | inseguro"
def validar(self):
if self.max_tentativas > 1:
exigir(self.timeout_tentativa)
exigir(self.prazo_total)
rejeitar(self.efeito == "inseguro")Isso transforma comportamento implícito em algo revisável e testável. Erros de autenticação ou configuração falham rapidamente; falhas transitórias de rede e rate limit podem repetir; correção de saída segue um caminho separado.
Registrar fatos, não raciocínio privado
Cada execução emite eventos versionados para roteamento, etapas, tentativas de modelo, ferramentas, retentativas, validação, artefatos e decisões humanas. Eles registram fatos observáveis—rota, duração, resultado, uso, categoria de erro anonimizada e referências a artefatos—não cadeia de pensamento privada.
Separar a capacidade pública dos especialistas internos
O usuário deve escolher uma capacidade—como arquitetura de software ou análise de opções—e não um modelo específico. Internamente, um grafo pode rotear entre especialistas, provedores e níveis de raciocínio conforme risco e complexidade. O contrato externo permanece estável enquanto a implementação evolui.
O que isso permite
Com execução explícita, a plataforma responde perguntas que logs de prompts não respondem: quais caminhos funcionam sem intervenção humana? Qual fallback aumenta custo sem melhorar qualidade? Qual validador detecta regressões? Onde um componente determinístico pode substituir um modelo?
Essa é a transição de experimentar com IA para engenheirar um sistema de IA: não eliminar a incerteza, mas torná-la limitada, observável e governável.