Open Executive

Un sistema de IA que actúa como el equipo ejecutivo virtual de tu empresa — un asesor senior con conocimiento de nivel MBA de Harvard, personalizado para tu negocio específico.

Demo

Un recorrido de Open Executive en acción — míralo en YouTube.

Qué hace

Desarrollado por sentelabs.ai, Open Executive brinda una única voz ejecutiva coherente respaldada por ocho agentes de IA especialistas:

• Chief Strategy Officer (Director de Estrategia) — análisis competitivo, fusiones y adquisiciones, posicionamiento de mercado, OKRs
• Chief Financial Officer (Director de Finanzas) — modelado financiero, levantamiento de capital, unit economics, flujo de caja
• Chief HR/People Officer (Director de RR.HH./Personas) — contratación, compensación, desempeño, cultura
• General Counsel (Asesor Legal General) — contratos, propiedad intelectual, nociones básicas de derecho laboral, cumplimiento
• Chief Operating Officer (Director de Operaciones) — diseño de procesos, gestión de proveedores, escalado operativo
• Chief Marketing Officer (Director de Marketing) — estrategia de go-to-market, marca, comunicaciones, prensa
• Chief Product Officer (Director de Producto) — roadmap, priorización, estrategia de producto
• Board Communications Director (Director de Comunicaciones con el Directorio) — presentaciones para el directorio, relación con inversores, gobernanza

Todas las respuestas provienen de una única voz ejecutiva consistente. La arquitectura interna de agentes nunca se le expone al usuario. Más allá de las preguntas y respuestas, el sistema mantiene una memoria episódica de decisiones e iniciativas pasadas a lo largo de las sesiones, y un planificador (scheduler) integrado puede sacar a la luz de forma proactiva seguimientos y acciones urgentes.

Arquitectura

Mensaje del usuario
    ↓
Orquestador Ejecutivo (claude-sonnet-4-6)
    ↓ tool use → llamadas a especialistas en paralelo
CSO / CFO / CHRO / GC / COO / CMO / CPO / Directorio
    ↓ cada especialista recupera contexto relevante desde ChromaDB
Conocimiento MBA incorporado + Documentos de tu empresa
    ↓
Respuesta ejecutiva sintetizada

Conocimiento (Knowledge) — Dos capas de recuperación por cada llamada a un especialista: (1) Markdown de nivel MBA incorporado (knowledge/builtin/, versionado en git) cargado en ChromaDB al arrancar, y (2) los documentos de tu empresa que subas, fragmentados (chunked) y almacenados en una colección company_docs aparte. El contexto de RAG se inyecta en el turno del usuario, nunca en el system prompt cacheado.

Memoria episódica (Episodic memory) — Después de cada respuesta, un proceso en segundo plano con claude-haiku-4-5 extrae decisiones, iniciativas y consejos clave hacia SQLite. La sesión siguiente arranca con un bloque <past_decisions> para que el Ejecutivo recuerde qué recomendó el mes pasado.

Planificador (Scheduler) — Un ejecutor de tareas integrado reclama las acciones pendientes mediante UPDATE … RETURNING para evitar que se disparen dos veces. La API debe correr como una única instancia; no la escales horizontalmente sin antes controlar (gate) el scheduler.

Cacheo de prompts (Prompt caching) — El system prompt está estructurado de modo que la persona del Ejecutivo, el perfil de la empresa y el índice de conocimiento se cachean por separado (hasta un 85% de aciertos de caché después de los primeros turnos). Nunca se coloca contenido dinámico en un bloque cacheado.

Consulta docs/architecture.md para el diseño completo.

Stack Tecnológico

Capa	Elección
Motor LLM	API de Anthropic Claude
Modelo por defecto	claude-sonnet-4-6 (Ejecutivo + la mayoría de los especialistas)
Razonamiento profundo	claude-opus-4-7 (CSO, CFO, GC, Directorio — con extended thinking)
Backend	Python 3.11 + FastAPI
Gestor de paquetes	uv
Almacén vectorial	ChromaDB (local, embebido)
Memoria episódica	SQLite
Interfaz web	Next.js 15 (App Router) + Tailwind
Licencia	Apache 2.0

