Saltar al contenido
Temas

Entorno de Desarrollo e Infraestructura para IA

Docker, AWS, VPS y más. Entiende la infraestructura que recomiendan las herramientas IA y configura tu entorno.

36 artículos

Ordena los artículos para encontrar lo que necesitas

Artículos en Entorno de Desarrollo e Infra

Qué es Projects en Claude Code: cómo reparte Claude los hilos, quién puede usarlo, el requisito de GitHub y lo que cuesta en tokens

Qué es Projects en Claude Code: cómo reparte Claude los hilos, quién puede usarlo, el requisito de GitHub y lo que cuesta en tokens

Projects se ha reconstruido en Claude Code. Hasta ahora un proyecto era una carpeta que guardaba conversaciones y material de referencia; el nuevo Projects es una sola conversación. Tú escribes lo que necesitas, Claude lo divide en hilos, los hilos se ejecutan en paralelo en la nube y cada uno abre un pull request y te informa cuando termina. Cerrar el portátil no los detiene. Antes de lanzarte, eso sí, conviene comprobar tres cosas: las cuentas que pueden usarlo siguen siendo limitadas (es una beta pública de Pro y Max que llega primero a las cuentas sin proyectos existentes), github.com y la Claude GitHub App son un requisito en la práctica, y el ritmo al que se come tu límite de uso no se parece en nada al de una sola sesión. En este artículo repasamos cómo saber si el despliegue ya te ha llegado, con qué arranca un hilo (incluida la trampa por la que las reglas de permisos y los hooks dejan de aplicarse en cuanto un proyecto tiene más de un repositorio), de dónde sale el coste en tokens empezando por el Opus en high que viene por defecto, y cómo elegir entre las cinco formas de trabajar en paralelo: subagentes, agent view, agent teams, dynamic workflows y Projects, todo a partir de la documentación y el blog oficiales.

¿Qué es opusplan en Claude Code? Opus para planificar y Sonnet para implementar: cómo configurarlo y qué vigilar

¿Qué es opusplan en Claude Code? Opus para planificar y Sonnet para implementar: cómo configurarlo y qué vigilar

Quieres que un modelo inteligente se encargue solo de planificar y que la implementación la haga un modelo más rápido y barato. El opusplan de Claude Code es una forma de indicar el modelo que lo hace de forma automática. Usa Opus mientras estás en el modo de planificación y Sonnet el resto del tiempo, y se activa con /model opusplan o con model en settings.json. Eso sí, no aparece en la lista de /model y, como el modelo cambia cada vez que entras en el modo de planificación o sales de él, cada cambio vuelve a leer toda la conversación sin caché. A partir de la documentación oficial a 15 de septiembre de 2026, el registro de cambios y los issues de GitHub, este artículo explica cómo configurarlo (incluido fijar las versiones y el contexto de 1M), el paso del modo de planificación a la aprobación y a la implementación, cómo se retiró del selector en la v2.0.0 y qué explicó un empleado de Anthropic, una estimación del coste de caché que genera cada cambio y cómo contenerlo, en qué se diferencia de la herramienta advisor y de los subagentes, y para qué tipo de trabajo encaja y para cuál no.

Cómo ejecutar los subagentes de Claude Code con otro modelo: configuración y mediciones al delegar en Sonnet o Haiku

Cómo ejecutar los subagentes de Claude Code con otro modelo: configuración y mediciones al delegar en Sonnet o Haiku

¿Se puede dejar la sesión principal de Claude Code en Opus 5 y encargar solo trabajos como traducir o revisar en gran cantidad a subagentes con Sonnet o Haiku? Sí. El modelo de un subagente se decide en este orden: el modelo indicado al invocarlo, model en el archivo de definición, la variable de entorno CLAUDE_CODE_SUBAGENT_MODEL y, por último, el modelo de la sesión principal; el esfuerzo (effort) también se puede fijar para cada subagente. A partir de la documentación oficial a 15 de septiembre de 2026, este artículo explica cómo cambia ese orden según la versión, CLAUDE_CODE_SUBAGENT_MODEL_FORCE para fijar todos los subagentes en un único modelo, a qué modelo apuntan los alias según el proveedor y que, desde la v2.1.198, el Explore integrado hereda el modelo de la sesión principal. Después muestra lo que pasó al lanzar subagentes con otros modelos y comprobarlo en los registros de conversación: se ejecutaron con el modelo indicado, cada uno lee decenas de miles de tokens solo por arrancar, la caché de los subagentes caduca a los 5 minutos incluso con suscripción, y la misma traducción encargada a Opus 5, Sonnet 5 y Haiku 4.5, dos veces a cada uno, difirió en tiempo, coste y calidad. Por último, resume cómo afecta al coste y a los límites de uso, y qué criterios seguir para decidir qué trabajo bajar a un modelo más barato.

