1
Las cuatro piezas, y cuál es la que importa
La consola es la pantalla desde la que encargas trabajo, ves los pasos y descargas lo hecho. El Nodo es un ejecutable que corre en tu ordenador o en tu servidor y es quien realmente ejecuta: abre los ficheros, corre los comandos, llama a las APIs. El relevo es nuestro servidor, y su papel entero es transportar el encargo de la consola a tu Nodo. El modelo es el cerebro, y lo eliges tú: Ollama en local, tu clave de API o un Nodo Cloud.
La pieza que decide todo lo demás es la segunda. En la mayoría de las plataformas el ejecutor vive en el proveedor, así que para trabajar necesita que le subas los documentos. Aquí el ejecutor vive donde tú lo pongas, y esa sola diferencia cambia la conversación de seguridad entera.
2
Qué preguntar cuando compares, en cinco líneas
Dónde se ejecuta la tarea. Qué guarda el proveedor de cada tarea, campo a campo. Si el catálogo de herramientas y conectores es cerrado o admite una API tuya que no esté en la lista. Si el precio escala por usuario o por tarea. Y si puedes irte con el sistema puesto o te llevas solo los ficheros.
Nuestras respuestas, para que las compares con las de otro: se ejecuta en tu máquina; de cada sesión el servidor guarda seis campos sin contenido (identificador, cuenta, estado, fecha y dos punteros internos) porque las columnas del contenido están eliminadas del esquema; hay 42 herramientas y 31 conectores más una entrada de API REST personalizada para lo que no esté; no hay coste por usuario ni por tarea; y el Nodo corre donde tú digas, tu portátil o un servidor vuestro, así que irte es apagarlo, no migrar nada.
3
Y cuando la plataforma la usa un equipo
Un Nodo se comparte con cuatro roles (dueño, admin, operador y supervisor) y con carpetas concretas por persona. Ejecutar comandos de shell es un permiso aparte, apagado por defecto incluso para un admin, porque un comando corre con los permisos del usuario del sistema y ahí ya no hay perímetro de carpeta que valga.
Las automatizaciones no guardan permisos congelados: guardan quién las creó y los comprueban en vivo antes de cada disparo. Si a esa persona le quitas el acceso, la tarea deja de ejecutarse; si el servidor no responde, tampoco se dispara. Es lo contrario de la automatización que sigue corriendo tres años después de que su autor se fuera.