Uma Geração, Cem Chamadas de Ferramenta: Code Mode Leva a Governança para a Ponte

O AI SDK da Vercel agora traz Code Mode: o modelo escreve JavaScript, o SDK executa esse código em um sandbox QuickJS, e o código chama suas ferramentas através de uma bridge. O teto padrão é de 100 requisições de bridge por geração, com 10 permitidas em voo ao mesmo tempo. Uma geração, até cem chamadas de ferramenta, e o humano vê o código uma vez, se vê. O recurso é explicitamente experimental, exige Node.js 22 ou superior e não roda em navegador nem em runtimes de edge. As implicações de governança são tudo, menos experimentais.

Se a sua história de controle de agentes é “um humano aprova cada chamada de ferramenta”, Code Mode é onde essa história termina. A aprovação por chamada assumia que o modelo emitia uma chamada estruturada por vez e que algo podia sentar no meio. Code Mode colapsa o loop: iteração, ramificação, concorrência e transformação de dados acontecem dentro de um único programa gerado. A unidade de revisão deixa de ser a chamada. Passa a ser o programa, a bridge pela qual esse programa fala e os tetos que o runtime impõe.

Fizemos o argumento econômico desse padrão quando a Cloudflare mostrou que a proliferação de ferramentas taxa cada token. Esse argumento está resolvido e não vamos repetir. O que há de novo em agosto de 2026 é que o padrão virou capacidade de primeira classe em um SDK, com um modelo de permissão revisável. Existe agora uma superfície de controle específica e enumerável para governar. Este ensaio a enumera.

O que o sandbox realmente é

Cada invocação recebe um contexto QuickJS novo. Sem globals do Node, sem acesso a sistema de arquivos, sem fetch de rede, sem eval, sem Function dinâmica. O código que o modelo escreve pode computar e pode chamar a bridge. Nada além disso.

Parece o controle. A documentação diz outra coisa, textualmente: “Treat the sandbox as defense in depth. Generated code and tool arguments are untrusted.” Trate essa posição como uma declaração de arquitetura do próprio fornecedor. O sandbox limita o que uma geração descontrolada ou hostil pode fazer contra o host. Ele nada diz sobre o que uma geração bem formada pode fazer através da bridge, e a bridge é onde os seus sistemas vivem.

É o mesmo empilhamento que percorremos nos cinco níveis de contenção de bash: a jaula de execução é uma superfície, e as capacidades que você entrega para dentro da jaula são outra. Um sandbox perfeito envolvendo uma bridge superprovisionada é um cofre de banco com um guichê que honra qualquer ordem de saque.

As três superfícies que você passa a governar

Superfície 1: o que a bridge expõe. A exposição de ferramentas é governada por experimental_toolCallers. Cada ferramenta pode ser marcada para invocação direta pelo modelo, para invocação a partir do código gerado, ou para ambas via DIRECT_TOOL_CALL. É a sua allowlist, realocada. A pergunta muda de “o modelo deveria ver esta ferramenta” para “o código gerado deveria poder iterar sobre esta ferramenta cem vezes sem um humano entre as iterações”. São perguntas diferentes. Uma ferramenta send_email tolerável sob aprovação por chamada vira um disparador em massa dentro de um for. Uma ferramenta de consulta somente leitura provavelmente serve nos dois caminhos. A auditoria é por ferramenta, por caminho, e é uma auditoria que ninguém podia ter feito antes, porque o segundo caminho não existia.

Superfície 2: os tetos. O runtime impõe limites de recursos: maxBridgeRequests (padrão 100), maxInFlightBridgeRequests (padrão 10), além de limites de timeout, memória, payload e saída de console. Esses padrões são o palpite do fornecedor sobre uma carga razoável. Eles não são a sua postura de risco. Cem chamadas via bridge contra uma API interna de analytics são uma tarde comum. Cem chamadas via bridge contra uma API de pagamentos são um incidente. Os tetos são configuração, ou seja, são código, ou seja, podem ser revisados, versionados e definidos por deployment. Trate o padrão como um ponto de partida que você aceita conscientemente ou reduz, conjunto de ferramentas por conjunto de ferramentas.

Superfície 3: autorização dentro das ferramentas. Como o código gerado e seus argumentos são não confiáveis, cada ferramenta precisa impor a própria autorização como se o chamador fosse hostil. Valide argumentos na ferramenta. Verifique a identidade atuante na ferramenta. Aplique rate limit e log de auditoria na ferramenta. Qualquer verificação que viva apenas no prompt, ou apenas no bom comportamento do modelo, não existe neste caminho. A bridge vai entregar o que o programa enviar, até o teto, e a ferramenta é a última parte que pode dizer não.

Repare no que está ausente das três superfícies: um humano. Esse é o design, e fingir o contrário desperdiça o padrão. A postura honesta é aceitar que a aprovação migrou do tempo de execução para o tempo de configuração, e então investir o esforço de revisão onde ele agora rende: nas declarações de tool callers, nos valores dos tetos e no código de autorização do lado da ferramenta. Os três são artefatos diffáveis em um pull request. A aprovação por chamada nunca foi.

O que a governança por chamada perde, e o que a substitui

A aprovação por chamada entregava duas coisas: um checkpoint antes de cada efeito colateral e uma trilha de auditoria que mapeava uma decisão para uma ação. Code Mode leva o checkpoint. Ele não precisa levar a trilha. Requisições de bridge continuam sendo eventos discretos e observáveis; o runtime que impõe maxBridgeRequests as está contando, o que significa que podem ser registradas junto com a geração que as produziu. A unidade revisável passa a ser o programa gerado mais a transcrição da bridge. Esse é um artefato forense melhor do que cem cliques de aprovação isolados, porque preserva a intenção: dá para ler o loop que produziu as chamadas, e cada chamada individual junto.

A perda é real no limite, porém. Sob aprovação por chamada, uma geração ruim custa uma chamada ruim. Sob Code Mode, uma geração ruim custa até maxBridgeRequests chamadas ruins antes de qualquer intervenção. Esse teto é o seu raio de dano, declarado como um inteiro, dentro de um arquivo de configuração. Se o seu time não tem resposta escrita para “qual é o maior número de invocações de ferramenta que aceitamos de uma única saída de modelo não revisada”, Code Mode agora exige uma.

Uma ressalva pertence a qualquer plano construído sobre isso: o recurso é experimental. A superfície de API carrega o prefixo experimental_, e os tetos, os padrões e a semântica dos callers podem mudar entre releases. Governe o padrão agora, mas fixe versões e re-audite a cada upgrade.

Faça isto agora

Escolha um agente que você roda, ou planeja rodar, sobre o AI SDK. Antes de habilitar Code Mode para ele, escreva três listas. Primeira: cada ferramenta, anotada com os caminhos de invocação que deveria permitir, direto, via código, ambos ou nenhum. Segunda: os valores de teto que você consegue defender diante da sua própria revisão de segurança, tratando o padrão de 100 como proposta, e ainda longe de decisão. Terceira: para cada ferramenta chamável por código, as verificações de autorização que vivem dentro da própria ferramenta, assumindo argumentos hostis. Se alguma lista for difícil de escrever, essa dificuldade é o achado da auditoria. A bridge está prestes a se tornar a interface mais movimentada da sua arquitetura de agentes. Governe a bridge como tal.

Fontes

Vercel (documentação do AI SDK v7). “Code Mode (AI SDK Core).” Agosto de 2026.

A Victorino ajuda times de engenharia a desenhar a superfície de controle de agentes que executam código: exposição da bridge, tetos de recursos e autorização dentro das ferramentas: contato@victorino.com.br | www.victorino.com.br