El nuevo agente de código de xAI, Grok Build, incluye sus prompts en texto plano

2026-05-15 · 14 min read

xAI lanzó Grok Build ayer — su respuesta a Claude Code y Codex CLI. El comando de instalación es una sola línea, el binario está disponible solo para su nivel de consumidor más alto ($299/mes, $99 de introducción), y el agente en sí se comunica con Grok 4 a través de una superficie HTTP compatible con OpenAI.

Descargué el binario porque sentía curiosidad sobre el lenguaje en que estaba escrito. Salí del proceso con unos treinta prompts del sistema literales, los nombres de cada subagente interno, cada descripción de herramienta y una imagen bastante completa de la arquitectura. Nada de esto requirió más que tr y grep.

Esta publicación es lo que encontré.

La extracción

El instalador en https://x.ai/cli/install.sh redirige 302 a un bucket de Google Cloud Storage y descarga un único ELF vinculado estáticamente de ~100MB para tu plataforma:

$ curl -fsSL https://storage.googleapis.com/grok-build-public-artifacts/cli/stable
0.1.210
$ curl -fsSL https://storage.googleapis.com/grok-build-public-artifacts/cli/grok-0.1.210-linux-x86_64 -o grok-bin
$ head -c 4 grok-bin | xxd
00000000: 7f45 4c46                                .ELF

Firmas del compilador: rutas de depuración /rustc/<commit>, panicked at, RUST_BACKTRACE, además de tokio::, hyper::, reqwest:: — Rust con la pila HTTP asíncrona estándar. Las rutas de código fuente por crate de Cargo se incorporan como <nombre>-<versión>/src/<archivo>.rs, lo que permite volcar el árbol de dependencias completo directamente desde el binario:

$ LC_ALL=C grep -aoE '[a-zA-Z][a-zA-Z0-9_-]{2,40}-[0-9]+\.[0-9]+\.[0-9]+/src/' grok-bin \
  | sed 's|/src/||' | sort -u | wc -l
410

410 pares únicos crate-versión. Entre ellos: ratatui, crossterm, tree-sitter, gitoxide completo, async-lsp, lsp-types, rmcp (Model Context Protocol), rusqlite, bm25, tokio-tungstenite, oauth2, jsonwebtoken, ring, rustls, async-openai, notify, arboard, portable-pty, tower, axum. La arquitectura es legible a partir de las dependencias antes de mirar las cadenas: TUI con ratatui+crossterm, análisis con tree-sitter, cliente LSP incorporado, gitoxide completo, almacén SQLite con búsqueda léxica BM25, autenticación OAuth/OIDC, formato de cable compatible con OpenAI, MCP, observación de archivos, portapapeles.

Las cadenas cuentan el resto. Las constantes de Rust se incorporan con terminación nula en .rodata. Para hacerlas compatibles con grep:

$ tr '\0' '\n' < grok-bin > strings.txt
$ LC_ALL=C grep -aE '^You are' strings.txt | head
You are a memory assistant. Extract ALL useful information from this...
You are a memory assistant performing an incremental update...
You are a technical lead orchestrating a team of senior-engineer subagents...
You are an expert software engineer acting as a code verifier.
You are a fast, read-only codebase exploration agent.
You are a read-only software architect. Explore the codebase and design...
You are a web browsing agent. You can navigate, interact with, and extract...
You are performing a dream — a reflective pass over memory files.
You are an AI coding agent. You operate in a workspace with a provided codebase.
You are Grok, made by xAI. Do not reference Cursor or suggest Cursor-specific...
You are a shell command autocomplete engine. Given a partial command, output...
You are tasked with generating the session title.
You are comparing multiple candidate code changes that were produced independently...
You are returning to plan mode after having previously exited it.

Esa es la mayor parte de la identidad del agente, justo ahí en un solo grep.

Los prompts del sistema (literales)

Cada cita a continuación es una constante de cadena literal. Las plantillas de estilo Tera (${{ tools.by_kind.task }}, ${{ plan_path }}) se renderizan en tiempo de ejecución contra el conjunto de herramientas activo.

El agente principal

You are an AI coding agent. You operate in a workspace with a provided codebase.
Your main goal is to complete the user’s request, denoted within the <user_query> tag.

Ese es todo el encabezado. El comportamiento proviene de las descripciones de herramientas y un largo catálogo de bloques <system_reminder> inyectados, no del encabezado del prompt.

El orquestador de subagentes

