Claude Cowork en móvil y web: por qué los equipos deberían rediseñar su marco de agentes

Introducción

La llegada de Claude Cowork a la web y a los dispositivos móviles no es solo un nuevo lugar donde hacer clic en un botón. Es una señal de que los agentes de IA están pasando de conversaciones breves en escritorio a sistemas de tareas de larga duración que pueden continuar trabajando en distintos dispositivos.

Para los equipos de producto, ingeniería y operaciones, la pregunta importante ya no es únicamente si un agente puede completar una tarea. La pregunta más difícil es si el agente puede mantener los límites adecuados mientras trabaja: qué archivos puede leer, qué herramientas puede usar, qué acciones requieren aprobación, qué evidencia debe devolver y cómo los humanos pueden revisar el resultado.

Este artículo explica el significado práctico de ese cambio. Se centra en el diseño del agent harness: la capa que rodea al modelo y que gestiona el contexto, las herramientas, los permisos, el estado, los registros, la validación y el control humano.

Notas sobre la fuente y las imágenes

Página fuente original: Claude Cowork 登上移动端与网页端：团队该重新设计 Agent Harness

La página fuente analizada mostraba una tarjeta SVG predeterminada del blog e imágenes del sitio y del pie de página, pero no capturas de pantalla del cuerpo del contenido, diagramas de flujo de trabajo, capturas de código ni imágenes de resultados que fueran claramente necesarias para el cuerpo del artículo. Para evitar insertar imágenes decorativas o no relacionadas, no se ha añadido ninguna imagen al cuerpo. Si una versión futura de la fuente incluye capturas del producto o diagramas, podrán insertarse cerca de las secciones correspondientes.

Ideas clave

• La expansión de Claude Cowork a escritorio, web y móvil cambia la manera en que los equipos deberían pensar sobre el trabajo de los agentes.
• Un agente que funciona en varios dispositivos no es solo una interfaz de chat. Es un hilo de tareas que puede continuar en segundo plano.
• Los equipos necesitan un agent harness claro: límites de contexto, permisos de herramientas, seguimiento de estado, registros, validación y reglas de aprobación.
• El acceso móvil es útil para revisar el progreso y dar confirmaciones ligeras, pero no debería convertirse en un atajo para saltarse la revisión de código, la aprobación de producción o los controles sobre datos sensibles.
• El mercado en general se está moviendo en la misma dirección: los productos con agentes se están convirtiendo en problemas de ingeniería de sistemas, no solo en problemas de selección de modelos.

Qué cambió

Claude Cowork ahora apunta a un flujo de trabajo en el que una misma tarea puede empezar en un dispositivo y continuar en otro. Un usuario puede asignar trabajo desde un escritorio, revisar el progreso desde un teléfono, responder a una solicitud mientras está lejos del escritorio y más tarde volver para revisar el resultado final.

Eso suena conveniente, pero también cambia el modelo de control. En una ventana de chat tradicional, el usuario normalmente permanece cerca de la interacción. Con un agente en segundo plano, el agente puede seguir usando contexto y herramientas mientras el usuario ya no está observando activamente cada paso.

Por eso, el acceso a agentes entre distintos dispositivos debe tratarse como algo más que una función del producto. Es una cuestión de diseño del flujo de trabajo. La tarea debe llevar consigo sus propios límites, requisitos de evidencia y reglas de aprobación, independientemente de si el usuario está en escritorio, web o móvil.

Por qué esto es un problema de agent harness

Un agent harness es la capa operativa que rodea al modelo. El modelo decide qué hacer a continuación, pero el harness determina qué puede hacer el

qué puede ver el modelo, qué herramientas puede usar, cómo se almacena el estado, cómo se registran las acciones, cómo se gestionan los fallos y cuándo un humano debe aprobar el siguiente paso.

Un modelo potente dentro de un entorno de control débil aún puede crear problemas graves. Puede leer los archivos equivocados, usar una herramienta fuera del alcance previsto, producir trabajo difícil de revisar o actuar antes de que el equipo haya validado el resultado.

Cuando un agente trabaja en varios dispositivos, el entorno de control importa aún más. La tarea puede comenzar en un ordenador de escritorio, continuar en una sesión remota, pedir confirmación en el móvil y luego generar un documento, un cambio de código o un mensaje. El modelo de permisos debe acompañar a la tarea, no al dispositivo.

Un buen entorno de control responde a preguntas prácticas antes de que la tarea comience:

• ¿Cuál es el objetivo exacto de la tarea?
• ¿Qué contexto está permitido?
• ¿Qué herramientas están disponibles?
• ¿Qué acciones están prohibidas?
• ¿Qué resultado se espera?
• ¿Qué validación debe ejecutarse?
• ¿Qué evidencia debe incluirse?
• ¿Qué requiere aprobación humana?
• ¿Cuándo debe detenerse el agente?

