Vercel AI SDK: así funciona el adaptador de Grok Build

El 13 de agosto de 2026, Vercel abrió a Grok Build una vía oficial para integrarse con HarnessAgent de Vercel AI SDK 7. Esto permite ejecutar Grok Build desde un producto mediante la misma interfaz de aplicación que Vercel ofrece hoy para nueve harnesses de programación compatibles, sin tener que reconstruir la capa de orquestación para cada uno.

Qué lanzó realmente Vercel

Este lanzamiento es un adaptador, no un nuevo modelo de Grok.

La forma más clara de entenderlo es separar las capas. Un modelo genera respuestas. Un harness de programación convierte ese modelo en un sistema capaz de trabajar: administra archivos, herramientas, sesiones y permisos, además del bucle que mantiene la tarea en marcha. Agent Client Protocol, o ACP, es el lenguaje común entre un cliente y un harness compatible. Un adaptador traduce ese protocolo a la interfaz que la aplicación ya sabe utilizar.

El nuevo paquete de Vercel es @ai-sdk/harness-grok-build. Conecta HarnessAgent con la CLI de Grok Build mediante ACP y se apoya internamente en el paquete de nivel inferior @ai-sdk/harness-acp.

El recorrido queda así:

Tu aplicación → HarnessAgent → adaptador de Grok Build → CLI de Grok Build dentro de un sandbox

La capa genérica de ACP se encarga de la infraestructura de conexión. El adaptador de Grok Build es el conector terminado: ya trae definidos el paquete, el ejecutable, la asignación de autenticación, el comando de arranque y el mapeo de herramientas. Para profundizar en el funcionamiento del protocolo, consulta la explicación del adaptador de harness ACP para AI SDK. Aquí nos centramos en la ruta de Grok Build que ya se puede utilizar.

Antes de este lanzamiento, integrar un entorno ACP exigía definir su perfil manualmente. Con el lanzamiento de Grok Build del 13 de agosto llegó un adaptador oficial y el mismo flujo de sesiones de HarnessAgent que ya utilizaban Claude Code, Codex, Deep Agents, OpenCode y Pi. En ese momento, la lista pasó a seis harnesses.

Desde el 31 de agosto de 2026, la incorporación de fx por parte de Vercel amplió la lista compatible a nueve harnesses: Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode y Pi. El adaptador de fx amplía el catálogo, pero no cambia el funcionamiento del adaptador de Grok Build.

La expresión «misma interfaz» importa más que «mismo agente». Es posible conservar el contrato de la aplicación, pero no se obtiene el mismo comportamiento de las herramientas, los permisos, la observabilidad ni las respuestas del modelo en los nueve harnesses compatibles.

Por qué este adaptador es relevante

Lo que cambia es el trabajo necesario para integrar cada entorno.

HarnessAgent.generate() y HarnessAgent.stream() devuelven resultados compatibles con AI SDK. Si un producto ya cuenta con una interfaz de chat o tareas basada en AI SDK, Grok Build puede incorporarse al flujo de resultados existente. El harness del servidor cambia; la interfaz de usuario no necesita un formato de respuesta nuevo solo porque cambie el ejecutor.

Para un equipo de plataforma, esto simplifica la comparación de entornos y el enrutamiento de distintos trabajos. Se pueden conservar un ciclo de vida de sesión y un formato de streaming comunes, y después elegir el harness más adecuado para cada tarea.

Nada de esto vuelve a Grok Build más rápido, barato o preciso. El lanzamiento añade una conexión compatible. Tampoco aporta ventajas a quien solo utiliza Grok Build desde su propia CLI. Está pensado para quienes construyen un producto o un sistema interno alrededor de agentes de programación.

Quién puede aprovecharlo desde mañana

Un fundador de devtools que quiere sumar otro entorno

Supongamos que vende un producto de revisión de código o reparación de repositorios con IA construido sobre AI SDK. Ahora puede añadir Grok Build como otro harness del lado del servidor sin crear para él una API de sesiones ni un contrato de streaming independientes.

El cambio concreto es pequeño: instalar el adaptador, conectar el mismo tipo de sandbox y seleccionar Grok Build cuando lo requieran el cliente o la tarea. El beneficio es contar con otro entorno de ejecución sin mantener una superficie de producto adicional.

Un ingeniero de plataforma que compara nueve harnesses

Un equipo de plataforma puede ejecutar la misma tarea acotada sobre un repositorio con Grok Build y con otro harness compatible. Después puede comparar la calidad del resultado y el comportamiento ante fallos dentro de un flujo de aplicación común.

La comparación debe ser rigurosa. La versión 1 de ACP no siempre expone el uso en cada paso, por lo que este adaptador no permite comparar con precisión el costo token por token cuando Grok no devuelve los totales. Sí permite contrastar los resultados y el comportamiento de extremo a extremo; lo que no se debe asumir es que todos los campos de observabilidad estarán igual de completos.

Un equipo de herramientas internas que repara repositorios

Un equipo de herramientas internas puede enviar una tarea de reparación de pruebas fallidas a un espacio de trabajo aislado, transmitir el texto del agente a un operador y destruir la sesión cuando termine el trabajo. El límite del sandbox protege el host, mientras que un ciclo de vida explícito evita que las sesiones temporales se conviertan en infraestructura olvidada.

El beneficio es el control operativo. El agente que modifica el código se ejecuta en un entorno acotado y la aplicación decide cuándo se crea y cuándo se destruye.

Un responsable de seguridad o confiabilidad que evalúa el lanzamiento

