Agentes de IA: como o Grok Build se conecta ao Vercel AI SDK

Em 13 de agosto de 2026, a Vercel abriu para o Grok Build um caminho oficial até o HarnessAgent do AI SDK 7. Na prática, um produto pode incorporar o Grok Build à sua camada de agentes de IA pela mesma interface de aplicação que a Vercel hoje oferece para nove coding harnesses compatíveis, sem refazer a camada de orquestração a cada integração.

O que a Vercel entregou de fato

Esse lançamento é um adaptador, não um novo modelo Grok.

A maneira mais simples de entendê-lo é separar as camadas. Um modelo produz respostas. Um coding harness transforma o modelo em um agente capaz de trabalhar ao gerenciar arquivos, ferramentas, sessões, permissões e o ciclo que mantém a tarefa em andamento. O Agent Client Protocol, ou ACP, é a linguagem comum entre um cliente e um harness compatível. Já o adaptador converte esse protocolo para a interface que a aplicação conhece.

O novo pacote da Vercel é o @ai-sdk/harness-grok-build. Ele conecta o HarnessAgent à CLI do Grok Build via ACP e usa, por baixo, o pacote @ai-sdk/harness-acp.

O fluxo fica assim:

Seu aplicativo → HarnessAgent → adaptador do Grok Build → CLI do Grok Build dentro de um sandbox

A camada genérica de ACP cuida da infraestrutura de base. O adaptador do Grok Build é o conector pronto, com pacote, executável, mapeamento de autenticação, comando de inicialização e mapeamento de ferramentas já definidos. Para entender os detalhes do protocolo, consulte a explicação sobre o adaptador de harness ACP do AI SDK. Aqui, o foco é o caminho do Grok Build que já pode ser usado.

Antes desse lançamento, integrar um runtime ACP exigia definir o perfil do runtime por conta própria. Ao estrear em 13 de agosto, o Grok Build ganhou um adaptador oficial e passou a seguir o mesmo fluxo de sessões do HarnessAgent usado por Claude Code, Codex, Deep Agents, OpenCode e Pi. Naquele momento, a lista chegava a seis harnesses.

Desde 31 de agosto de 2026, a inclusão do fx pela Vercel ampliou o suporte para nove harnesses: Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode e Pi. O adaptador do fx aumenta o catálogo, mas não muda o funcionamento do adaptador do Grok Build.

A expressão “mesma interface” é mais importante do que “mesmo agente”. O contrato da aplicação pode continuar igual. Já o comportamento das ferramentas, as permissões, a observabilidade e as respostas do modelo não serão idênticos entre os nove harnesses compatíveis.

Por que isso importa para agentes de IA

O que mudou foi o trabalho necessário para integrar cada runtime.

HarnessAgent.generate() e HarnessAgent.stream() retornam resultados compatíveis com o AI SDK. Se o produto já tem uma interface de chat ou de tarefas baseada no AI SDK, o Grok Build pode entrar no fluxo de resultados existente. O harness no servidor muda; a interface do usuário não precisa adotar outro formato de resposta só porque o agente foi trocado.

Para uma equipe de plataforma, isso cria um caminho mais organizado para comparar runtimes ou encaminhar tarefas diferentes. É possível manter o mesmo ciclo de vida das sessões e o mesmo formato de streaming, escolhendo depois o harness mais adequado a cada trabalho.

Nada disso torna o Grok Build mais rápido, barato ou preciso. O lançamento acrescenta uma integração com suporte oficial. Também não traz vantagem para quem usa o Grok Build apenas pela própria CLI. O recurso atende quem está construindo um produto ou sistema interno em torno de agentes de programação com IA.

Quem já pode aproveitar essa integração

Fundador de devtools adicionando outro runtime

Imagine um produto de revisão de código ou correção de repositórios com IA, criado sobre o AI SDK. O Grok Build pode ser incluído como mais um harness no servidor, sem exigir uma API de sessão nem um contrato de streaming exclusivos para ele.

