Modos

Qué es un modo

Un modo es una propiedad de un espacio, almacenada como una columna en la fila del espacio. Todas las conversaciones de un espacio lo comparten, incluidos los hilos: un hilo hereda el modo de su espacio igual que cualquier otra conversación. Por eso, un mismo agente puede estar en modos distintos en espacios distintos a la vez, y cambiar el modo de un espacio cambia lo que ocurre en el siguiente turno sin tocar al agente.

Hay exactamente cuatro: chat, review, plan, orchestrate. La propia enumeración no conlleva ninguna política. Todo lo que garantiza un modo se declara una sola vez, en un perfil de capacidades, del que proyecta cada capa de aplicación:

Superficie de herramientas: qué herramientas existen en ese modo, expresadas como un nivel máximo de aprobación, una lista de permitidos, una lista de denegados y un conjunto de clases de efecto rechazadas.
Verbo de salida obligatorio: qué debe llamar la ejecución para haber entregado algo.
Clases de efecto denegadas: lo que la barandilla de acciones rechaza de plano.
Postura del worktree: si se puede escribir en el worktree. Se aplica quitando de la superficie las herramientas que mutan, y eso es lo que hace que se cumpla en cualquier host. Cuando el host tiene un entorno aislado del sistema operativo, esa misma postura también define las reglas de escritura del sistema de archivos —un modo de solo lectura monta el worktree en solo lectura—, pero eso es una segunda copia de la garantía, no la que hace el trabajo.
Bloque de prompt de sistema: un preámbulo de capacidades generado a partir de la lista de herramientas realmente materializada, más instrucciones escritas a mano.

Cada capa de aplicación proyecta desde ese único perfil, de modo que la superficie de herramientas, la barandilla, la postura del worktree y el prompt no pueden contradecirse.

Los cuatro modos

Chat — se muestra como «Agent»

Es el modo predeterminado y el único sin restricciones adicionales: la superficie de herramientas completa hasta el nivel de ejecución, un worktree en el que se puede escribir, ninguna clase de efecto denegada y ningún contrato de finalización. Úsalo para implementar, corregir errores, resolver dudas sobre el código y cualquier cosa puntual.

Fíjate en la etiqueta: en el compositor, el modo se muestra como «Agent», y no como «Chat».

Plan — solo lectura, un único entregable

El modo plan pone el worktree en solo lectura y elimina por completo las herramientas de escritura de la superficie, así que la restricción es estructural y no una simple instrucción. El agente lee, busca e investiga, y entrega exactamente una cosa: una llamada submit_plan que lleva un grafo de dependencias tipado: un objetivo más nodos con claves, títulos, descripciones y las claves de nodo de las que depende cada uno.

El plan se muestra como una fila compacta en la conversación y abre Plan Studio en una pestaña junto a ella. Aprobarlo compila el grafo en una orquestación, ejecuta el trabajo generado y devuelve el espacio en el que se redactó al modo agente.

Si una ejecución en modo plan termina sin haber llamado nunca a submit_plan, el bucle inyecta primero un recordatorio que dice que el plan no existe hasta que esa llamada tenga éxito. El recordatorio autoriza explícitamente una salida honesta del tipo «aquí no hace falta ningún plan», porque el modo plan es un ajuste del espacio y una pregunta corriente hecha dentro de él no debería forzar un plan falso.

Hay una segunda salida, distinta: exit_plan_mode. Es una puerta de aprobación estricta, no un verbo de salida: un agente que la llama en lugar de submit_plan no ha entregado nada. La primera llamada abre una aprobación duradera plan_exit y devuelve pending, y el espacio sigue en solo lectura; las llamadas repetidas siguen en pending en vez de abrir una segunda puerta. Solo cuando se concede la aprobación, una llamada posterior cambia el espacio a chat. Si se rechaza, el agente puede abrir una nueva solicitud con un plan revisado.

Para salir tú mismo del modo plan, cambia el desplegable del compositor (o pulsa Shift+Tab). exit_plan_mode se decide con la herramienta MCP decide_approval. Las filas de «aprobación de agente» de la bandeja de entrada son otra cosa: solicitudes de confirmación por turno de un agente en ejecución.

Revisión — solo lectura, sin contrato

El modo de revisión sirve para revisar PR. Pone el worktree en solo lectura, limita la superficie de herramientas por debajo del nivel de ejecución y aplica una lista de permitidos seleccionada de herramientas de revisión, tickets y comunicación. Un espacio abierto para una pull request se crea automáticamente en modo de revisión.

La salida del agente son hallazgos estructurados —nodos de revisión— y, cuando se finaliza una revisión, un veredicto. Un nodo lleva un tipo (bug, suggestion, recommendation, question o ticket), una prioridad de P0 (bloquea la publicación) a P3 (deseable), una confianza autoevaluada, un anclaje opcional (archivo más un intervalo de líneas; las notas de todo el repositorio no llevan ninguno) y un estado de ciclo de vida que pasa de open a consensusReady cuando lo confirma un par —nunca el autor—. Un hallazgo cuya prioridad o confianza falte o esté fuera de rango se descarta en la frontera de lectura en lugar de contaminar el veredicto.

