Cómo construir tu asistente personal IA paso a paso con Claude Code, MCP y un bot de Telegram (tutorial 2026)

Por el equipo de Kiwop · Agencia Digital especializada en Desarrollo de Software e Inteligencia Artificial aplicada para clientes globales en Europa y USA · Publicado el 19 de abril de 2026 · Última actualización: 19 de abril de 2026

TL;DR — Tutorial paso a paso para montar tu asistente personal IA sobre Claude Code MCP como stack base: cuatro canales (IMAP, Gmail, Slack, Telegram), briefings automáticos a las 08:00 y 19:00, bot bidireccional y comandos slash. Unas 500 líneas de Python, cero dependencias de pago más allá de la suscripción Claude Max x20. Setup completo en 60-90 minutos siguiendo los pasos.

Este es el segundo artículo de la serie sobre el PA de Kiwop. El primero, De OpenClaw a PA con Claude Code y MCP, explica por qué lo construimos tras el cambio de política de Anthropic del 4 de abril de 2026. Este tutorial muestra cómo lo construimos, con el código real que tenemos en producción desde hace dos semanas. Al terminar, tendrás un asistente personal IA funcional en tu máquina, con la misma arquitectura que usamos a diario en la agencia. El repositorio de referencia está en https://github.com/purroy/majordomo.

No es una demo de juguete. Procesa correo de producción, agenda real, mensajes de Telegram desde el móvil y briefings que aterrizan a las 08:00 y las 19:00 sin intervención humana. La filosofía es minimalista a propósito: cada pieza hace una sola cosa, el pegamento entre piezas es Unix, y los secretos nunca tocan el disco en claro.

Qué vas a construir

Al final del tutorial, tu PA tendrá cuatro canales operativos y una arquitectura deliberadamente simple.

Los cuatro canales activos del PA son:

• Correo IMAP/SMTP propio: para el buzón corporativo de tu dominio (mail.tuempresa.com), leído con scripts Python sobre la librería estándar de Python. Lectura, triaje, redacción y envío con confirmación explícita.
• Google Workspace (Gmail + Calendar + Drive): a través de los MCP servers oficiales — puedes añadir otros similares como Outlook/Microsoft 365 si tu organización lo usa.
• Slack: DMs y menciones, vía MCP server oficial de Slack para Claude.
• Telegram: un bot bidireccional que es a la vez canal de salida (briefings) y de entrada (hablas con el PA desde el móvil).

El stack técnico son cuatro capas. Claude Code como motor conversacional. Conectores MCP para todo lo que tiene uno oficial (Google + Slack). Scripts Python propios para los huecos que MCP no cubre (IMAP y Telegram). Y launchd (en macOS) o systemd/Task Scheduler (en Linux/Windows) para el arranque y los disparadores programados.

El coste marginal real es cero sobre la suscripción Claude Max x20 que ya pagas para desarrollo. Las ~500 líneas de Python son tuyas — ninguna dependencia instalable, solo librería estándar. No hay backend, no hay base de datos, no hay Docker. Todo el estado persistente vive en archivos locales y en el llavero del sistema operativo.

A alto nivel, la arquitectura sigue tres principios que conviene explicitar antes de meternos en el código. El primero es que Claude Code es el motor pero no es el dueño del estado: tus prompts están en archivos Markdown versionables en tu propio repositorio, tus secretos están en el llavero del sistema, tus briefings son archivos en disco. Si mañana quisieras cambiar de motor, solo tendrías que sustituir las llamadas a claude --print por otra CLI equivalente. El segundo es que MCP hace el trabajo pesado cuando existe un servidor oficial (Google, Slack) y escribes código solo cuando no lo hay (IMAP, Telegram). El tercero es que la seguridad vive en tres capas independientes — OAuth del MCP, Keychain de macOS y regla de confirmación en prompts — de modo que comprometer una no compromete el sistema.

Prerequisitos y coste real

Antes de empezar, revisa que tienes lo que hace falta. El tutorial asume macOS porque es lo que usamos nosotros, pero hay una sección al final sobre cómo portarlo a Linux o Windows.

Requisitos de cuenta y suscripción:

