Muse vs Dots y Grok Bot: costes, usos y agentes para empresas

No quiero otra IA que me explique lo que tengo que hacer. Quiero una que haga trabajo útil y me deje comprobarlo. Esa es la diferencia que me interesa al comparar Muse de Meta, Dots de ChatGPT y Grok Bot. No quién responde más bonito. Quién puede quitar trabajo de encima sin meterte un problema nuevo.

Mi elección rápida, antes de entrar en detalle:

Es mi orden de evaluación, no un podio de rendimiento. Más abajo tienes conexiones documentadas, costes y escenarios para decidir con criterio.

Si tienes una empresa, seguramente conoces la escena. Abres una herramienta, le pides ayuda, te devuelve una propuesta estupenda y acabas siendo tú quien busca los datos, entra en las aplicaciones, pega el texto, comprueba las cifras y se acuerda de retomarlo mañana. Has tenido una conversación. El trabajo sigue esperándote.

Los agentes persistentes plantean otra cosa: que el encargo siga vivo, tenga herramientas y vuelva con una entrega. Eso puede ser útil para revisar un buzón, preparar un presupuesto, ordenar información de una tienda o mantener una investigación. También puede ser una forma bastante cara de generar más borradores pendientes. La diferencia no la resuelve un vídeo de lanzamiento.

Mi pregunta es esta: ¿qué acaba hecho cuando tú dejas de estar pendiente? Y después vienen otras dos: cuánto te cuesta y qué puede tocar el agente mientras trabaja. Si no tienes respuestas claras a esas tres preguntas, todavía no tienes un sistema. Tienes una suscripción.

Este artículo compara productos, no solo modelos. Muse no es lo mismo que Muse Spark; Dots no es una etiqueta para cualquier conversación de ChatGPT; Grok Bot no es simplemente preguntarle a Grok. Tampoco voy a tratar un asistente conectado a unas aplicaciones como si tuviera acceso ilimitado a todas las herramientas de una empresa. Una cosa es lo que el proveedor documenta y otra lo que funciona, con tu cuenta, en tu proceso.

La comparación está fechada el 6 de octubre de 2026. Los planes, los límites y la disponibilidad cambian. Las cifras que aparecen llevan fuente; donde no he podido contrastar una tarifa oficial, lo digo. No voy a rellenar una tabla con un número que parece razonable solo para que quede completa.

Y una aclaración antes de entrar: esto no es un benchmark en el que haya puesto a las tres herramientas a resolver el mismo trabajo. Es una comparación documental y operativa. Los casos de aplicación son escenarios hipotéticos, diseñados para que puedas convertirlos en una prueba. No son historias de clientes, testimonios ni resultados comerciales que estemos atribuyendo a estos productos.

¿Por qué incluyo Grok Bot? Porque la pregunta útil no es Meta contra OpenAI como si fueran equipos de fútbol. Es qué sistema encaja con el trabajo que necesitas sacar. Dejar fuera una alternativa comparable por no salir en el titular sería hacer una comparación peor. Lo que no haré es mezclar su cuota con la de otros productos de Grok o dar por hecho que compartir marca significa compartir condiciones.

Mi criterio de compra tendría cuatro columnas: trabajo que termina, tiempo que tienes que dedicarle, acceso necesario y coste por resultado aceptado. Las tablas de funciones vienen después. Que una herramienta conecte muchas aplicaciones puede servirte. Que conecte justo la que necesitas, con el permiso adecuado y una salida utilizable, sirve más.

También quiero separar automatización de autonomía. Si cada mañana necesitas copiar unas cifras y aplicar siempre la misma fórmula, quizás no necesitas un agente pensando durante media hora. Necesitas una extracción fiable y una regla. Si el encargo obliga a interpretar documentación, resolver una excepción o preparar una propuesta con contexto, entonces sí merece la pena evaluar un agente. No todo trabajo gana por llevar IA.

La oportunidad está en el recorrido completo: recibir información, convertirla en una decisión, preparar la acción y comprobar lo que pasó. Ahí hay bastante trabajo que una pequeña empresa hoy hace a mano. Si automatizas solo la parte de escribir, el resto sigue siendo tuyo. Si conectas todo sin límites, el riesgo también pasa a ser tuyo.

Por eso el artículo baja a casos concretos. Una consulta comercial que necesita una respuesta. Un anuncio con clics y ninguna conversión atribuida. Una ficha de producto con información contradictoria. Una página que debe cambiar sin perder lo que ya funciona. No porque esos ejemplos demuestren qué marca gana, sino porque obligan a hacer las preguntas que un eslogan esquiva.

Mi posición de partida es bastante clara: prefiero un agente que termine una tarea pequeña, bien, a otro que me prometa dirigir la empresa entera. Después podremos darle más trabajo. Primero que demuestre qué hace con el que ya tiene.

Muse, Dots y Grok Bot: no estás eligiendo otro chatbot

Mi criterio para comparar Muse, Dots y Grok Bot es bastante simple: qué trabajo puedes encargarles, con qué acceso y qué pruebas recibirás cuando terminen. Una entrega revisable pesa más que una respuesta simpática o el nombre del modelo. Si quieres descargar trabajo de una empresa, importa el recorrido entero: recibir el encargo, localizar la información, actuar dentro de los permisos y entregar algo que otra persona pueda revisar sin rehacerlo.

Conviene separar tres cosas que suelen mezclarse en las comparativas. El modelo interpreta y genera. El producto organiza la relación con el usuario y las herramientas. El entorno de ejecución permite hacer el trabajo. Puedes tener una respuesta excelente y ningún archivo aprovechable. Puedes tener acceso a muchas aplicaciones y una tarea mal definida. Incluso puedes recibir un archivo aparentemente correcto cuyo contenido nadie ha contrastado. Son problemas distintos; ponerlos bajo la etiqueta «IA más inteligente» no ayuda a resolverlos.

Qué promete cada producto y qué no demuestra esa promesa

Meta presenta Muse como un agente personal basado en Muse Spark, con una máquina virtual propia, navegador y relación con el usuario mediante WhatsApp. El anuncio explica que puede seguir trabajando con la aplicación cerrada y describe Sentinel como una capa de control para acciones que requieren aprobación, incluidos envíos y pagos. Son características anunciadas por Meta, no una prueba nuestra de fiabilidad. Presentación oficial de Muse.

OpenAI presenta Dots como agentes personales basados en GPT‑6 Astra, disponibles en la nube de forma continuada, con plugins y acceso desde superficies como Slack y Teams. El anuncio habla de 4.000 aplicaciones accesibles mediante el ecosistema de plugins. Para tu empresa, toca comprobar cuáles están disponibles, configurar sus permisos y probar el proceso concreto que quieres delegar. Presentación oficial de Dots.

La documentación de xAI describe Grok Bot con un entorno persistente en la nube, navegador, archivos, terminal, bots que pueden trabajar en paralelo y comunicación en equipo. También contempla aprender mediante demostraciones y skills. El dominio de un procedimiento particular de tu negocio tendría que comprobarse con encargos repetidos; una demostración inicial solo muestra un punto de partida. Documentación oficial de Grok Bot.

