Manual del Grok Bot, parte 2: 14 usos prácticos de sus nuevas funciones, de Vault y Teach a Task a los bots compartidos

Este artículo es la segunda entrega de una guía en dos partes de Forward Future sobre las funciones recientes de Grok Bot. Cada apartado explica qué hay de nuevo, por qué importa y cómo aprovecharlo, e incluye un prompt de ejemplo. El texto recibido llega cortado en el punto 38, el último caso que aparece, así que este resumen cubre solo los puntos 25 a 38. Las funciones se agrupan en tres bloques: Vault y 1Password, Computer Use con Teach a Task, y Shared Bots con flujos multiagente.

Bloque 1: Vault y 1Password. Según el artículo, Grok Bot incorporó Vault, un almacén de credenciales, métodos de pago y datos de contacto, y amplió su integración con 1Password. La idea central es que el bot pueda trabajar dentro de sitios web autenticados sin que el usuario pegue contraseñas o datos de tarjeta en un chat. El texto lo presenta como más relevante de lo que parece, porque mucho trabajo repetitivo ocurre en webs que no tienen integraciones útiles.

Punto 25: preparar compras y gestionar el checkout. Con Vault, el bot puede rellenar datos guardados en flujos de pago compatibles. Puede buscar el producto, comprobar disponibilidad, preparar el carrito y mostrar el total, con límites de precio, marca y entrega. El prompt propuesto pide detenerse antes del pago y no aceptar sustitutos ni términos adicionales. El artículo hace una advertencia de seguridad. Las tarjetas de Vault pueden usarse sin una aprobación nueva en cada transacción. Quien quiera autorizar cada pago personalmente debe usar un flujo de pago de un solo uso en lugar de una tarjeta guardada.

Punto 26: acceder a sitios web a través de 1Password. Es el caso que el autor considera más convincente, porque no implica gastar dinero. Sirve, por ejemplo, para entrar en el portal de un proveedor, descargar facturas, sacar informes de una cuenta de empresa o recoger datos de un servicio sin API cómoda. El usuario aprueba el inicio de sesión y las credenciales se rellenan en el navegador del bot sin exponerle la contraseña. La integración se despliega de forma gradual y exige una versión compatible de 1Password. Algunos sitios seguirán requiriendo que el usuario tome el control para verificaciones adicionales.

Bloque 2: Computer Use y Teach a Task. Grok Bot puede manejar sitios web y software de escritorio. Teach a Task permite convertir un flujo de navegador demostrado en una habilidad reutilizable. Es útil sobre todo cuando no hay API ni integración lista.

Punto 27: encontrar compradores para algo que se vende. Un usuario describió que usó el bot para vender un dominio. Comparó marketplaces, investigó empresas que podrían quererlo y redactó mensajes personalizados. El prompt pide comparar cinco marketplaces con sus comisiones, identificar hasta 20 compradores plausibles, buscar contactos públicos y redactar un correo por cada uno. También exige enlaces a las fuentes, marcar las coincidencias dudosas y no contactar a nadie ni crear anuncios de pago sin aprobación. El autor recomienda una lista corta de compradores creíbles antes que el envío masivo.

Punto 28: negociar una factura de internet más baja. El artículo cita el ejemplo de un usuario en X (@mikepat711) que pidió al bot negociar con su proveedor a través del chat oficial de soporte. Aportó una factura censurada, explicó qué quería y definió lo que no aceptaría. El bot habría tardado unos 30 minutos y encontrado una oferta que ahorraría unos 58 dólares al mes. El propio texto aclara que es el resultado de una sola persona. Aun si no se consigue una tarifa mejor, el bot puede explicar las opciones y preparar un guion para una llamada posterior.

Selección del equipo: un bot para reclamaciones de seguros de salud. Un miembro del equipo de Forward Future propone un bot que desenmarañe la cobertura del seguro, se convierta en experto del plan y ayude con las disputas de reclamaciones. Debería organizar pólizas, explicaciones de beneficios, facturas y correspondencia, señalar discrepancias, preparar preguntas o borradores de apelación y seguir plazos pendientes. El autor insiste en tratarlo como asistente de análisis documental y administración de reclamaciones, no como intérprete autorizado de la ley de seguros ni de la necesidad médica. También advierte de que hay que ser muy cuidadoso con los datos personales a los que accede.

Punto 29: registrar el teléfono en el registro «Do Not Call». Un emprendedor (@MinimalDuck) pidió ayuda al bot para reducir las llamadas spam. Según el relato, el bot completó el registro en el Registro Nacional de No Llamar de EE. UU., incluido el paso de confirmación. El artículo recuerda que el registro no elimina las llamadas ilegales y que el proceso varía según el país. Recomienda usar solo el registro oficial, donotcall.gov.

Punto 30: que el bot opere otra herramienta de IA. Un usuario habría dirigido desde el móvil cómo Grok Bot instalaba, configuraba y ejecutaba Hermes Desktop en el ordenador del bot, y luego capturaba los resultados. El autor lo trata como un experimento avanzado que, según los informes, es posible pero implica mucho ensayo y error. El prompt sugerido limita la instalación a fuentes oficiales y exige preguntar antes de instalar más software, usar credenciales o iniciar servicios de pago.