• Claude Max x20 de Anthropic: la suscripción "for power users", unos 200 USD/mes. Claude Code viene incluido y es el motor del PA.
• Cuenta de Google Workspace con permisos para autorizar Gmail, Calendar y Drive vía OAuth.
• Workspace de Slack donde tengas cuenta (no hace falta ser admin para el MCP de lectura de tus propios DMs y menciones).
• Un dominio de correo sobre IMAP si tu buzón principal no es Gmail (opcional — si todo tu correo es Gmail, sáltate el Paso 3).
• Cuenta de Telegram (gratuita) para crear el bot vía @BotFather.

Requisitos de sistema:

• macOS 14+ con Homebrew instalado (para el flujo base del tutorial).
• Python 3.11+ (viene con macOS reciente; si no, brew install [email protected]).
• Claude Code CLI instalado: npm i -g @anthropic-ai/claude-code o vía brew.
• Terminal con permisos de Full Disk Access si quieres que launchd pueda correr los briefings sin pedir autorización repetida.

Coste mensual proyectado, desglose honesto:

El punto clave: el coste marginal del PA es cero si ya tienes Claude Max. Si no la tienes y solo la comprarías para el PA, el cálculo cambia — tendrías que valorar si el ahorro de tiempo te compensa 200 USD/mes. Para cualquier persona que ya use Claude Code en desarrollo, la respuesta suele ser sí de forma trivial.

El tiempo estimado para completar el tutorial desde cero, contando los OAuth y el debug inevitable, es de 60 a 90 minutos. Si solo quieres los tres primeros canales (sin Telegram ni briefings programados), bajas a 30-40 minutos.

Paso 1: Estructura base del proyecto

El PA vive en un directorio propio fuera de cualquier otro proyecto. La primera decisión es dónde ubicarlo. Nosotros usamos ~/Dev/PA por convención — sustitúyelo si prefieres otra ruta. El repositorio completo de referencia está en https://github.com/purroy/majordomo — úsalo si te pierdes en algún paso.

El .gitignore debe excluir cualquier cosa con datos personales — briefings, borradores de correo, estado del bot:

Ahora el archivo más importante del repositorio: CLAUDE.md. Define la persona del asistente, idioma por defecto, y la regla de confirmación que es el corazón de la seguridad del PA.

La regla de confirmación es innegociable. Diferencia un PA que puedes dejar en manos de un modelo de lenguaje de uno que te va a enviar un correo embarazoso cuando malinterprete un "sí" de hace dos turnos. La hemos probado durante todo marzo sin un solo falso positivo.

Commit inicial:

Paso 2: Conectar MCP servers

MCP ([Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25)) es el estándar abierto que Anthropic publicó a finales de 2024 para que los modelos de lenguaje se conecten a herramientas externas de forma uniforme. Un MCP server es un proceso que expone un conjunto de funciones (leer correos, buscar archivos, enviar mensajes) a través de un protocolo común; un MCP client (como Claude Code) lo arranca y consume esas funciones como si fueran herramientas propias. Si quieres profundizar en por qué MCP es la pieza que desbloquea los agentes IA en 2026, tenemos un análisis más amplio en WebMCP: tu web preparada para agentes IA.

Para el PA activamos cuatro MCP servers oficiales, los cuatro publicados por Anthropic/Claude o por los propios proveedores:

• Gmail MCP: lectura, búsqueda y composición de correos.
• Google Calendar MCP: agenda, creación y modificación de eventos.
• Google Drive MCP: búsqueda y lectura de archivos.
• Slack MCP: lectura de DMs, canales y envío con confirmación.

La forma más sencilla de configurarlos es a través de la interfaz de Claude Code. Desde la raíz del proyecto (~/Dev/PA), lanza:

Dentro de la sesión interactiva de Claude Code, añade los MCP servers con el comando /mcp add para cada uno. El comando te lanzará el flujo OAuth correspondiente en el navegador — autoriza con la cuenta que quieres que use el PA, no necesariamente tu cuenta personal principal.

Seguridad del flujo OAuth. Un aspecto clave: los MCP servers oficiales usan OAuth del navegador, no credenciales en disco. Tu refresh_token lo guarda el MCP server en sus propios almacenes cifrados, no el PA. Eso significa que si alguien roba tu .claude/ o tu repositorio, no se lleva acceso a tu Gmail — tendría que comprometer además el almacén del MCP server y, en última instancia, tu llavero macOS. La superficie de ataque queda acotada.