Las capacidades de la tabla proceden de las tres fuentes enlazadas arriba. La última columna es mi criterio de evaluación, no una función anunciada por los fabricantes. Esa distinción debería estar en cualquier comparativa seria: una cosa es lo que promete el producto y otra lo que le vamos a exigir para trabajar con él.

La unidad de comparación es un encargo, no una conversación

Imagina una empresa de reformas que quiere preparar la reunión semanal. Es un ejemplo hipotético. El encargo consiste en revisar solicitudes nuevas, detectar presupuestos sin respuesta y entregar una tabla con el siguiente paso propuesto para cada caso. No pide «ideas para vender más». Pide una pieza de trabajo concreta, basada en registros concretos y con un límite: no contactar todavía a ningún cliente.

Para comparar los tres productos, usaría exactamente ese encargo y la misma muestra de información autorizada. Todos tendrían el mismo material: comparar acceso completo con un resumen apresurado distorsionaría la prueba. Mantendría también el resultado solicitado ante un atasco. Si pedimos una tabla utilizable, esa tabla es la entrega; una explicación sobre cómo construirla sirve de apoyo, pero deja el trabajo pendiente.

La prueba debería mostrar también dónde se interrumpió el trabajo. Un agente que detecta que le falta acceso y lo explica con precisión ofrece una información útil. Uno que rellena los huecos con suposiciones produce una tabla bonita y un problema. Prefiero el primero, aunque su respuesta parezca menos espectacular. En operaciones, saber qué no se ha comprobado forma parte del trabajo.

El modelo importa, pero no sustituye el sistema de trabajo

El modelo contribuye a la calidad, y la compra debe evaluar el conjunto. Para una empresa, la pregunta práctica es si permite pasar de información dispersa a un resultado fiable con una supervisión asumible. Si después tienes que buscar cada dato, perseguir los archivos y reconstruir las decisiones, el trabajo sigue ahí. Se ha movido de sitio.

Elegiría primero el proceso que se quiere descargar y después comprobaría qué producto encaja. Un estudio que vive de documentos, una tienda que depende de sus pedidos y una agencia que coordina entregas pueden necesitar accesos y controles distintos. El mismo agente podría resultar útil en un proceso y poco adecuado en otro. El contexto decide.

Mi recomendación es empezar por un trabajo pequeño, recurrente y revisable. Un informe interno con fuentes y errores fáciles de detectar enseña más sobre la utilidad operativa que una demostración abierta donde cualquier respuesta razonable parece un éxito. La comparación empieza a tener sentido cuando puedes señalar la entrega y decir: esto sí nos sirve, esto falta y esto no debía haberse hecho.

Conexiones y ordenador persistente: acceso no significa permiso

Tener un agente que continúa trabajando cambia la forma de delegar. Puedes dejar un encargo y volver después a revisar su resultado. La continuidad exige precisar el objetivo y los límites: qué información puede usar, qué puede modificar y en qué punto debe detenerse. El criterio empresarial se expresa en esas instrucciones y se comprueba en la entrega.

Conectar aplicaciones es preparar el trabajo, no terminarlo

Una conexión resuelve una parte del acceso. Interpretar el negocio requiere reglas. Si una carpeta contiene propuestas antiguas, borradores y documentos vigentes, el agente necesita saber cuál es la fuente válida. Si un contacto aparece duplicado, hace falta una regla para tratarlo. Si dos documentos dicen cosas distintas, la tarea debe contemplar cómo registrar esa discrepancia. De lo contrario, el acceso solo permite encontrar más contradicciones.

En su anuncio para pequeñas empresas, Meta describe conexiones de Muse con activos de Meta y herramientas como Canva, Shopify, QuickBooks, Stripe, Asana y Box, además de conectores personalizados. También indica aprobaciones para publicar, enviar y gastar. El anuncio de esa versión se refiere a Estados Unidos y Canadá; aquí lo usamos para describir su planteamiento, sin trasladar automáticamente ese alcance a otra cuenta o país. Muse para pequeñas empresas.

Yo haría un inventario del proceso antes de conectar nada: dónde llega la petición, dónde está la información válida y dónde debe guardarse la entrega. Parece poco emocionante. Es justo lo que evita que un agente prepare un documento correcto y lo deje en un sitio que nadie consulta. La utilidad depende también de que el trabajo encaje en la rutina del equipo, no de que exista en alguna pestaña.

Las conexiones deberían concederse por necesidad del encargo. «Por si acaso» es un mal motivo para dar acceso a toda una empresa. Mi criterio es que cada permiso tenga una explicación sencilla: necesita leer aquí para obtener este dato; necesita escribir allí para dejar esta entrega. Si no puedes completar esa frase, probablemente estás concediendo acceso antes de definir el trabajo.

Persistencia no es acceso ilimitado a tu ordenador

La ayuda de OpenAI explica que Dots funciona en la nube y que el acceso al ordenador local es opcional y está desactivado por defecto. Distingue, por tanto, el entorno cloud de una conexión local. También advierte de límites del navegador cloud, para los que puede resultar pertinente la opción local. Tener un dot no equivale a darle automáticamente el control de tu equipo. Primeros pasos con tu dot.

Esa separación merece una pregunta propia durante la evaluación: ¿qué puede hacer en el entorno remoto y qué necesita de mi equipo? No porque uno sea necesariamente mejor, sino porque cambia la dependencia operativa. Si un encargo requiere un archivo que solo está en un ordenador, hay que resolver ese acceso de forma autorizada. Si se puede completar con una carpeta compartida y permisos limitados, quizá no haga falta ampliar la superficie.

Persistencia significa continuidad del entorno descrito, no continuidad garantizada de cada tarea. Un sitio puede pedir una intervención, una sesión puede caducar o una fuente puede no estar disponible. Esos son escenarios que conviene probar, no fallos concretos que atribuyamos aquí a estos productos. El contrato de trabajo debe decir qué resultado esperas si aparece un bloqueo: un aviso útil, el avance guardado y la causa concreta, no silencio ni una falsa confirmación.

También separaría memoria y archivo. Recordar una preferencia puede ayudar a redactar; un presupuesto aprobado necesita una versión identificable y consultable. No usaría la memoria del agente como sustituto del archivo empresarial. La ayuda de Dots señala que desconectar una aplicación no elimina la información que el dot ya obtuvo de ella. Conviene consultar la gestión de memoria, no deducirla de una acción sobre la conexión. Ayuda oficial de Dots.

Preparar, aprobar y ejecutar son decisiones diferentes

Yo establecería una frontera entre trabajo interno y acción externa. Revisar documentos, construir una tabla o preparar un borrador puede formar parte de una delegación acotada. Enviar ese borrador a un cliente, publicar en una cuenta o realizar un pago merece un permiso específico. Que el agente haya hecho bien la preparación no le concede por extensión la siguiente acción.

Esa frontera debe poder entenderse sin manual. «Prepara el correo y déjalo pendiente de aprobación» es más claro que «gestiona esta oportunidad». El segundo encargo deja demasiados huecos: ¿contestar?, ¿prometer fechas?, ¿adjuntar documentos?, ¿seguir insistiendo? Cuanto más persistente sea el trabajo, menos conviene confiar en que una instrucción ambigua se arreglará sola.

