Quest AI Workbench

Entorno de trabajo seguro para agentes de IA autocontenido, basado en FastAPI con React frontend. Conecta servicios externos (Gmail, Slack, GitHub, Airtable) mediante OAuth o claves API sin exponer datos sensibles al internet.

¿Qué es Quest?

Quest es una herramienta de trabajo para agentes de IA construida sobre Node.js con FastAPI. Su diseño principal se centra en conectar servicios externos (Gmail, Slack, Telegram, GitHub, Airtable) mediante OAuth o claves API, permitiendo que agentes ejecuten conversaciones sobre esos datos sin exponer información sensible al internet.

Para quién está diseñado

• Equipos que necesitan automatizar tareas repetitivas conectando herramientas internas (Gmail, Slack, Telegram)
• Desarrolladores que crean agentes para analizar documentos PDF o Excel con acceso a datos sensibles del equipo
• Organizaciones que automatizan reportes financieros conectados a APIs de contabilidad o facturación
• Equipos que integran herramientas de productividad como Notion o Trello mediante OAuth

Casos de uso verificados

• Conectar herramientas internas (Gmail, Slack, Telegram) para automatizar respuestas o tareas repetitivas
• Crear agentes que analicen documentos PDF o Excel con acceso a datos sensibles del equipo
• Automatizar reportes financieros conectados a APIs de contabilidad o facturación
• Integrar herramientas de productividad como Notion o Trello mediante OAuth
• Conectar servicios de email corporativo (Outlook, Office 365) para agendar reuniones o enviar notificaciones

Arquitectura y componentes

Quest es un servidor FastAPI de proceso único que sirve tanto la API REST/WebSocket como el frontend React compilado como archivos estáticos. El estado vive en una base de datos SQLite más archivos JSON bajo data/. Los scripts escritos por LLMs ejecutan en contenedores Podman efímeros rootless.

Seguridad por diseño

• Modo privado: agente tiene acceso a servicios conectados pero no al internet
• Modo público: se invierte la postura permitiendo acceso al internet pero cortando el acceso a recursos internos
• Script runner aislado en contenedores Podman con ejecución sandboxada y sin salida de red externa
• Gestión segura de credenciales mediante OAuth o claves API con validación en tiempo de ejecución

Requisitos reales (Debian 12/13)

Packages requeridos: git curl python3 python3-venv nodejs npm podman uidmap slirp4netns. uidmap y slirp4netns son obligatorios para rootless Podman.

Instalación y despliegue

Modo local (desarrollo)

python3 run.py --

Port 9000, throwaway seeded database, canned-account login, no credentials required to boot. Good for a first smoke test.

Producción

python3 run.py --prod

Port 8000, real sign-in, domain restriction. On an unconfigured machine this launches an interactive first-run wizard (scripts/bootstrap_prod.py) que promt por OAuth y Vertex AI.

Persistencia

• Base de datos SQLite para estado del sistema
• Archivos JSON bajo data/ para credenciales y configuraciones
• Script-runner image se reconstruye automáticamente cuando cambia el Dockerfile.script-runner

Red y puertos

• Local: puerto 9000 con login sin credenciales
• Producción: puerto 8000 con autenticación OAuth
• Script-runner usa 10.0.2.2 con socat forwarding para red rootless

Actualización y backup

Para despliegue permanente, front el servidor con reverse proxy para HTTPS (WebSocket upgrade headers, ≥5 min read timeout, large client body size para uploads) y gestiona el proceso con systemd. Los plugins se cargan desde plugins/*/plugin.py o directorios extra en QUEST_PLUGIN_PATH.

Ventajas

• Diseño seguro por defecto: modo privado no permite acceso al internet ni a datos sensibles
• Arquitectura de plugins modularizada: nuevos servicios se integran mediante sistema independiente sin modificar código central
• Script runner aislado en contenedores Podman con ejecución sandboxada y sin salida de red externa
• Modelos soportados: Anthropic Claude, Google Gemini (Vertex AI) vía OpenRouter
• Gestión segura de credenciales mediante OAuth o claves API con validación en tiempo de ejecución

Limitaciones

• Depende de servicios externos que pueden ser inestables o no tener APIs públicas disponibles
• La seguridad depende del entorno de despliegue (host, red, credenciales), no es un componente aislado
• El uso de OAuth puede requerir permisos adicionales en cada proveedor de servicio
• No incluye capacidades nativas de razonamiento profundo o generación de código compleja

FAQ sustentada

¿Qué modelos de LLM soporta Quest?

Quest usa Google Cloud Vertex AI para todos los tráfico de LLM (Claude y Gemini). No hay API key de Anthropic ni Gemini directa. Necesitas un proyecto GCP con Vertex AI enabled y service account key.

¿Requiere Docker/Compose?

No, Quest no incluye Dockerfile oficial ni compose.yml. Usa Podman rootless para script-runner sandbox. Para despliegue permanente, front el servidor con reverse proxy (nginx/caddy) y gestiona con systemd.

¿Cómo configurar OAuth de Google?

En Google Cloud Console: crea OAuth client (Web application), registra redirect URIs (https://quest.yourdomain.com/auth/callback y https://quest.yourdomain.com/auth/google-services/callback), obtén client ID/secret, y usa wizard de bootstrap para escribir en server_config.json.

¿Qué es el script runner?

Los scripts escritos por LLMs ejecutan en contenedores Podman efímeros rootless con networking vía slirp4netns (10.0.2.2 con socat forwarding). El image se construye desde Dockerfile.script-runner y se reconstruye automáticamente cuando cambia el Dockerfile.

¿Cómo actualizar Quest?

Clona nuevo repositorio, ejecuta uv sync para backend deps, cd frontend && npm ci para frontend deps, luego python3 run.py --prod --bootstrap para reiniciar con wizard. Para despliegue permanente, actualiza systemd service y reverse proxy config.