Una vez autorizados los cuatro, comprueba que Claude Code los detecta:

Deberías ver las herramientas disponibles agrupadas por servicio: mcp__claude_ai_Gmail__search, mcp__claude_ai_Google_Calendar__list_events, etcétera. La nomenclatura sigue el patrón mcp__<server>__<tool>.

En este punto ya puedes preguntarle al PA "¿qué tengo hoy en el calendario?" o "busca en Drive el contrato con el cliente X" y funciona. Lo que falta son los dos canales que MCP no cubre bien: el correo IMAP corporativo y Telegram.

Paso 3: Scripts Python para IMAP y Keychain

Si todo tu correo está en Gmail, este paso es opcional. Si, como nosotros, el buzón principal corre sobre un servidor IMAP propio (mail.kiwop.com en nuestro caso), toca escribir el puente.

La arquitectura de los scripts es deliberadamente pequeña. Un módulo interno _mail.py con la lógica común (conexión IMAP, parseo, SMTP), y tres comandos mínimos que el PA puede invocar:

• mail_fetch.py: lista UIDs recientes o no leídos como JSON.
• mail_read.py: lee el cuerpo completo de un UID (sin marcarlo como leído — usa BODY.PEEK).
• mail_send.py: envía un correo o lo guarda como borrador.

Regla de oro sobre credenciales. Nunca guardes la contraseña IMAP en un archivo del repo ni en una variable de entorno persistente tipo ~/.zshrc. El riesgo no es teórico: cada vez que compartes un script, haces un commit con .env trackeado o instalas una extensión de VS Code que lee tu entorno, estás exponiendo secretos. En macOS tenemos Keychain, un llavero cifrado del sistema operativo accesible vía el comando security. Los scripts leen la credencial al vuelo cuando la necesitan y jamás la escriben en disco.

Primero, guarda las credenciales en Keychain:

Los puertos habituales: 993 para IMAP sobre SSL y 587 para SMTP con STARTTLS. Si tu proveedor usa SMTPS implícito, cambia a 465.

Ahora el helper shell que lee y escribe en Keychain. Lo llamamos scripts/keychain.sh:

El equivalente Python usa subprocess para invocar security:

El fallback a variable de entorno es deliberado: cuando portes esto a Linux (systemd), ahí security no existe y usarás env vars exportadas desde el unit file, leídas desde un archivo con permisos 600.

Con Keychain conectado, el mail_fetch.py queda claro. Es un CLI que imprime JSON para que Claude Code lo parsee fácilmente:

mail_send.py añade una salvaguarda importante: sin el flag --yes, guarda el mensaje como .eml en drafts/ y no lo envía. Solo con --yes explícito sale por SMTP. Esto aplica la regla de confirmación del CLAUDE.md a nivel de código, no solo de prompt — incluso si el modelo se saltara la regla, el script no enviaría.

Detalle crítico sobre `BODY.PEEK`. Cuando el PA "lee" un correo para triarlo, no debe marcarlo como leído. Si lo marcas, pierdes tu bandeja de pendientes como señal visual en el cliente de correo. La bandera IMAP que setea \Seen es BODY[]; la que no la setea es BODY.PEEK[]. Úsala siempre en mail_read.py.

Paso 4: Bot de Telegram con sesión persistente

El bot de Telegram es la pieza más interesante del PA porque invierte el flujo: en vez de que tú abras un terminal y escribas a Claude, Claude recibe tus mensajes desde el móvil.

El plan: un daemon Python que hace long polling contra la API de Telegram (sin necesidad de webhook público), y cada mensaje que recibe lo reenvía a claude --print con una sesión ejecutada dentro del repositorio del PA. Claude ejecuta el prompt con todas sus herramientas (MCP + scripts Python) y devuelve la respuesta. El daemon la formatea para Telegram y la manda de vuelta al chat.

Crear el bot lleva dos minutos. Abre Telegram, habla con @BotFather, lanza /newbot, dale un nombre y un username. Te devuelve un token tipo 123456:ABC-XYZ_.... Guárdalo en Keychain y a continuación detecta tu chat_id (el ID de la conversación 1-a-1 entre tú y el bot):