El veredicto es ship, hold o block, y los resultados por eje que se integran en él solo pueden hacerlo más severo: un eje condicionado que ha fallado fuerza block, y un eje condicionado que no ha podido ejecutarse fuerza al menos hold. La ausencia de pruebas nunca pone en verde una puerta.

A diferencia de plan y orquestación, revisión no tiene contrato de finalización. Los hallazgos se acumulan mediante add_review_node y se publican con finalize_review, y ambas pueden llamarse legítimamente cero veces: un agente de pipeline que se ejecuta en modo de revisión puede estar ahí para completar un ticket.

Orquestación — solo lectura, propone un equipo

El modo de orquestación convierte un objetivo en un plan para todo un equipo. Como el modo plan, es de solo lectura y no puede escribir archivos; además de la superficie de investigación, tiene un único verbo privilegiado, propose_orchestration, que emite una propuesta estructurada: roles, un árbol de subtickets, un paso de síntesis y un presupuesto. El prompt solo nombra las herramientas que están en la superficie, así que el modelo no gasta turnos narrando contrataciones ni trabajo de tickets que no puede invocar.

Nada de la propuesta se ejecuta hasta que la apruebas. Al aprobarla, un materializador determinista contrata a los agentes, crea los tickets y un proyecto y ejecuta un pipeline generado. Aprobar es competencia exclusiva del operador: no hay ninguna herramienta MCP para ello, así que un agente puede proponer, pero nunca aprobar su propio plan. Las reproposiciones iniciadas por un agente están limitadas por un enfriamiento de dos minutos, así que los replanteamientos consecutivos se rechazan y se le dice que los agrupe. Consulta Orquestación.

Dos reglas que conviene conocer

El propio verbo de salida de un modo nunca puede denegarse. submit_plan y propose_orchestration están fijados en la superficie de herramientas y preaprobados, pasando por alto tanto el filtro de herramientas como la puerta de aprobación y la barandilla de acciones, de modo que el dial de autonomía por espacio no puede silenciar el entregable de un modo. La ask_user del arnés está fijada por el mismo motivo: es la forma en que una ejecución llega al operador, así que ponerle una puerta bloquearía una ejecución que necesita preguntar algo. Es de nivel de lectura, así que todos los modos de solo lectura la conservan, y está exenta del envoltorio de aprobación: un prompt delante de otro prompt falla en cerrado cuando no hay ningún aprobador conectado, lo que negaría al agente el propio acto de preguntar.

Los modos de solo lectura no deniegan el acceso a la red ni a los secretos. Las clases de efecto que revisión, plan y orquestación rechazan son las que cambian el mundo: borrado de archivos, escrituras fuera del worktree, commits, pushes, creación y publicación de PR, escrituras de sincronización con proveedores, instalación de paquetes, lanzamiento de procesos, mutación del espacio de trabajo y control de recintos. La salida a la red y el acceso a secretos se quedan en sus valores predeterminados a propósito: la investigación es justo el objetivo de un modo de solo lectura.

Elegir y cambiar de modo

El desplegable de modo del compositor ofrece tres opciones: Agent (chat), Plan y Orchestrate. review no lo puede seleccionar el usuario: lo fija el sistema cuando se crea un espacio de revisión de PR y también lo fijan los pasos de pipeline.

Un nodo de pipeline que abre un espacio puede fijar el modo de esa sala con una clave extras['mode'] (chat, review o plan). La clave debe coincidir exactamente: cualquier otra grafía —incluida orchestrate— se ignora en silencio y la sala recibe el valor predeterminado del cuerpo (review en el cuerpo de creación de espacio). Un paso de agente se une a una sala que no ha creado y no le vuelve a definir los permisos.

La resolución en sí es sencilla. El despachador lee la columna mode del espacio; un despacho sin espacio —una ejecución puntual, una invocación de la CLI o un id de espacio de otro espacio de trabajo, que simplemente no está en el archivo de base de datos de este espacio de trabajo— se resuelve como chat. Cambiar el modo surte efecto a partir del siguiente turno.

Dónde se cumple realmente la garantía

La superficie de herramientas de un modo la construye y la aplica el arnés integrado. Es el único transporte capaz de hacer invisible una herramienta en lugar de limitarse a denegarla, de poner una puerta a cada llamada antes de que se ejecute y de observar un contrato de finalización.

En el transporte de Claude Code, un modo distinto de chat se pasa como --permission-mode plan. Claude lo respeta por convención; sus propias herramientas de lectura, escritura y edición se ejecutan sin que nadie las vea, y sus comandos de shell solo los comprueba un hook que lee la línea de comandos. Para ese transporte, el modo es una orientación, no una frontera de Control Center; consulta El modelo de agentes.

Las listas de permitidos restringen las herramientas de nivel de escritura y superior. El nivel de lectura del arnés integrado sigue alcanzando herramientas que ninguna lista nombra; en Claude Code, una herramienta que la lista de permitidos omite se rechaza tanto si el servidor la tiene como si no.

Conceptos relacionados

Ciclo de vida del despacho de agentes: dónde se resuelve y se proyecta el modo
El modelo de agentes: qué transportes pueden aplicar un modo
Barandillas: la política de clases de efecto en la que desemboca el preajuste de un modo
Orquestación: qué hace una propuesta de orquestación aprobada
Usar el modo plan: el recorrido práctico