El riesgo de los agentes siempre activos

El trabajo en segundo plano es útil. Un gerente de producto puede pedir a un agente que organice comentarios de clientes. Un ingeniero puede hacer que un agente inspeccione registros y sugiera una solución. Un fundador puede pedir un primer borrador de una actualización para inversores mientras viaja.

El riesgo es que un agente pueda seguir actuando después de que el usuario deje de prestar atención de cerca. Eso no es automáticamente inseguro, pero sí requiere límites mejores.

Los equipos deberían separar los permisos de los agentes en categorías claras:

La confirmación móvil puede acelerar el flujo de trabajo, pero no debería sustituir un diseño real de aprobación. Un toque en el teléfono debería confirmar una acción bien delimitada, no conceder acceso amplio a una tarea poco clara.

Lo que los equipos de desarrollo deberían cambiar

1. Definir los límites de la tarea antes de la ejecución

Toda tarea de un agente debería comenzar con una breve descripción de la tarea. Esa descripción debería incluir el objetivo, el contexto permitido, las herramientas permitidas, las acciones prohibidas, el resultado esperado, el método de validación y la condición de detención.

Esto es especialmente importante para tareas de programación. Una solicitud vaga como “arregla este problema” es demasiado amplia para un agente sin supervisión. Una versión más segura nombraría el problema, identificaría los archivos o módulos relevantes, especificaría el comando de prueba y exigiría un diff junto con notas de riesgo.

1. Pedir evidencia, no solo respuestas

Los resultados de los agentes deberían incluir pruebas. Para tareas de código, eso significa diffs, resultados de pruebas, registros de compilación y una breve explicación del riesgo. Para tareas de investigación, significa enlaces a las fuentes, nivel de confianza y aspectos abiertos

preguntas. Para las tareas operativas, esto significa el plan de acción, los sistemas afectados, las notas de reversión y los puntos de aprobación.

El objetivo no es hacer que el agente escriba informes más largos. El objetivo es reducir el costo de revisión.

1. Encaminar las tareas según el riesgo y el costo

No todas las tareas necesitan el modelo más potente ni el presupuesto de razonamiento más amplio. Las tareas de bajo riesgo de formato, resumen y clasificación a menudo pueden ejecutarse con modelos más baratos o más rápidos. Los cambios de arquitectura, las migraciones, la depuración en producción y las tareas sensibles a la seguridad deben usar modelos más potentes y una revisión más estricta.

El enrutamiento de modelos debe formar parte del entorno de ejecución, no ser una ocurrencia tardía. Un equipo que enruta según el riesgo puede controlar el costo sin reducir la seguridad.

1. Limitar la memoria de forma deliberada

Los agentes pueden beneficiarse de una memoria de proyecto estable: reglas del repositorio, comandos habituales, convenciones de nomenclatura, notas de arquitectura y preferencias de estilo.

No deberían almacenar de manera informal secretos, credenciales, datos de clientes, suposiciones temporales ni conclusiones no verificadas. La memoria solo es útil cuando está curada. De lo contrario, se convierte en otra fuente de deriva oculta del contexto.

Una plantilla práctica para el entorno de ejecución

Los equipos no necesitan una plataforma compleja para empezar. Pueden comenzar con una plantilla de tareas sencilla y aplicarla de manera consistente.

task_goal: "Describe el resultado exacto que el agente debe producir."
allowed_context:
- "Enumera las carpetas, archivos, tickets, registros o documentos que el agente puede leer."
allowed_tools:
- "Enumera herramientas como terminal, navegador, gestor de incidencias, documentación o ejecutor de pruebas."
forbidden_actions:
- "No desplegar en producción."
- "No enviar mensajes externos."
- "No eliminar archivos ni datos."
validation:
- "Ejecuta las pruebas o comprobaciones pertinentes."
- "Incluye la salida de los comandos o explica por qué no se pudo ejecutar la validación."
expected_output:
- "Proporciona un diff, un resumen, los riesgos y los siguientes pasos."
human_approval_required_for:
- "Enviar mensajes"
- "Desplegar"
- "Eliminar datos"
- "Cambiar permisos"
stop_condition: "Detente cuando la salida esté lista para revisión humana o cuando falte el contexto necesario."

Para pequeñas correcciones de código, exige una rama local, un diff, la salida de las pruebas y una nota de riesgo. Para informes de investigación, exige fuentes y niveles de confianza. Para comprobaciones de lanzamiento, exige registros de compilación, comprobaciones fallidas e indicaciones de reversión. Para tareas con datos de clientes, exige una nota sobre el alcance de los datos y un plan de enmascaramiento. Para acciones en producción, el agente debe preparar el plan, pero una persona debe ejecutar o aprobar la acción.