Estructura del Repositorio

openexecutive/
├── packages/
│   ├── core/
│   │   └── openexecutive/
│   │       ├── orchestrator/     # Persona del Ejecutivo + bucle de enrutamiento
│   │       ├── agents/           # 8 agentes especialistas
│   │       ├── knowledge/        # Almacén ChromaDB + pipeline de RAG
│   │       ├── memory/           # Perfil de la empresa + memoria episódica
│   │       ├── onboarding/       # Máquina de estados del asistente + constructor de perfil
│   │       ├── prompts/          # Persona + prompts de dominio + gestor de caché
│   │       ├── api/              # App de FastAPI + rutas
│   │       ├── integrations/     # Slack, Email, Telegram, Google Chat, Discord
│   │       ├── scheduler/        # Ejecutor de tareas en segundo plano (instancia única)
│   │       ├── alerts/           # Sistema de alertas proactivas
│   │       ├── audit/            # Registro de auditoría
│   │       ├── architecture/     # Utilidades internas de arquitectura
│   │       ├── workflows/        # Definiciones de flujos multi-paso
│   │       └── cli.py            # CLI con Click
│   └── ui/                       # Interfaz web Next.js 15
├── evals/                        # Escenarios de evaluación + ejecutor con LLM-como-juez
├── fixtures/                     # Fixtures de empresas demo (perfiles, documentos, planteles)
├── scripts/                      # Scripts de operador (secretos de Fly, autenticación de Google)
├── docker/                       # Dockerfile(s) + docker-compose.yml
├── fly.api.toml / fly.ui.toml    # Configuraciones de Fly.io — apps de API + UI de dev
├── fly.api.qa.toml / fly.ui.qa.toml  # Configuraciones de Fly.io — apps de API + UI de QA
├── fly.honcho.toml               # Configuración de Fly.io — app de memoria Honcho (opcional)
└── docs/                         # Documentación de arquitectura + despliegue

Inicio Rápido

# Clonar el repo
git clone https://github.com/SenteLabsAI/OpenExecutive.git
cd OpenExecutive

# Configurar tu clave de API de Anthropic
cp .env.example .env
# Edita .env y agrega ANTHROPIC_API_KEY=sk-ant-...
# Para el inicio de sesión con Google de la interfaz web, completá también el bloque AUTH_*
# (mirá docs/auth.md para los pasos en la Google Cloud Console).

# Iniciar todo
make dev

Toda la configuración vive en ese .env en la raíz del repo — make dev y make docker lo cargan tanto para la API como para la UI (Auth.js necesita AUTH_SECRET / AUTH_GOOGLE_ID / AUTH_GOOGLE_SECRET en tiempo de ejecución). También se lee un packages/ui/.env.local para claves exclusivas de la UI, pero para las claves presentes en ambos archivos, el .env de la raíz tiene precedencia.

Abrí http://localhost:3000 para empezar a chatear con tu ejecutivo. La API corre en el puerto 8000 y la UI en el 3000.

Primer arranque: requiere Python 3.11+ y Node 22+. El uv sync inicial descarga dependencias pesadas de ML (ChromaDB + sentence-transformers/PyTorch), y el primer arranque descarga un modelo de embeddings pequeño (~90 MB) para construir el índice vectorial local — así que el primer make dev tarda unos minutos antes de que la app esté lista. Los arranques posteriores son rápidos.

Para colaboradores que no usan make:

cd packages/core
uv sync
source .venv/bin/activate
uvicorn openexecutive.api.main:app --reload --port 8000

# En una segunda terminal
cd packages/ui && npm install && npm run dev

Ejecutar el Bot de Discord