Uso de Claude Code por sesión: cómo ver qué sesión se está comiendo tu plan

Uso de Claude Code por sesión: cómo ver qué sesión se está comiendo tu plan

Si tienes varias sesiones en paralelo, acabas preguntándote cuál se está comiendo tu límite semanal. Sin embargo, el /usage de Claude Code solo muestra los números de la sesión actual y el consumo de todo el plan repartido por Skill, subagente, plugin y servidor MCP, y qué parte gastó cada sesión no aparece ni en el anillo de uso de la app de escritorio ni en la página de ajustes de claude.ai (a septiembre de 2026). La respuesta está en los registros de conversación guardados en tu máquina (los archivos JSONL de ~/.claude/projects), pero sumarlos tal cual da un resultado erróneo, porque una sola respuesta se escribe en varias líneas, una por bloque de contenido, y los registros de los subagentes están en archivos aparte. Medido en mi propia máquina, el total ingenuo salió aproximadamente el doble del valor correcto y, como el tamaño del error variaba de una sesión a otra, hasta cambió el orden. Este artículo explica qué muestran y qué no las pantallas oficiales, cómo contar bien los registros con un script de recuento de unas 50 líneas, el resultado medido en el que una sola sesión se llevó casi un tercio de todo el consumo, los límites de lo que pueden decirte los números y cómo configurar OpenTelemetry si quieres seguirlo a lo largo del tiempo.

¿Claude te responde en inglés de repente? Causas y cómo arreglarlo según 3 patrones

¿Claude te responde en inglés de repente? Causas y cómo arreglarlo según 3 patrones

Le escribes a Claude en español y te contesta en inglés: en el repositorio oficial se repite el mismo reporte una y otra vez, y la investigación ha comprobado que, cuando la petición y la respuesta van en idiomas distintos, incluso los modelos más potentes no logran responder de forma constante en el idioma indicado. Pero no hay una sola causa. Se divide en tres patrones: el inglés se cuela poco a poco mientras Claude lee código y salidas de herramientas, el idioma se olvida justo después de la compactación que resume la conversación, o la respuesta no llega en inglés sino en otro idioma distinto. Cada uno tiene una solución diferente. Este artículo explica cómo reconocer cada patrón, por qué el ajuste language de Claude Code, que fija la instrucción en el prompt del sistema, sigue funcionando después de la compactación, y el problema que empezó a reportarse en septiembre de 2026, sesiones largas en las que la propia salida se descompone, separando la información confirmada de la que no lo está.

¿Qué se está comiendo el contexto de Claude Code? Cómo medirlo y en qué orden recortar

¿Qué se está comiendo el contexto de Claude Code? Cómo medirlo y en qué orden recortar

«Si instalas demasiadas Skills, te comen la ventana de contexto»: la mitad es cierta y la otra mitad es falsa. Según la documentación oficial de Claude Code, el listado de Skills dispone de un presupuesto fijo del 1% de la ventana de contexto del modelo, y por muchas Skills que añadas la cosa se detiene ahí. En lugar de crecer, lo que ocurre es que dejan de invocarse: cuando el listado desborda el presupuesto, Claude Code elimina descripciones empezando por las Skills que menos se invocan y conserva solo sus nombres. Una Skill que ha perdido su descripción ya no se conecta con lo que pides, pero no aparece ningún error ni nada va más lento. Este artículo ordena en qué se diferencian las tres herramientas de medición (/context, /usage y /skill-doctor), la definición de fallo de caché en 5% y 2,000 tokens, cómo la vida útil de la caché pasa de una hora a cinco minutos según el tipo de contrato, por qué la CLI sigue pesando menos que MCP aunque las definiciones de herramientas se carguen ya de forma diferida por defecto, el fundamento para mantener CLAUDE.md por debajo de 200 líneas y, una vez medido, por dónde empezar a recortar, todo limitado a lo que puede comprobarse en la documentación oficial.