Pedir confirmación para todo tampoco es buena delegación. Mi propuesta es reservarla para decisiones con impacto y definir de antemano las operaciones internas permitidas. Si autorizas clasificar una carpeta de prueba y generar un resumen, no necesitas revisar cada párrafo mientras se escribe. Sí necesitas revisar el resultado y cualquier salto de alcance. Controlar no consiste en mirar continuamente. Consiste en diseñar bien las fronteras.

Cómo pedir trabajo y evaluar el entregable sin dejarte impresionar

La calidad del encargo condiciona lo que podrás verificar después. Si pides «hazme un buen análisis», estás dejando al agente decidir qué considera bueno y luego intentas discutirle el resultado. Yo prefiero definir la entrega antes de empezar: material válido, objetivo, formato y acciones que quedan fuera. Con eso ya tienes algo que comprobar.

Un encargo que otra persona pueda entender

Este sería un ejemplo hipotético de instrucción para cualquiera de los tres productos, siempre que el acceso correspondiente esté disponible y autorizado:

Revisa los documentos de la carpeta de prueba «Solicitudes revisables». Utiliza solo esos archivos. Prepara una tabla con empresa, necesidad expresada, información que falta y siguiente paso recomendado. Cada necesidad debe incluir la referencia al documento que la acredita. Si dos fuentes discrepan, registra la discrepancia. Guarda la tabla y un resumen de bloqueos en la carpeta «Revisión interna». No envíes mensajes, no modifiques los originales y no completes datos personales por inferencia.

La instrucción no presume que todos los productos tengan esa carpeta conectada ni garantiza que terminen. Sirve para mostrar el nivel de concreción que pediría. Permite detectar un fallo de acceso, uno de comprensión o uno de ejecución sin confundirlos. Si no puede leer los archivos, no estamos evaluando la calidad del análisis. Estamos comprobando una conexión que todavía no funciona para ese encargo.

Añadiría una condición de cierre: la tarea solo termina cuando la tabla está guardada en el destino acordado y el resumen identifica qué se revisó y qué no. «He analizado los documentos» es una afirmación; el archivo accesible y sus referencias son la evidencia. Si el agente no puede guardar la tabla, debe entregar el contenido disponible y declarar ese límite. No debería presentar como completado un paso que sigue pendiente.

Revisa la entrega, no solo el mensaje de cierre

Yo abriría el resultado y contrastaría varias filas con las fuentes. Comprobaría también las omisiones: qué documentos no aparecen, qué campos se han quedado vacíos y qué información se ha convertido en certeza sin respaldo. Una revisión que solo busca errores dentro de lo entregado puede pasar por alto la mitad del trabajo que falta.

El formato debe permitir continuar. Una tabla sin referencias obliga a volver a buscarlo todo. Un informe que mezcla hechos y propuestas exige separarlos antes de decidir. Un archivo guardado con un nombre confuso dificulta recuperar la versión correcta. Referencias, distinciones y nombres claros forman parte del resultado: alguien tendrá que usarlo cuando el agente ya no esté explicándolo.

Para medir utilidad propondría cuatro registros sencillos: tareas completadas con el alcance acordado, tiempo de revisión humana, errores que obligaron a rehacer trabajo y acciones realizadas fuera de permiso. Son indicadores propuestos para una prueba propia, no datos de rendimiento de Muse, Dots o Grok Bot. Publicaría las cifras después de ejecutar y documentar esa prueba.

Repetibilidad: la prueba que separa una demo de una rutina

Una demostración enseña una ejecución. Una rutina necesita repetirse con entradas distintas y seguir respetando los límites. Antes de aumentar la autonomía, cambiaría la muestra: un documento incompleto, dos solicitudes parecidas, una fuente contradictoria y una petición que excede el permiso. No para tender una trampa, sino para comprobar qué ocurre cuando el trabajo deja de venir perfectamente preparado.

Mi criterio sería observar si mantiene el objetivo, si pide una intervención concreta cuando hace falta y si conserva el avance aprovechable. «Necesito ayuda» sirve de poco. «No puedo abrir este documento; he revisado el resto y esta fila queda pendiente» permite intervenir sin empezar de nuevo. La diferencia es operativa, aunque ninguna de las dos respuestas lleve una animación espectacular.

Si una corrección se repite, la convertiría en una instrucción estable y volvería a probarla. No asumiría que el agente ya ha aprendido porque lo afirma. La documentación de Grok Bot contempla demostraciones y skills; comprobar su efecto en un procedimiento concreto seguiría siendo parte de nuestra evaluación. Descripción oficial de Grok Bot.

Elegiría Muse, Dots o Grok Bot por su capacidad comprobada para completar nuestro encargo dentro de sus límites, con una entrega que el equipo pueda aprovechar. Primero un proceso. Después una prueba revisable. Y solo cuando esa prueba aguante, más responsabilidad. Esa es la diferencia entre tener otra IA abierta y empezar a quitar trabajo de verdad.

Ilustración original generada para explicar el concepto; no es una captura de los productos ni evidencia de rendimiento.

Casos comerciales: ordenar leads y preparar presupuestos sin mandar por tu cuenta

Yo empezaría por una bandeja pendiente antes que por un agente intentando dirigir la empresa. Tiene un perímetro claro: averiguar qué ha pedido alguien, qué se le ha contestado y qué falta para avanzar. La dificultad está en leer bien, conservar el hilo y no prometer algo que el negocio no puede entregar.

Los casos que siguen son escenarios hipotéticos, no experiencias de clientes ni resultados de pruebas. La comparación entre Muse de Meta, Dots de ChatGPT y Grok Bot plantea dónde probaría su encaje como agentes persistentes con herramientas. No demuestra cuál trabaja mejor. Cualquier conexión mencionada es una arquitectura propuesta, condicionada a que exista una vía compatible, permisos suficientes y una comprobación de acceso. Una marca en un diagrama no equivale a una integración nativa disponible.

Una consulta entrante que necesita contexto, no una respuesta genérica

Escenario hipotético: una agencia recibe una consulta sobre una web nueva. El remitente menciona que ya habló con alguien, pero no adjunta aquella conversación. Contestar directamente con un catálogo de servicios sería desperdiciar el contexto.

La entrada sería el correo autorizado, el historial de ese contacto y la ficha comercial vigente. Propondría acceso de lectura al buzón y al CRM, limitado al hilo y a los documentos necesarios. El agente tendría que localizar la petición, comprobar si existe una propuesta anterior y separar lo confirmado de lo que falta. Si no encuentra el intercambio previo, lo señalaría; no lo reconstruiría con frases plausibles.

La salida útil es una ficha breve con el servicio solicitado, el interlocutor, el último compromiso y una respuesta completa en borrador. El comercial revisaría destinatario y texto antes de autorizar el envío. Después, el sistema de correo tendría que comprobar que el mensaje exacto figura en Enviados y registrar esa evidencia en la ficha. Esto acredita el envío archivado; no prueba lectura ni interés del destinatario.

El prompt podría ser:

Revisa solo este hilo y la ficha adjunta. Resume la petición y los compromisos anteriores con su fuente. Prepara una respuesta que conteste lo pedido y solicite únicamente el dato imprescindible que falte. No envíes, no cambies el estado del contacto y no prometas plazos sin respaldo. Si hay dos contactos posibles, detente y muestra la ambigüedad.

