Radar Tech: agentes de IA viraram um novo tipo de workload — e a API do provedor virou dependência crítica de runtime

O que a semana mostrou

Uma sequência de sinais, todos apontando para o mesmo lugar.

O status.claude.com registrou "Elevated errors for multiple models" em 22/09/2026. A investigação abriu às 00:57 UTC, a causa foi identificada às 01:17, houve recuperação parcial às 01:35 e resolução por volta das 02:35. Janela total: cerca de 80 minutos. A superfície afetada declarada pelo próprio provedor inclui claude.ai, a API pública, o Claude Code e o Claude Cowork.

O detalhe que mais importa não é a duração: é que a recuperação foi desigual entre famílias de modelo. No update intermediário, duas famílias já tinham voltado ao normal enquanto uma terceira ainda acumulava erro residual. Isso invalida a premissa silenciosa de que "quando o provedor voltou, voltou tudo".

Agentes não são microsserviços

No mesmo período apareceu o AX (Agent Substrate), apresentado como runtime declarativo para tarefas de agente: a tarefa é descrita em YAML com quatro primitivas — Task (execução isolada em sandbox com limite de CPU e memória), Workspace (repos git, servidores MCP e skills declarados antes do início), Gateway (política de rede com allowlist explícita de hosts e portas, mais injeção de credenciais) e Model (configuração e rotação de chave de modelo em um só lugar).

O argumento dos autores é direto e vale ler com atenção: orquestradores construídos para microsserviços sem estado ou batch previsível ficam custo-proibitivos quando o workload é um ator que computa intensamente por um minuto e depois passa longo tempo esperando resposta de modelo, de tool ou de humano. Manter sandbox ocioso vivo é onde o dinheiro vaza — e orquestradores genéricos não têm suspensão e retomada nativas.

A escala declarada é de bilhões de tarefas por cluster, com multiplexação densa convertendo tempo ocioso em capacidade útil. Independentemente de você adotar ou não: a categorização está certa. Se você trata agentes como jobs, você está pagando por espera.

Um ácido no MCP

Também na janela: o ensaio "MCP was always a bad idea" (321 pontos e 317 comentários no Hacker News). A tese não é que o protocolo seja mal feito, e sim que ele foi desenhado para uma era em que os modelos eram menos capazes. Agentes atuais com acesso a terminal descobrem CLIs com --help e compõem scripts, e a maioria dos servidores MCP remotos apenas embrulha APIs HTTP que já existem.

A implicação arquitetural é a que interessa: cada servidor MCP é um hop adicional de dependência no caminho crítico do agente. Se ele apenas embrulha uma API, você comprou uma dependência e chamou de abstração. A direção proposta pelos críticos é padronizar o uso direto de APIs HTTP com as convenções que já existem — negociação de conteúdo e identificação do agente por header.

O gargalo mudou de lugar

O CI não ficou de fora. Um relato de engenharia da Linear descreve exatamente o padrão: agentes de código aceleraram o envio de mudanças, mas a validação não acompanhou, e CI virou simultaneamente gargalo e vetor de custo. O time declarou que a suíte de testes quase quadruplicou durante o ano, e ainda assim conseguiu derrubar o tempo de espera de PR de pouco mais de 6 minutos para pouco mais de 5, com o tempo de runner por teste caindo aproximadamente pela metade.

O que fica de lição é mais metodológico que numérico: eles pararam de otimizar a média e passaram a otimizar o que está no caminho crítico do gate de merge. Um job pequeno de detecção de mudanças, que bloqueia oito shards de teste, importa mais que o job mais lento do pipeline. Movimento para runners com CPU mais rápida deu ganhos de ~34% em comparação like-for-like; trocas de toolchain entregaram quedas de 68%, 73% e 55% em etapas específicas.

O corolário desconfortável: se o seu gate de build depende de uma chamada a modelo externo, você terceirizou o seu pipeline de entrega.

O que isso significa na prática

Junte os três: dependência externa frágil, workload com formato próprio e gate de entrega acoplado a provedor. O desenho que sai disso:

• Classifique cada fluxo em parada dura, degradação controlada ou contingência por espera. Sem essa classificação, você não sabe o que priorizar.
• Coloque um gateway de modelo no caminho de saída de toda chamada de LLM: telemetria por modelo, validação de contrato, orçamento global de retry e um lugar único para rotacionar chave.
• Meça por família de modelo, não por provedor. Um incidente pode ser parcial, e a decisão de degradar depende de qual família ainda responde.
• Declare o critério de degradação antes do incidente. "Ligar o modo degradado depois de 30 minutos confirmados ou de três janelas consecutivas abaixo do limiar" é uma decisão de arquitetura. Descobrir isso às 3 da manhã por consenso no chat é uma decisão ruim.
• Trate compliance como anterior à disponibilidade. Se o dado não pode sair da fronteira, o failover válido é modelo local na fronteira ou degradação determinística — nunca provedor externo. Esta é a recomendação que mais aparece errada em planos de continuidade.
• Prove cada mitigação antes de precisar dela. Circuit breaker sem game day é decoração.

Nenhuma dessas peças é exótica. O que falta na maioria das organizações é escrever a decisão, com o blast radius nomeado e o modo de falha de cada mitigação declarado — inclusive o da própria mitigação.

O pacote de prompts desta semana na ArchPrompts cobre exatamente esse fluxo: um arquiteto sênior cético que produz ADR ou plano de implementação, com guardrails contra alucinação, exemplos que calibram casos de borda e um harness de verificação de 24 itens para quem for validar a saída.