Ahora el daemon. El esqueleto de telegram_bot.py es este:

Tres detalles no obvios del diseño.

Primero, whitelist de `chat_id`: la variable allowed_chat es tu propio chat y cualquier mensaje de otro chat_id se descarta silenciosamente. Si alguien descubre el username de tu bot y le manda mensajes, no le contesta. Es la barrera más simple pero más eficaz contra el abuso.

Segundo, `--permission-mode bypassPermissions`: el daemon corre sin pedir confirmación para ejecutar scripts del repo porque no hay un humano delante que pueda responder. La seguridad no viene de los prompts de Claude Code, viene de que (a) el daemon solo responde al chat_id whitelisted, (b) el PA tiene la regla de confirmación en CLAUDE.md, y (c) los scripts sensibles como mail_send.py exigen --yes a nivel de código.

Tercero, sesiones efímeras por mensaje. Cada ask_claude genera un session-id nuevo con uuid.uuid4(). Eso significa que el bot no mantiene memoria de conversación entre mensajes — cada petición parte de cero con tu CLAUDE.md y tus comandos cargados. La memoria "larga" (tus preferencias, firma, contactos prioritarios) vive en memory/ como archivos que Claude lee al iniciar cada sesión, no en la propia sesión. Esto evita acumular contexto obsoleto y hace el comportamiento muy predecible.

Markdown compatible con Telegram. Telegram no renderiza Markdown estilo GitHub (no entiende tablas, no entiende enlaces con corchetes en muchos contextos, interpreta mal ciertos caracteres). En lugar de luchar con parse_mode: MarkdownV2 — que te obliga a escapar todos los caracteres especiales y rompe con facilidad — usamos un pequeño conversor a texto plano legible (md_to_telegram.py) que elimina la sintaxis Markdown preservando la estructura.

Para probarlo antes del launchd:

Abre Telegram, escribe /ping a tu bot. Debería responder pong. Manda luego "¿qué hora es?" — debería contestarte con la hora actual consultando al sistema via sesión de Claude. Felicidades: ya tienes un PA accesible desde el móvil.

Paso 5: Briefings programados con launchd

[`launchd`](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html) es el gestor de procesos y tareas programadas de macOS. Es el equivalente a cron + systemd combinados en un solo sistema. Cada tarea se define en un archivo XML (.plist) que le dice a macOS qué ejecutar, cuándo, y qué hacer si falla.

Vamos a crear tres launchd jobs:

1. Bot de Telegram como daemon permanente (KeepAlive: true).
2. Briefing matutino cada día a las 08:00.
3. Briefing vespertino cada día a las 19:00.

Primero el wrapper scripts/run_briefing.sh que lanza Claude Code en modo no interactivo para generar el briefing:

Ahora el .plist del briefing matutino. Guárdalo en scripts/launchd/com.kiwop.pa-briefing-morning.plist:

Clave importante: el `PATH` explícito en EnvironmentVariables. launchd no hereda tu PATH del shell, así que si no se lo pasas, claude no estará disponible y el briefing fallará silenciosamente. Incluye /opt/homebrew/bin (Apple Silicon), /usr/local/bin (Intel) y ~/.local/bin (si instalaste Claude Code vía pip --user).

Duplica el archivo para el vespertino cambiando morning por evening y la hora a 19. Y crea el del bot de Telegram:

El trío RunAtLoad: true + KeepAlive: true + ThrottleInterval: 15 significa: arranca al iniciar sesión, reinicia si se cae, y no intentes reiniciar más rápido que cada 15 segundos (para evitar bucles de fallo).

Para activar los tres .plist:

Para verificar que están activos:

Deberías ver las tres entradas con PID (para el bot, que corre continuamente) o con - (para los briefings, que solo corren a sus horas).

Para disparar un briefing manualmente sin esperar a las 08:00 (útil para testing):

Paso 6: Comandos slash /morning, /evening, /inbox, /reply

Los comandos slash de Claude Code viven en .claude/commands/ como archivos Markdown. Cada archivo es un prompt template que Claude ejecuta cuando invocas /nombre en la sesión. Son la forma más limpia de encapsular flujos repetitivos sin repetir el mismo prompt largo cada vez.

