Claude Duet: la IA quiere acompañar tu trabajo, incluso cuando cierras el chat

Hay una parte del trabajo que casi nunca aparece en la lista de tareas: acordarse de la propia lista. Comprobar si llegó aquella respuesta, averiguar si un pendiente cambió de responsable, volver a abrir la hoja de cálculo que faltaba completar. Pasas el día ocupado y, cuando te das cuenta, una buena parte se ha ido en buscar el punto donde lo habías dejado.

Quien trabaja en varios frentes conoce esa sensación. El navegador se convierte en una colección de asuntos sin terminar. Cada pestaña promete: “después vuelves aquí”. Algunas llevan tanto tiempo que ya podrían pagar alquiler.

Por eso Claude Duet me llamó la atención. Veo una conversación interesante sobre la continuidad: ¿cómo puede una herramienta acompañar un trabajo a lo largo del tiempo y devolver a la persona aquello que realmente exige una decisión?

Anthropic anunció Claude Duet el 21 de octubre de 2026, como una versión experimental con lista de espera, inicialmente para suscriptores Pro y Max en Estados Unidos. Por tanto, ese anuncio no representa disponibilidad general en Brasil. [1]

Mi análisis parte de la documentación pública. No estoy contando una prueba personal de Duet. Quiero examinar la propuesta desde la perspectiva de quien desarrolla integraciones y necesita encajar la automatización en la rutina.

Qué cambia cuando la conversación continúa

Duet utiliza una computadora en la nube y recursos de la cuenta Claude, incluidos memoria y aplicaciones conectadas, para continuar tareas y avisar cuando necesita al usuario. [2]

Lo que me interesa es el intervalo entre recibir una solicitud y cerrarla. Imaginemos a alguien preparando una propuesta comercial. Tiene parte de los datos, espera una confirmación y necesita un documento. Un resumen bien escrito ayuda, pero el trabajo sigue abierto después de que ese resumen esté listo.

Yo evaluaría un asistente de este tipo por su capacidad para seguir esas dependencias. ¿Identificó lo que faltaba? ¿Dejó claro quién debe actuar? ¿Distinguió el documento recibido de la versión aprobada? ¿Pudo retomar el asunto sin obligar a la persona a contar toda la historia de nuevo?

Ese sería un avance útil: reducir el esfuerzo de reconstruir el contexto cada vez que se retoma algo. También es una expectativa exigente. Un asistente que mantiene una lista ordenada, pero pierde el motivo de cada pendiente, termina devolviendo la organización al usuario.

La mirada de quien desarrolla integraciones

Mi trabajo con Oombe incluye automatización de marketplaces y necesidades relacionadas con Mercado Livre, Shopee, publicación y transferencia de anuncios, catálogos, compatibilidades y pagos. Esa experiencia me lleva a prestar mucha atención a lo que ocurre entre una solicitud y un resultado comprobado.

Pensemos en un cambio de catálogo. Existen la solicitud inicial, la identificación de los artículos, la regla aplicable, el procesamiento y la comprobación. Según el caso, todavía puede haber alguna excepción que requiera una persona. Cada etapa lleva información que debe llegar a la siguiente.

Cuando observo agentes que acompañan el trabajo, veo una posibilidad interesante de ayudar a organizar esa capa de pendientes. La pregunta que haría sería: “¿puedes devolverme una visión verificable de lo que necesita atención?”.

Fíjate en la exigencia de la palabra verificable. Me gustaría saber de dónde salió la información, a qué momento se refiere y qué falta confirmar. Un texto convincente sin esos elementos me añadiría otra etapa de investigación.

Eso no significa que exista una integración nativa de Duet con Oombe o con Mercado Livre. Los ejemplos siguientes son hipótesis de trabajo, condicionadas a acceso autorizado, herramientas compatibles y pruebas. Sirven para explicar qué buscaría en un piloto.

Tres situaciones en las que buscaría utilidad

Reunir los pendientes de una operación

Empezaría por algo delimitado: una exportación autorizada de registros, preparada para el análisis, con los datos necesarios para la tarea. Pediría organizar los pendientes por motivo, indicar qué información falta y producir una lista de comprobación.

Imaginemos registros con observaciones sobre datos incompletos, información divergente y validación pendiente. Un buen análisis conservaría el identificador de cada elemento y señalaría la evidencia utilizada para agruparlo. Cuando no hubiera información suficiente, el resultado esperado sería marcar la duda.