A mudança concreta é pequena: instalar o adaptador, conectar o mesmo tipo de sandbox e selecionar o Grok Build quando o cliente ou a tarefa pedir. O ganho é ter outra opção de runtime sem precisar manter mais uma superfície no produto.

Engenheiro de plataforma comparando nove harnesses

Uma equipe de plataforma pode executar a mesma tarefa delimitada em um repositório com o Grok Build e outro harness compatível. Depois, compara a qualidade da conclusão e o comportamento diante de falhas dentro de um único fluxo de aplicação.

Essa comparação precisa ser honesta. O ACP versão 1 nem sempre informa o uso em cada etapa, portanto o adaptador não oferece uma comparação precisa de custo token a token quando o Grok não devolve os totais. Dá para comparar resultados e o comportamento de ponta a ponta. Não dá para presumir que todos os campos de observabilidade estarão igualmente completos.

Equipe de ferramentas internas corrigindo repositórios

Uma equipe de ferramentas internas pode enviar a correção de um teste com falha para um workspace isolado, transmitir o texto do agente a um operador e destruir a sessão ao final do trabalho. O limite do sandbox protege o host, enquanto o ciclo de vida explícito impede que sessões temporárias virem infraestrutura esquecida.

O benefício é o controle operacional. O agente que altera o código roda em um ambiente delimitado, e a aplicação determina quando esse ambiente começa e termina.

Líder de segurança ou confiabilidade avaliando o lançamento

Há uma decisão concreta nesse caso. A autenticação direta usa XAI_API_KEY. A autenticação pelo AI Gateway usa as credenciais do Gateway. O modo padrão auto escolhe o AI Gateway quando essas credenciais estão presentes; caso contrário, recorre à autenticação direta da xAI.

Também é necessário testar as permissões no limite real de cada ferramenta. O Grok Build não anuncia modos de sessão ACP, e algumas operações internas seguras podem ocorrer sem uma solicitação de permissão do ACP. Uma política criada para outro harness não comprova que o Grok Build terá o mesmo comportamento.

Como executar o fluxo documentado

A configuração completa mais curta usa o Vercel Sandbox e as opções padrão do adaptador.

1. 1

   Instale os pacotes

   Adicione a API comum de harnesses, o adaptador do Grok Build e a implementação do Vercel Sandbox:

   pnpm add @ai-sdk/harness @ai-sdk/harness-grok-build @ai-sdk/sandbox-vercel

2. 2

   Forneça as credenciais do sandbox e do modelo

   No caminho documentado para o Vercel Sandbox, disponibilize VERCEL_OIDC_TOKEN. Para autenticar diretamente no Grok, forneça XAI_API_KEY. Para usar o Gateway, forneça a credencial correspondente do AI Gateway; AI_GATEWAY_BASE_URL pode ser usado quando essa rota exigir a substituição da URL base. A seleção padrão auth: 'auto' do adaptador escolhe a rota disponível.

3. 3

   Crie, execute e destrua a sessão

   Use o exemplo atual do harness do Grok Build:

   import { HarnessAgent } from '@ai-sdk/harness/agent';
   import { grokBuild } from '@ai-sdk/harness-grok-build';
   import { createVercelSandbox } from '@ai-sdk/sandbox-vercel';
   
   const agent = new HarnessAgent({
     harness: grokBuild,
     model: 'grok-build-0.1',
     sandbox: createVercelSandbox({
       runtime: 'node24',
       ports: [4000],
     }),
   });
   
   const session = await agent.createSession();
   
   let exitCode = 0;
   try {
     const result = await agent.stream({
       session,
       prompt: 'Check the test failures and fix the production code.',
     });
   
     for await (const part of result.stream) {
       if (part.type === 'text-delta') {
         process.stdout.write(part.text);
       }
     }
   } catch (err) {
     exitCode = 1;
     console.error(err);
   } finally {
     await session.destroy();
     process.exit(exitCode);
   }