Para el PA definimos cuatro comandos mínimos: /morning, /evening, /inbox, /reply. Este es el ejemplo de .claude/commands/morning.md:

Buenos días — <fecha>

Agenda de hoy

• HH:MM–HH:MM · Título · (lugar / asistentes)

Correo (N no leídos)

🔥 Fuego: [UID] Remitente — Asunto · contexto ⚠ Importante: [UID] ... Para revisar: [UID] ... Ruido: N items

Slack

🔥 ... ⚠ ...

Prioridades sugeridas

1. ...
2. ...
3. ...

El comando /reply es particularmente importante porque aplica la regla de confirmación:

Fíjate en el patrón: el comando hace cumplir la regla de confirmación a nivel de prompt (paso 5), y el script hace cumplir la regla a nivel de ejecución (el --yes obligatorio en mail_send.py). Doble capa. Si el modelo "olvida" el paso 5, el script no envía. Si alguien modifica el script para saltarse --yes, el prompt todavía exige confirmación. Es la misma filosofía de defensa en profundidad que recomendamos en proyectos de integración de LLMs para cualquier acción con efectos irreversibles.

Los cuatro comandos base son suficientes para el 90% del uso diario. Puedes añadir más: /schedule (crear reuniones), /book (agendar desde una invitación), /auth (diagnóstico del estado de los MCPs).

Paso 7: Probar el setup end-to-end

Con todo montado, toca una ronda de tests completa antes de darlo por funcional. Este es el checklist que usamos en Kiwop cada vez que replicamos el setup en otra máquina:

1. MCPs autenticados. En una sesión de Claude Code desde ~/Dev/PA:

Los cuatro servers deben aparecer con tools disponibles. Si alguno dice "not authenticated", repite el OAuth.

2. Correo IMAP funcional. Desde terminal:

Debería devolver un JSON con tus tres correos no leídos más recientes. Si falla con imaplib.IMAP4.error, revisa Keychain y puertos.

3. Briefing manual. Desde sesión interactiva de Claude Code:

Genera un briefing completo. No debe tardar más de 60 segundos.

4. Bot de Telegram bidireccional. Desde Telegram, a tu bot:

• /ping → pong (inmediato)
• "¿qué tengo hoy en la agenda?" → respuesta con la agenda real (30-40 segundos)

5. Logs de launchd sin errores.

El telegram_bot.err.log debe tener una línea "Bot up. Allowed chat=...". Si hay un FATAL: secret read failed, revisa que Keychain tiene los ítems PA-telegram-bot-token y PA-telegram-chat-id.

6. Prueba en frío del briefing programado.

Debe haber generado el briefing del día y empujado una copia a tu Telegram. Si Telegram no recibe, revisa las credenciales PA-telegram-* en Keychain.

Problemas comunes y cómo diagnosticarlos:

Una vez pasa los seis puntos del checklist, el PA está listo para uso diario. A partir de aquí todo es refinar: añadir memory/ con tus preferencias de estilo, añadir más comandos slash según los flujos que detectes repetitivos, ajustar los prompts de morning.md y evening.md al output exacto que te resulta más útil.

Consejo práctico sobre los primeros siete días. Después de montarlo, el PA va a hacer cosas subóptimas hasta que descubras qué le falta de contexto sobre ti. Nosotros recomendamos empezar en modo "solo lectura" la primera semana: deja que genere briefings, déjale triar inbox, pero no uses /reply ni confirmes acciones de escritura todavía. Durante esa semana irás detectando patrones que corregir — "clasifica mal los correos de este cliente porque no sabe que es VIP", "resume de más los mensajes cortos de Slack", "marca como ruido cosas que para mí son importantes". Todas esas correcciones van a memory/triage_rules.md y al CLAUDE.md. A partir del día siete o ocho, cuando el triaje esté consistente al 85-90%, ya puedes abrir el uso de escritura con /reply y empezar a ganar tiempo real. Saltarse esta fase de calibración es el error más común y la causa principal de abandonos en nuestra muestra de personas a las que hemos ayudado a montarlo.

Variantes y escalado: Linux, Windows, y corriendo 24/7

