Guía de Mycel

Requisitos

En el ordenador que vaya a ejecutar las tareas (tu Nodo) no necesitas instalar nada: el Nodo es un ejecutable que descargas del Panel (Windows, macOS o Linux) y abres. Lo único que eliges es el «cerebro» del agente:

• Modo local (recomendado, gratis y privado): Ollama con un modelo descargado. Según tu equipo:

  ollama pull qwen2.5-coder:14b   # GPUs de 12 GB o CPU, para empezar
  ollama pull qwen3-coder:30b    # equipos potentes (24 GB+ de VRAM)

• Modo API (sin GPU): una clave de OpenAI o de Anthropic. Se añade al comando del Nodo (--openai-key=… / --anthropic-key=…) y sus modelos aparecen en el selector de la web. Ver Modelos y proveedores.

Si el modelo elegido en la web no está instalado en tu Nodo, el agente no falla: usa el mejor modelo que tengas y te deja una nota explicando cómo instalar el que pediste.

Elegir modelo no es obligatorio. Al conectar tu Nodo, el Panel detecta tu hardware (RAM/GPU) y propone el paquete que le cuadra (modelo de código, de visión y de embeddings para RAG), que se descarga con un solo clic.

Instalación por sistema

En el Panel → Nodos verás el botón de descarga para tu sistema. Descarga el ejecutable, ábrelo y pega tu token cuando lo pida. Si vas a usar el modo local, instala además Ollama.

Windows 10/11

1. Descarga mycel-win.exe del Panel y haz doble clic. Se abre una consola; pega tu token cuando lo pida.
2. La primera vez, Windows puede mostrar un aviso azul de SmartScreen («Windows protegió su PC»). Es normal en programas nuevos sin firma de fabricante: pulsa «Más información» y luego «Ejecutar de todos modos». Solo hace falta una vez.
3. Modo local: instala Ollama para Windows y déjalo en la bandeja. En PowerShell: ollama pull qwen2.5-coder:14b
4. Funciona nativo en Windows: no hace falta WSL ni nada más.

macOS

1. Descarga mycel-mac-arm64 (Apple Silicon) o mycel-mac (Intel). La primera vez ábrelo con clic derecho → Abrir, y a partir de ahí con doble clic como cualquier otro programa. Pega tu token.
2. Modo local: instala Ollama para Mac y ábrelo. En Terminal: ollama pull qwen2.5-coder:14b

Linux

1. Descarga mycel-linux, dale permiso (chmod +x mycel-linux) y ejecútalo: ./mycel-linux. Pega tu token.
2. Modo local: curl -fsSL https://ollama.com/install.sh | sh y luego ollama pull qwen2.5-coder:14b

El modelo de estos tres pasos es el de arranque, el que cabe en un equipo modesto y te deja probar hoy mismo. Para trabajo autónomo de verdad el mínimo recomendado es un 30B (ollama pull qwen3-coder:30b, ~24 GB de VRAM): por qué, en Modelos y proveedores. Si tu equipo no llega, el Panel te lo dirá al conectar el Nodo y te propondrá el paquete que sí rinde ahí.

Primeros pasos

1. Crea tu cuenta gratis y sin tarjeta.
2. Conecta tu equipo: crea tu Nodo (un nombre y un clic), descarga el ejecutable para tu sistema y ábrelo. Pega tu token cuando lo pida; queda guardado para las próximas veces. No hace falta instalar nada más.

   En un servidor sin escritorio también se lanza desde la terminal con flags: ./mycel-linux --token=mcl_XXXX --server=wss://ESTE-MISMO-DOMINIO (en Windows, mycel-win.exe).

3. Espera la luz verde: cuando la consola del Nodo diga «Esperando tareas», la web se activa sola.
4. Encarga tu primera tarea. Por ejemplo: «Crea un script en Python que organice la carpeta de descargas por tipo de archivo, con tests», «Investiga las tres librerías más usadas para X y recomiéndame una con fuentes» o «Analiza este CSV y dame un informe con los datos clave».

Verás el plan, cada paso (archivos escritos, comandos ejecutados, su salida real, búsquedas web), la verificación y un informe final descargable. Puedes cancelar una tarea en curso desde la cabecera de la sesión.

Sesiones: donde encargas el trabajo

Sesiones es la pantalla principal. Cada sesión es un encargo y todo lo que pasó con él: el plan, cada paso ejecutado con su salida real, la verificación y los entregables. Se abre una nueva con el botón + de la barra lateral y se retoma cualquiera desde Recientes.

Antes de escribir: dónde va a trabajar

En una sesión nueva eliges el destino, y esto importa más que el texto de la tarea: es lo que decide qué archivos ve el agente.

• El Nodo, si tienes más de uno ejecutable. La elección se recuerda.
• El workspace (en un Nodo tuyo): una carpeta real de tu disco que hayas registrado en Panel → Workspaces. La alternativa es «Sandbox (experimento aislado)», una carpeta limpia por sesión: perfecta para probar, inútil si querías tocar tu proyecto.
• La carpeta (en un Nodo compartido contigo): ahí no eliges workspace sino una de las carpetas que su dueño te haya concedido. Si no te ha concedido ninguna, la tarea corre en el sandbox del Nodo y la pantalla te lo dice.

El cuadro de tarea

• Plantillas: encargos ya redactados por vertical (chatbot propio, facturas PDF a Excel, borradores de respuesta al correo, KPIs de ventas, cribar CVs, control de stock…). La plantilla se inserta en el cuadro con huecos «así» para que los ajustes: propone, no envía.
• Selector de modelo: «Automático (el mejor del Nodo)» o uno concreto de los que tus Nodos anuncian, agrupados por proveedor. Ver Modelos y proveedores.
• Dictado por voz, si tu navegador lo soporta.
• Enter envía; Shift+Enter hace un salto de línea.

No hay «adjuntar archivo», y es a propósito. Tus documentos no se suben a ninguna parte: ya están en el equipo del Nodo. Se le indican poniéndolos en el workspace o en la carpeta que elijas, y el agente los lee ahí.

Mientras trabaja, y después

La sesión se va escribiendo sola: el plan con sus pasos en verde o en rojo, los comandos con su salida, las búsquedas, las notas del agente y un «Trabajó durante…» con las líneas añadidas y borradas. En la cabecera hay un botón Cancelar mientras esté en curso, y si la tarea falla, uno de Reintentar.

Los entregables aparecen en el panel de la derecha: el informe final y cada archivo producido, con vista previa según el tipo (Markdown, imágenes y SVG ampliables, PDF, vídeo, audio, tablas de Excel/CSV, código), y botones de copiar, descargar y leer en voz alta. Los archivos viven en tu Nodo: se descargan pasando por él, así que hace falta que esté encendido.

Con el Nodo apagado la lista de sesiones sale vacía, y no es un fallo: las sesiones viven en el Nodo, no en el servidor de Mycel. Enciéndelo y vuelven todas. Es la misma decisión que explica Soberanía: si el servidor pudiera enseñarte el historial, es que lo tendría.

En un Nodo de otra persona depende de tu rol: dueño, administrador y operador lanzan tareas; el supervisor ve y exporta toda la actividad pero no ejecuta, y la pantalla se lo dice en vez de fallar al enviar. Ver Equipos.

El Panel: tus Nodos y tus proyectos

El Panel es la sala de máquinas: desde aquí se crea un Nodo, se descarga su ejecutable, se regenera su token, se exporta su actividad y se registran los workspaces. Es el sitio al que te manda el resto de la guía cuando dice «Panel → Nodos» o «Panel → Workspaces».

Crear y conectar un Nodo

1. Escribe un nombre («Torre del salón», «Servidor de la oficina») y pulsa Crear Nodo.
2. Se abre el cuadro de conexión. Descarga el ejecutable para el sistema del equipo que vas a conectar (solo se ofrecen los que esta instancia sirve de verdad).
3. Elige el cerebro: Local (Ollama), Clave de API (Mycel te arma el comando con el flag correcto; la clave se usa en tu navegador para escribir ese comando y no se guarda en Mycel) o Nodo Cloud (OVH/VPS).
4. Abre el ejecutable en ese equipo y pega el token cuando lo pida. Queda guardado en ~/.mycel y reconecta solo.

El token se muestra una sola vez. Mycel lo guarda cifrado y no puede volver a enseñártelo: si lo pierdes, usa Nuevo comando de conexión (el icono de la llave), que genera otro y invalida el anterior al instante. Para actualizar el binario no hace falta nada de eso: en la Ficha del Nodo lo descargas de nuevo y el token guardado sigue valiendo.