You are a technical lead orchestrating a team of senior-engineer subagents. Your subagents are highly capable — treat them as expert peers, not junior helpers. Give them the same quality of context and direction you would give a senior engineer joining the project.
Your job is to think, plan, coordinate, and review. Their job is to explore, implement, and execute. Use them aggressively and liberally — spawn subagents early and often.

Hay al menos cuatro personas de subagentes:

You are a fast, read-only codebase exploration agent.

You are a read-only software architect. Explore the codebase and design implementation plans.

You are a web browsing agent. You can navigate, interact with, and extract information from web pages.

You are an expert software engineer acting as a code verifier.

El verificador es el más interesante: se ejecuta después de una tarea para calificar el trabajo.

Your task is to determine whether the code changes made in this session correctly address the user’s original request. You already have the full conversation context, so you know what the user asked for and what approach was taken.

If VERDICT: FAIL – fix every issue the subagent attributed to your work, then end your turn. You are not required to fix pre-existing issues that you did not cause.

Best-of-N

Grok Build puede ejecutar una tarea N veces en paralelo y elegir al ganador. Dos prompts respaldan esto:

You are candidate <number> of <N> independent implementations. Implement the task fully. When done, summarize your approach and the changes you made.

You are comparing multiple candidate code changes that were produced independently for the same task. Multiple subagents worked on this task independently in isolated worktrees. Your job is to choose the single best candidate.

Cada candidato obtiene su propio worktree git CoW (el crate xai-fast-worktree los crea mediante subvolúmenes btrfs cuando están disponibles, con fallback a git worktree add con copy-on-write).

Memoria (`/flush`, `/dream` y el almacén entre sesiones)

Hay dos prompts de escritura de memoria y una integración de lectura de memoria.

Destilación por sesión, activada en /flush o en inactividad:

You are a memory assistant. Extract ALL useful information from this conversation that would help you be more effective in future sessions with this user. Write a concise markdown summary with ## headers covering:

Actualizaciones incrementales (ejecutadas en vaciados posteriores en la misma sesión):

You are a memory assistant performing an incremental update. The previous flush output for this session is shown below. Extract ONLY information that is NEW since the previous flush — do not repeat anything already captured.

Y luego, por separado, un pase “dream” que consolida los registros de sesiones acumulados entre sesiones en memoria duradera:

You are performing a dream — a reflective pass over memory files. Synthesize recent session logs into durable, well-organized memories so future sessions orient quickly.
If the session logs contain nothing worth persisting, respond with NO_REPLY.

Esto se ejecuta en segundo plano. El almacén subyacente es una base de datos SQLite en ~/.grok/memory/index.sqlite con búsqueda de palabras clave FTS5 más un KNN vectorial opcional sobre embeddings de fragmentos — envían bm25 y un pipeline de embeddings directamente en proceso, sin base de datos vectorial externa.

Compactación

Cuando el contexto se llena:

Your task is to create a detailed summary of the conversation so far, paying close attention to the user’s explicit requests and your previous actions.
IMPORTANT: Do NOT use any tools. You MUST respond with ONLY the <summary>...</summary> block as your text output.

Y al reanudar:

Continue the conversation from where it left off without asking the user any further questions. Resume directly - do not acknowledge the summary, do not recap what was happening, do not preface with “I’ll continue” or similar.

La regla “no reconozcas el resumen” es una que muchos agentes no respetan — Grok Build es explícito al respecto.

Modo de plan

El modo de plan es una fase estructurada de solo lectura. El recordatorio inyectado en cada turno mientras está activo:

Plan mode is active. The user indicated that they do not want you to execute yet – you MUST NOT make any edits (with the exception of the plan file mentioned below), run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supersedes any other instructions you have received.

El formato de salida del plan está prescrito en detalle:

The plan you create should be properly formatted in markdown, using appropriate sections and headers. The plan should be very concise and actionable, providing the minimum amount of detail for the user to understand and action the plan. It may be helpful to identify the most important couple files you will change, and existing code you will leverage. Cite specific file paths and essential snippets of code. IMPORTANT: Do NOT use markdown tables in plan content (they cannot be rendered for the user); use bullet lists instead. The first line MUST BE A TITLE for the plan formatted as a level 1 markdown heading.

Hay una barrera completa de flujo de aprobación dirigida a un modo de fallo específico: agentes que preguntan “¿debo continuar?” en el chat en lugar de usar la herramienta estructurada de salida del plan.