Mediría borradores aceptados, correcciones relevantes y contactos que realmente avanzan tras la intervención humana. Un formulario recibido cuenta como consulta entregada, no como lead cualificado. La cualificación exige los criterios comerciales del negocio y una decisión registrada; el agente no debe inventarse solvencia o intención de compra.

Si falla el acceso al buzón, usaría una exportación autorizada del hilo. Si el historial sigue incompleto, dejaría un borrador que reconozca el hueco. Para acusar recibo con un texto fijo y crear un registro, elegiría un workflow determinista. No hace falta interpretación para ejecutar dos pasos siempre iguales.

Un presupuesto que respeta lo hablado y deja visibles las exclusiones

Escenario hipotético: una pyme pide renovar su web, conservar contenidos y añadir reservas. El formulario dice una cosa y el correo posterior concreta otra. Aquí pondría a prueba si el agente sostiene contexto entre revisiones, sin confundir un añadido con una condición aceptada.

La entrada incluiría ambos mensajes, el inventario actual, la oferta aprobada y una plantilla de presupuesto. La arquitectura propuesta necesitaría lectura de documentos y del CRM; el archivo de trabajo se guardaría en una carpeta restringida. Ningún acceso a facturación sería necesario para preparar el borrador.

Yo pediría primero una tabla interna: petición, fuente, inclusión propuesta, exclusión y pregunta pendiente. Si el cliente menciona reservas, pero no especifica cómo se gestionan, el agente no debe dar por hecho una pasarela, una aplicación concreta ni una migración sin incidencias. Puede formular una opción provisional, claramente condicionada, para que el responsable decida.

Después produciría el presupuesto y un correo de acompañamiento. Antes de mandarlos, una persona comprobaría alcance, condiciones, identidad del cliente y coherencia entre documento y mensaje. Para explicar qué se está presupuestando, tendría sentido enlazar el trabajo de diseño web en Madrid, siempre que corresponda al servicio solicitado, sin convertir la respuesta en una colección de enlaces comerciales.

Convierte estos mensajes en un presupuesto borrador usando la plantilla aprobada. Conserva literalmente las condiciones confirmadas. Marca cada añadido como pendiente de aprobación y separa lo incluido de lo excluido. No inventes funcionalidades, disponibilidad ni condiciones. Entrega también un correo breve y una lista de contradicciones que debo resolver antes de enviarlo.

La medida sería la fidelidad al alcance: peticiones omitidas, inclusiones no autorizadas y vueltas necesarias para aprobar el documento. Yo revisaría además el archivo final, porque un presupuesto con texto correcto puede tener una página cortada o una exclusión escondida.

Si una plantilla no se puede generar, la alternativa es un borrador editable con los mismos campos, no un PDF vacío presentado como terminado. Cuando el catálogo es cerrado y la propuesta se calcula con reglas inequívocas, dejaría el cálculo y la generación a software determinista. El agente puede interpretar la consulta; no necesita improvisar la aritmética ni las condiciones.

SEO, contenido y web: preparar decisiones que luego se comprueban

Un agente persistente puede tener sentido cuando hay que volver sobre un problema con fuentes distintas y mantener una lista de decisiones pendientes. Yo no le daría una orden abierta de "mejora el SEO". Le daría páginas concretas, datos identificados y una pregunta que tenga respuesta comprobable.

En los tres escenarios hipotéticos siguientes, Google Search Console, Google Ads, Matomo y WordPress aparecen como arquitectura propuesta. Habría que verificar conectores o rutas de acceso, propiedades, permisos y datos disponibles antes de trabajar. Nada de esto presupone que Muse, Dots o Grok Bot traigan esas conexiones de fábrica. Tampoco presupone acceso de escritura.

Una caída de consultas que requiere separar tráfico, medición y ventas

Escenario hipotético: una agencia observa menos solicitudes y quiere saber dónde mirar primero. La entrada sería una exportación de Search Console, datos autorizados de Matomo, registros de formularios y estados comerciales del CRM. Si también hay campañas, incorporaría un informe de Google Ads de solo lectura. Cada archivo llevaría su periodo, propiedad y definición de métricas.

Antes de explicar la caída, el agente comprobaría que los periodos son comparables, que el formulario sigue entregando mensajes y que no se está contando dos veces el mismo contacto. Propondría un identificador técnico de entrega, siempre que la arquitectura lo permita, para conciliar formulario y registro comercial. No asumiría que una visita y un contacto pertenecen a la misma persona sin evidencia y una base adecuada para ese tratamiento.

Ejemplo numérico puramente didáctico: de 12 consultas entregadas, el comercial podría marcar 5 como cualificadas según sus criterios y dejar 7 sin cualificar. Son estados diferentes. Ese reparto inventado para explicar el método no demuestra rendimiento de una agencia, de una campaña ni de ninguno de los agentes.

La salida sería un diagnóstico con hechos, hipótesis y una comprobación siguiente. Para un servicio de SEO en Madrid, prefiero una tarea concreta sobre la página afectada a un informe lleno de recomendaciones aplicables a cualquier web. El responsable aprobaría la investigación o el cambio acotado; cualquier gasto publicitario necesitaría una autorización aparte.

Compara estos periodos sin mezclar clics, visitas, formularios entregados y leads cualificados. Identifica discrepancias y cita archivo, campo y periodo. Propón una causa probable solo si explicas qué evidencia falta para confirmarla. No cambies campañas ni presupuestos. Devuelve una comprobación prioritaria y el criterio que permitiría descartarla.

Mediría primero cobertura y corrección de la medición; después, evolución de consultas y cualificación. La atribución entre canales quedaría limitada a lo que los registros sostengan. Si falta Matomo, no rellenaría sesiones con clics de Search Console. Si hay datos incompatibles, presentaría series separadas y pediría corregir el origen. Para detectar un formulario que deja de entregar, un chequeo técnico programado y determinista suele ser una opción más directa que hacer deliberar a un agente.

Un artículo que empieza por fuentes y termina en una revisión editorial

Escenario hipotético: una empresa necesita explicar un servicio que sus clientes preguntan con frecuencia. La entrada sería un conjunto autorizado de preguntas anonimizadas, documentación del servicio, páginas existentes y fuentes primarias para cualquier afirmación comprobable. El agente recibiría una intención concreta, no permiso para llenar el blog.

Propondría herramientas de lectura, búsqueda y edición de un borrador. Si WordPress ofrece una vía compatible y autorizada, el destino inicial sería un borrador privado; si no, un archivo local. Primero habría que comprobar qué página responde ya a esa pregunta. Crear otro artículo con el mismo propósito puede añadir trabajo sin resolver una necesidad nueva.

La salida tendría un enfoque, un esquema y el texto completo, junto con las afirmaciones que requieren comprobación. El autor revisaría legibilidad y utilidad; el responsable del servicio validaría explicaciones y límites. En salud, usaría material educativo aprobado y preguntas anonimizadas. No entregaría historias clínicas a un agente generalista ni convertiría mensajes de pacientes en ejemplos reconocibles.

Redacta un borrador que responda a esta pregunta usando solo las fuentes adjuntas. Antes, comprueba si alguna página del inventario ya cubre la misma intención. Vincula cada afirmación factual a su fuente; si no hay respaldo, elimínala o déjala como pregunta pendiente. No inventes testimonios ni experiencia propia. Entrega texto completo, enlaces internos pertinentes y comprobaciones previas a publicar.