Qué más hay en cada Nodo

• Ficha del Nodo: estado, identificador, los modelos que ese Nodo trae (los de Ollama si es local, los de tu clave si va por API), hardware (RAM, GPU, CPU), uso acumulado, descarga del binario y el comando de conexión con el hueco del token.
• Equipo: invitar personas y darles rol sobre ese Nodo. Ver Equipos.
• Eliminar el Nodo, o salir de uno que otra persona compartió contigo.
• Configuración recomendada: al conectar, el Nodo informa de su hardware y el Panel propone el paquete de modelos que mejor rinde ahí (principal, visión y embeddings para RAG). Se descarga con un botón y verás la barra de progreso en vivo, sin escribir un solo ollama pull.

Exportar la actividad (trazabilidad)

Dos iconos en la fila de cada Nodo, sin rótulo escrito: pásale el ratón por encima y te dicen lo que hacen. El del ojo («Ver la actividad del Nodo (JSON filtrable)») abre el visor Actividad del Nodo, con cuatro pestañas y su recuento (Todo, Sesiones, Asistentes, Automatizaciones), filtro por persona y por texto, y botones de Copiar JSON y Descargar. El de la flecha hacia abajo («Exportar la actividad del Nodo (trazabilidad)») se lo baja entero sin abrir nada. Sirve para auditar quién encargó qué y con qué resultado.

El alcance lo decide tu rol, no tú: dueño, administrador y supervisor exportan la actividad completa del Nodo; un operador exporta solo lo suyo. Y como todo esto vive en el Nodo, la exportación necesita que esté encendido: si está apagado, Mycel lo dice en vez de darte un fichero a medias.

Workspaces

Un workspace es una carpeta real de tu disco que registras con un nombre para poder elegirla al crear una sesión. Se da de alta con nombre y ruta, o pulsando Explorar para recorrer las carpetas del Nodo sin escribirla a mano. Quitarlo de Mycel no toca ni la carpeta ni sus archivos: solo deja de ofrecértela. Ver Workspaces.

Si algún chatbot tuyo tiene conversaciones esperando a una persona, el Panel te lo avisa arriba con un enlace directo a Chats: nadie recibe un aviso si el bot no tiene a quién avisar.

Cuenta: tu perfil, tus avisos y tus datos

Cuenta no está en la lista de apartados: se abre con el engranaje del pie del menú lateral, junto a tu nombre (el rótulo dice «Cuenta y ajustes»). Es tuya y solo tuya, no depende de ningún Nodo ni de ningún equipo, y dentro hay tres cosas.

Perfil, y el Telegram donde recibes los escalados

Además del nombre con el que te ven tus compañeros, aquí está el campo que hace falta para el trabajo en equipo: «Telegram para avisos». Es un chat_id numérico (te lo dice @userinfobot si le escribes) y lo pones tú, no quien administra el Nodo: cuando un chatbot que tienes asignado escala a una persona, el aviso con el contexto y los datos recogidos te llega a ese chat, además de aparecer en Chats. Sin él sigues atendiendo desde la web, pero te enteras cuando la abres.

Que tú lo pongas no basta: el bot tiene que poder escribirte. El aviso lo manda el Nodo con las credenciales del asistente, así que el de Telegram necesita que ese bot tenga su token de Telegram, y el de email, una clave de envío en su canal de correo. Está entero en Equipos.

Contraseña

Se cambia con la actual más la nueva (8 caracteres mínimo). Al cambiarla el resto de sesiones quedan cerradas: es lo que quieres si has entrado desde un ordenador que no era el tuyo.

Exportar y borrar: el RGPD, con dos botones

• Exportar mis datos descarga en JSON todo lo que la plataforma sabe de ti: tus sesiones, workspaces, Nodos y las recetas que aportó tu agente. Es el derecho de acceso y portabilidad, servido sin pedírselo a nadie.
• Borrar cuenta elimina la cuenta y todo eso de forma inmediata e irreversible, recetas incluidas. Pide tu contraseña para confirmar, a propósito.

Lo que no sale en la exportación es lo que nunca estuvo aquí: tus documentos, el contenido de tus tareas y las conversaciones de tus chatbots viven en tu Nodo, y se exportan desde Panel → Ver/Exportar actividad. Los skills tampoco: son ficheros de tu equipo, y los abres o los borras como cualquier otro fichero tuyo. Ver Privacidad.

El Nodo

El Nodo es un ejecutable que conecta tu ordenador con tu cuenta. Se conecta hacia fuera, así que no abres puertos ni tocas el router. Normalmente solo lo abres y pegas tu token. Para apagarlo, cierra la ventana o pulsa Ctrl+C; para volver, ábrelo de nuevo.

# Uso normal: descarga el binario del Panel, ábrelo y pega tu token.
# El token se guarda en ~/.mycel/config.json y reconecta solo.

# Avanzado (servidores/headless), desde la carpeta del binario:
./mycel-linux --token=mcl_XXXX --server=wss://ESTE-MISMO-DOMINIO    # Windows: mycel-win.exe

# Flags útiles:
#   --name="Torre del salón"        nombre con el que aparece en el panel
#   --model=qwen3-coder:30b         modelo por defecto (mínimo recomendado)
#   --judge-model=…                 modelo que verifica el trabajo (lo pone Mycel por ti)
#   --openai-key=sk-...             añade los modelos de OpenAI al selector
#   --anthropic-key=sk-ant-...      añade los modelos de Anthropic al selector
#   --deepseek-key / --groq-key / --openrouter-key / --mistral-key / --together-key
#   --openai-url=http://...         endpoint compatible con OpenAI (LM Studio, vLLM…)
#   --reset                         olvida el token guardado (para cambiarlo)

• Un Nodo ejecuta una tarea a la vez (tu GPU no es infinita).
• Puedes conectar varios equipos; Mycel usará el que esté libre.
• Te avisa en consola si hay una versión nueva del Nodo para descargar.
• Si el Nodo se desconecta a mitad de tarea, la sesión se marca como fallida con un aviso claro; el Nodo reconecta solo (reintentos con espera creciente) y queda listo para que relances la tarea.
• Revoca un Nodo en cualquier momento desde el panel: puedesborrarlo o regenerar su token. En ambos casos el token anterior deja de funcionar al instante y el equipo se desconecta; para volver, pega el token nuevo.
• Los experimentos en sandbox se guardan en ~/.mycel/runs/ del equipo del Nodo.

Nodo Cloud (OVH/VPS)

Un servidor cloud tuyo también puede ser el Nodo, y así no hay que dejar el ordenador encendido. Recomendamos OVH Public Cloud: computación europea (Gravelines/Estrasburgo), tus datos no salen de la UE. Sirve cualquier VPS Linux: el Nodo conecta hacia fuera, sin abrir puertos.

1. En Panel → Nodos, crea un Nodo («Crear Nodo») y en el cuadro de conexión que aparece, bajo «¿Qué cerebro va a usar este equipo?», elige “Nodo Cloud (OVH/VPS)”. Se genera un token dedicado para ese servidor.
2. Elige el cerebro: CPU + clave de API (instancia barata, p. ej. b3-8) o GPU + Ollama (p. ej. una L4: el script instala Ollama y descarga el modelo, 100 % privado también en la nube).
3. Copia el artefacto que te convenga:
   • “Script (VPS ya creado)”: pégalo por SSH como root.
   • “cloud-init (al crear la instancia)”: en OVH, pega el YAML en el script de post-instalación y arranca.
4. En 2–5 minutos el Nodo aparece en línea en tu Panel, listo para recibir tareas como uno doméstico.

• El texto generado contiene tu token (y tu clave de API si la pusiste): trátalo como una contraseña. Puedes revocarlo desde el Panel cuando quieras.
• El Nodo cloud instala un servicio (mycel-node.service) que arranca solo y se reconecta si se corta la red. Diagnóstico: journalctl -u mycel-node -f.
• Seguridad: el agente en cloud lleva un guard que bloquea el acceso a la red interna y al metadata del proveedor por defecto.

Modelos y proveedores

El «cerebro» del agente se elige por tarea en el selector del composer (abajo a la izquierda de la caja de tareas). Ahí aparecen todos los modelos que tus Nodos conectados ofrecen:

• Locales (Ollama): mínimo recomendado qwen3-coder:30b, o llama3.3:70b para máxima capacidad. Gratis, privados, tan rápidos como tu GPU.
• Proveedores de API (sin GPU): OpenAI (openai/…), Anthropic (anthropic/…), DeepSeek (deepseek/…), Groq (groq/…), OpenRouter (openrouter/…), Mistral (mistral/…) y Together (together/…).
• Endpoint propio: cualquier servidor compatible con OpenAI (LM Studio, vLLM…) con --openai-url.