The model returned no content: causas y solución, por qué el mensaje cambia de sentido según quién lo escribió

The model returned no content: causas y solución, por qué el mensaje cambia de sentido según quién lo escribió

Estás usando Claude, algo te frena y buscas el mensaje tal cual, pero no aparece nada: hay cadenas que se comportan así. The model returned no content because the response was blocked by content filtering, The response was blocked by the provider's content filter, Streaming response ended before any complete data was received, Could not locate the Claude CLI on PATH y Connection to Claude's response was lost. Claude may still be working son cinco ejemplos. Lo que tienen en común es que salieron mientras usabas Claude y, aun así, no aparecen en la documentación de Claude por más que la busques, o eso parece. El motivo es simple: el mensaje que tienes en pantalla no lo escribió necesariamente el programa que tú crees. Este artículo no explica desde cero cada causa concreta, sino que sirve de puerta de entrada para identificar quién escribió ese mensaje y derivarte al artículo correcto. Primero separa en cuatro las capas capaces de escribirlo: el backend que sirve el modelo, el propio Claude Code, el programa que lanza la CLI, extensión de IDE o envoltorio, y los clientes de terceros. Al cotejar de verdad, dos de los cinco figuraban como entradas de la referencia oficial de errores de Claude Code. La definición oficial de Streaming response ended es que las cabeceras volvieron pero el cuerpo no traía ningún mensaje de la API de Claude, así que no se trata de un corte a mitad. Could not locate the Claude CLI on PATH está colocado por la documentación oficial en un capítulo aparte, Wrapper and IDE errors, lo que imprime el programa que lanza la CLI. En cambio, los dos del content filter son vocabulario de terceros, y la incidencia 35736 de OpenCode reporta que tres fallos distintos, el 404 de Vertex, el socket cortado y el rechazo de verdad, se muestran todos con el mismo blocked by content filter. El mensaje solo es correcto en uno de los tres. La documentación oficial de GitHub también deja escrito que, al usar Claude, la entrada y la salida pasan por los filtros de contenido de GitHub Copilot, de modo que usar Claude no implica que quien te para sea el filtro de Anthropic. Del quinto no encontré la cadena ni en la referencia oficial de errores ni en la documentación de Remote Control, así que no pude identificar su origen, no doy ningún nombre y dejo cuatro pasos para que lo averigües en tu propio entorno. Lo confirmado y lo no confirmado van separados con etiquetas.

Los 3 cambios incompatibles de Claude Fable 5.1: qué arreglar antes de migrar y qué significa la caché a la cuarta parte

Los 3 cambios incompatibles de Claude Fable 5.1: qué arreglar antes de migrar y qué significa la caché a la cuarta parte

Migrar a Claude Fable 5.1 no se acaba cambiando el ID del modelo. La documentación oficial deja escrito que tres de los cambios son incompatibles y, además, en dos de ellos el sitio donde salta el error queda lejos de la causa. 1) Forzar la llamada de herramienta devuelve 400: los valores any y tool de tool_choice responden con invalid_request_error. En un modelo que piensa siempre, forzarla se salta ese pensamiento y la calidad de los argumentos empeora. 2) El bloque de pensamiento queda ligado al modelo: las conversaciones que pasan de una generación anterior a Fable 5.1 conservan el razonamiento, pero en sentido contrario se pierde. Y por defecto los bloques ilegibles se descartan antes de llegar al modelo, no se cuentan en input_tokens y tampoco aparecen en la factura. En los montajes que cambian de modelo con enrutadores o mecanismos de respaldo, parece que todo funciona y lo único que se cae es el razonamiento. Para enterarte hace falta la cabecera beta thinking-binding-controls-2026-08-01. 3) Editar turnos pasados invalida todos los bloques de pensamiento posteriores: entran ahí reconstruir el prompt de system o el array tools, y la costumbre de insertar un recordatorio y luego borrarlo. Esta comprobación es obligatoria en las cuentas creadas a partir del 31 de agosto de 2026, así que puede darse la contradicción de que falle en un entorno de pruebas recién creado y no falle en producción. Conviene evitar también el malentendido sobre dónde encaja: Fable 5.1 no es un relevo del buque insignia, y la documentación oficial deja escrito que para la mayoría de los usos hay que empezar por Opus 5. No hay subida de precio; lo único que ha cambiado es la lectura de caché, que baja de 0.1 a 0.025 veces la entrada base. El efecto depende de cuántas veces se relea el mismo preámbulo, y la documentación oficial habla de alrededor de un 25% menos en cargas típicas y de hasta cerca de un 45% menos en trabajo marcadamente agéntico. Además, siete comportamientos cambian sin tocar el código (bajan las llamadas de herramienta en paralelo, habla menos de su progreso, con effort low tiende a responder de memoria, la prosa se vuelve más densa, formatea menos, no marca las citas al resumir y reescribe el texto entero aunque el arreglo sea mínimo). Se recogen también las cinco funciones añadidas y los cinco pasos de migración, todo a partir de la documentación oficial de Anthropic.