Tras aprobar el texto, revisaría imágenes, enlaces y render de la página en escritorio y móvil. Publicar requeriría una orden concreta. Después comprobaría el contenido servido, metadatos, canónica e indexabilidad; una respuesta correcta del gestor no demostraría que la página pública quedó bien. La evaluación editorial sería inmediata, mientras que el seguimiento de búsquedas necesitaría sus propios periodos y datos. No atribuiría una subida posterior exclusivamente al agente.

Si una fuente contradice otra, conservaría la discrepancia para resolverla, en vez de mezclar ambas en una explicación segura de sí misma. Si el borrador repite lo existente, optaría por actualizar la página adecuada. Y para aplicar siempre el mismo formato, comprobar campos obligatorios o generar una tabla de contenidos, usaría reglas fijas. La interpretación editorial tiene sitio; repetir una plantilla no exige autonomía.

Una web con un fallo de conversión que exige mirar y tocar con cuidado

Escenario hipotético: un formulario parece funcionar en escritorio, pero la empresa recibe quejas desde móvil. La entrada incluiría las URL afectadas, una descripción del fallo y acceso autorizado al entorno de pruebas. Si hubiera capturas de usuarios, se eliminarían datos personales innecesarios.

Yo dividiría el trabajo en reproducción, propuesta y comprobación. La arquitectura propuesta podría incluir navegador, lectura de errores y edición en un entorno aislado. No daría acceso general a producción para investigar un botón. El agente tendría que identificar dispositivo, tamaño de pantalla, pasos y resultado observado antes de tocar nada.

La salida sería una reproducción documentada y una corrección acotada, con archivos afectados y forma de revertirla. El responsable técnico revisaría el cambio. Tras aprobar el despliegue, tocaría repetir la interacción pública y comprobar la llegada del envío al destino. Si el formulario muestra "enviado" pero el mensaje nunca llega, la prueba ha fallado.

Reproduce el problema en escritorio y móvil dentro del entorno autorizado. No edites hasta identificar el paso que falla. Propón el cambio mínimo, guarda una reversión y prueba también un envío inválido. No despliegues. Entrega la evidencia del fallo, la corrección y el resultado observable en el destino de prueba, sin incluir datos personales.

Mediría rutas probadas frente al inventario afectado, defectos que siguen abiertos y entrega real de los mensajes de prueba. El número de capturas no sería una medida de calidad. Tampoco un test aislado permitiría afirmar que toda la web funciona: habría que declarar qué páginas y estados se han revisado.

Si no se reproduce, recopilaría la diferencia de entorno y dejaría el diagnóstico abierto. Una alternativa segura sería probar el recorrido con datos ficticios autorizados; otra, revisar registros acotados. No inventaría una causa para poder cerrar. Los chequeos repetibles de campos, enlaces y respuesta del formulario los automatizaría con pruebas deterministas. Reservaría el agente para interpretar el fallo, proponer el cambio y leer los resultados sin ocultar los casos negativos.

Tienda online, operaciones y atención al cliente: intervenir sin alterar pedidos a ciegas

En una tienda online en Madrid, yo probaría primero tareas que permitan leer, contrastar y preparar una acción. Cambiar inventario, emitir devoluciones o prometer una fecha de entrega añade consecuencias que no desaparecen porque el agente recuerde la conversación.

Los siguientes son escenarios hipotéticos. Shopify, el sistema de pedidos, el transportista y la bandeja de soporte forman una arquitectura propuesta, sujeta a conectores disponibles, permisos y pruebas. La comparación de Muse, Dots y Grok Bot consistiría en encargarles el mismo recorrido bajo esas condiciones y revisar la evidencia. Hasta ejecutar esa prueba, solo hay un diseño de trabajo, no un ganador.

Un pedido retrasado que necesita una respuesta respaldada

Escenario hipotético: una persona escribe porque su pedido no ha llegado. La entrada sería el mensaje, una referencia de pedido validada por el proceso del negocio y las políticas aprobadas de atención. El agente recibiría acceso de lectura al pedido y al seguimiento disponible, sin facultad para cambiar la dirección o tramitar un reembolso.

El flujo empezaría comprobando identidad y pedido. Después contrastaría el estado de la tienda con la fuente del transportista, incluyendo la fecha de actualización. Si una dice "enviado" y otra no tiene movimiento, el agente recogería ambas. No debe concluir que el paquete se ha perdido ni anunciar que llegará mañana.

La salida útil sería un borrador de respuesta y una incidencia interna con responsable. Atención al cliente aprobaría el texto y la acción: consultar al transportista, pedir un dato o aplicar una política ya confirmada. Si una devolución requiere autorización, quedaría pendiente. Tras enviar la respuesta por una vía autorizada, habría que verificar el registro exacto del envío y la creación de la incidencia.

Consulta únicamente el pedido validado y el seguimiento autorizado. Redacta una respuesta breve que distinga el estado confirmado de lo desconocido. No prometas fechas, no modifiques datos y no tramites devoluciones. Si las fuentes discrepan, prepara una incidencia con ambas evidencias y la siguiente consulta necesaria. Muestra la política que respalda cualquier opción ofrecida.

Mediría casos resueltos, incidencias reabiertas y respuestas que necesitan corrección por una promesa sin respaldo. Contestar rápido no compensaría informar mal. El seguimiento posterior tendría que comprobar si la incidencia avanzó, sin mandar mensajes repetidos cada vez que el estado siga igual.

Si el transportista no responde, la alternativa sería reconocer que no hay información nueva y escalar al responsable. Si no se valida la referencia, el agente no debe mostrar datos de otro pedido por semejanza de nombre. Para notificaciones basadas en un estado inequívoco, como una confirmación de pedido ya pagado, usaría un workflow estable con plantilla aprobada. El agente tendría más sentido en la excepción que necesita interpretar mensajes y reconciliar fuentes.

Un catálogo con discrepancias que requiere corregir la fuente

Escenario hipotético: una tienda prepara productos para publicar y detecta diferencias entre la ficha del proveedor y la hoja interna. La entrada sería el catálogo autorizado, las fichas originales y las reglas editoriales de la tienda. Yo limitaría el acceso al lote seleccionado y pediría un inventario previo de campos, productos y variantes.

La arquitectura propuesta podría leer Shopify o una exportación y guardar propuestas separadas del catálogo público. El agente compararía cada producto por su identificador, registraría el campo en conflicto y citaría ambas fuentes. Si faltan medidas o materiales, no los deduciría de una imagen. Una descripción agradable con una característica inventada sigue estando mal.

La salida sería un lote de borradores acompañado de un informe de diferencias. El responsable de producto validaría características; la persona que gestiona la tienda aprobaría los cambios concretos. La publicación, si se autoriza, necesitaría respaldo previo y una comprobación posterior de fichas, variantes y enlaces. Un fallo parcial obligaría a identificar qué productos cambiaron antes de repetir la operación.

Compara este lote con las fichas del proveedor por identificador exacto. Propón mejoras de redacción sin añadir características. Separa conflictos y campos ausentes; no elijas una fuente por intuición. No cambies precios, stock ni catálogo público. Entrega borradores revisables y una lista de diferencias por producto para aprobar cada cambio.