La forma fácil: en Panel → Nodos, al crear o desplegar un Nodo, elige «Clave de API», pega la clave del proveedor que quieras (con su enlace para conseguirla) y Mycel te arma el comando de conexión con el flag correcto. No tienes que editar nada a mano. Puedes activar varios proveedores a la vez.

Con proveedores de API, los prompts van directamente de tu Nodo al proveedor con tu clave: la plataforma Mycel nunca los ve ni guarda la clave. El coste de esos tokens corre a cargo de tu cuenta del proveedor. DeepSeek y Groq son las opciones más baratas para empezar. Detalles en Privacidad.

Para código en local, los coder de Qwen son el mejor equilibrio. Para investigación y redacción larga, los modelos de API suelen rendir mejor. La elección se recuerda y aplica a las siguientes tareas; si no eliges nada, el Nodo usa el mejor modelo que tenga disponible.

El modelo local mínimo. Para trabajo autónomo real el mínimo recomendado es un modelo de 30B (p. ej. qwen3-coder:30b, ~24 GB de VRAM/RAM): los 7B/14B pierden foco en tareas de varios pasos y quedan como opción «solo pruebas». Con un 30B (o mejor, llama3.3:70b en equipos de 48 GB+) salen de forma fiable: documentos Office, código con tests ejecutados, análisis de datos, RAG, descargas de PDFs reales, investigación web citando fuentes, visión y tareas programadas. Si tu equipo no llega a 30B, usa una clave de API o un Nodo Cloud con GPU. Qué se le pide en cada caso, en la biblioteca de encargos.

Qué puedes pedirle (más que código)

Atajo: en Sesiones, el botón “Plantillas” del cuadro de tarea trae encargos listos por vertical, tu propio chatbot de Telegram con tus documentos, facturas PDF a Excel, borradores de respuesta al correo, vigía de mercado semanal…, con huecos «así» que ajustas antes de enviar: la plantilla propone, tú decides.

El agente trabaja con un bucle plan → ejecutar → verificar → informe y un conjunto de herramientas reales: leer y escribir archivos (por tramos en los grandes, y sacando el texto de PDF, Word, Excel y PowerPoint; de un Excel lee todas las hojas, no solo la primera), edición quirúrgica, búsqueda de texto que entra también dentro de esos documentos y nombra los ficheros que no ha podido abrir, ejecutar comandos, perfilar datos (CSV/TSV/JSON/JSONL/XLSX: filas, columnas, tipos y estadísticas, sin necesitar Python), describir imágenes con un modelo de visión, buscar en la web, descargar archivos, montar un RAG local sobre una carpeta de documentos (responde citando la fuente), extraer el contenido principal de páginas o APIs, generar infografías SVG y entregar documentos Office reales (.xlsx, .docx, .pptx) que se abren en Microsoft Office, LibreOffice o Google. Si le falta una librería, intenta instalarla con el comando correcto de tu sistema y te lo muestra en la conversación. Eso cubre mucho más que programar:

• Ingeniería de software: crear proyectos, añadir funcionalidades, arreglar bugs, escribir tests, refactorizar y ejecutarlo todo antes de dártelo por terminado.
• Investigación con fuentes: «Compara las opciones X e Y, contrasta al menos dos fuentes y dame una recomendación con enlaces». El informe final cita las URLs usadas. También puede descargar los documentos (p. ej. varios PDFs sobre un tema) a un workspace.
• Pregunta a tus documentos (RAG): registra una carpeta con PDFs, notas o datos; Mycel la indexa en tu equipo y responde citando el archivo de origen, sin que nada salga de tu máquina. Como un NotebookLM privado. Necesita un modelo de embeddings (local nomic-embed-text o de API).
• Análisis de datos y documentos: pon un CSV, un log o unos markdown en un workspace y pide resúmenes, métricas, inconsistencias o un informe ejecutivo. El agente perfila el archivo (dimensiones, tipos y estadísticas) antes de analizarlo, así que sus conclusiones se basan en los datos reales.
• Redacción técnica: READMEs, documentación de un proyecto existente, posts, guías de uso, leyendo primero tu código real para no inventar.
• Automatización: scripts de copia de seguridad, renombrado masivo, conversiones de formato, tareas de sistema, verificados con ejecuciones reales.
• Entregables Office: «pásame esto a Excel», «hazme un Word con el informe» o «monta una presentación»: genera .xlsx, .docx y .pptx reales, sin depender de Microsoft Office ni de Python.
• Tareas programadas (agéntico): «cada mañana revisa X y avísame», «en 10 minutos recuérdame…». Mycel lo programa desde el propio chat y cada ejecución aparece en esa misma sesión, que se queda viva para seguirla, pausarla o cambiarla hablando con ella.
• Memoria del workspace: cada tarea corre «en limpio», así que Mycel guarda los hechos durables que le digas (tu negocio, tu idioma, destinatarios, decisiones) en la memoria local del workspace (.mycel/memory.md) y los tiene en cuenta en las tareas siguientes, sin que nada salga de tu equipo. Es distinto del RAG de documentos: aquí guarda hechos, no el contenido de tus archivos.

Consejo: los encargos concretos rinden más que las épicas. «Analiza ventas.csv y dame los 5 productos con más margen» funciona mejor que «analiza mi negocio». Cada tarea completada además destila una receta para tu cuenta, que mejora tus siguientes encargos.

Navegador interactivo (opcional): para páginas que exigen login, clics o mucho JavaScript, Mycel puede pilotar un navegador real (browser_*). Es opt-in porque instala un navegador en tu equipo: actívalo lanzando el Nodo con MYCEL_BROWSER=1 tras instalar Playwright (npm i -g playwright y luego npx playwright install chromium). Si no lo activas, el agente usa las herramientas web estáticas y te indica cómo habilitarlo.

Chatbots para tu web y tu mensajería

Mycel monta chatbots conversacionales controlados por un grafo de flujo y los sirve desde tu Nodo. El mismo asistente responde por cualquier canal, tu web, Telegram, WhatsApp o Slack, porque el cerebro (el grafo) es único y el canal solo cambia por dónde entra y sale el mensaje.

1. Cómo crear uno

El constructor (Chatbots → Nuevo chatbot) va en tres pasos que puedes recorrer en cualquier orden sin perder nada: ¿qué quieres montar?, tu negocio y el flujo. Publicar está siempre a mano para quien ya sabe lo que hace. Dentro del primer paso hay tres caminos, del más rápido al más fino:

• Descríbelo y Mycel lo monta. Escribe qué quieres («un asistente para mi gestoría que resuelva dudas de nóminas e IVA y derive al asesor de cada oficina») y el modelo de tu Nodo genera el grafo entero, con sus caminos. Suele tardar menos de un minuto.
• Parte de una plantilla. Hay 17, y cada una se ve como una tarjeta que dice de cuántos pasos consta, qué datos pide y si usa tus documentos, pasa a una persona o avisa a tu CRM: atención al cliente, captación de leads (normal y avanzada, con envío al CRM), reservas/citas, FAQ documental, soporte técnico con escalado, cualificación B2B, encuestas, agendar demo, quejas, RRHH, e-commerce y sectoriales (inmobiliaria, clínica, restaurante, seguros, asesoría).
• Editor visual de nodos. Arrastra los nodos, pulsa uno para editar su mensaje, lo que recoge y sus transiciones. Es el mismo grafo, en visual.

Hay un cuarto camino, sin formularios: montarlo conversando desde Conexiones. Ahí Mycel te pide las credenciales del canal una a una, las comprueba y deriva el flujo. Es el camino corto si lo que quieres es un bot de Telegram, WhatsApp o Slack.

Elegir una plantilla o generar un flujo reemplaza el que tengas. Si ya habías trabajado en él, Mycel te lo pregunta antes en vez de machacarlo.

2. El grafo de flujo

Un chatbot es un grafo de nodos unidos por transiciones:

• Nodo: un paso con un objetivo. Puede decir algo, recoger datos (nombre, email…), usar tu documentación (RAG) para responder solo desde ella, o escalar a una persona.
• Transición: «si el visitante pide una cita → nodo reservar». El LLM habla natural dentro de cada nodo; el grafo pone la estructura.
• Acción (grafo avanzado): un nodo puede actuar, no solo conversar. Al recoger un lead, lo envía a tu CRM por webhook y te avisa por Telegram. El bot trabaja de verdad.

3. Dónde y cómo conectarlo