1. Creá una aplicación de Discord en https://discord.com/developers/applications
2. Activá el intent privilegiado Message Content (Bot → Privileged Gateway Intents)
3. Invitá al bot con los scopes bot + applications.commands
4. Configurá las variables de entorno en .env: DISCORD_BOT_TOKEN, DISCORD_APP_ID, DISCORD_GUILD_IDS
5. Corré la API normalmente — el bot arranca como parte del ciclo de vida (lifespan) de FastAPI cuando DISCORD_BOT_TOKEN está configurado:

make dev

El bot está embebido en el proceso de la API (junto con el poller de email, el scheduler y el resumer) de modo que comparte la misma base de datos SQLite y el almacén vectorial ChromaDB bajo /data en producción. Omití el token para desactivarlo.

Para iterar sobre el código exclusivo del bot sin reiniciar la API, make discord corre el bot como un proceso independiente contra la misma base de datos local.

Los usuarios pueden mandarle un DM al bot, mencionarlo con @mention en un canal (responde en un hilo), o usar los comandos slash /ask y /today. Los comandos slash se sincronizan con DISCORD_GUILD_IDS al instante en el arranque; dejalo en blanco para un registro global (hasta 1 hora de demora de propagación).

Desplegar a producción

Simplemente configurá los secretos en la app de API existente — no hace falta una nueva app de Fly:

flyctl secrets set -a openexec-api-dev \
  DISCORD_BOT_TOKEN=... \
  DISCORD_APP_ID=... \
  DISCORD_GUILD_IDS=...

El acceso de usuarios de Discord se gestiona a través de la UI de /people — agregá una fila de Persona con discord_user_id seteado.

La máquina se reinicia y el bot arranca en el próximo arranque del lifespan. Para desactivarlo en producción: flyctl secrets unset -a openexec-api-dev DISCORD_BOT_TOKEN.

Onboarding de tu Empresa

La primera vez que visites la app, se te guiará a través de un asistente para configurar el perfil de tu empresa:

• Datos básicos de la empresa (nombre, industria, etapa, tamaño del equipo)
• Modelo de negocio e ingresos
• Panorama competitivo
• Prioridades estratégicas
• Cultura y valores
• Opcional: posición financiera, carga de documentos

Después del onboarding, el Ejecutivo hará referencia al contexto específico de tu empresa en cada respuesta.

Interfaces

Interfaz	Cómo se usa
Interfaz web	http://localhost:3000
Slack	Mencioná @OpenExecutive o mandale un DM a la app
Email	Poné en copia (CC) o escribí al correo configurado (poller IMAP/SMTP)
Telegram	Mandale un mensaje al bot configurado
Google Chat	Mencioná la app en un espacio
Discord	Mandale un DM al bot, mencionalo con @mention en un canal, o usá los comandos slash /ask / /today
CLI	openexecutive chat

Carga de Documentos

Subí tu pitch deck, modelo financiero, documentos de estrategia, o cualquier documento de la empresa a través de la interfaz web o la API. El Ejecutivo los referenciará cuando sea relevante.

# Vía CLI
openexecutive upload deck.pdf model.xlsx strategy.md

# Vía API
curl -X POST http://localhost:8000/documents \
  -F "file=@deck.pdf" \
  -F "domain=strategy"

Despliegue (Fly.io)

Dos entornos, cada uno con su propio conjunto de apps de Fly, controlados por rama:

Entorno	Disparador	Workflow	Apps
dev	push/merge a main (continuo)	.github/workflows/deploy.yml	openexec-api-dev, openexec-ui-dev
qa	push/merge a qa (promoción deliberada)	.github/workflows/deploy-qa.yml	openexec-api-qa, openexec-ui-qa

Ambos workflows usan dorny/paths-filter para desplegar solamente la app que cambió (API, UI, o ambas). QA es un gemelo estable de dev — misma imagen y runtime, solo difiere el nombre de la app (fly.api.qa.toml / fly.ui.qa.toml) — así que va detrás de main y se mantiene verificado. Una app opcional de memoria Honcho (fly.honcho.toml) se despliega de forma independiente.