Como ejemplo numérico didáctico, un lote ficticio de 20 productos podría contener 16 fichas completas y 4 con medidas pendientes. El informe debería conservar ese reparto, no presentar 20 fichas listas porque ha redactado todos los párrafos. Mediría campos respaldados, conflictos abiertos y productos comprobados después de publicar. Ninguna de esas cifras sería una promesa de ventas.

Si no se puede leer el catálogo, trabajaría sobre una exportación autorizada y marcaría su fecha. Si falta la fuente del proveedor, devolvería el lote pendiente, sin rellenarlo. Importar identificadores, validar tipos y sincronizar existencias con reglas conocidas pertenece a un workflow determinista. Yo usaría al agente para explicar discrepancias y preparar decisiones, pero mantendría las operaciones que afectan pedidos y stock bajo controles explícitos. Esa separación es la que probaría con cualquiera de los tres agentes antes de dejarlo trabajando de forma persistente.

Ilustración original generada para explicar el concepto; no es una captura de los productos ni evidencia de rendimiento.

Cuánto cuestan Muse, Dots y Grok Bot: la cuota no es el coste del trabajo

Compararía estas herramientas con la cuenta completa. Una suscripción barata puede salir cara si te obliga a revisar todo dos veces. Una más cara puede tener sentido si resuelve un trabajo que antes consumía varias horas. El importe del escaparate es el punto de partida; la revisión y las correcciones deciden cuánto cuesta usarla.

Mi pregunta sería esta: ¿cuánto nos cuesta obtener una entrega válida, contando preparación, supervisión y correcciones? Una entrega válida. No una respuesta larga ni una carpeta llena de archivos que alguien tiene que ordenar después. Si la empresa compra capacidad de ejecución, el gasto debe compararse con trabajo aprovechable. Lo demás es pagar por actividad.

Precios confirmados y huecos que no vamos a rellenar

Esta tabla recoge importes de fuentes oficiales consultadas el 6 de octubre de 2026. Son dólares estadounidenses y no he añadido impuestos, convertido a euros ni deducido condiciones fiscales. Es una selección de puertas de entrada, no un catálogo exhaustivo ni una comparación de planes equivalentes.

Los niveles de Pro y la condición de Ultrafast proceden de la ayuda oficial de ChatGPT Pro. Los importes de Business y la distinción entre Standard y Premium están en las notas oficiales de ChatGPT Business. Los precios de Cursor figuran en su página oficial de planes.

La página oficial de Muse sí confirma una modalidad gratuita con límite de uso y la opción de contratar una suscripción al agotarlo. No ofrece en el contenido que he podido verificar una tarifa numérica para esa ampliación. Por eso no traslado cifras de prensa a la tabla. Preguntas frecuentes oficiales de Muse.

El anuncio empresarial de Meta sitúa Muse en Estados Unidos y Canadá. Eso no acredita que una empresa española pueda contratarlo hoy con las mismas funciones. Antes de diseñar una dependencia, confirmaría el acceso en la cuenta y el mercado concretos. Anuncio de Muse para pequeñas empresas.

Las condiciones regionales de Dots que aparecen en la tabla y la inclusión del primer dot figuran en su ayuda oficial. El uso y las modalidades disponibles deben comprobarse en la cuenta concreta. Primeros pasos con Dots.

Antes de pagar revisaría la condición aplicable a la cuenta concreta. Si aparece una promoción del primer mes, la anotaría separada del precio recurrente y comprobaría qué ocurre al terminar. Proyectaría el año con ese importe recurrente. «Primer dot incluido» y «primer mes gratis» son condiciones diferentes; cualquier promoción temporal queda pendiente de verificación.

La cuenta completa: cuota, preparación y revisión

El coste total de uso, o TCO, reúne los recursos necesarios para obtener el resultado. En esta comparación yo contaría la suscripción, el tiempo para preparar el proceso, el tiempo de revisión y las herramientas adicionales que hagan falta. Si hay correcciones, también entran. Si un responsable interrumpe su trabajo para desbloquear al agente, ese rato no desaparece porque no llegue una factura.

Un ejemplo didáctico, sin relación con las tarifas anteriores: supongamos una cuota de 100 euros, cinco horas de revisión valoradas internamente a 30 euros, dos horas de preparación al mismo valor y 40 euros de herramientas adicionales. El primer mes suma 100 + 150 + 60 + 40 = 350 euros. Son supuestos para enseñar la cuenta, no mediciones de Muse, Dots o Grok Bot.

Supongamos ahora que el proceso manual sustituido ocupaba veinte horas al mes, valoradas a esos mismos 30 euros. Su referencia sería 600 euros. Frente a los 350 del ejemplo, la diferencia asciende a 250 euros. Es una comparación interna de recursos bajo esas hipótesis; convertir ese tiempo en ahorro efectivo exige que se cumplan y que la empresa utilice la capacidad liberada.

Si la preparación no se repite y el resto se mantiene, el mes siguiente serían 290 euros. La diferencia frente a 600 sería de 310. Conviene señalar esa separación entre puesta en marcha y operación habitual. También evitar una trampa frecuente en las cuentas: descontar las horas de revisión del ahorro y volver a sumarlas al coste. Eso contaría el mismo esfuerzo dos veces.

Tiempo liberado no es facturación conseguida

Las horas recuperadas pueden utilizarse para vender, atender mejor o cerrar trabajo atrasado. Pero no equivalen a ingresos. Si nadie decide qué hacer con ellas, el valor previsto puede quedarse en una hoja de cálculo. Yo dejaría por escrito el destino de ese tiempo: qué tarea humana queremos sacar adelante y quién se responsabiliza de que ocurra.

Antes de comprar un plan superior, comprobaría si el límite que nos frena está en el producto o en nuestra organización. Si el agente espera documentos, permisos o aprobaciones, toca resolver esas esperas. La capacidad adicional merece la pena cuando permite completar más entregas válidas.

Mi unidad para decidir sería el coste por entrega aceptada. Si planteas diez encargos y solo seis sirven sin rehacerlos, no repartiría el gasto entre diez éxitos imaginarios. Revisaría los cuatro fallos y calcularía sobre los seis resultados aprovechables. Es un criterio propuesto, no una tasa de éxito atribuida a ningún fabricante. La diferencia importa: una comparativa útil no maquilla trabajo pendiente como productividad.

Escalar con agentes: más ejecución no significa más clientes

Un agente puede hacer trabajo. Tu empresa tiene que saber recibirlo. Esa segunda parte suele quedar fuera de la demostración y dentro del problema. Si las entregas crecen, alguien necesita revisarlas, incorporarlas al proceso y decidir qué sigue. Multiplicar ejecutores sin preparar esa recepción puede producir una cola más grande, no una empresa que funciona mejor.

Empezaría preguntando qué trabajo puede avanzar sin pisar otro trabajo y cuánto resultado útil puede absorber el equipo. Abrir otro agente es una acción sencilla. Mantener criterio, permisos y versiones entre varios encargos ya exige organización.

El cuello de botella puede estar después del agente

Pongamos otro ejemplo hipotético. Cada día llegan treinta entregas y revisar cada una requiere doce minutos. Son 360 minutos: seis horas de revisión. Si duplicas la producción sin cambiar el procedimiento de aceptación, sesenta entregas exigirían doce horas. No he medido esto en ningún producto; es aritmética para mostrar dónde podría aparecer el atasco.