• Tu web (WordPress, PrestaShop, Shopify, HTML, PHP): copia el snippet y pégalo antes de </body>. Muestra una burbuja de chat y avisa de que es una IA (AI Act).
• Telegram: crea un bot con @BotFather, pega su token al publicar. Tu Nodo sondea los mensajes y responde con el mismo grafo.
• WhatsApp (Cloud API de Meta): pega el access_token y el phone_number_id. Configura el webhook con la URL que te da Mycel (lleva un secreto para que nadie más pueda escribirle).
• Slack: pega el bot_token y apunta el Event Subscriptions a la URL de webhook con secreto.

Sin credenciales de WhatsApp/Slack no pasa nada: publícalo para la web o Telegram y añade los otros canales cuando los tengas, es el mismo bot.

4. Seguimiento y mejora

En el panel de cada chatbot ves las conversaciones (cuántas, escaladas a persona, el último mensaje) para ajustar el flujo. Pulsa Editar flujo y se abre el editor visual con el grafo cargado; guardas y se actualiza en su sitio (mismo enlace).

5. Privacidad y seguridad

• El grafo y tus documentos NUNCA salen del Nodo. De cada bot, el servidor guarda solo la ficha administrativa: su identificador público, de qué cuenta es, qué Nodo lo sirve, el título que le pusiste, los secretos de sus webhooks y, si se lo asignaste, quién es su responsable. El grafo, el conocimiento, las credenciales de canal y las conversaciones viven en tu Nodo.
• Aviso de IA obligatorio en todos los canales (AI Act, ago-2026).
• Endpoint público protegido: rate-limit, el publicId es propiedad inmutable de su dueño, cada webhook lleva su secreto (y el de Slack verifica además la firma de Slack), y las acciones (webhooks al CRM) pasan por el guardián anti-SSRF.

Recomendado servirlo desde un Nodo Cloud europeo para que esté disponible 24/7 y los datos permanezcan en la UE.

Chats: cuando el bot pasa la conversación a una persona

Un chatbot bien montado sabe hasta dónde llega. Cuando un visitante pide hablar con alguien, la conversación se escala: el bot se aparta y aparece en Chats, con el número de las que siguen esperando en el menú y en el Panel. Respondes desde ahí y tu mensaje le llega al visitante por su mismo canal, sea la web, Telegram, WhatsApp o Slack.

Cada tarjeta es un bot, con sus conversaciones escaladas, cuántas están sin responder y quién es el responsable si se ha asignado. Al abrir una ves la transcripción entera (turnos del Visitante, del Bot y de cada persona que haya intervenido, con su nombre) y escribes debajo. Mientras atiendes tú, el bot no vuelve a meterse: cada mensaje que mandas renueva ese turno tuyo, y el bot solo vuelve a responder si la conversación se queda un cuarto de hora sin que intervenga nadie. Está pensado para que un visitante que escribe al día siguiente no se quede esperando a una persona que ya cerró el portátil.

«Sin responder» significa algo concreto

Una conversación cuenta como pendiente cuando está escalada y el último turno no lo escribió una persona. Ese es el número del distintivo del menú y el del aviso del Panel: siempre el mismo, porque lo calcula el servidor una vez y no cada pantalla por su cuenta.

Quién ve y quién responde

Los chats de un bot no los ve todo el equipo del Nodo. El reparto es este, y conviene saberlo antes de chocar con él:

• Dueño y administrador del Nodo: ven, responden y asignan responsable.
• Supervisor: ve las conversaciones y no puede responder. Es un rol de auditoría, y contestarle a un cliente no lo es.
• Operador: solo ve los bots que le hayan asignado; en ellos responde como el dueño. Sin asignación, el bot no le aparece.
• La persona asignada a un bot lo ve y lo responde, sea cual sea su rol.

Asignar un responsable se hace desde Chatbots y es lo que convierte «alguien contestará» en «contesta esta persona»: además de darle acceso, es el contacto al que el bot avisa al escalar.

El Nodo del chatbot tiene que estar encendido. Las conversaciones, como el propio bot y las credenciales de sus canales, viven allí: Mycel solo hace de cable. Con el Nodo apagado la pantalla te dice exactamente eso, y no «no hay conversaciones»; responder devuelve un aviso claro en vez de perder tu mensaje. Si lo que falla es tu rol, también te lo dice, para que no confundas «no puedo» con «está roto». Ver Equipos.

Conexiones: tus cuentas, y bots montados conversando

Conexiones es la pantalla donde Mycel se enchufa a lo que tu empresa ya usa: tu facturación, tu CRM, tu tienda. Hace dos cosas distintas y conviene tenerlas separadas en la cabeza: guardar credenciales (para que el agente pueda usarlas en tus tareas), que es lo que da nombre a la pantalla, y montar un chatbot para un canal solo conversando, que es una acción que también vive ahí porque necesita esas mismas credenciales.

Esta pantalla necesita un Nodo encendido para hacer nada, y no es un capricho de la interfaz: las credenciales se cifran en el Nodo, así que sin Nodo no hay dónde guardarlas. Con todos apagados entras igual, pero lo que verás es un aviso de que hace falta conectar uno. Si el Nodo es de otra persona, hace falta ser su dueño o su admin.

Conexiones: tus cuentas, cifradas en tu equipo

Una Conexión es un juego de credenciales con nombre. Se guarda cifrada en tu Nodo (AES-256-GCM, en ~/.mycel/connections/) y el servidor de Mycel solo ve la ficha: el nombre que le pusiste, qué servicio es y los datos que no son secretos (de un buzón, por ejemplo, el servidor, el puerto y el usuario, para poder enseñártelos en la lista). La contraseña no sale nunca del Nodo, ni ella ni los tokens de OAuth.

• Se comprueba antes de guardar. Cuando el servicio lo permite, Mycel entra de verdad con esas credenciales antes de darlas por buenas. Si el servicio contesta que no, no se guardan: una contraseña guardada «por si acaso» es el dato de más que no queremos en tu disco. Un buzón se comprueba siempre; si lo que falla es la red y no el servicio, la conexión de un conector HTTP sí se guarda, y te lo dice con esas palabras («guardada, pero no pude comprobarla en vivo») para que no la des por buena.
• Varias cuentas del mismo servicio. Atención, facturación, cada oficina: les pones nombre y las distingues.
• El agente las usa por su nombre. «Pásame las facturas de marzo de Holded» funciona porque el Nodo resuelve la credencial en casa; el modelo nunca la ve.

Montar un chatbot conversando (cuatro pasos)

Es el camino corto: eliges el canal y el asistente te lleva de la mano. Va marcando en qué paso estás y se puede cancelar en cualquiera.

1. Credenciales. Te las pide de una en una, explicando de dónde sacar cada una. Los secretos se escriben como contraseña y no salen del Nodo.
2. Comprobación. Telegram y Slack se comprueban contra su API antes de seguir. WhatsApp no: la Cloud API de Meta no ofrece esa comprobación, así que ahí solo se valida el formato y la propia pantalla te lo advierte. Si falla la red, hay un botón para reintentar (no te pide un dato nuevo, porque no falta ninguno).
3. Qué debe resolver. Lo describes con tus palabras y el modelo de tu Nodo deriva el flujo de conversación. Puede tardar cerca de un minuto: lo está pensando tu equipo, no nuestros servidores.
4. Revisar y publicar. Ves el grafo montado y puedes reescribir lo que dice cada paso. Pones el nombre de tu empresa (rellena los huecos del texto) y publicas.

Te puedes equivocar sin empezar de cero: los datos ya introducidos aparecen como etiquetas y pulsando una vuelves a introducirla. Y si cancelas a medias, el Nodo borra de verdad lo que habías escrito, no solo la pantalla.

Copia la URL de webhook cuando te la enseñe. Si publicas para WhatsApp o Slack, esa dirección lleva un secreto dentro y solo se muestra ahí: el panel de Chatbots no la vuelve a enseñar. Sin pegarla en Meta o en Slack, tu asistente no recibe ni un mensaje.

Un asistente que dejas a medias caduca a los 7 días y se borra solo del Nodo. Es a propósito: lo que escribiste sobre tu negocio antes de terminar no tiene por qué quedarse en el disco para siempre.

Para añadir pasos, cambiar las flechas o marcar qué paso consulta tus documentos, publícalo y ábrelo en el editor de Chatbots: esa herramienta vive ahí y no se duplica aquí.

Correo: leer tu bandeja y responder con aprobación

Un correo enviado lleva tu dominio y tu firma, y no se puede retirar. Por eso Correo no atiende sola: enseña tu bandeja y redacta un borrador que tú apruebas, editas o descartas. Cuando lo apruebas, el correo sale de verdad desde tu propio buzón. La persona sigue decidiendo, y no hay forma de quitarla de en medio.