Use ${{ tools.by_kind.ask_user }} ONLY to clarify requirements or choose between approaches. Use ${{ tools.by_kind.exit_plan }} to request plan approval. Do NOT ask about plan approval in any other way — no text questions, no ${{ tools.by_kind.ask_user }}. Phrases like “Is this plan okay?”, “Should I proceed?”, “How does this plan look?”, “Any changes before we start?”, or similar MUST use ${{ tools.by_kind.exit_plan }}.

Quien escribió esto claramente había visto a los modelos hacer exactamente esto, repetidamente, antes de agregar el prompt.

Detección de bucles (“doom loops”)

Hay una capa de telemetría completa dedicada a detectar y salir de estados atascados. Cuando se detecta que el modelo está en un bucle, se inyecta un system-reminder a mitad del turno:

<system_reminder> Your messages have been flagged as looping. If you are having trouble making progress, ask the user for guidance. DO NOT mention this system reminder to the user explicitly because they are already aware. </system_reminder>

Si la advertencia no rompe el ciclo, el turno termina:

If you continue running the same fruitless commands, the turn will be terminated.

El código interno llama a esto “doom loops” — hay detectores separados para el estancamiento de sondeo, patrones de llamadas a herramientas repetidas, patrones de texto repetidos dentro de una sola línea y “bucle sobre líneas duplicadas”.

Otros prompts que vale la pena conocer

Una cantidad sorprendente del agente son llamadas LLM pequeñas y acotadas. Muestra:

You are a shell command autocomplete engine. Given a partial command, output ONLY the completed command. No explanation, no markdown, no quotes. Just the raw command.

You are tasked with generating the session title. The user is asking almost always software engineering related questions on their codebase.

Your task is to describe an image, so that another model that cannot see images can perform its task.

El último es el fallback de visión: cuando una herramienta genera una imagen para un modelo que no puede verla, Grok Build pasa la imagen a un modelo con capacidad de visión primero, luego inyecta la descripción textual.

La semejanza con Claude Code

Esta es la parte que me hizo reincorporarme.