Topología

App	Propósito	Estado
openexec-api-{dev,qa}	FastAPI + scheduler	Volumen persistente executive_data en /data
openexec-ui-{dev,qa}	Next.js 15	Sin estado (stateless)
openexec-honcho-dev	Memoria por persona de Honcho (opcional)	Respaldada por Postgres

⚠️ Solo instancia única: El scheduler reclama filas mediante UPDATE … RETURNING. Correr dos máquinas de API dispararía dos veces las acciones programadas. max_machines_running = 1 está seteado en fly.api.toml / fly.api.qa.toml — no lo sobrescribas.

Secretos requeridos de GitHub Actions

Los despliegues se autentican con tokens de despliegue de Fly por app, almacenados como secretos de Actions del repo (o de la organización). Generá cada uno con flyctl tokens create deploy -a <app> -x 999999h:

Secreto	App	Usado por
FLY_API_TOKEN_API	openexec-api-dev	dev
FLY_API_TOKEN_UI	openexec-ui-dev	dev
FLY_API_TOKEN_HONCHO	openexec-honcho-dev	dev (tarea de honcho)
FLY_API_TOKEN_API_QA	openexec-api-qa	qa
FLY_API_TOKEN_UI_QA	openexec-ui-qa	qa

Los secretos de runtime por app (ANTHROPIC_API_KEY, BACKEND_SHARED_SECRET, el conjunto AUTH_*, tokens de integración) se configuran directamente en cada app de Fly — mirá scripts/fly-secrets.sh.example.

Bootstrap por única vez (dev)

# 1. Crear apps y volumen
flyctl apps create openexec-api-dev
flyctl apps create openexec-ui-dev
flyctl volumes create executive_data --region iad --size 1 -a openexec-api-dev

# 2. Configurar el secreto requerido
flyctl secrets set -a openexec-api-dev ANTHROPIC_API_KEY=sk-ant-...

# 3. Crear tokens de despliegue y agregarlos como secretos de GitHub FLY_API_TOKEN_API y FLY_API_TOKEN_UI
flyctl tokens create deploy -a openexec-api-dev -x 999999h
flyctl tokens create deploy -a openexec-ui-dev  -x 999999h

# 4. Primer despliegue
gh workflow run "Deploy (dev)" -f target=both

QA se hace bootstrap de la misma forma contra los nombres de app -qa (push a la rama qa, o gh workflow run "Deploy (qa)"). Mirá docs/deployment.md para el manual completo (operaciones, rollback, modos de falla comunes, por qué no se usa .flycast).

Control de acceso

La UI desplegada está protegida detrás del inicio de sesión con Google con una lista blanca (allow-list) de correos, y la API pública está protegida por un header de secreto compartido entre el proxy de la UI y el backend de FastAPI. Mirá docs/auth.md para la configuración completa (pasos en la Google Cloud Console, secretos de Fly requeridos, agregar/quitar usuarios, rotar secretos, y una tabla de depuración).

Configuración

Todos los ajustes van por variables de entorno. Mínimo requerido: ANTHROPIC_API_KEY — a menos que configures un backend local o de OpenRouter en su lugar (mirá Ejecutar con Modelos Locales). Debe configurarse al menos un proveedor o la app se niega a arrancar.