Cómo está repartida la pantalla

Es un cliente de correo: arriba eliges la cuenta, debajo tienes la lista de correos y a la derecha el mensaje y su borrador. Eso es todo lo que se usa a diario. Lo que se toca una vez está detrás de los dos botones de la cabecera, «Configuración» y «Cuentas», que abren la misma ventana por su pestaña correspondiente:

• General. El tono de tu negocio: cómo habláis, qué no prometéis nunca, vuestro horario. Vale para todos tus buzones y cambia una vez al año. El campo se llama «Cómo responde tu negocio».
• Cuentas. Cada buzón, con lo suyo: sus instrucciones («aquí solo llegan facturas de proveedores») y su carpeta de documentos. Aquí también se añade una cuenta nueva y se borra una existente.

Los tres niveles se apilan al redactar, y el más concreto manda: el tono del negocio, luego el del buzón, y encima lo que escribes en qué quieres responder para ese correo.

Todo esto se guarda en tu Nodo, no en nuestro servidor: es texto sobre tu negocio y una ruta de tu disco. Al borrar una cuenta se va con ella.

Añadir tu buzón (IMAP para leer, SMTP para responder)

En Correo → Cuentas añades el buzón de tu empresa. Necesitas los datos del servidor de entrada (normalmente imap.tudominio.es o mail.tudominio.es, puerto 993): están en el panel de tu hosting o en la configuración de Outlook o Thunderbird. Puedes añadir tantos buzones como quieras y darles nombre.

El servidor de salida (SMTP) es opcional y va en esa misma conexión: si lo dejas en blanco se usa el mismo host de entrada y el puerto 587, que es lo correcto en la mayoría de los hostings españoles; de los proveedores que Mycel ya conoce (Gmail, Microsoft 365) sabe además su servidor de salida y lo pone él. Rellénalo si tu proveedor los tiene separados. Va junto y no aparte a propósito: leer y responder son el mismo buzón, así que son la misma credencial y tienen el mismo dueño. Nadie puede responder desde un buzón que no puede leer.

• Entra tu Nodo, no nosotros. Las conexiones IMAP y SMTP las abre tu equipo con las credenciales de su vault, sobre TLS y validando el certificado. Ni el servidor de Mycel ni nosotros vemos tu contraseña ni tus correos.
• Leer es solo lectura, y de verdad. Abre el buzón en modo examen y lee con BODY.PEEK: no marca nada como leído, no mueve, no borra. Tu bandeja queda exactamente como estaba.
• La contraseña nunca sale sin cifrar. Al enviar, si tu servidor no ofrece cifrado (STARTTLS en el 587, o TLS directo en el 465), el Nodo corta antes de mandarla y te lo dice, en vez de intentarlo igual.
• El correo llega ya legible. El Nodo decodifica el MIME en casa y manda texto; el HTML crudo de un correo ajeno no entra en el panel, porque sería una inyección servida en bandeja.

Gmail y Microsoft 365

Esas dos no aceptan una contraseña normal, así que tienen su propia entrada: en Correo → Cuentas, el botón «Añadir un buzón de Gmail o Microsoft 365». Se entra con OAuth2 (XOAUTH2 sobre TLS), que es lo que esos dos exigen desde que retiraron la autenticación básica. En Gmail sigue valiendo además la contraseña de aplicación por la entrada normal, si la prefieres.

Lo que hay que hacer una vez: registrar tu propia aplicación en Google Cloud o en Azure y autorizar tu buzón. De ahí salen tres datos (client_id, client_secret y refresh_token) que pegas en el formulario. A partir de ahí tu Nodo se saca solo los permisos de acceso, cada vez que abre el buzón, y no vuelves a tocar nada: eso es lo que hace que funcione también en una tarea programada de madrugada y no solo mientras miras la pantalla.

El límite honesto: Mycel todavía no abre el navegador para pedirte permiso y hacer ese registro por ti, así que el alta de Gmail y Microsoft 365 es más trabajo que la de un correo de hosting, y se hace una sola vez. Si revocas el permiso desde tu cuenta de Google o de Microsoft, la conexión deja de funcionar y hay que volver a autorizarla: es así a propósito, el permiso lo mandas tú.

La documentación de cada cuenta

En la ficha de un buzón puedes darle una carpeta de tu equipo con lo que haga falta para contestar desde ahí: tarifas, condiciones, modelos de escrito, el histórico de un cliente. Mycel la lee e indexa en tu máquina (los documentos no se copian a ninguna parte y el índice se queda dentro de la propia carpeta), y al redactar busca lo que viene a cuento y cita de dónde sale cada dato en vez de inventárselo. Es la diferencia entre «no puedo confirmarle el plazo» y «según sus condiciones, 30 días desde la factura».

Es por cuenta, no general, porque una gestoría no mira los mismos papeles para contestar desde facturacion@ que desde laboral@. Si añades documentos nuevos a la carpeta, pulsa Guardar y releer los documentos. La carpeta tiene que ser una de las que el dueño del Nodo te haya concedido: es el mismo reparto que gobierna el explorador de archivos y las tareas.

Hace falta un modelo de embeddings en el Nodo para construir el índice (con Ollama, por ejemplo nomic-embed-text). Si no lo hay, la pantalla te lo dice al guardar en vez de callarse; el borrador se sigue redactando, solo que sin citar documentos.

Sin buzón añadido: la bandeja de muestra

Mycel trae una bandeja de doce correos de ejemplo de una gestoría (una factura, un plazo, una queja, algo de Hacienda, un proveedor). Sirve para ajustar el tono antes de darle acceso a tu correo real, que es justo el orden en que una empresa quiere probar esto. Con ella, aprobar no manda nada porque esos correos no existen y no hay a quién contestar, y la pantalla lo dice con esas palabras. Cuando ya no la necesites, se quita desde Correo → Cuentas como cualquier otra cuenta (y se puede volver a poner).

El borrador: tres textos tuyos, y no son el mismo

El tono del negocio (Configuración → General) cambia poco y vale para todos tus buzones. Las instrucciones de la cuenta (Cuentas → ese buzón) dicen a qué se responde desde ESE buzón. Y qué quieres responder se escribe junto al borrador, porque cambia en cada correo: «que sí, que se lo mandamos el jueves», «que la factura ya está pagada». Sin ese último, el borrador sale correcto y genérico, que es justo el que nadie llega a enviar. Puedes reescribirlo y pulsar Rehacer las veces que haga falta, sin perder lo escrito.

Aprobar y enviar: sale de verdad, y lo mandas tú

Al pulsar Aprobar y enviar el correo sale: el Nodo habla SMTP con tu propio servidor y la respuesta va desde tu misma dirección, la que lee la bandeja. Ya no se puede retirar.

No hay modo automático, y no es una casilla que falte por hacer. Un correo enviado lleva tu dominio y tu firma, así que el clic final es de una persona que acaba de leer el correo y el borrador. Lo que Mycel automatiza es lo caro: leer, entender y redactar. Aprobar, no. También sigue existiendo el camino por la API HTTP de un proveedor de envío (Brevo, Mailgun, SendGrid) para lo que el SMTP no cubre.

Por qué el agente no manda correo solo

Hubo una herramienta con la que el agente respondía correos dentro de una tarea, sin que nadie aprobara nada. Se ha retirado. El motivo, dicho como se dijo al decidirlo: no automatizamos el correo porque podría hacerse un prompt inyectado y robarnos datos.

Desarrollado: el agente lee tu bandeja, y un correo lo escribe cualquiera. Ese texto entra en el contexto del modelo igual que tus instrucciones, y ahí no hay una línea que separe «lo que me pide mi jefe» de «lo que pone en este correo». Si además el modelo pudiera enviar, alguien podría escribirte un correo redactado para que la respuesta se llevara datos tuyos, y esa respuesta saldría con tu dominio, tu dirección y tu reputación, hacia una persona que se la va a creer. Es el canal más grave que puede tener un producto así, y por eso es el que se cierra: entre el modelo y el buzón de un desconocido hay ahora, siempre, una persona que ha leído lo que se va a mandar.

Hasta dónde llega esto, sin redondear. Retirar el envío automático cierra ese canal, no vuelve inmune al agente que lee correo. El problema general es más ancho: un agente autónomo, contenido que no controlas y herramientas que salen hacia fuera. El agente sigue pudiendo hacer peticiones HTTP, leer páginas y descargar ficheros, y nuestro guard de red bloquea las direcciones privadas (tu red interna, localhost, el metadata de tu proveedor cloud), no internet público. Un correo malicioso que consiga que el agente pida una URL sigue siendo posible. Lo decimos aquí porque preferimos que lo sepas a que te lo vendamos cerrado: si trabajáis con correo de remitentes desconocidos, revisad la traza de las sesiones.