El tutorial está escrito sobre macOS porque es donde trabajamos, pero la arquitectura es portable. Los cuatro ajustes principales:

Gestor de procesos.

Un unit de systemd para el bot de Telegram en Linux sería aproximadamente así (~/.config/systemd/user/pa-telegram.service):

Activación: systemctl --user daemon-reload && systemctl --user enable --now pa-telegram.service.

Almacén de secretos.

El fallback a variables de entorno en un archivo con permisos 600 funciona en las tres plataformas y es el denominador común si quieres un único código para todos los sistemas.

launchd vs systemd, comparativa honesta:

¿Correrlo 24/7 en un servidor remoto? Es viable y lo hemos probado. El patrón: un pequeño VPS Linux con systemd corriendo el bot de Telegram y los briefings programados, más una conexión IMAP/SMTP al buzón, más el CLI de Claude Code autenticado con tu cuenta Anthropic. Ventajas: el PA contesta aunque tu portátil esté apagado. Desventajas: el OAuth de los MCP servers es más delicado sin navegador local (tendrás que hacer el flujo inicial en tu máquina y copiar el refresh token), y cualquier actualización del CLI de Claude Code requiere SSH y despliegue. Para la mayoría de profesionales que usan el Mac a diario, mantenerlo en local es la opción con mejor relación simplicidad/utilidad.

El salto a un PA multi-usuario (uno que sirva a un equipo) no es una variante del mismo tutorial — es un SaaS y requiere decisiones arquitectónicas muy distintas (multi-tenancy, autenticación, aislamiento de sesiones). Si te interesa explorar esa ruta, lo abordamos en los proyectos de desarrollo de agentes IA a medida.

Dos extensiones que hemos visto funcionar en la práctica cuando el PA base ya está estable. La primera es un memory/ poblado con archivos Markdown que Claude carga en cada sesión: un triage_rules.md con tus criterios exactos para clasificar correo, un writing_style.md con ejemplos de correos escritos por ti para que los borradores suenen a tu voz, un vip_contacts.md con las direcciones que nunca deben caer en "ruido". La segunda es un watcher de correo en segundo plano (un daemon similar al bot de Telegram, pero que en vez de escuchar Telegram escucha tu bandeja IMAP) que dispara una notificación cuando llega un correo marcado como fuego según tus reglas — útil para flujos donde no basta con el briefing de las 08:00. Ambas extensiones se construyen con la misma filosofía que el resto: scripts cortos, secretos en Keychain, sesiones efímeras de Claude Code.

Preguntas frecuentes

¿Cuánto cuesta realmente construir este PA?

Si ya tienes Claude Max x20 (unos 200 USD/mes), el coste marginal del PA es cero. Los MCP servers son gratuitos, el bot de Telegram corre en tu Mac sin hosting, y los scripts Python no requieren dependencias de pago. Si no tienes Claude Max, el cálculo cambia: los 200 USD/mes son la inversión fija. El tiempo de construcción siguiendo este tutorial es de 60-90 minutos.

¿Es seguro dar acceso a mi correo y calendario a un PA construido así?

Sí, con las siguientes condiciones explícitas. Primero, los MCP servers oficiales autentican por OAuth sin guardar tu contraseña en disco — el token vive en un almacén cifrado del propio MCP server. Segundo, las credenciales IMAP/SMTP están en macOS Keychain (llavero del sistema operativo, cifrado), nunca en archivos planos. Tercero, el bot de Telegram solo responde al chat_id whitelisted y la regla de confirmación obligatoria en CLAUDE.md impide acciones de escritura sin "sí" explícito. La superficie de ataque queda muy acotada, comparable a la de cualquier cliente de correo de escritorio.

¿Qué pasa con la privacidad de los datos? ¿Anthropic entrena con mis correos?

Anthropic declara públicamente (política a 2026) que los datos enviados por API y por Claude Code no se usan para entrenar modelos. Para contenido regulado (sanitario, legal con secreto profesional, financiero confidencial), conviene revisar los términos específicos vigentes y considerar si un PA sobre infraestructura propia es más apropiado — en cuyo caso una solución de RAG empresarial puede ser la alternativa correcta.

¿Se puede integrar WhatsApp en este PA?