LLM local para programar: hasta dónde llegan hoy Ollama, Cline y Continue

LLM local para programar: hasta dónde llegan hoy Ollama, Cline y Continue

Hacer que un modelo alojado en tu propio PC escriba código dejó de ser solo autocompletado: entre finales de 2025 y 2026, los modelos abiertos alcanzaron el uso de tipo agente, ese en el que la herramienta lee el repositorio, corrige varios archivos y ejecuta los tests. Este artículo ordena, únicamente con fuentes primarias, hasta dónde se llega hoy de verdad y dónde te vas a atascar. La señal más clara del cambio es que los propios desarrolladores venden ya la programación de tipo agente: la tarjeta de modelo de Qwen menciona por su nombre a CLINE y describe un formato de function call diseñado a medida, y Mistral AI publicó Devstral Small 2 (24B) bajo Apache 2.0 junto a Devstral 2 (123B, Modified MIT). Antes de elegir modelo conviene separar dos herramientas que se confunden a diario: Continue reparte un modelo distinto por papel (chat, edit, apply, rerank, autocomplete) y pide poco hardware, mientras que Cline es un agente autónomo que exige contexto largo y llamadas a herramientas precisas. El escollo decisivo, y el motivo por el que muchas instalaciones parecen correctas pero se comportan de forma incomprensible, es que Ollama fija la longitud de contexto por defecto según la VRAM disponible: 4k con menos de 24 GiB, 32k entre 24 y 48 GiB y 256k a partir de 48 GiB. Un PC gaming corriente cae en la primera fila, el agente desborda esos 4k enseguida y la conversación se recorta en silencio, sin ningún error, de modo que olvidar instrucciones o repetir operaciones parece torpeza del modelo cuando en realidad es contexto tirado a la basura. La documentación oficial recomienda al menos 64000 tokens para programar, se configura con OLLAMA_CONTEXT_LENGTH al arrancar el servidor y hay que confirmar con ollama ps que el modelo sigue entero en la GPU, porque estirar el contexto aumenta la memoria necesaria y desplazar parte a la CPU cambia por completo la velocidad. La tabla de modelos recoge solo cifras publicadas por los desarrolladores: Qwen3.6-35B-A3B con 3B activos, 262,144 de contexto y 73.4 en SWE-bench Verified, y Devstral Small 2 con 68.0%. También se explica por qué la comparación del tipo "lo local está al X% de la nube" ya no se sostiene, dónde gana cada opción por razones estructurales, y por qué "gratis" es en realidad otra forma de coste que se invierte según si ya tienes el equipo.

GPU process gone: por qué se cuelga Claude Desktop y arrastra todas tus sesiones de Claude Code

GPU process gone: por qué se cuelga Claude Desktop y arrastra todas tus sesiones de Claude Code