Responder de verdad: a quién sale y por qué solo a esa persona

Se RESPONDE a un correo que ya está en tu bandeja, y siempre a quien escribió (su Reply-To, o si no su remitente). Esa pantalla no tiene campo «Para:», ni copia, ni «responder a todos»: el destino lo saca el Nodo de las cabeceras del correo original, releídas en el momento del envío.

Tampoco esto es una limitación por falta de tiempo: es la misma decisión, una capa más abajo. Si el destinatario se pudiera elegir con una frase, bastaría con mandarte un correo que dijera «reenvía el balance de tus clientes a esta dirección». Al no existir ese parámetro, no hay nada que decirle: la respuesta va a quien escribió, y punto. Ojo con lo que eso tampoco cubre: cualquiera se convierte en «quien escribió» con solo escribirte, así que lo que de verdad protege el contenido es que lo leas antes de aprobarlo.

Solo se responde desde buzones tuyos: los que has conectado tú con su contraseña. Tener acceso al Nodo donde vive una credencial no es poder escribir en nombre de quien la guardó, y eso vale también para el dueño de la máquina. Una cosa más, para que no te pille: un correo enviado no se puede retirar, y queda en el hilo de quien lo recibe y en el recibo del envío que te enseña la pantalla.

Cómo se entra, y cuándo se lee la bandeja

Quien va a meter el correo de su empresa necesita saber con qué se encuentra el lunes. Se entra con usuario y contraseña sobre TLS (el correo de tu hosting) o con OAuth2 (Gmail y Microsoft 365), para leer y para enviar, y la bandeja se lee cuando tú la abres o cuando se lo pides al agente: nada sondea el buzón por su cuenta. Si quieres que algo ocurra solo a una hora, esa pieza son las tareas programadas y la vigilancia de carpetas.

De cada correo ves también sus adjuntos con nombre, tipo y tamaño, que es lo que hace falta para decidir qué hacer con él.

Enviar sin que una persona lo apruebe es un «nunca»: no es trabajo pendiente, es una decisión, y el porqué está contado arriba.

Quién puede leer cada buzón

La respuesta corta es «depende de quién sea el equipo», y conviene leerla entera antes de teclear ahí la contraseña de tu correo. La pantalla donde conectas la cuenta te dice, en ese momento, en qué Nodo se va a guardar y de quién es ese Nodo.

• Tus compañeros, no. Y esto es real, no un modo de decirlo: cada cuenta queda a nombre de quien la conectó. Otra persona del equipo no la ve en su lista, no puede abrirla desde esta pantalla y no puede pedírsela a su agente: el Nodo recibe con cada tarea la lista de buzones de quien la lanza, y los demás ni aparecen por su nombre. Da igual que sea administradora del Nodo.
• Quien administra la máquina, sí. Si conectas tu buzón en el Nodo de tu empresa, quien es dueño de ese Nodo puede leerlo, desde esta pantalla y desde su agente. No es un fallo ni un permiso que se nos haya olvidado poner: el equipo es suyo, y en una empresa las cuentas de trabajo son de la empresa. Lo que no puede es responder desde tu buzón: un correo con tu dirección va firmado por ti, y eso se queda para su dueño.
• En tu propio Nodo, solo tú. Un Nodo doméstico o un servidor cloud tuyo no tiene más dueño que tú, así que la pregunta ni se plantea.

De ahí la regla práctica: si quieres que no llegue nadie más que tú, la respuesta es tu propio Nodo, no una casilla dentro de Mycel. Elegir dónde vive tu correo es la decisión, y por eso te la ponemos delante cuando la tomas.

Y sin maquillarlo. Aunque no dejáramos entrar por la pantalla, quien tiene el Nodo en su mesa tiene el disco: con acceso a esa máquina (o con permiso para ejecutar comandos en ella) se llega al almacén cifrado de todas formas, porque la clave está en el mismo equipo. Preferimos decirlo a prometer una separación que el sistema no puede sostener: la separación entre compañeros es real; la separación frente al dueño de la máquina no lo es. Lo mismo vale, un escalón más allá, para quien administre el servidor físico de un Nodo cloud. Está desarrollado en Seguridad.

Y no hay interruptor de «compartir con el equipo»: si dos personas atendéis info@empresa.com, cada una lo conecta con la contraseña que le hayan dado, y cada una le pone su tono. El email es el email: quien reparte el acceso a un buzón es quien reparte su contraseña, y eso pasa en vuestro proveedor de correo, no aquí. Duplicarlo dentro de Mycel era una segunda opinión sobre la misma puerta. Ver Equipos.

El agente también puede leer la bandeja por ti, sin abrir esta pantalla. Se le pide en una tarea normal: «mira si ha entrado la factura de Hacienda» o «resume los correos sin leer de hoy». Es la misma conexión y las mismas reglas de arriba, ni una más ni una menos: el agente alcanza exactamente los buzones que tú alcanzas en esta pantalla. Lo que no hará es contestar: te dejará el texto. Cómo funcionan las tareas, en Primeros pasos.

Automatizaciones: encargos que se ejecutan solos

Un encargo que se repite sin que tú estés delante: por tiempo («cada lunes a las 9 revisa la carpeta de facturas y hazme un resumen») o por cambio en una carpeta («cuando entre un PDF aquí, extráeme los datos»). Las ves todas en Automatizaciones, en el menú.

Cómo se crean

Pidiéndoselo al agente en una sesión normal, con tus palabras. No hay formulario de cron: el agente entiende «cada lunes a las 9», «cada hora», «dentro de un minuto» o «cuando entre un fichero en esta carpeta», registra la automatización y te confirma qué ha programado. Si le pides algo recurrente y lo hiciera una sola vez, la propia tarea se marca como incorrecta y te lo dice: programar y hacer no son lo mismo.

• Por tiempo: cada N minutos/horas, cada día a una hora, un día concreto de la semana a una hora, o una sola vez dentro de un rato.
• Por fichero: vigila una carpeta del workspace y se dispara cuando entra o cambia un fichero (y, si lo pides, en sus subcarpetas). Es reactivo: no consulta cada X, salta con el evento del sistema de ficheros.

El reloj vive en tu Nodo

Ni el horario ni el contenido del encargo se guardan en el servidor de Mycel: viven en tu Nodo, igual que todo lo demás (ver Soberanía). Consecuencia directa y buscada: con el Nodo apagado no se ejecuta nada, y la pantalla lo dice con esas palabras en vez de enseñarte una lista vacía. Si necesitas que se disparen a las 3 de la mañana, ese Nodo tiene que estar encendido; para eso está el Nodo Cloud.

Qué puedes hacer con cada una

• Ejecutarla ahora, sin esperar a su hora, para comprobar que hace lo que creías.
• Pausarla y reanudarla. Pausada sigue en la lista: se para, no se pierde.
• Borrarla.
• Asignarle un responsable del equipo (operario o admin): la ve en su lista, puede pausarla y sus ejecuciones quedan trazadas a su nombre. Ver Equipos.

De cada una se dice cómo fue la última vez, no solo cuántas veces ha corrido: «5 ejecuciones» se lee como cinco aciertos y podían ser cinco fallos seguidos. Si la última falló, sale el error. Un Nodo antiguo no manda ese dato y entonces no se afirma nada, que no es lo mismo que decir que salió bien.

Los resultados se anexan a la sesión que pidió la automatización, así que el historial de cada disparo se lee entero ahí. Y una automatización corre a nombre de quien la creó, con sus permisos: en cada disparo se vuelven a preguntar al servidor, así que quitarle a alguien la capacidad de ejecutar comandos o revocarle un buzón surte efecto en el siguiente. Ver Equipos.

La carpeta es la excepción, y conviene saberlo: queda fijada en la automatización el día que se crea, no se vuelve a consultar. Si le estrechas a alguien las carpetas concedidas, sus automatizaciones ya programadas siguen apuntando a la que tenían. Para cortarlo del todo hay que borrarlas: el dueño del Nodo y sus admin las ven todas en Automatizaciones y son los únicos que pueden borrarlas (pausar puede además el responsable asignado).

Equipos: compartir Nodos, permisos y trazabilidad