A partir de ahí, podría evaluar si la organización me ayudó a elegir por dónde empezar. Sería especialmente útil identificar varios registros relacionados con una misma causa posible, siempre que la hipótesis siguiera identificada como hipótesis. El beneficio estaría en facilitar la investigación, sin convertir la semejanza entre textos en un diagnóstico confirmado.

Preparar una respuesta que alguien pueda revisar

Otro experimento posible consistiría en proporcionar una solicitud y un conjunto autorizado de información para preparar una respuesta. Pediría que el borrador separara lo confirmado de aquello que requiere verificación y destacara cualquier compromiso de plazo.

Ese detalle importa. “Lo estamos revisando” y “estará resuelto mañana” generan expectativas muy distintas. Al revisar, necesitaría identificar rápidamente qué afirmación tiene respaldo y cuál exige una decisión mía.

También evaluaría si el texto responde a la duda de la persona. Un borrador puede tener una gramática impecable y seguir evitando el asunto. En ese caso, el pulido solo habría vuelto más engañosa la revisión. El objetivo del piloto sería obtener una respuesta útil, con lenguaje humano y hechos comprobables, antes de cualquier envío autorizado.

Retomar un asunto sin empezar de cero

Una tercera hipótesis sería acompañar una pequeña solicitud con cambios de estado: documento solicitado, material recibido, revisión en curso, duda devuelta. Definiría esos estados previamente y pediría un resumen de los cambios relevantes.

El resumen debería decir qué cambió desde la revisión anterior. Repetir todo cada día puede crear una rutina cansada, especialmente cuando el usuario tiene que descubrir por su cuenta qué línea contiene la novedad.

También pediría que los pendientes antiguos siguieran visibles hasta que hubiera un motivo para cerrarlos. El silencio de una conversación no resuelve automáticamente el asunto. A veces solo significa que todos están esperando que alguien más responda.

Conectar aplicaciones es una decisión de ingeniería

Antes de cualquier piloto, haría un pequeño mapa: qué información entra, por qué camino, quién puede verla y qué resultado debe salir. Esa conversación suele ser más útil que empezar preguntando cuántas aplicaciones puede conectar la herramienta.

Para mí, una integración debe responder preguntas concretas. ¿El acceso permite consultar o también modificar? ¿El archivo contiene información suficiente? ¿Existe un identificador estable? ¿Cómo reconocer que el análisis utilizó una versión antigua? ¿Quién comprueba el resultado?

Si el piloto depende de exportaciones, definiría su frecuencia y formato de actualización. Si depende de un conector, comprobaría las operaciones realmente disponibles. Si incluye navegar por una interfaz, verificaría las condiciones y limitaciones de ese camino antes de asumir que sirve al proceso.

El mismo cuidado se aplica a automatizar una decisión. Empezaría manteniendo las reglas objetivas en un lugar donde puedan comprobarse: criterios de agrupación, prioridades y condiciones de cierre. La contribución de la IA se evaluaría dentro de ese diseño.

Es un trabajo de traducción entre necesidad y funcionamiento. Quien conoce la operación tiene un papel central en esa conversación, porque sabe qué significa cada campo y qué situaciones parecen iguales en pantalla, pero requieren tratamientos diferentes.

Una memoria útil necesita contexto actualizado

Me gustaría que un asistente recordara las preferencias de presentación y el avance de las solicitudes. Al mismo tiempo, trataría las reglas que cambian como información que necesita fecha y revisión. Una indicación antigua puede seguir sonando perfectamente razonable después de dejar de servir al proceso.

Por eso, en un piloto, registraría el origen de las reglas y cuándo deberían comprobarse de nuevo. También separaría preferencias personales, instrucciones de una tarea y criterios permanentes de la operación. Esa distinción ayuda a decidir qué debe acompañar al siguiente trabajo.

Hay un detalle concreto en la documentación: desconectar una aplicación interrumpe nuevos accesos, pero no borra automáticamente lo que ya entró en la memoria; el usuario puede restablecerla. [3]

Incluiría esa comprobación al cerrar cualquier experimento. Probar una herramienta también implica entender cómo retirar accesos y limpiar el contexto que dejó de tener sentido.

La aprobación debe ayudar a decidir

Anthropic describe aprobaciones para acciones relevantes, una comprobación externa al modelo y protecciones todavía sujetas a errores. [3]

En mi diseño del piloto, una aprobación útil mostraría exactamente la acción propuesta, su destino y la información utilizada. Necesitaría entender la consecuencia antes de confirmar, sin reconstruir todo el trabajo.