El problema no se soluciona diciendo que la revisión también la hará una IA. Esa puede ser una opción que evaluar, pero no una respuesta automática. Hay que comprobar qué puede contrastar el segundo sistema, qué información comparte con el primero y quién decide cuando discrepan. Dos textos que se dan la razón no constituyen una comprobación independiente.

Yo separaría trabajos fáciles de aceptar de trabajos que requieren criterio. Una lista de documentos encontrados permite comprobar existencia y referencia. Una propuesta comercial necesita revisar alcance y compromisos. Un borrador destinado a publicarse exige revisar contenido y presentación. No pondría las tres cosas en la misma cola con la misma regla de aprobación.

Puedes ganar capacidad preparando mejor esa recepción. Plantillas de entrega claras, fuentes enlazadas y bloqueos identificados reducen búsquedas innecesarias. Eso no garantiza que desaparezcan errores; permite encontrarlos sin reconstruir la tarea entera. Antes de comprar más ejecución, probaría si el proceso actual está desperdiciando tiempo al revisar resultados mal empaquetados.

Paralelizar trabajos independientes, no responsabilidades difusas

Mi regla sería un responsable por cada resultado y límites claros entre encargos. Si dos agentes pueden modificar el mismo archivo a la vez, necesitas una coordinación específica. Si uno investiga y otro prepara una propuesta, define qué información recibe el segundo y qué datos siguen pendientes. «Colabora con el otro» es insuficiente si ninguno sabe qué versión manda.

Una agencia, como escenario hipotético, podría separar la recopilación de fuentes de la elaboración de una tabla interna. La primera tarea entrega documentos y referencias; la segunda trabaja sobre ese material cerrado. Se puede repartir el trabajo sin permitir que ambos cambien simultáneamente la propuesta final. El reparto depende de las relaciones entre tareas, no de las ganas de llenar la pantalla de agentes.

Reservaría un registro sencillo con encargo, responsable, resultado esperado y estado. No hace falta montar una plataforma nueva para empezar. Sí hace falta poder responder quién está trabajando en qué y qué parte sigue sin comprobarse. Si no puedes responderlo, aumentar la concurrencia introduce confusión donde antes había una tarea pendiente.

También pondría una condición de parada. Un agente no debería insistir indefinidamente cuando falta una fuente o el acceso necesario. Debe conservar el avance y señalar el bloqueo. En un equipo con varios ejecutores, esa información evita que otros sigan construyendo sobre una pieza que todavía no existe. Trabajar en paralelo no elimina dependencias. Solo permite aprovechar las partes que realmente son independientes.

Límites de uso y tamaño de la compra

Cursor explica que Grok Bot está incluido en sus planes de pago y que el uso se organiza con niveles semanales. La documentación contempla la vinculación con SuperGrok y señala que la asignación no se acumula. No trataría esa inclusión como un cheque en blanco para trabajo continuo. Planes de Grok Bot en Cursor.

La semana de uso y el mes de facturación son medidas diferentes. Para decidir, apuntaría cuándo se agota la capacidad, qué tareas quedan pendientes y cuánto valor tienen. No inventaría una equivalencia entre horas humanas, mensajes y capacidad del agente. Si el proveedor mide de una forma y tu negocio necesita otra, hace falta observar el proceso para unir ambas cuentas.

En planes por usuario, la expansión también debe calcularse por personas y duración. Con los importes oficiales de Business Premium, tres usuarios durante doce meses equivaldrían a 3.600 USD con la referencia anual de 100 por usuario y mes, frente a 4.500 USD usando 125 mensuales. Diferencia: 900 USD. Es una cuenta sobre tarifas, sin impuestos ni conversión, no una oferta ni un cálculo de ahorro operativo. Tarifas oficiales de Business.

Para elegir una modalidad anual, comprobaría primero el encaje, las condiciones y la necesidad de esos usuarios. Comprar doce meses de una herramienta que no incorpora tu proceso puede ser más caro que una prueba mensual de mayor importe. El descuento viene después de acertar con la herramienta.

Para ampliar, exigiría una razón concreta: hay encargos aprovechables que esperan por una limitación identificada, y el equipo puede aceptar más resultados. Si lo que faltan son solicitudes comerciales, ampliar agentes no crea clientes por sí solo. Puede ayudar a preparar investigación o materiales; conseguir demanda y cerrar ventas sigue siendo otro resultado que hay que medir.

Permisos y responsabilidad: la autonomía se compra con control

Quiero un agente que avance dentro de un alcance claro y pida aprobación donde corresponde. Eso exige fijar qué puede hacer, qué requiere intervención y qué debe dejar registrado. La autonomía útil tiene una responsabilidad bien repartida: la empresa define la frontera y comprueba que se respete.

El control tiene coste y debe estar en la cuenta. Configurar permisos, preparar un entorno de prueba y revisar acciones consume tiempo. Me parece razonable asumirlo cuando protege un proceso que merece delegarse. Lo absurdo sería omitirlo del presupuesto y presentarlo después como un inconveniente inesperado.

Las reglas del producto no sustituyen tus límites

La documentación de Grok Bot describe modos como «Ask first», permisos concedidos y reglas automáticas para gestionar aprobaciones. Esas reglas no son una garantía de que el modelo decida siempre correctamente. La misma documentación trata los permisos y el manejo seguro de secretos mediante los mecanismos de traspaso previstos. Hay que leer estas condiciones antes de conceder acceso, no después de una acción equivocada. Aprobaciones, seguridad y privacidad de Grok Bot.

Meta presenta el entorno Confidential de Muse como una dirección futura. La evaluación de hoy debe basarse en las protecciones efectivamente disponibles, con su alcance y sus límites. Anuncio oficial de Muse.

Yo empezaría con un permiso de lectura acotado y un destino de escritura interno, si el encargo puede resolverse así. Eso permite evaluar la entrega sin conceder de entrada acciones públicas. Después ampliaría lo necesario. No porque un producto sea sospechoso por definición, sino porque el alcance debería crecer con la evidencia de utilidad y control, no con el entusiasmo del primer día.

Separaría también entornos. Una carpeta de prueba no es el archivo definitivo del negocio. Una propuesta interna no es el documento enviado al cliente. Cuando la prueba exija datos reales, seleccionaría solo los necesarios y comprobaría qué tratamiento admite la empresa. Un ensayo no tiene carta blanca para copiarlo todo.

Aprobar una acción concreta y conservar una salida

Mi criterio para una aprobación sería que mostrase el resultado y el destino. «¿Puedo enviar?» no basta si no sabes qué va a enviar, a quién y con qué adjuntos. La aprobación debería referirse a esa versión concreta. Si el contenido cambia después, cambia también lo que habías autorizado. Lo mismo vale para una publicación o una modificación con impacto en clientes.

Antes de permitir escritura sobre material importante, comprobaría cómo conservar el original y cómo recuperar una versión anterior. No afirmo que todos estos productos ofrezcan el mismo mecanismo. Lo que digo es que la empresa debe resolver esa salida antes de aceptar la acción. Si no hay recuperación y el riesgo es considerable, mantendría el trabajo en borrador.