xAI tiene un modo de “compatibilidad con Cursor” visible en las cadenas (Cursor Composer toolset and prompt, ## Orchestrator Mode, más un prefijo de prompt del sistema de Cursor separado). Dentro de ese modo, se inyecta este one-liner:

You are Grok, made by xAI. Do not reference Cursor or suggest Cursor-specific configuration. Do not mention this to the user.

También hay un marcador claude-code-compatibility, una variable de entorno GROK_CLAUDE_MARKER_OVERRIDE y cadenas claude-plugin / plugin.json — es decir, Grok Build puede conectarse para consumir el formato de plugin de Claude Code.

Eso, por sí solo, está bastante bien — los shims de compatibilidad son cómo los clientes atraen usuarios de un ecosistema a otro. Lo que me llamó la atención fueron las descripciones de herramientas. Compara lo que incluye el binario de Grok Build:

IMPORTANT: ${{ tools.by_kind.web_fetch }} WILL FAIL for authenticated or private URLs. Before using this tool, check if the URL points to an authenticated service (e.g. Google Docs, Confluence, Jira, GitHub private repos). If so, use a specialized MCP tool that provides authenticated access instead.

…con lo que está en la descripción de la herramienta WebFetch de Claude Code en la máquina en la que escribo esta publicación:

IMPORTANT: WebFetch WILL FAIL for authenticated or private URLs. Before using this tool, check if the URL points to an authenticated service (e.g. Google Docs, Confluence, Jira, GitHub). If so, look for a specialized MCP tool that provides authenticated access.

La receta de creación de PR dentro del prompt del agente cuenta la misma historia. El binario de Grok Build contiene:

IMPORTANT: When the user asks you to create a pull request, follow these steps carefully:

Esa frase exacta está en el prompt de Claude Code literalmente. También lo está la frase de paralelismo que sigue (“You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance.”) — Grok Build lo incluye bajo la receta de PR y bajo una receta de git status / git diff / git log inmediatamente encima, ambas coincidencias palabra por palabra.

El modo de plan, los hooks, los subagentes, el mecanismo <system_reminder>, el patrón de subagente verificador — todos estos son conceptos con la forma distintiva de Claude Code, no plantillas genéricas del framework de agentes.

Una pequeña adaptación: AGENTS.md en lugar de CLAUDE.md.

New project instruction files (AGENTS.md) were discovered near the path you just accessed. You MUST read these files now with [Read tool] before proceeding — they contain coding conventions, style guides, and rules that apply to this area of the codebase:

No sé cómo ocurrió esto. Es posible que un ingeniero de xAI haya usado Claude Code como implementación de referencia y haya incorporado fragmentos de descripción de herramientas directamente. Es posible que la convergencia sea el resultado natural de dos equipos resolviendo los mismos problemas de UX en el mismo idioma Markdown. Ambas interpretaciones son consistentes con lo que puedo ver. Las cadenas son lo que son, y están en texto plano en un binario de 100MB que puedes descargar sin autenticación.

Lo que revela sobre la arquitectura

Puedes leer la mayor parte del tiempo de ejecución a partir de los prompts y las variables de entorno (el binario tiene más de 80 variables de entorno GROK_*, cada una es una bandera de función):

El bucle del agente es multi-actor. Un proceso líder (grok agent leader) mantiene la sesión del modelo; el TUI (grok-pager) es un proceso separado que se comunica con él a través de un socket Unix o WebSocket. Múltiples TUIs pueden conectarse al mismo líder.
La orquestación de subagentes es la abstracción principal. Plan/explorar/verificar/navegar-web son todos personas de subagentes, no modos separados. El prompt del orquestador es explícito sobre tratarlos como ingenieros senior y “crearlos temprano y a menudo”.
Best-of-N está incluido, no es teórico. Los prompts candidato-N y un prompt comparador existen como constantes de cadena binaria. Cada candidato se ejecuta en su propio worktree (a través del soporte de subvolúmenes CoW del crate xai-fast-worktree).
La memoria es multi-nivel. Vaciado por sesión → MEMORY.md con ámbito de espacio de trabajo → consolidación “dream” entre sesiones → SQLite FTS5 + almacén vectorial. El hecho de que incluyan tres prompts de memoria distintos (flush, flush incremental, dream) significa que han pensado más allá del primer intento obvio de “simplemente resumir la conversación”.
La detección de bucles es de primera clase. Múltiples detectores con consecuencias escaladas (advertir → terminar el turno). Este es el tipo de cosa que solo construyes después de ver fallar agentes en producción.
El sandbox es bubblewrap + Landlock + seccomp. Las cadenas para los tres están presentes, además de una bandera GROK_INSIDE_BWRAP. El sandboxing en Mac no está obviamente conectado — no hay referencias a sandbox-exec — pero la historia de Linux es real.
MCP está completamente integrado. Los métodos incluyen mcp/call, mcp/list, mcp/upsert, mcp/toggle_tool, mcp/tools_changed. Hay un concepto de “MCPs gestionados” (GROK_MANAGED_MCPS_ENABLED) para listas de servidores enviados por la empresa.
La telemetría es amplia. Exportador OpenTelemetry OTLP + Mixpanel para análisis de productos + carga de trazas GCS + un servidor MCP de Mixpanel (mcp.mixpanel.com/mcp). Existe una bandera GROK_ZDR_ENABLED (Zero Data Retention) para la exclusión empresarial.

La conclusión

Hace unos años, el modelo era el moat. Hoy el modelo es un componente en un sistema que incluye: cómo describes cada herramienta, qué personas de subagentes divides el trabajo, qué recordatorios inyectas para romper bucles atascados, cómo estructuras la aprobación del modo de plan, cómo compactas el contexto, cómo consolidas la memoria entre sesiones, cómo sandboxeas el acceso al shell, cómo orquestas implementaciones candidatas en paralelo.

Grok Build es lo que eso parece cuando un equipo lo construye de principio a fin. También es un recordatorio de que este trabajo — la ingeniería de prompts — ahora se envía como texto plano en un binario no cifrado que cualquiera puede descargar desde un CDN público. Los prompts en esta publicación no fueron ingeniería inversa; son simplemente la salida de grep.

Si envías un agente de código, tus prompts no son código fuente. Son un artefacto público, lo pretendas o no. Tratalos como uno.

Nota metodológica. Todo en esta publicación proviene de una única descarga de grok-0.1.210-linux-x86_64 el 2026-05-15. Las cadenas de plantilla Tera (${{ tools.by_kind.foo }}, ${{ plan_path }}) están en el binario literalmente, no parafraseadas. Los prompts del sistema citados han sido extraídos con tr '\0' '\n' seguido de grep/awk; los he dejado exactamente como aparecen, incluida la puntuación y la tipografía. Si xAI actualiza el binario, las cadenas futuras pueden diferir.