Guía de Grok Bot: 50 usos de sus nuevas funciones (Parte I): correo propio, rutinas proactivas y bots verificadores

Aviso previo: el contenido descargado es un fragmento parcial de un artículo de Forward Future cuyo resto está tras un paywall («Keep Reading, Available to paid subscribers»). Este resumen se limita a lo que aparece en la parte accesible, que cubre la introducción, el plan general y los primeros ocho casos de uso de los 50 anunciados.

El artículo, firmado por Nick Wentz y fechado el 5 de noviembre de 2026, sostiene que la novedad más útil, aunque menos llamativa, de las últimas semanas en Grok Bot es que cada bot puede tener su propia dirección de correo electrónico. Con ella se pueden montar flujos que se activan solos. Por ejemplo, si un cliente potencial escribe al bot, este puede investigar la empresa, consultar el CRM y redactar una respuesta personalizada. Un recibo que llega a otro alias puede registrarse como gasto, y un boletín que llega a un tercero puede archivarse para un informe semanal.

Además del correo, el texto menciona otras incorporaciones del último mes: paneles interactivos, una integración más profunda con X, mejor acceso a sitios web y apps móviles, flujos de programación más potentes y nuevas formas de compartir bots especializados dentro de un equipo. El autor afirma que lo valioso llega al combinar estas capacidades. Un bot que lee el correo, cruza el calendario, detecta un compromiso olvidado y redacta el seguimiento es, según él, algo cualitativamente distinto de uno que solo filtra mensajes.

Los 50 casos de uso se agrupan por funcionalidad y no por sector, y cada uno incluye un prompt adaptable. El autor los recopila de lanzamientos de producto, demos y ejemplos de usuarios en X y YouTube. Las diez categorías, con su número de casos, son estas: correo e inbound triggers (5), bot principal proactivo y rutinas (7), búsqueda en X e integraciones de investigación (6), páginas y paneles interactivos (6), Vault y 1Password (2), uso del ordenador y «enseñar una tarea» (5), bots compartidos y flujos multiagente (10), agentes en la nube de Cursor y vídeo (3), voz e integraciones móviles (3) y comercio, integraciones y plantillas (3). El artículo incluye además «Team Picks» del equipo de Forward Future. Advierte también de que no todas las funciones están disponibles para todos: algunas exigen planes o integraciones concretas y otras aún se están desplegando.