Punto 31: enseñar una tarea al bot mostrándosela. Es una de las funciones que más interesan al autor. Teach a Task graba las interacciones del navegador durante un máximo de diez minutos y las convierte en un borrador de habilidad. El artículo menciona que el canal de YouTube de Kevin Stratvert la cubrió con tareas de contabilidad en QuickBooks. El ejemplo es una tarea semanal de abrir un portal de proveedor, descargar un informe, renombrarlo y guardarlo en Drive. Los pasos para empezar son abrir una conversación individual con el bot y la vista de ordenador, elegir Teach a task si está disponible, explicar el objetivo y demostrarlo. Después hay que revisar la habilidad generada, sobre todo el manejo de excepciones, y probarla antes de crear una rutina recurrente. La grabación captura las interacciones visibles del navegador, no el audio del micrófono. La función aún se está desplegando. Si no está disponible, la habilidad puede crearse con instrucciones escritas. El autor aconseja empezar con un flujo simple y predecible, y destaca la función como una forma de bajar la barrera para construir automatizaciones sin tocar APIs.

Bloque 3: Shared Bots y flujos multiagente. Los «Team Bots» aparecieron a finales de septiembre y ahora se llaman Shared Bots. Permiten compartir asistentes especializados con instrucciones, herramientas y conocimiento comunes. El texto advierte de que conviene evitar colecciones elaboradas de bots que pasen más tiempo coordinándose que trabajando.

Punto 32: actualizar el CRM tras cada llamada con un cliente. A partir de una demostración de ventas, el bot extraería de la transcripción nuevos interlocutores, objeciones, compromisos y próximos pasos. Los compararía con el CRM, propondría cambios con referencias a los pasajes de apoyo y prepararía un correo de seguimiento. Nada se escribe ni se envía sin aprobación. El autor pide cuidado con los compromisos y plazos inferidos: si el cliente no aceptó algo de forma explícita, no debe registrarse como decisión confirmada.

Punto 33: emparejar un bot de investigación con uno de contacto comercial. Un testimonio de la empresa Above the Line describe un bot que investiga eventos y decisores y otro que convierte esa investigación en mensajes personalizados. El patrón sirve para clientes potenciales, socios o candidatos. La ventaja es que la investigación puede revisarse y reutilizarse antes de redactar. El consejo es empezar con dos bots, no con cinco.

Punto 34: convertir una solicitud de propuesta (RFP) en una estimación por partidas. Above the Line cuenta que logró en unos 30 segundos un trabajo que antes llevaba mucho más a un productor. El propio artículo aclara que el ahorro real dependerá de cada negocio. El prompt pide usar una tarifa y estimaciones históricas comparables, listar supuestos, exclusiones y riesgos, y tratar todo como borrador hasta que lo revise alguien autorizado.

Punto 35: dirigir los términos de venta inusuales al aprobador adecuado. Un «Deal Bot» revisaría peticiones fuera de lo estándar, como descuentos, condiciones de pago o cambios contractuales. Las clasificaría como estándar, con revisión de finanzas o con revisión legal, y prepararía un resumen para el aprobador. El bot nunca aprueba descuentos ni toma decisiones legales. Solo facilita el proceso.

Punto 36: una cadena de investigación a publicación. Un creador describió cuatro bots. El primero vigila cuentas de X y recopila noticias. El segundo evalúa y redacta. El tercero comprueba que exista aprobación editorial. El cuarto pasa el trabajo aprobado a un agente de programación que prepara la actualización web. Nada se publica sin una decisión humana final. El autor pide mantener una revisión editorial sustancial, porque pasar una noticia incorrecta por cuatro bots no la hace más precisa. Uno de los miembros del equipo destaca el flujo por conectar tareas que suelen tratarse por separado y por poder reutilizarse en boletines, artículos y contenido social.

Punto 37: agrupar tickets de soporte relacionados y preparar respuestas por lotes. El equipo de Grok Bot habría descrito el caso de un ingeniero que aprobó respuestas para 204 tickets en unos diez minutos. El bot agruparía tickets con probable causa común, investigaría y redactaría respuestas coherentes. El autor recomienda ser conservador al agrupar, porque un error enviado a 200 personas es mucho peor que uno en un solo borrador. También avisa de que las cifras son de la propia empresa y deben leerse como ejemplo, no como referencia universal de productividad.

Punto 38: un compañero de IA compartido para ingeniería. El equipo de Grok Bot habría usado un Shared Bot conectado a Slack, Notion, Linear, Datadog y Cursor para seguir debates de proyecto, clasificar errores, crear tickets y lanzar agentes de programación. La empresa afirma que un equipo de cinco personas envió más de 100 pull requests al día durante el proyecto. El texto lo califica como cifra aportada por el proveedor. El contenido recibido se corta justo al empezar el prompt de este punto, así que no hay más detalle ni conclusión final del artículo.

Ideas transversales. Casi todos los prompts del artículo comparten el mismo diseño: tareas acotadas, resultados con fuentes, aprobación humana antes de pagar, enviar, publicar o modificar registros, y prohibiciones explícitas de lo que el bot no debe hacer. Varias cifras llegan de testimonios de usuarios o de las propias empresas, y el autor las presenta con cautela. Para los lectores, la lección práctica es empezar por flujos simples y predecibles, probar antes de programar la rutina y tener presente el acceso a datos sensibles al conectar credenciales, pagos o documentos personales.