Las credenciales merecen una frontera aparte. Utilizaría el mecanismo seguro disponible y limitaría el permiso asociado, manteniendo los secretos fuera de documentos compartidos, informes e instrucciones que otros agentes puedan repetir. Si el acceso falla, registraría el fallo sin copiar el secreto para «dejar constancia». La trazabilidad necesita identificar la operación, no exhibir la contraseña.

Cuando una tarea se detenga, pediría conservar los archivos ya preparados y una descripción precisa de lo que falta. Así el equipo puede continuar sin repetirlo todo. Una salida ordenada también forma parte de la calidad: probar un agente no debería dejar una dependencia imposible de deshacer.

Qué exigiría antes de aumentar la autonomía

Antes de aumentar la autonomía, buscaría resultados repetidos, límites respetados y errores que el equipo pueda detectar antes de que afecten fuera. Revisaría también qué pasa ante un bloqueo y si una corrección concreta se mantiene en el siguiente encargo. Eso permite saber dónde funciona y dónde seguimos poniendo revisión humana.

La compra sensata es la que puedes explicar con una tarea, una cuenta y una frontera. Esta herramienta nos entrega esto. El coste completo es este. Puede actuar hasta aquí. Si esas respuestas todavía son vagas, comprar más autonomía no las aclara. Primero arreglaría el proceso. Después decidiría cuánto Muse, Dots o Grok Bot merece entrar en él.

Ilustración original generada para explicar el concepto; no es una captura de los productos ni evidencia de rendimiento.

Qué elegiría yo y cómo comprobaría que merece la pena

Mi primera elección depende del trabajo, no del logo

Para un negocio que concentra su operación en el ecosistema de Meta, pondría Muse en la primera prueba. No porque eso lo convierta en mejor para todo, sino porque el encaje merece comprobarse en el trabajo que ya tienes. Escogería un flujo pequeño: leer información autorizada, preparar una propuesta y dejarla lista para revisión. Antes de pagar o montar dependencias, confirmaría que la cuenta puede usar las funciones necesarias en su mercado.

Para una empresa que ya organiza su trabajo con ChatGPT y necesita continuidad entre encargos, documentos y herramientas, pondría Dots en esa prueba. Miraría especialmente el paso entre el objetivo general y la tarea ejecutable. El agente no tiene que impresionarme diciendo que sabe lo que quiero: tiene que conservar el contexto útil, pedir el dato que falta y devolver el resultado en el sitio donde voy a usarlo.

Si lo que quiero organizar son responsabilidades separadas, rutinas y trabajo coordinado entre agentes, pondría Grok Bot en la prueba. Lo evaluaría con una responsabilidad real y un relevo: que alguien distinto pueda ver el estado, entender qué está pendiente y continuar. Tener varios nombres en pantalla no es un equipo. Repartir trabajo, evitar duplicados y entregar con criterio común sí puede llegar a serlo.

Estas son mis prioridades de evaluación, no una clasificación de rendimiento. No he medido cuál vende más, cuál programa mejor ni cuál comete menos errores. Presentarlo como una carrera ganada sería humo. Sí puedo decir cómo compraría: por el trabajo que puedo comprobar, con los costes y las restricciones encima de la mesa.

No probaría los tres a la vez en producción. Prepararía un mismo paquete con documentos no sensibles, un objetivo y los mismos criterios de aceptación. Si el acceso disponible no es equivalente, lo anotaría: una diferencia de permisos no se debe vender después como una diferencia de inteligencia. Tampoco permitiría que dos herramientas respondieran al mismo cliente o modificaran el mismo proyecto mientras las comparo.

Una prueba pequeña que permite decidir sin autoengañarse

Mi prueba inicial tendría un entregable concreto y una persona responsable. Por ejemplo: un informe sobre una página con sus fuentes, problemas encontrados y propuesta de corrección en borrador. Nada de publicar. Un segundo trabajo podría ser una respuesta comercial preparada a partir de un expediente de ejemplo. Y un tercero, una comparación de un catálogo pequeño con su ficha de referencia.

Definiría qué cuenta como terminado antes de empezar. Para el informe: fuentes accesibles, observaciones que se puedan reproducir, prioridades entendibles y ninguna cifra inventada. Para la respuesta: destinatario correcto, contexto conservado, oferta consistente y un borrador que no requiera rehacerlo entero. Para el catálogo: campos comparados, discrepancias explícitas y ningún cambio fuera del archivo de prueba.

Registraría el tiempo de preparar el encargo, el tiempo hasta la entrega y el tiempo de revisión. Los tres. Si solo mides cuánto tarda en contestar, estás premiando velocidad de redacción. Añadiría los fallos relevantes: un dato supuesto, un archivo que no aparece, una acción no autorizada o un bloqueo que se disimula como si estuviera resuelto. El fallo importa por sus consecuencias, no por lo educadamente que esté explicado.

También probaría una excepción sencilla. Quitar un documento necesario del expediente, introducir dos versiones de un precio o dejar un enlace inaccesible. Quiero saber si el agente detecta el hueco y se detiene donde debe. No me sirve que entregue una respuesta perfecta solo cuando todo está perfectamente ordenado. Tampoco le pediría que resolviera una imposibilidad para luego criticarlo por no hacerlo. El encargo debe ser exigente y realizable.

Al cerrar la prueba, decidiría continuar, cambiar el alcance o descartar. Continuar no significa conceder acceso a todo: significa añadir el siguiente trabajo seguro que aporte valor. Cambiar el alcance puede ser dejar al agente en investigación y usar otro sistema para ejecutar. Descartar puede ser la decisión más rentable si el control cuesta más que hacer la tarea.

La utilidad está en lo que dejas de perseguir

Hay una señal que me interesa especialmente: cuántas veces tienes que volver para recordar lo mismo. Si necesitas preguntar continuamente dónde está el archivo, si se comprobó una cifra o si la tarea sigue abierta, el supuesto asistente te está dando trabajo de coordinación. Esa parte se suele esconder detrás de una respuesta convincente.

Yo quiero terminar con menos cosas pendientes, no con más pestañas. Quiero una propuesta que se pueda leer, una corrección que se pueda probar y un seguimiento que no desaparezca cuando cierro la conversación. Y si no puede seguir, que lo diga con el motivo concreto. Sin inventarse actividad.

Esto también exige ordenar la empresa. Un agente no puede saber qué presupuesto está aprobado si hay varias versiones sin identificar. No puede orientar una campaña hacia el cliente correcto si ni siquiera hemos definido a quién queremos vender. No puede presentar un rediseño como publicado si solo tenemos una propuesta. Parte de la mejora consiste en quitar esas ambigüedades, no en comprar otra inteligencia.

Mi recomendación final sería empezar por un trabajo con valor, contexto y resultado comprobable. Después medirlo. Si funciona, repetir. Si se sostiene, ampliar. El salto de una buena conversación a un sistema útil no ocurre porque el producto se llame agente. Ocurre cuando termina algo que necesitabas y tú puedes confiar en la evidencia que te deja.

Si quieres trasladar estos procesos a una web y a una captación que tengan sentido, puedes ver nuestro trabajo de diseño web en Madrid, SEO en Madrid y tiendas online. La herramienta viene después del objetivo. Primero hay que saber qué queremos que acabe hecho.