Como punto de partida, el autor recomienda no montar de inmediato un equipo elaborado de agentes. Propone elegir un flujo que ya consuma tiempo real y comprobar si el bot lo resuelve de forma fiable. Sugiere cinco casos prioritarios: dar al bot su propia bandeja (#1), un «jefe de gabinete» proactivo (#7), auditar suscripciones (#22), «enseñar una tarea» (#31) y actualizar el CRM tras las reuniones (#32). Para perfiles técnicos recomienda el #43, que delega desarrollo en agentes en la nube de Cursor. Para quien ya ejecuta varios bots, señala el #8, el verificador de automatizaciones.

Categoría 1, correo e inbound triggers. Según el texto, en octubre Grok Bot permitió que los bots tuvieran dirección propia y después añadió alias etiquetados, del tipo tubot+recibos@... o tubot+leads@..., que activan rutinas distintas. El caso 1 propone tres alias: uno para recibos (extraer comercio, fecha, importe y categoría y volcarlos en una hoja de cálculo), otro para leads (investigar al remitente, consultar el CRM y preparar un informe con borrador de respuesta) y otro para investigación (recopilar boletines y resumirlos cada viernes). Recomienda probar cada alias con un correo de prueba antes de reenviar correo real. Pide que el bot incluya enlaces a las fuentes, señale errores y nunca envíe mensajes externos sin aprobación. Hay dos salvedades. Los alias organizan el trabajo entrante, pero no aíslan accesos ni permisos. Y puede que no se pueda cambiar una dirección una vez reclamada, así que conviene elegir bien el nombre.

El caso 2 recoge el ejemplo de Melvin Vivas (@melvindvivas), que usa un filtro de Gmail para reenviar consultas entrantes a su bot. El bot investiga al remitente y su negocio antes de que el usuario abra el mensaje. Puede resumir a qué se dedica la empresa, noticias recientes, el encaje y preguntas útiles, y, con un CRM conectado, comprobar contactos previos. El autor aconseja que la primera versión se limite a investigar y redactar. Matt Berman, del equipo, eligió como favorito un «Lead Bot». El texto subraya que importa darle los criterios reales de calificación.

El caso 3 describe el enfoque de Brian Casel (@CasJam). En lugar de recibir notificaciones constantes, sus bots le envían correos estructurados solo cuando hace falta una decisión. Llevan un asunto fijo y elementos numerados, y él responde qué aprobar, cambiar u omitir. El prompt propuesto genera cada lunes a las 8:00 un único resumen con un máximo de seis decisiones. Cada una incluye recomendación y consecuencia de no actuar. El artículo precisa que el flujo original de Casel usaba un servicio de correo para agentes de terceros. También advierte de que responder a un correo normal no equivale necesariamente a aprobar una acción mediante el sistema de aprobación autenticado de Grok Bot. Matt Berman añade un «Email Triage Bot» como favorito. Clasifica el correo por importancia, señala lo que requiere respuesta y prepara borradores. El consejo es empezar solo con clasificación y borradores, sin dejar que archive ni modifique nada por su cuenta.

El caso 4 trata de unificar mensajes de clientes de varios canales (WhatsApp, SMS, Apple Messages y plataformas de soporte). Según el artículo, Bird lanzó recientemente una integración que enruta los mensajes entrantes a Grok Bot. Cada mensaje puede activar una rutina que identifica al cliente, consulta datos de cuenta o pedido y redacta una respuesta. El prompt exige marcar reembolsos, asuntos legales o de seguridad y cualquier caso fuera de política, y enviar los borradores a aprobación sin responder nunca directamente al cliente. Requiere la integración y los disparadores de eventos adecuados, y se recomienda probar primero con consultas de bajo riesgo.

El caso 5 gira en torno a Alex Finn (@AlexFinn), citado como CEO. Según el texto, usó un bot dedicado para revisar mensajes de patrocinio, detectar oportunidades reales y responder a las legítimas. El artículo afirma que, cuatro horas después de configurarlo, el bot negoció y cerró un acuerdo de 10.000 dólares. Es una afirmación del autor que no podemos verificar de forma independiente. El texto señala que, incluso sin ingresos directos, el bot ahorra tiempo al comprobar si la empresa es legítima, si el producto encaja con la audiencia y si hay presupuesto o brief. El prompt pide ordenar las oportunidades por encaje y potencial comercial, redactar peticiones de aclaración y no aceptar nada sin aprobación. El artículo aclara que la demostración de Finn es anterior a octubre y que las nuevas funciones de correo facilitan montarla.

Categoría 2, bot principal proactivo y rutinas. El artículo explica que el bot principal puede sugerir ayuda por iniciativa propia, y que las rutinas ahora admiten más disparadores y límites de ejecución más altos. El caso 6 recoge el ejemplo de Kris Kashtanova (@icreatelife). Su bot revisa qué comentarios no ha contestado y le envía enlaces directos, pero no responde por ella. El prompt propuesto revisa cada mañana a las 7:30 los comentarios de las últimas 24 horas, agrupa por publicación y prioriza, sin responder, dar «me gusta» ni seguir a nadie de forma automática. Según el texto, según la plataforma puede requerir un conector o automatización del navegador. Brian Knepprath, del equipo, propone una variante multiplataforma que reúne en un solo sitio respuestas, menciones y preguntas dirigidas al usuario, sin que la IA suplante su voz.

El caso 7 propone un «jefe de gabinete» proactivo. Matt Palmer (@mattyp), a quien el texto presenta como trabajador del área de relaciones con desarrolladores en SpaceXAI, contó que su bot detectó que un viaje programado no encajaba con la hora de llegada de su vuelo. También detectó un correo de cambio de horario que no se había reflejado en el calendario. El autor ve una versión aún más valiosa en el seguimiento de compromisos. Se trata de promesas hechas en correos, Slack y reuniones que no llegan a la lista de tareas, y también de las que otros han hecho al usuario. El prompt revisa cada tarde el calendario de mañana, el correo reciente, conversaciones de Slack aprobadas y tareas abiertas. Avisa solo cuando algo lo merezca y distingue compromisos confirmados de inferidos. No envía mensajes ni modifica el calendario sin aprobación. La dificultad principal, según el autor, es calibrar el umbral de avisos para que el bot no se convierta en otra bandeja de entrada. Nick Wentz presenta su variante, el «Commitment Breaker», que prefiere a un resumen diario genérico.

El caso 8, el último visible, propone que un bot se dedique solo a verificar que los demás automatismos hicieron su trabajo. Un usuario de Grok Bot describió, según el texto, un bot verificador que detectó una rutina de sincronización marcada como correcta durante seis días sin escribir datos. El razonamiento es que una rutina puede ejecutarse «con éxito» sin producir el resultado deseado. Una hoja puede actualizarse sin añadir filas, un borrador puede guardarse en el sitio equivocado y una sincronización con el CRM puede dejar de actualizar registros sin avisar. El prompt propuesto revisa cada viernes las rutinas y salidas accesibles, comprueba que el resultado esperado existe y clasifica cada flujo como Verificado, Fallido o No verificable. El texto se corta aquí, antes de terminar el prompt y de llegar al resto de categorías.

En resumen, la parte visible deja un patrón común. Hay que empezar con un flujo concreto y de poco riesgo. Los bots deben redactar y preparar, pero no actuar de forma externa sin aprobación humana. Conviene agrupar las decisiones en pocos avisos y verificar los resultados reales. Los casos 9 a 50, incluidos los de paneles, Vault y 1Password, uso del ordenador, bots compartidos, Cursor, voz, móvil y comercio, quedan fuera del material disponible y no se describen aquí.