Variable	Requerida	Por defecto	Descripción
ANTHROPIC_API_KEY	Sí¹	—	Clave de API de Anthropic
DEFAULT_MODEL	No	claude-sonnet-4-6	Ejecutivo + la mayoría de los especialistas
DEEP_REASONING_MODEL	No	claude-opus-4-7	CSO, CFO, GC, Directorio
VECTOR_STORE_PATH	No	./chroma_db	Directorio de ChromaDB
EPISODIC_DB_PATH	No	./episodic_memory.db	SQLite para la memoria episódica
COMPANY_PROFILE_PATH	No	./company/profile.yaml	Perfil de la empresa
ENABLE_CACHING	No	true	Cacheo de prompts de Anthropic
ROUTING_MODEL	No	claude-haiku-4-5-20251001	Modelo para el enrutamiento de intención
SLACK_BOT_TOKEN	No	—	Token OAuth del bot de Slack
SLACK_APP_TOKEN	No	—	Token de modo socket de Slack
EXEC_EMAIL_ADDRESS	No	—	Dirección de Gmail del Ejecutivo (OAuth de Gmail MCP)
EMAIL_POLL_INTERVAL_SECONDS	No	60	Cada cuánto se consulta si hay email nuevo
TELEGRAM_BOT_TOKEN	No	—	Token del bot de Telegram (de @BotFather)
TELEGRAM_WEBHOOK_SECRET	No	—	Cadena aleatoria para validar el webhook
DISCORD_BOT_TOKEN	No	—	Token del bot de Discord (Developer Portal → pestaña Bot)
DISCORD_APP_ID	No	—	ID de la aplicación de Discord (pestaña General Information)
DISCORD_GUILD_IDS	No	—	IDs de guild separados por comas para el registro de comandos slash de dev
DISCORD_NOTIFY_CHANNEL_ID	No	—	ID de canal por defecto para notificaciones salientes
GOOGLE_CHAT_PROJECT_NUMBER	No	—	Número de proyecto de GCP para Google Chat
GOOGLE_CHAT_SERVICE_ACCOUNT_FILE	No	—	Ruta al archivo JSON de la cuenta de servicio
GOOGLE_OAUTH_CLIENT_ID	No	—	ID de cliente OAuth de Google (Gmail MCP)
GOOGLE_OAUTH_CLIENT_SECRET	No	—	Secreto de cliente OAuth de Google (Gmail MCP)
OPENROUTER_ENABLED	No	false	Enrutar las llamadas de Claude a través de OpenRouter y habilitar modelos que no son de Anthropic por agente en la Council UI
OPENROUTER_API_KEY	No	—	Requerida cuando OPENROUTER_ENABLED=true
LOCAL_MODELS_ENABLED	No	false	Enrutar los slugs seleccionados a un servidor local compatible con OpenAI (Ollama, LM Studio, vLLM, llama.cpp)
LOCAL_BASE_URL	No	—	URL del servidor local incluyendo la ruta de versión, ej: http://localhost:11434/v1. Requerida cuando LOCAL_MODELS_ENABLED=true
LOCAL_API_KEY	No	—	Token bearer opcional (vLLM / gateways); Ollama y LM Studio no lo necesitan
LOCAL_MODELS	No	—	Slugs de modelos locales separados por comas para mostrar en la Council UI y enrutar localmente, ej: llama3.3,qwen2.5
LOCAL_TIMEOUT_S	No	300	Timeout por llamada para la generación local, en segundos
HONCHO_ENABLED	No	false	Capa de memoria por persona (honcho.dev) — una ficha de par compartida entre todos los canales
HONCHO_API_KEY	No	—	Requerida cuando HONCHO_ENABLED=true
HONCHO_BASE_URL	No	—	Endpoint de Honcho auto-hospedado

Mirá .env.example para la lista completa.

¹ ANTHROPIC_API_KEY es requerida solo cuando servís modelos de Claude directamente. Se puede omitir por completo si corrés con modelos locales (LOCAL_MODELS_ENABLED) o enrutás a través de OpenRouter (OPENROUTER_ENABLED).

Ejecutar con Modelos Locales

Open Executive puede correr contra cualquier servidor local compatible con OpenAI — Ollama, LM Studio, vLLM, o llama.cpp — en lugar de (o junto con) la API de Anthropic. Los slugs de modelos locales se enrutan a tu servidor a través de la misma abstracción de proveedor que usan los modelos hospedados; sin cambios de código en los agentes ni en el orquestador.