Una empresa puede dar de alta un Nodo potente (o varios) y dejar que sus trabajadores lo usen, con permisos al detalle. Es como compartir un repositorio en GitHub: invitas por email a un usuario ya registrado en Mycel (no se envían correos) y le das un rol. El Nodo debe estar activo para gestionar su equipo: tiene su propio almacenamiento (en el equipo local o en tu servidor cloud), y solo un Nodo conectado puede enseñar sus carpetas reales.

Roles por Nodo

• Admin: co-responsable. Usa el Nodo, gestiona los accesos y ve/exporta toda la actividad.
• Operador: ejecuta tareas y ve/exporta solo las suyas.
• Supervisor: solo lectura. Ve y exporta toda la actividad del Nodo (el gerente que necesita saber qué hace Mycel en cada equipo).

Permisos de carpetas del Nodo

El Nodo es una máquina con su propio almacenamiento. Para cada trabajador eliges a qué carpetas del Nodo accede, explorándolas en vivo: «Ninguna (carpeta aislada)», «Solo las que elija» (p. ej. la del Cliente A, y sus subcarpetas) o «Todas las del Nodo». Así el asistente de un operario accede a los ficheros del Cliente A pero no a los del Cliente B, según su trabajo. Los accesos se puedeneditar y quitar cuando quieras. Si te falta una carpeta, el explorador tiene un botón Nueva carpeta para crearla en el Nodo sin entrar por SSH: es justo lo que hacía falta para dar de alta un servidor recién alquilado.

Este reparto vale para cualquier rol, incluido el Admin: gestionar el equipo no es una llave maestra sobre los datos. Un admin al que le pusiste «ninguna carpeta» no explora el disco del Nodo, y uno con carpetas concedidas solo ve (y solo puede conceder a otros) lo que él mismo tiene. Son dos ejes a propósito: el rol dice qué operacionespuede hacer alguien; esto, sobre qué datos.

Tampoco se sale por la puerta de atrás: la ruta se resuelve de verdad antes de decidir, así que ni con .., ni con una ruta absoluta, ni con un acceso directo. Una junction de Windows (que cualquiera puede crear, sin ser administrador) colocada dentro de la carpeta del Cliente A y apuntando a la del Cliente B no sirve para leer ni para escribir allí.

La capacidad que se concede aparte

Hay algo que el reparto de carpetas no puede contener, y por eso es un permiso independiente que viene apagado:

• Ejecutar comandos del sistema. Quien lo tiene alcanza lo que alcance la cuenta que ejecuta el Nodo, incluidas tus credenciales guardadas. No es un contenedor: si le das esto, le das la máquina. Un miembro puede trabajar con documentos, datos, informes y chatbots sin tenerlo.

El correo no se reparte con permisos

Aquí hubo dos casillas más, «leer el correo» y «responder el correo», y se retiraron. En su lugar hay dos reglas más simples y más difíciles de equivocar:

• Cada cuenta es de quien la conecta. Se da de alta con su contraseña en Correo y queda a su nombre: un compañero no la ve, no la abre y no puede pedírsela al agente, ni siendo administrador del Nodo. Si dos personas atendéis soporte@empresa.com, cada una lo conecta por su lado, con su tono y su contexto. El email es el email: quien reparte el acceso a un buzón es quien reparte la contraseña, y eso pasa en vuestro proveedor de correo, no en Mycel.
• El dueño del Nodo es la excepción, y se dice en pantalla. Los buzones conectados en su máquina los lee él: es su equipo, y en una empresa las cuentas de trabajo son de la empresa. Responder desde ellos, no. Quien necesite un buzón privado frente a todo el mundo necesita su propio Nodo, no un permiso: está entero en quién puede leer cada buzón.
• El agente lee y redacta; enviar lo aprueba una persona. No hay permiso que active el envío automático, porque no existe el envío automático. Por qué, justo debajo.

Actualiza los Nodos antes de repartir. Para que Mycel pueda garantizar que un miembro no ejecuta comandos, o que solo abre sus buzones, el Nodo tiene que saber aplicar ese límite. Un Nodo con una versión anterior no sabe, y entonces Mycel prefiere rechazar la tarea antes que prometer un límite que no se cumple: la persona verá un aviso pidiendo actualizar el Nodo, con el enlace para hacerlo. Al dueño no le afecta: en su propia máquina no hay nada que restringir.

Para supervisión de solo lectura, sin ejecutar ni tocar la máquina, usa el rol Supervisor: no ejecuta, así que la conversación del shell ni se plantea. Y si dos grupos no deben ver los datos del otro, no es cuestión de permisos: hace falta un Nodo por oficina.

Trazabilidad y exportación (lo que exige la UE)

Cada tarea queda etiquetada con quién la ejecutó y en qué Nodo. Desde el panel, el dueño o un supervisor pueden exportar toda la actividad del Nodo en un JSON: las sesiones con su registro completo (qué pensó y qué hizo el agente), las conversaciones de los chatbots (los datos de tus clientes) y las tareas programadas. Todo vive en el Nodo (el equipo del dueño), nunca en mycel.es, y es portable como exige el derecho de acceso y portabilidad del RGPD.

Asignar chatbots y automatizaciones a un responsable

Cada chatbot y cada tarea programada del Nodo puede tener un responsable(un miembro con rol operador o admin): se asigna desde la ficha del chatbot o desde la automatización. El responsable ve las conversaciones de sus bots (y solo las de los suyos), recibe sus escalados, y las ejecuciones de sus automatizaciones quedan trazadas a su nombre. El dueño, los admin y los supervisores lo ven todo; un operario sin asignaciones no ve ninguna conversación. Asignar es cosa de quien gestiona el Nodo (su dueño o un admin), y solo se puede nombrar a un operador o a un admin: un supervisor no, porque responderle a un cliente no es auditar.

Escalado a una persona y Chats en vivo

Cuando un chatbot pasa la conversación a «una persona», Mycel avisa al responsable asignado (a su Telegram, que él pone en su Cuenta, o a su email; si el bot no tiene responsable, al destino fijo que configures: Telegram, email o webhook a tu sistema de tickets) con el contexto y los datos recogidos. Además, la conversación aparece en el Chats de la web: el responsable la retoma en vivo, sus respuestas llegan al cliente por su canal original (el widget de la web, Telegram, WhatsApp o Slack) y, mientras atiende, el bot se aparta y no interviene. Todo el contenido sigue viviendo en el Nodo; la plataforma solo lo retransmite a quien puede verlo.

El aviso sale por un canal que el bot TENGA, porque lo manda tu Nodo con tus credenciales, no nosotros por ti: el de Telegram necesita el token del bot de Telegram, y el de email necesita que le des al asistente una clave de envío (Brevo o SendGrid) en su canal de correo. Sin ese canal, el destino sencillamente no entra en la lista de avisos. No se queda en silencio: el Nodo lo dice por su salida con el motivo exacto, y la conversación aparece igualmente en Chats, que es donde de verdad se atiende. El webhook a tu sistema de tickets no necesita credenciales de canal: es una URL tuya.

Soberanía del dato y AI Act

Desde el 2 de agosto de 2026 el Reglamento Europeo de IA (AI Act) aplica plenamente y, junto con el RGPD, obliga a las empresas a controlar a dónde van los datos y a ser transparentes con la IA (con sanciones de hasta 35 M€ o el 7 % de la facturación global). La arquitectura de Mycel te da la base para cumplir:

• El dato no sale de la UE. El Nodo corre en tu equipo o en un servidor tuyo en Europa, con modelos locales (Ollama) o de un proveedor europeo. Así evitas las transferencias de datos personales a IA de fuera de la UE que el RGPD (Cap. V) restringe.
• Transparencia y trazabilidad. Cada acción del agente queda registrada en tu Nodo, con verificación de resultados; los chatbots que generes avisan de que son una IA.
• Sin retención en el servidor. El servidor de Mycel es un relevo sin estado: no guarda el contenido de tus tareas ni tus documentos.

Mycel es la herramienta que te aporta soberanía y control; la responsabilidad última del cumplimiento normativo es de cada empresa según su caso de uso.

Workspaces: tus proyectos reales

Por defecto cada tarea trabaja en un sandbox aislado: perfecto para experimentos. Para que Mycel trabaje sobre un proyecto tuyo (código, documentos, datos), registra su carpeta en Panel → Workspaces (ruta absoluta en el disco del equipo donde corre el Nodo) y elígelo al crear la sesión.

• El agente empieza leyendo tu proyecto (estructura, README, manifiestos) y busca en el código antes de tocar nada.
• Hace cambios mínimos respetando tu estilo, y los verifica ejecutando el proyecto o sus tests.

La lista de workspaces es tuya, no de un Nodo