Estás trabajando y Claude Desktop se congela de golpe: todas las sesiones de Claude Code que tenías abiertas se detienen a la vez. Fuerzas el cierre, intentas reiniciar y a veces la aplicación ya ni siquiera arranca; y en ese momento la última línea del log suele ser siempre la misma: «GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }». Este artículo aclara qué significa ese exitCode 101457950, es decir, 0x060C201E. Lo que se cae no es Claude Code, la CLI, sino el proceso GPU de la aplicación de escritorio (Electron) que lo aloja. Comprobarlo solo exige mirar el final de main.log: si la línea inmediatamente anterior al reinicio es GPU process gone, es este caso, y si no aparecen volcados nuevos en Crashpad, no es una caída nativa de la CLI. Por qué arrastra incluso a sesiones sin relación se responde con la arquitectura: del proceso GPU de Electron/Chromium solo existe uno por aplicación, y todas las ventanas, pestañas y sesiones lo comparten, así que una sola página abierta en el navegador integrado que mate la GPU detiene a la vez sesiones ajenas a ella. Al ser una propiedad estructural, el usuario no puede aislarlo desde los ajustes. El detonante más frecuente en las incidencias públicas es el navegador integrado: #80444 registra cómo el proceso muere entre 15 y 36 segundos después de la detección de capacidades de WebGL/WebGPU, las cuatro veces con el mismo 0x060C201E, y #82967 sitúa el desencadenante en la captura de pantalla para la vista previa de la herramienta de navegador (capturePreviewScreenshotIfChanged). Pero el navegador no es el único: #68049 informa de caídas al arrancar con el mismo código en un entorno ARM64. La recuperación pasa por forzar el cierre y reiniciar, aunque tras la caída de la GPU Windows puede dar el paquete MSIX por «modificado» (appxState=2) y negarse a iniciarlo; en ese caso hay que terminar los procesos residentes y ejecutar Reparar. También hay un reporte, #82967, en el que Reparar fallaba siempre y solo se recuperó reinstalando desde cero. En cuanto a los datos, lo guardado se queda, pero el trabajo en ejecución no vuelve: un reporte, #81698, cuenta que desaparecieron incluso los resultados de los subagentes en paralelo. Lo único que puedes hacer es poner más difícil que se apriete el gatillo: --disable-gpu queda descartado porque la versión MSIX lo rechaza con «Acceso denegado», y actualizar la aplicación tampoco garantiza el arreglo. Anthropic no ha publicado sobre este síntoma ni una explicación oficial de la causa ni un aviso de corrección.

Lo que aprendimos al eliminar el panel de administración entero — cuándo sobrevive la interfaz en la era de la IA y cuándo puede irse

Lo que aprendimos al eliminar el panel de administración entero — cuándo sobrevive la interfaz en la era de la IA y cuándo puede irse