Si un mensaje está listo para enviarse, quiero revisar el destinatario y el texto. Si la propuesta es actualizar un registro, quiero comparar el estado actual con el cambio sugerido. Si falta información, prefiero recibir la pregunta concreta que permite avanzar.

También definiría qué decisiones deben llegar hasta mí. Cuando todo pide atención, cuesta reconocer lo que realmente importa. Esa rutina debería proteger el tiempo de quien revisa y conservar una posibilidad real de decir: “espera, esto debe cambiar”.

Cómo organizaría un primer piloto

Elegiría un único proceso, con principio, final y responsable claros. Reunir los pendientes de una exportación sería un buen candidato inicial. “Organizar toda la empresa” haría imposible evaluar el resultado y daría a la herramienta demasiado espacio para interpretar el objetivo.

Antes de empezar, haría una ronda con el método habitual y anotaría el trabajo necesario: localizar archivos, comprobar campos, agrupar elementos, revisar conclusiones y preparar la siguiente acción. Eso crearía una referencia concreta.

Después, prepararía los datos de prueba y definiría el resultado esperado. Por ejemplo: una relación de pendientes con identificador, motivo, evidencia, siguiente acción sugerida e indicación de duda. Si el caso exige interpretación, dejaría explícito que la herramienta debe presentar alternativas en vez de elegir en silencio.

La primera revisión tendría dos preguntas: ¿puedo rastrear cada conclusión hasta el material proporcionado? ¿El resultado está listo para el uso acordado? Un informe puede ser correcto y aun así exigir tantos ajustes de formato que la tarea siga casi entera en manos de la persona.

En la siguiente ronda, añadiría una pequeña actualización al mismo proceso. Así evaluaría la continuidad: ¿el asistente detectó el cambio, conservó lo que seguía pendiente y evitó repetir lo que ya estaba resuelto?

Por último, documentaría las excepciones encontradas y decidiría si merece la pena ampliar la prueba. Esa ampliación debería seguir lo demostrado. Si la herramienta organizó bien los archivos, el siguiente paso puede ser otra tarea de organización. Modificar precios o comprometer plazos requiere una evaluación propia.

El reloj también debe contar la revisión

Mediría el tiempo total que dedica la persona a llegar a un resultado aprovechable. Entrarían en la cuenta la preparación del material, las instrucciones, la comprobación, las correcciones y el seguimiento. El tiempo de procesamiento de la herramienta se registraría por separado.

También observaría la calidad de las interrupciones. ¿Qué avisos ayudaron a actuar? ¿Cuáles sobraban? ¿Hubo algún pendiente importante que solo apareció cuando la persona volvió a investigar manualmente? La experiencia debe reducir la carga de seguimiento, además de producir documentos.

El producto tiene límites concretos: el trabajo en segundo plano consume la cuota compartida del plan, las comprobaciones ocurren a intervalos y la herramienta puede interpretar mal la urgencia. [4]

Tendría en cuenta esas condiciones al planificar. Un proceso que exige respuesta inmediata necesita un mecanismo adecuado a ese plazo. Una revisión periódica de pendientes puede tolerar otra frecuencia. La elección depende del trabajo y debe quedar clara antes de que alguien empiece a confiar en ese seguimiento.

El conocimiento de la operación adquiere otra función

La parte de esta conversación que más me entusiasma es transformar la experiencia en orientación utilizable. La persona que conoce la rutina puede explicar por qué un pendiente merece prioridad, qué evidencia confirma una conclusión y cuándo una excepción debe derivarse.

Ese conocimiento ayuda a diseñar el piloto, evaluar los resultados y mejorar la automatización. Para desarrolladores e integradores, veo espacio para construir esas transiciones con criterios claros, datos bien definidos y resultados que puedan comprobarse.

Voy a seguir Claude Duet desde ese ángulo: ¿cuánta organización y continuidad puede asumir de forma útil, dentro de las condiciones que ofrece?

Para mí, un buen resultado sería terminar el día con menos asuntos abandonados entre pestañas, mensajes y archivos, sabiendo qué se hizo y qué sigue necesitando de mí. Ya sería una buena ayuda. Y quizá permitiría cerrar algunas de esas pestañas que están a punto de firmar el contrato de alquiler.

Fuentes

[1] Anthropic. Introducing Claude Duet. Publicado el 21/10/2026.

[2] Anthropic. Claude Duet: página oficial del producto.

[3] Anthropic. Claude Duet Safety, Privacy, and Security. Publicado el 23/10/2026.

[4] Claude Help Center. Get started with Claude Duet.

Documentación consultada el 25/10/2026. Las funciones y condiciones de la versión experimental pueden cambiar.