# 1. Descargá un modelo capaz y amigable con el tool-use (ejemplo: Ollama)
ollama pull llama3.3

# 2. En .env — apuntá al servidor local y listá los slugs a exponer
LOCAL_MODELS_ENABLED=true
LOCAL_BASE_URL=http://localhost:11434/v1   # Por defecto de Ollama
LOCAL_MODELS=llama3.3

# 3. (Opcional) correr SIN clave de Anthropic — hacé que lo local sea el default en todos lados
DEFAULT_MODEL=llama3.3
DEEP_REASONING_MODEL=llama3.3
ROUTING_MODEL=llama3.3
# ...y dejá ANTHROPIC_API_KEY sin configurar

Los slugs listados aparecen en el desplegable de modelos de la Council UI, así que también podés correr una configuración híbrida — mantené al Ejecutivo en Claude mientras cambiás especialistas individuales a un modelo local por agente.

Advertencias. La búsqueda web del lado del servidor (ENABLE_WEB_SEARCH) y el cacheo de prompts de Anthropic / extended thinking no tienen equivalente local y se desactivan automáticamente para los modelos locales. El enrutamiento multi-agente se apoya fuertemente en el tool use, así que elegí un modelo que sea fuerte en eso (ej: Llama 3.3 70B, Qwen2.5) — los modelos chicos pueden enrutar mal. LOCAL_API_KEY solo se necesita si tu servidor (vLLM, o un gateway) requiere un token bearer; Ollama y LM Studio no lo necesitan.

Agregar un Nuevo Agente Especialista

1. Creá packages/core/openexecutive/agents/your_agent.py extendiendo BaseAgent
2. Agregá una constante de system prompt en packages/core/openexecutive/prompts/domain_prompts.py
3. Registralo en packages/core/openexecutive/orchestrator/router.py — agregalo a SPECIALIST_REGISTRY y al enum specialist en SPECIALIST_TOOLS
4. Agregá el alias de dominio a DOMAIN_ALIASES en packages/core/openexecutive/knowledge/retriever.py
5. Agregá documentos de conocimiento a knowledge/builtin/your_domain/
6. Agregá al menos 2 escenarios de evaluación a evals/scenarios/
7. Enviá un PR — CI requiere todo lo anterior

Desarrollo

make dev          # Iniciar FastAPI + Next.js
make test         # Correr los tests de Python
make eval         # Correr la suite de evaluación
make lint         # Correr ruff + mypy
make docker       # Construir y correr el stack de Docker

# Solo tests unitarios (no requieren llamadas a la API)
pytest packages/core/tests/unit/ -v

Sistema de Evaluación

evals/ contiene 29 escenarios que cubren los 8 dominios, puntuados por claude-opus-4-7 como LLM-como-juez. Cada escenario define una consulta, un contexto de empresa simulado, los temas esperados, el enrutamiento de especialistas requerido, y una rúbrica específica del dominio. Cinco dimensiones de puntuación (coherencia de la persona, precisión del dominio, uso del contexto de la empresa, calidad del enrutamiento, accionabilidad) se califican cada una de 1 a 5. El gate de CI requiere un promedio ≥ 3.5/5; cualquier dimensión que caiga más de un 10% respecto de main hace fallar el PR.

Privacidad

Todo lo que está en company/ está en el gitignore — el YAML de perfil, los documentos subidos, y el almacén vectorial de ChromaDB. Nada de esto sale de tu máquina local (o de tu propio volumen de Fly en despliegues en la nube) excepto como parte de los prompts enviados a la API de Anthropic. Anthropic no entrena con los datos de la API.

Contribuir

Mirá .github/CONTRIBUTING.md. Todos los PRs deben incluir:

• Implementación funcional (sin stubs)
• Tests para el comportamiento nuevo
• Escenarios de evaluación para agentes nuevos o cambios de prompt

Licencia

Apache 2.0 — libre para uso comercial, requiere atribución.