Cómo evaluar distintos agentes

Los equipos deberían evitar comparar agentes solo por demostraciones o primeras impresiones. Herramientas como Claude Cowork, Claude Code, OpenAI Codex, GitHub Copilot, Cursor y agentes internos deberían probarse con tareas reales, con el mismo presupuesto de tiempo y los mismos criterios de aceptación.

Entre las preguntas útiles de evaluación se incluyen:

• ¿Puede el agente identificar el contexto correcto sin leer en exceso archivos no relacionados?
• ¿Puede usar las herramientas de forma segura y mantenerse dentro del alcance solicitado?
• ¿Produce cambios pequeños y revisables en lugar de grandes reescrituras poco claras?
• ¿Proporciona resultados de pruebas, citas, registros u otras evidencias?
• ¿Sabe cuándo detenerse y pedir intervención humana?
• ¿Qué tan costosa es la ejecución en tokens, tiempo y esfuerzo de revisión?
• ¿Qué tan difícil es?

¿revertir un resultado fallido?

Ejecuta cada tarea más de una vez. Los agentes son sistemas probabilísticos. Una sola ejecución impresionante no demuestra fiabilidad, y una sola mala ejecución no prueba que la herramienta sea inutilizable. Fíjate en la tasa de finalización, los tipos de fallo, el coste de revisión, el coste por resultado útil y el esfuerzo de recuperación.

Señales del mercado

Claude Cowork forma parte de un movimiento más amplio. Las herramientas de IA se están convirtiendo en sistemas de agentes que combinan modelos, herramientas, permisos, memoria, registros y evaluaciones.

Amazon Bedrock AgentCore muestra cómo las plataformas en la nube están avanzando hacia una infraestructura de agentes gestionada. Los debates de investigación sobre harness engineering apuntan a la misma idea: la capacidad del modelo importa, pero el sistema que rodea al modelo determina si puede usarse de forma fiable. Los materiales de OpenAI sobre Codex también plantean el bucle del agente como un problema de orquestación que implica prompts, herramientas, ejecución y gestión del contexto.

La conclusión práctica es simple: la próxima etapa de los productos de IA no se ganará solo eligiendo el modelo más potente. Los equipos también necesitarán una mejor estrategia de contexto, permisos de herramientas más seguros, registros persistentes, evaluaciones repetibles y un control humano claro.

Plan de acción recomendado

Semana 1: Auditar el uso actual de agentes

Haz una lista de todos los agentes de IA o asistentes de programación que utiliza el equipo. Incluye aplicaciones de escritorio, agentes web, herramientas del IDE, agentes del navegador, bots internos y scripts conectados a APIs de modelos. Para cada herramienta, documenta qué puede leer, qué puede escribir y si puede activar acciones externas.

Semana 2: Clasificar las tareas por riesgo

Separa las tareas en grupos de riesgo bajo, medio y alto.

Las tareas de bajo riesgo pueden incluir formato, resumen y generación de borradores. Las tareas de riesgo medio pueden incluir ediciones de código, transformación de datos o triaje de incidencias. Las tareas de alto riesgo incluyen cambios en producción, manejo de datos de clientes, trabajo de seguridad, cambios de facturación y comunicación externa.

Semana 3: Crear un pequeño benchmark interno

Elige 20 tareas reales del último mes. Úsalas como conjunto de referencia. Incluye tareas exitosas, tareas fallidas, tareas ambiguas y tareas que requirieron corrección humana.

Mide la tasa de finalización, el tiempo de revisión, la calidad de la evidencia, el coste en tokens y la complejidad de reversión. Esto le da al equipo una forma práctica de comparar agentes en lugar de depender de afirmaciones de marketing.

Semana 4: Estandarizar instrucciones y validación

Añade instrucciones del repositorio, plantillas de tareas, comandos de validación, expectativas de registro y condiciones de detención. Haz visible el proceso de revisión. Si un agente no puede mostrar qué cambió y cómo validó el resultado, la tarea no debe considerarse completada.

Preguntas frecuentes

¿Qué es Claude Cowork?

Claude Cowork es el flujo de trabajo de estilo agente de Anthropic para delegar tareas a Claude a través de superficies compatibles como escritorio, web y móvil. Está diseñado para trabajo orientado a resultados, donde Claude puede usar archivos, herramientas y flujos de trabajo conectados, mientras el usuario revisa y aprueba los resultados importantes.

¿Por qué importa Claude Cowork en móvil y web?