A fecha de abril de 2026 no existe un MCP oficial de WhatsApp. Hay bridges no oficiales (Matrix, Beeper, la propia WhatsApp Business Cloud API de Meta) que se pueden conectar como un canal adicional, pero todos tienen caveats: los bridges no oficiales pueden violar ToS de Meta y ser inestables, y la Business Cloud API requiere una cuenta comercial verificada. Nuestra recomendación pragmática es usar Telegram como canal móvil primario.

¿Este PA puede dar servicio a varios usuarios?

No, por diseño. Un PA es single-user: sus credenciales, su memoria, sus preferencias, y su CLAUDE.md apuntan a una sola persona. Para escenarios multi-usuario (un equipo que comparte un asistente común) la arquitectura correcta es un SaaS multi-tenant con aislamiento de datos por usuario — no una copia del PA con variables compartidas. Es una conversación totalmente distinta.

¿Funciona sin conexión a internet?

No. Claude Code requiere conexión para consultar el modelo, los MCP servers usan APIs online (Google, Slack, Telegram), y IMAP/SMTP obviamente también. El PA descrito aquí es un cliente que orquesta servicios cloud — no un modelo local. Si necesitas operación offline, es un rediseño completo con un LLM local (Llama, Mistral) corriendo en ollama o similar, con restricciones de calidad y rendimiento notables.

¿Cuánto tiempo tarda el PA en dar su primer briefing matutino?

El run_briefing.sh completo tarda entre 40 y 90 segundos según cuánto correo tengas que triar. La parte más lenta es el fetch IMAP con --with-body (una conexión por UID), seguida del razonamiento del modelo sobre el triaje. Si tu bandeja es muy grande (>50 no leídos), puede subir a 2-3 minutos. Si es la primera ejecución y el MCP de Calendar aún está calentándose, añade 5-10 segundos extra.

¿Puedo personalizarlo para mi flujo concreto?

Sí, y es la filosofía del proyecto. Los archivos clave a tocar: CLAUDE.md (persona, tono, reglas), .claude/commands/*.md (flujos concretos), memory/ (preferencias persistentes, firma, contactos VIP, reglas de triaje). El código Python rara vez hay que tocarlo salvo para añadir cuentas IMAP adicionales o integrar un canal nuevo. Empieza con el setup base funcionando antes de personalizar — es más barato aprender dónde personalizar cuando ya ves qué te sobra y qué te falta.

Conclusión: 60 minutos entre tú y tu primer PA operativo

Llevamos dos semanas usando este PA en Kiwop y la conclusión más honesta que podemos escribir es que el salto de productividad real no viene del modelo — viene del diseño minimalista alrededor del modelo. Claude Code, Opus 4.7, los MCP servers: son la parte cara que no construyes tú. Los ~500 líneas de Python, el puñado de archivos Markdown, los tres .plist de launchd — eso es lo que haces tú, y es lo que convierte las capacidades del modelo en un asistente útil para tu día.

Este tutorial ha cubierto el camino completo desde un directorio vacío hasta un PA operativo con cuatro canales y briefings programados. El código de referencia que hemos usado está publicado en https://github.com/purroy/majordomo bajo una licencia permisiva — clona, hazle fork, adáptalo. No es la única manera de construir un PA en 2026, pero es una que sabemos que funciona porque la usamos cada mañana a las 08:00 antes de encender el Mac del trabajo.

Si mientras seguías el tutorial has encontrado un hueco donde tu caso concreto necesita más que este stack base — integraciones a medida con tu CRM, un canal de Teams, un MCP propietario para tu ERP, o directamente un asistente multi-usuario para todo tu equipo — en Kiwop construimos esas piezas como parte de nuestros servicios de desarrollo de agentes IA y consultoría de IA. Nuestro punto de partida siempre es el mismo: capas finas, desacopladas, agnósticas al proveedor. No hay nada en este tutorial que no puedas replicar tú mismo en una tarde, pero si el tiempo es más caro que el coste de externalizar, contacta con nuestro equipo y lo hacemos contigo.

El PA que tienes ahora corriendo en tu Mac es tuyo. Nadie puede cortarlo de la noche a la mañana. Y eso, en 2026, es la propiedad más valiosa que puede tener un agente IA aplicado al trabajo diario.