Un workspace se ata a tu cuenta, no al equipo donde lo diste de alta, y es a propósito: tus proyectos te siguen entre tus Nodos sin volver a registrarlos. La consecuencia conviene saberla, porque la lista no distingue entre tus equipos: una ruta que solo existe en el portátil se te ofrece igual cuando eliges el sobremesa, o un Nodo Cloud, donde esa carpeta no existe.

Cuando pasa, el Nodo lo dice y para: «El workspace "X" no existe en este equipo. Comprueba la ruta en Panel → Workspaces». No cae al sandbox por su cuenta, que sería la forma callada de trabajar media hora sobre la carpeta equivocada. La regla práctica es una ruta, un equipo: si el Nodo es un servidor, regístrale rutas de ese servidor con el botón Explorar del Panel, que recorre sus carpetas reales y las escribe por ti.

Qué toca el agente ahí dentro

Un workspace es la carpeta de verdad, no una copia, y elegirla es la decisión de seguridad de la sesión. Esto es lo que alcanza el agente:

• Escribe, edita, mueve y borra ficheros dentro de esa carpeta, y el borrado alcanza también a subcarpetas enteras. Cada operación queda en la traza de la sesión, con su ruta.
• Los comandos que ejecuta corren con los permisos de la cuenta que abrió el Nodo, no dentro de un contenedor: llegan hasta donde llegue esa cuenta en la máquina. Por eso ejecutar comandos es un permiso aparte, y viene apagado para los miembros de tu equipo.

De ahí la recomendación: apunta el workspace a la carpeta del proyecto, no a la raíz del disco ni a tu carpeta de usuario entera. Cuanto más estrecho es el destino, menos hay que revisar después.

Recetas: cómo aprende tu agente

Tu agente no empieza en blanco y no aprende del trabajo de desconocidos. Son dos fuentes, y solo dos:

• El recetario curado. Un libro de recetas que escribimos y mantenemos nosotros, con el método que funciona en las tareas típicas (analizar un CSV, montar un entregable Office, investigar citando fuentes). Viaja con el producto: lo tienes desde la primera tarea, sin haber ejecutado ninguna.
• Lo que aprende contigo. Al terminar un encargo con éxito, tu agente destila su forma (el tipo de tarea, el tipo de entregable y las herramientas que hicieron falta), y esa receta solo se le sirve a tu cuenta. No cruza a otra, ni llega a la tuya lo aprendido en otra.

Los dos carriles se sirven con criterios distintos, y a propósito. Una receta aprendida tiene que ganárselo: solo se sirve cuando ha demostrado, con medición, que mejora el resultado frente a no usarla, y si no lo demuestra se aparta. Una curada se sirve además cuando encaja de lleno con la tarea que tienes delante, sin esperar a esa medición: la hemos escrito y revisada nosotros, así que no hace falta que se gane la confianza primero. La distinción no es cosmética: lo que nace de un éxito que se reporta a sí mismo se mide antes de servirse. Y lo que guarda es forma, no contenido: nunca el texto de tu encargo, ni tu código, ni nombres de archivo, ni rutas. Ese micelio, lo que crece en tu casa y se queda en ella, es lo que da nombre al producto. Detalles en Privacidad.

Solución de problemas

Windows: «Windows protegió su PC» (SmartScreen) al abrir el .exe

Es el aviso normal de Windows para programas nuevos sin firma de fabricante; no significa que haya un virus. Pulsa «Más información» y luego «Ejecutar de todos modos». Solo aparece la primera vez.

En macOS dice que no se puede abrir / desarrollador no identificado

La primera vez ábrelo con clic derecho → Abrir (o quita la cuarentena con xattr -d com.apple.quarantine mycel-mac-arm64).

Quiero cambiar el token guardado

Abre el Nodo con --reset (o borra ~/.mycel/config.json) y pega el nuevo.

«No tienes ningún Nodo conectado»

El Nodo no está abierto o el token es de un Nodo borrado. Ábrelo de nuevo y comprueba que dice «Esperando tareas».

El Nodo dice «Token de Nodo caducado: se regeneró desde el Panel»

Este Nodo no se ha borrado: alguien regeneró su token desde el Panel, y regenerar invalida el anterior al instante. No crees un Nodo nuevo (perderías su historial, sus permisos y las carpetas concedidas): copia el comando de conexión en Panel → Nodos → ficha del Nodo (el icono de copiar de su fila) y relanza el mismo Nodo. Si no has sido tú, el aviso es justo lo que querías ver: alguien está usando una copia del token viejo, y queda anotado con su dirección.

Una persona del equipo recibe «Este Nodo usa una versión antigua…»

Ese Nodo no sabe aplicar todavía el límite por miembro que hace falta: ejecutar comandos, o qué buzones de correo puede abrir cada persona. Mycel prefiere rechazar la tarea antes que prometer un límite que no se cumple. La salida es actualizar el Nodo (descarga el binario nuevo en Panel → Nodos → ficha del Nodo, el icono de copiar de su fila, y relánzalo: el token guardado sigue valiendo y no hay que regenerar nada); en el caso de la shell vale también concederle la capacidad en Equipo, si de verdad debe tenerla. Al dueño no le afecta.

Dejé un asistente a medias y ya no está

Los asistentes sin terminar caducan a los 7 días y el Nodo los borra solos, junto con lo que hubieras escrito. Es a propósito: esos datos no tienen por qué quedarse en tu disco indefinidamente. Vuelve a empezar desde Conexiones; son cuatro pasos.

«Ese archivo pesa X y el límite de descarga por el relay es de 256 MB»

Los ficheros del Nodo se descargan pasando por la plataforma, y ahí hay un tope. No se ha bajado nada a medias a propósito (mejor eso que un archivo cortado que parece bueno): cópialo directamente desde el equipo donde corre el Nodo. Si administras la instancia, el tope se puede cambiar sin recompilar.

El Nodo conecta pero avisa de que no puede ejecutar tareas

No hay ningún cerebro disponible: ni Ollama con modelos ni claves de API. Modo local: comprueba ollama list y descarga un modelo (ollama pull qwen2.5-coder:14b). Modo API: relanza el comando del Nodo añadiendo --openai-key=… o --anthropic-key=…. La propia terminal del Nodo te indica las dos opciones.

Elegí un modelo y la tarea usó otro

Es el fallback automático: el modelo elegido no está instalado en el Nodo que ejecutó la tarea, así que usó el mejor disponible y lo dejó anotado en el timeline. Para usar el que pediste: ollama pull <modelo> en ese equipo.

En Windows: ¿necesito WSL, Git Bash o algo más?

No, y de hecho es mejor no usar WSL. Ejecuta el comando de conexión en PowerShell o CMD de Windows: el Nodo es nativo, detecta y verifica el intérprete del sistema (cmd.exe) y las herramientas de archivos son multiplataforma. El Nodo es un ejecutable: no necesitas instalar Node ni nada más (solo Ollama si usas el modo local). Si el agente necesita una herramienta que no tienes (por ejemplo Python), te lo dirá en el timeline con el enlace para instalarla.

Errores «WSL (… - Relay) … execvpe(/bin/bash) failed»

Estás ejecutando el Nodo dentro de WSL y su bash está dañado (un problema del propio WSL, frecuente tras actualizaciones de Windows). Mycel lo detecta y te lo dice en el timeline en vez de fallar en seco. La solución es sencilla: cierra esa terminal y lanza el mismo comando de conexión en PowerShell (tecla Windows → escribe «PowerShell»). Ahí los comandos del agente funcionan de forma nativa, sin WSL.

«El workspace no existe en este equipo»

La ruta registrada no existe en el equipo donde corre el Nodo (¿lo registraste desde otro ordenador?). Revisa la ruta en Panel → Workspaces. En Windows usa el formato C:\Users\tu-usuario\proyecto.

Errores 401/404/429 con modelos de API

El timeline te lo explica: 401 = clave inválida (revísala en el comando del Nodo), 404 = ese modelo no existe en tu cuenta del proveedor (elige otro en el selector), 429 = cuota o saldo agotado en el proveedor.

El agente termina sin hacer lo que pedí

Los modelos pequeños se pierden con encargos enormes. Trocea: mejor tres tareas concretas que una épica. O elige un modelo más capaz en el selector (local más grande o de API). Cada éxito además aporta recetas que mejoran los siguientes.

¿Cómo elijo el modelo que usa el agente?

En el selector del composer (abajo a la izquierda de la caja de tareas) eliges entre todos los modelos de tus Nodos conectados (locales y de API); la elección se recuerda y aplica a las siguientes tareas y seguimientos. También puedes fijar el modelo por defecto de un equipo con --model=… en su comando de conexión.