El acceso desde móvil y web facilita supervisar y continuar las tareas de agentes fuera del entorno de escritorio. El cambio más importante es que el trabajo con agentes se vuelve más asíncrono, lo que significa que los equipos necesitan reglas más sólidas para permisos, revisión, registros y

validación.

¿Qué es un arnés de agente?

Un arnés de agente es el sistema que rodea al modelo y que gestiona el contexto, las herramientas, el estado, la memoria, los registros, la validación y la aprobación humana. Convierte un modelo, de ser un generador de texto, en un sistema de flujo de trabajo controlado.

¿Es suficiente la confirmación móvil para la seguridad de los agentes?

No. La confirmación móvil es útil, pero solo debería aprobar acciones claramente delimitadas. Las acciones sensibles, como enviar mensajes externos, modificar sistemas de producción, eliminar datos o cambiar permisos, deben seguir requiriendo una revisión explícita y reglas de aprobación bien definidas.

¿Cómo debería un equipo de desarrollo usar agentes de IA de forma segura?

Empiece con tareas acotadas, límites claros de contexto, diferencias revisables, resultados de pruebas y condiciones de detención. Evite el acceso amplio a repositorios, credenciales, datos de clientes o sistemas de producción, a menos que exista un sólido flujo de aprobación.

¿Qué debería devolver un agente después de una tarea de programación?

Un resultado útil de un agente de programación debería incluir los archivos modificados, un resumen del diff, los resultados de las pruebas o de la compilación, los riesgos conocidos y cualquier trabajo de seguimiento. Esto acelera la revisión y reduce la probabilidad de errores ocultos.

¿Cómo pueden los equipos comparar Claude Cowork, Codex, Cursor, Copilot y otros agentes?

Use tareas reales de su propio flujo de trabajo y ejecute cada herramienta con los mismos criterios de aceptación. Compare la tasa de finalización, el costo de revisión, el tipo de fallo, la evidencia del resultado, el costo en tokens y el esfuerzo de reversión, en lugar de basarse solo en una única demostración.

Herramientas relacionadas

• Claude Cowork: Flujo de trabajo con agentes de Anthropic para asignar tareas a Claude en dispositivos y superficies de trabajo compatibles.
• Claude Code: Agente de programación de Anthropic para flujos de desarrollo basados en terminal e IDE.
• OpenAI Codex: Agente de programación de OpenAI para crear, editar, revisar y lanzar software con apoyo de IA.
• GitHub Copilot: Asistente de programación con IA de GitHub para sugerencias de código, chat, revisiones y flujos de trabajo de desarrollo.
• Cursor: Entorno de programación con IA enfocado en edición consciente del código base, chat y desarrollo de software al estilo de agentes.
• Amazon Bedrock AgentCore: Infraestructura de AWS para crear, desplegar y operar agentes de IA a gran escala.

Enlaces relacionados

• Original NxCode Article: El artículo original que inspiró esta versión publicada en inglés.
• Claude Cowork Product Page: Página oficial sobre las capacidades de Claude Cowork, las superficies compatibles y la disponibilidad según el plan.
• Use Claude Cowork Safely: Guía de seguridad de Anthropic sobre permisos, sesiones remotas, inyección de prompts y supervisión humana.
• Amazon Bedrock AgentCore Harness GA: Anuncio de AWS sobre la infraestructura gestionada de arnés para agentes.
• [Harness Engineering for Self-Improvement](https://lilianweng.github.

io/posts/2026-07-04-harness/): La discusión de Lilian Weng sobre la ingeniería de harness y la mejora de los sistemas de IA.

• OpenAI Codex Developers: Página oficial para desarrolladores de Codex como agente de programación.
• Unrolling the Codex Agent Loop: Explicación técnica de OpenAI sobre cómo Codex orquesta las llamadas al modelo, las herramientas, los prompts y el contexto.

Resumen

Claude Cowork expandiéndose entre escritorio, web y móvil es una actualización útil del producto, pero su verdadero significado es más profundo. Los agentes de IA se están convirtiendo en sistemas de tareas persistentes que pueden seguir trabajando fuera de una sola ventana de chat.

Para los equipos, la respuesta correcta no es dar a los agentes una libertad ilimitada. El camino más seguro es la delegación controlada: alcance de tareas limitado, permisos explícitos, resultados revisables, registros persistentes, comandos de validación y aprobación humana para acciones sensibles.

Un buen harness de agentes hace que sea más fácil confiar en el agente porque hace que el trabajo sea visible y auditable. Empieza con tareas pequeñas, mide el rendimiento en flujos de trabajo reales y amplía los permisos solo cuando el proceso de revisión sea lo bastante sólido.

El futuro del trabajo con agentes no consiste solo en modelos más inteligentes. Consiste en un mejor diseño del harness alrededor de los modelos.