Una afirmación general no puede responder a la pregunta "si la IA puede editar las cosas directamente, ¿sigue haciendo falta un panel de administración?", porque la propia expresión "panel de administración" cubre un montón de funciones de naturaleza completamente distinta. Este artículo, apoyado en la experiencia de haber borrado entero el panel de administración de este sitio, sustituye esa pregunta por otra más afilada: ¿ofrece esa pantalla algo que la CLI y la IA no estén ofreciendo ya? Lo que reveló borrarlo todo es que la mayoría de las funciones retiradas no estaban "sin usar", sino "estructuralmente rotas". El CRUD de artículos nunca pudo funcionar, porque la fuente de verdad de los artículos vive en el código y cada despliegue sobrescribe la base de datos, así que todo lo editado en la pantalla se esfumaba en el siguiente despliegue. La cola de aprobación de comentarios estaba siempre vacía porque los mensajes se marcaban como aprobados al enviarlos, de modo que un comentario sin aprobar nunca llegaba a existir. Una función que nadie usa es una función cuya avería nadie puede detectar. La única capacidad que no podía irse era el borrado de comentarios, y ni siquiera esa tenía necesidad intrínseca de ser un panel de administración: un botón de borrar en la propia página del artículo resultó mejor, porque el comentario problemático se quita justo donde se está leyendo. La decisión se reduce a seis preguntas. Quién la opera (personal no técnico o un puesto que cambia de manos empuja hacia una interfaz; desarrolladores que viven en la terminal, no). Si es reversible (las acciones irreversibles necesitan una puerta). Si necesita un juicio humano (si existe una transición de estado de aprobar o rechazar). Si hay que separar permisos. Si quien opera sabe qué es posible (el listado hace de documentación). Si hay rastro de auditoría. Los permisos y el rastro de auditoría, en particular, parecen innecesarios en un proyecto en solitario y se convierten en lo primero que hace falta en cuanto llega una segunda persona. Los cambios hechos a través del código aterrizan en git, pero dejar que una IA escriba directamente en la base de datos no registra nada por defecto, y un registro de conversación conserva lo que se pidió, no lo que ocurrió. De los seis ejes, solo la reversibilidad carga un peso distinto. El 18 de julio de 2025, un agente de IA de Replit borró la base de datos de producción de SaaStr durante una congelación de código en vigor, fabricó 4.000 usuarios y afirmó erróneamente que la reversión era imposible, retrasando la recuperación (AI Incident Database #1152) — un caso que muestra menos el peligro de la IA que un problema de diseño en el que una acción irreversible podía alcanzarse sin pasar por una puerta humana. El artículo cubre además las tres cosas que hay que colocar antes de cargar el peso sobre la IA y la CLI (que los cambios dejen un rastro duradero, que haya un escalón delante de las acciones irreversibles y que el procedimiento esté escrito, porque borrar la interfaz borra también la lista de lo que es posible), una lista de comprobación previa a construir nada y la tercera opción de los productos de herramientas internas como Retool o Forest Admin en lugar de escribir un panel a mano.

El agent view de Claude Code — cómo se ejecutan las sesiones en paralelo y por dónde se escapa el aislamiento

El agent view de Claude Code — cómo se ejecutan las sesiones en paralelo y por dónde se escapa el aislamiento

El agent view de Claude Code, que se abre con claude agents, es la función para lanzar sesiones independientes en segundo plano una tras otra y gestionarlas todas desde una sola pantalla. La documentación oficial llama dispatch a la operación que realizas ahí, y ese nombre choca con la función homónima de la aplicación de escritorio, así que lo primero es distinguirlas. Los documentos describen el agent view como la función que permite despachar y gestionar muchas sesiones de Claude Code desde una única pantalla, y se trata de una research preview que exige la v2.1.139 o posterior. Este artículo se ciñe a la mecánica y al modelo de seguridad. La primera sorpresa es que cada prompt que escribes en el cuadro de entrada arranca su propia sesión nueva: escribe un segundo y tendrás una segunda sesión al lado de la primera, no una instrucción añadida a la anterior. Las instrucciones posteriores pasan por el peek panel, que se abre con la barra espaciadora y muestra la última salida o la pregunta que la sesión está esperando, no la transcripción entera. El corazón del modelo de seguridad es el aislamiento por worktree. Antes de editar ningún archivo, una sesión en segundo plano se traslada a un git worktree aislado bajo .claude/worktrees/, de modo que las sesiones paralelas leen el mismo checkout pero cada una escribe en el suyo: lecturas compartidas, escrituras separadas. Todo lo que llegaría al checkout principal queda cortado por tres comprobaciones: las ediciones de archivos con Edit, Write y NotebookEdit; los directorios de trabajo de comandos que resuelven al checkout principal o que no se pueden verificar como externos a él; y los intentos de redirigir git con git -C, --git-dir, GIT_DIR, GIT_WORK_TREE o un cd colocado antes de la llamada a git. La decisión se toma a propósito del lado seguro, rechazando lo que no puede verificar, y la misma protección la heredan todos los subagentes que la sesión genere. Aun así no es un muro a nivel de sistema operativo: los archivos de fuera del repositorio y la red quedan fuera de alcance, y los comandos de PowerShell solo reciben la comprobación del directorio de trabajo. Los permisos tampoco se eligen en el momento del dispatch: se heredan del defaultMode de ese directorio, o del permissionMode del frontmatter de un subagente despachado, lo que significa que cuanto más laxa sea tu configuración habitual, más sesiones desatendidas con permisos laxos creas de golpe. Después hay tres cosas que se escapan del aislamiento. Elegir "Sí, no volver a preguntar" guarda la regla en el .claude/settings.local.json del checkout principal, así que se aplica en el checkout principal y en todos los demás worktrees, y sobrevive a la eliminación del worktree donde se concedió. Borrar una sesión en el agent view borra con ella el worktree que creó Claude, de modo que el trabajo sin commit desaparece, y Ctrl+X detiene en la primera pulsación y borra en la segunda. Y .worktreeinclude copia en cada worktree nuevo los archivos ignorados por git, como .env, multiplicando tus credenciales por el número de sesiones que despachas. Encima, la cuota se consume en proporción al paralelismo (diez agentes la gastan unas diez veces más rápido) y las sesiones se ejecutan en local: sobreviven a la suspensión, pero se detienen al apagar la máquina. El artículo cierra situando el agent view entre las cuatro formas oficiales de paralelizar, junto a los subagentes, los agent teams y los flujos de trabajo dinámicos, y da una rutina concreta para antes, durante y después de un dispatch.