Aquí hay una decisión real. La autenticación directa utiliza XAI_API_KEY; la autenticación mediante AI Gateway utiliza las credenciales de Gateway. El modo auto, que es el predeterminado, selecciona AI Gateway cuando encuentra esas credenciales y recurre a la autenticación directa de xAI en caso contrario.

También es necesario probar los permisos en el límite real de cada herramienta. Grok Build no anuncia modos de sesión ACP y algunas operaciones integradas seguras pueden ejecutarse sin solicitar permiso mediante ACP. Una política creada para otro harness no demuestra que Grok Build se comporte de la misma manera.

Cómo ejecutar Grok Build con Vercel AI SDK

La configuración completa más breve utiliza Vercel Sandbox y los valores predeterminados del adaptador.

1. 1

   Instala los paquetes

   Añade la API común de harnesses, el adaptador de Grok Build y la implementación de Vercel Sandbox:

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

2. 2

   Configura las credenciales del sandbox y del modelo

   Para seguir la ruta documentada con Vercel Sandbox, debes proporcionar VERCEL_OIDC_TOKEN. Si utilizas la autenticación directa de Grok, añade XAI_API_KEY. Para la ruta de Gateway, proporciona la credencial correspondiente de AI Gateway; AI_GATEWAY_BASE_URL está disponible cuando es necesario sobrescribir la URL base. La selección predeterminada auth: 'auto' del adaptador elige la ruta disponible.

3. 3

   Crea, ejecuta y destruye la sesión

   Utiliza el ejemplo actual del harness de 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

   Ten en cuenta la instalación por red en la primera sesión

   La primera sesión necesita acceso saliente a la red porque el harness ACP instala el paquete fijado @xai-official/grok@1.0.5 dentro del sandbox. Un sandbox sin salida a internet fallará antes de que el agente pueda realizar trabajo útil.

El detalle fácil de pasar por alto es el puerto. Grok Build necesita un sandbox con red y al menos un puerto expuesto para el puente ACP. El ejemplo utiliza Node 24 y el puerto 4000. Un objeto de sandbox que no incluya esa ruta de red no ofrece una configuración equivalente.

El ejemplo actual pasa model: 'grok-build-0.1' a HarnessAgent. Si hace falta controlar el adaptador, se puede sustituir grokBuild por createGrokBuild(). Es posible elegir la autenticación, el reenvío de credenciales, el nivel de razonamiento, los servidores MCP, el puerto del puente, el tiempo máximo de arranque o una función personalizada para el token del puente. Si se omite reasoningEffort, Grok Build utiliza el valor predeterminado de su configuración.

Las limitaciones, sin rodeos

El adaptador hereda las limitaciones de la versión 1 de ACP, y son relevantes en producción.

• Los datos de uso están incompletos. ACP no expone los límites entre pasos del modelo ni el uso por paso. El adaptador infiere esos límites e informa que el uso es desconocido cuando Grok no proporciona totales.
• No se puede redirigir de forma portable un turno en curso. ACP carece de una API común para intervenir a mitad de un turno o realizar una compactación manual.
• El filtrado de herramientas integradas es limitado. Se pueden filtrar las herramientas del host, pero intentar filtrar las herramientas integradas de Grok provoca un error de capacidad no compatible.
• Los catálogos de herramientas pueden quedar desactualizados. Cuando cambia la lista de herramientas del host, Grok Build debe actualizar su lista MCP de ACP. Si conserva la lista anterior, el turno falla de forma explícita.

También existe un riesgo en la gestión de versiones. Los paquetes de harnesses de AI SDK son experimentales, por lo que cabe esperar cambios incompatibles entre versiones. El adaptador de Grok fija internamente la CLI y el comando de inicio de ACP, y createGrokBuild() no permite sobrescribir esos detalles. Esto simplifica la ruta compatible, pero también deja en manos del paquete del adaptador el momento en que cambia el entorno fijado.

La credencial predeterminada del puente es un token aleatorio de 32 bytes. Si se sustituye la función que genera el token, el reemplazo debe devolver un valor debidamente secreto. Es un control de seguridad, no un lugar conveniente para usar una cadena legible de desarrollo.

Por último, este no es un lanzamiento de precios. La ruta elegida para autenticar Grok y el sandbox de red siguen teniendo sus propios costos operativos. El adaptador reduce el trabajo de integración a medida, pero no elimina la infraestructura subyacente.

Qué conviene hacer ahora

Conviene actuar esta semana si ya se utiliza AI SDK 7 y se quiere ofrecer Grok Build como entorno de programación seleccionable. Empieza con una tarea acotada sobre un repositorio, conserva el adaptador predeterminado, prueba tanto la ruta correcta como la de error y verifica que la sesión se elimine.

Antes de pasar a producción, ejecuta una evaluación breve si el producto necesita varios harnesses. Compara los resultados de las tareas, el comportamiento de los permisos, la recuperación ante fallos y el costo total de cada trabajo. No utilices el consumo por paso como métrica decisiva, porque ACP puede no proporcionarlo.

Conviene esperar si la compactación manual, la intervención a mitad de un turno, la medición exacta por paso o las listas de herramientas integradas permitidas son requisitos. Se trata de carencias del protocolo, no de errores de configuración.

Nada cambia para quien usa Grok Build directamente, llama a modelos de Grok sin un harness de programación o no tiene una aplicación que necesite alternar entre entornos de agentes.

Si buscas más análisis prácticos sobre las herramientas que están cambiando la forma de lanzar productos, suscríbete al newsletter.