4. 4

   Prepare a instalação via rede na primeira sessão

   A primeira sessão precisa de acesso de saída à rede, pois o harness ACP instala dentro do sandbox o pacote @xai-official/grok@1.0.5, em uma versão fixada. Sem esse acesso, o sandbox falhará antes que o agente consiga realizar trabalho útil.

O detalhe fácil de esquecer é a porta. O Grok Build precisa de um sandbox com rede e pelo menos uma porta exposta para a ponte ACP. O exemplo usa Node 24 e a porta 4000. Um objeto de sandbox sem esse caminho de rede não oferece uma configuração equivalente.

O exemplo atual passa model: 'grok-build-0.1' ao HarnessAgent. Para controlar o adaptador em mais detalhes, substitua grokBuild por createGrokBuild(). Assim é possível escolher a autenticação, o encaminhamento de credenciais, o nível de raciocínio, os servidores MCP, a porta da ponte, o tempo limite de inicialização ou uma função personalizada para o token da ponte. Se reasoningEffort for omitido, o Grok Build usará o padrão configurado.

Os limites que precisam ficar claros

O adaptador herda as limitações do ACP versão 1, e elas fazem diferença em produção.

• Os dados de uso são incompletos. O ACP não expõe os limites entre etapas do modelo nem o uso por etapa. O adaptador infere esses limites e marca o uso como desconhecido quando o Grok não fornece os totais.
• Não há como orientar uma execução em andamento de forma portável. O ACP não oferece uma API comum para direcionamento durante a execução nem para compactação manual.
• A filtragem de ferramentas internas é limitada. É possível filtrar ferramentas do host, mas tentar filtrar as ferramentas internas do Grok gera um erro de recurso não compatível.
• O catálogo de ferramentas pode ficar desatualizado. Quando a lista de ferramentas do host muda, o Grok Build precisa atualizar sua lista MCP no ACP. Se continuar usando a lista antiga, a execução falha de forma explícita.

Também existe um risco de gestão de versões. Os pacotes de harness do AI SDK são experimentais, portanto mudanças incompatíveis entre lançamentos são esperadas. O adaptador do Grok fixa internamente a CLI e o comando de inicialização do ACP, e createGrokBuild() não permite substituir esses detalhes. Isso simplifica o caminho com suporte oficial, mas também deixa a cargo do pacote do adaptador o momento de atualizar o runtime fixado.

A credencial padrão da ponte é um token aleatório de 32 bytes. Se a função de geração do token for substituída, ela precisará retornar um valor realmente secreto. Trata-se de um controle de segurança, não de um lugar conveniente para usar uma string de desenvolvimento legível.

Por fim, esse não é um lançamento de preços. A rota escolhida para autenticar no Grok e o sandbox com rede continuam trazendo seus próprios custos operacionais. O adaptador reduz o trabalho de integração sob medida, mas não elimina a infraestrutura necessária.

O que fazer agora

Vale agir nesta semana se a equipe já usa o AI SDK 7 e quer oferecer o Grok Build como runtime de programação selecionável. Comece com uma tarefa delimitada em um repositório, mantenha o adaptador padrão, teste tanto o caminho de sucesso quanto o de falha e confirme a limpeza da sessão.

Antes de entrar em produção, faça uma avaliação curta se o produto precisar operar vários harnesses. Compare o resultado das tarefas, o comportamento das permissões, a recuperação após falhas e o custo total de cada trabalho. Não use o consumo por etapa como critério decisivo, pois o ACP pode não fornecê-lo.

Espere se compactação manual, direcionamento durante a execução, medição exata por etapa ou listas de permissão para ferramentas internas forem requisitos. Essas lacunas estão no protocolo, não em uma configuração incorreta.

Nada muda para quem usa o Grok Build diretamente, chama modelos Grok sem um coding harness ou não mantém uma aplicação que precise alternar entre runtimes de agentes.

Para receber mais análises práticas sobre as ferramentas que estão mudando a forma como as equipes entregam software, assine a newsletter.