#Open Executive

Open Executive is designed to transform leadership and management. Highly configurable, it can be deployed at any management level. Out of the box it supports spend approval thresholds, integration with corporate knowledge systems, and defined governance for how it interacts with human colleagues and other AI systems. Open Executive can also be configured as a digital twin to replicate a busy leader—responding in alignment with their specific role and insights—allowing leaders to truly scale their impact through AI.

It meets people where they already work, with integrations for Slack, Discord, Telegram, email, Google Workspace, Notion and any MCP-compatible AI tool, with more on the roadmap. Open Executive will always be open source.

A managed cloud offering is coming (https://openexecutive.ai), where you can get access without deploying anything yourself.

#Demo

A walkthrough of Open Executive in action — watch on YouTube.

#What It Does

Developed by sentelabs.ai Open Executive provides a single coherent executive voice backed by eight specialist AI agents:

• Chief Strategy Officer — competitive analysis, M&A, market positioning, OKRs
• Chief Financial Officer — financial modeling, fundraising, unit economics, cash flow
• Chief HR/People Officer — hiring, compensation, performance, culture
• General Counsel — contracts, IP, employment law basics, compliance
• Chief Operating Officer — process design, vendor management, operational scaling
• Chief Marketing Officer — GTM strategy, brand, communications, PR
• Chief Product Officer — roadmap, prioritization, product strategy
• Board Communications Director — board decks, investor relations, governance

All responses come from one consistent executive voice. The internal agent architecture is never exposed to the user. Beyond Q&A, the system maintains episodic memory of past decisions and initiatives across sessions, and a built-in scheduler can proactively surface follow-ups and time-sensitive actions.

#Architecture

User message
    ↓
Executive Orchestrator (claude-sonnet-5)
    ↓ tool use → parallel specialist calls
CSO / CFO / CHRO / GC / COO / CMO / CPO / Board
    ↓ each specialist retrieves relevant context from ChromaDB
Built-in MBA knowledge + Your company documents
    ↓
Synthesized executive response

Knowledge — Two retrieval layers per specialist call: (1) built-in MBA-level Markdown (knowledge/builtin/, git-tracked) seeded into ChromaDB at startup, and (2) your uploaded company documents chunked and stored in a separate company_docs collection. RAG context is injected into the user turn, never the cached system prompt.

Episodic memory — After every response, a background claude-haiku-4-5 pass extracts key decisions, initiatives, and advice into SQLite. The next session opens with a <past_decisions> block so the Executive remembers what it recommended last month.

Scheduler — A built-in job runner claims due actions via UPDATE … RETURNING to prevent double-firing. The API must run as a single instance; do not horizontally scale it without gating the scheduler first.

Prompt caching — The system prompt is structured so the Executive persona, company profile, and knowledge index are cached separately (up to 85% cache hit rate after the first few turns). No dynamic content ever goes in a cached block.

See docs/architecture.md for the full design.

#Tech Stack

#Repo Layout

openexecutive/
├── packages/
│   ├── core/
│   │   └── openexecutive/
│   │       ├── orchestrator/     # Executive persona + routing loop
│   │       ├── agents/           # 8 specialist agents
│   │       ├── knowledge/        # ChromaDB store + RAG pipeline
│   │       ├── memory/           # Company profile + episodic memory
│   │       ├── onboarding/       # Wizard state machine + profile builder
│   │       ├── prompts/          # Persona + domain prompts + cache manager
│   │       ├── api/              # FastAPI app + routes
│   │       ├── integrations/     # Slack, Email, Telegram, Google Chat, Discord
│   │       ├── scheduler/        # Background job runner (single-instance)
│   │       ├── alerts/           # Proactive alert system
│   │       ├── audit/            # Audit logging
│   │       ├── architecture/     # Internal architecture utilities
│   │       ├── workflows/        # Multi-step workflow definitions
│   │       └── cli.py            # Click CLI
│   └── ui/                       # Next.js 15 web UI
├── evals/                        # Eval scenarios + LLM-as-judge runner
├── fixtures/                     # Demo company fixtures (profiles, docs, rosters)
├── scripts/                      # Operator scripts (Google auth)
├── docker/                       # Dockerfile(s) + docker-compose.yml
└── docs/                         # Architecture + deployment docs

#Quick Start

# Clone the repo
git clone https://github.com/SenteLabsAI/OpenExecutive.git
cd OpenExecutive

# Set your Anthropic API key
cp .env.example .env
# Edit .env and add ANTHROPIC_API_KEY=sk-ant-...
# For the web UI's Google sign-in, also fill in the AUTH_* block
# (see docs/auth.md for the Google Cloud Console steps).

# Start everything
make dev

All configuration lives in that repo-root .env — make dev and make docker both load it for the API and the UI (Auth.js needs AUTH_SECRET / AUTH_GOOGLE_ID / AUTH_GOOGLE_SECRET at runtime). A packages/ui/.env.local is also read for UI-only keys, but for keys present in both files the root .env takes precedence.

Open http://localhost:3000 to start chatting with your executive. The API runs on port 8000 and the UI on 3000.

First run: requires Python 3.11+ and Node 22+. The initial uv sync pulls heavy ML dependencies (ChromaDB + sentence-transformers/PyTorch), and the first boot downloads a small embedding model (~90 MB) to build the local vector index — so the first make dev takes a few minutes before the app is ready. Subsequent starts are fast.

On Windows: run make from Git Bash or WSL, not PowerShell or cmd. The recipes are POSIX shell (if [ -f .env ]; …), and GNU Make falls back to cmd.exe when no sh is on PATH — which fails with -f was unexpected at this time. If Make still picks the wrong shell, point it at one: make dev SHELL="C:/Program Files/Git/bin/sh.exe". Note that make stop uses lsof and has no Windows equivalent; stop the two dev servers from their own terminals instead.

For contributors not using make:

cd packages/core
uv sync
uv run uvicorn openexecutive.api.main:app --reload --port 8000

# In a second terminal
cd packages/ui
npm install
npm run dev

uv run executes inside the project's virtualenv without activating it, so these commands are the same on macOS, Linux and Windows. (Activating manually works too, but the path differs per platform: .venv/bin/activate on macOS/Linux, .venv\Scripts\Activate.ps1 on Windows.) The packages/ui commands are listed one per line rather than chained with && so that they run in every shell too: Windows PowerShell 5.1, the version that ships with Windows, has no && operator and rejects the chained form with The token '&&' is not a valid statement separator in this version.

#Run the Discord Bot

1. Create a Discord application at https://discord.com/developers/applications
2. Enable the Message Content privileged intent (Bot → Privileged Gateway Intents)
3. Invite the bot with bot + applications.commands scopes
4. Set env vars in .env: DISCORD_BOT_TOKEN, DISCORD_APP_ID, DISCORD_GUILD_IDS
5. Run the API normally — the bot starts as part of the FastAPI lifespan when DISCORD_BOT_TOKEN is set:

make dev

The bot is embedded in the API process (alongside the email poller, scheduler, and resumer) so it shares the same SQLite database and ChromaDB vector store under /data in production. Skip the token to disable.

For iterating on bot-only code without restarting the API, make discord runs the bot as a standalone process against the same local DB.

Users can DM the bot, @mention it in a channel (replies in a thread), or use /ask and /today slash commands. Slash commands sync to DISCORD_GUILD_IDS instantly on startup; leave blank for global registration (up to 1-hour propagation delay).

#Deploying to production

The bot runs inside the existing API process — no extra service. Set these on the API and restart it:

DISCORD_BOT_TOKEN=...
DISCORD_APP_ID=...
DISCORD_GUILD_IDS=...

Discord user access is managed via the /people UI — add a Person row with discord_user_id set.

The bot starts on the next lifespan boot. To disable it, unset DISCORD_BOT_TOKEN and restart.

#Onboarding Your Company

The first time you visit the app, you'll be guided through a wizard to set up your company profile:

• Company basics (name, industry, stage, team size)
• Business model and revenue
• Competitive landscape
• Strategic priorities
• Culture and values
• Optional: financial position, document upload

After onboarding, the Executive will reference your specific company context in every response.

The built-in knowledge base is trusted by default — the Executive can use it straight away, and the Review queue starts empty rather than asking you to sign off on ~81 shipped documents. Items reach the queue when you upload a document, edit an existing file, or deliberately send a domain for review from the Review page. While a domain is being reviewed its content is withheld from the Executive, so the UI confirms the count before it starts.

#Interfaces

#Document Upload

Upload your pitch deck, financial model, strategy docs, or any company documents via the web UI or API. The Executive will reference them when relevant.

# Via CLI
openexecutive upload deck.pdf model.xlsx strategy.md

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

#Deployment

Two containers — the FastAPI backend and the Next.js UI — plus one persistent volume at /data. docker/docker-compose.yml is the reference topology and also what make docker runs locally, so the local and deployed shapes match.

⚠️ Single-instance only: the scheduler claims rows via UPDATE … RETURNING, which is not safe across processes. A second API replica double-fires every scheduled action. Pin the API to one instance. The UI is stateless.

Set ANTHROPIC_API_KEY, BACKEND_SHARED_SECRET, BACKEND_ALLOWED_ORIGINS and OE_PUBLIC_DEPLOYMENT=1 on any internet-reachable instance. See docs/deployment.md for the full guide — persistent state, health-check timing, resource sizing, operations, and common failure modes.

#Access control

The deployed UI is gated behind Google sign-in with an email allow-list, and the public API is protected by a shared-secret header between the UI proxy and the FastAPI backend. See docs/auth.md for the full setup (Google Cloud Console steps, required environment variables, adding/removing users, rotating secrets, and a debugging table).

#Configuration

All settings via environment variables. Minimum required: ANTHROPIC_API_KEY — unless you configure a local or OpenRouter backend instead (see Running on Local Models). At least one provider must be set or the app refuses to start.

See .env.example for the full list.

¹ ANTHROPIC_API_KEY is required only when you serve Claude models directly. It can be omitted entirely if you run on local models (LOCAL_MODELS_ENABLED) or route through OpenRouter (OPENROUTER_ENABLED).

² The application default is on, but .env.example ships ENABLE_WEB_SEARCH=false so a fresh setup incurs no per-search charges — if the agents tell you they can't search the web or read the news, flip it to true in your .env and restart. Uses Anthropic's server-side web_search tool, so it applies to Claude models (local models can't use it). WEB_SEARCH_ALLOWED_DOMAINS / WEB_SEARCH_BLOCKED_DOMAINS scope where it may look (set at most one).

#Running on Local Models

Open Executive can run against any OpenAI-compatible local server — Ollama, LM Studio, vLLM, or llama.cpp — instead of (or alongside) the Anthropic API. Local model slugs route to your server through the same provider abstraction the hosted models use; no agent or orchestrator code changes.

# 1. Pull a capable, tool-use-friendly model (example: Ollama)
ollama pull llama3.3

# 2. In .env — point at the local server and list the slugs to expose
LOCAL_MODELS_ENABLED=true
LOCAL_BASE_URL=http://localhost:11434/v1   # Ollama default
LOCAL_MODELS=llama3.3

# 3. (Optional) run with NO Anthropic key — make local the default everywhere
DEFAULT_MODEL=llama3.3
DEEP_REASONING_MODEL=llama3.3
ROUTING_MODEL=llama3.3
# ...and leave ANTHROPIC_API_KEY unset

The listed slugs appear in the Council UI model dropdown, so you can also run a hybrid setup — keep the Executive on Claude while flipping individual specialists to a local model per-agent.

Caveats. Server-side web search (ENABLE_WEB_SEARCH) and Anthropic prompt caching / extended thinking have no local equivalent and are automatically disabled for local models. Multi-agent routing leans heavily on tool use, so pick a model that's strong at it (e.g. Llama 3.3 70B, Qwen2.5) — small models may route poorly. LOCAL_API_KEY is only needed if your server (vLLM, or a gateway) requires a bearer token; Ollama and LM Studio need none.

#Using a hosted OpenAI-compatible gateway

The LOCAL_* settings are not limited to localhost — the same recipe works with any hosted OpenAI-compatible endpoint (an aggregator or inference gateway):

LOCAL_MODELS_ENABLED=true
LOCAL_BASE_URL=https://gateway.example.com/v1
LOCAL_API_KEY=your-gateway-key
LOCAL_MODELS=vendor/model-a,vendor/model-b

The listed slugs are sent to the gateway verbatim and appear in the Council UI dropdown, exactly like local slugs. Gateways that speak OpenRouter's request format and model namespace can alternatively be used through the OpenRouter path (OPENROUTER_ENABLED=true + OPENROUTER_API_KEY + OPENROUTER_BASE_URL=https://gateway.example.com/v1), which keeps that path's Claude-name translation and feature handling.

The local-model caveats above apply to the LOCAL_* path unchanged, plus one that matters more for hosted endpoints: everything the Executive processes — company profile, documents, conversations — is sent to whichever endpoint you configure here. Point these settings only at a provider you trust with that data.

#Adding a New Specialist Agent

1. Create packages/core/openexecutive/agents/your_agent.py extending BaseAgent
2. Add a system prompt constant in packages/core/openexecutive/prompts/domain_prompts.py
3. Register in packages/core/openexecutive/orchestrator/router.py — add to SPECIALIST_REGISTRY and the specialist enum in SPECIALIST_TOOLS
4. Add domain alias to DOMAIN_ALIASES in packages/core/openexecutive/knowledge/retriever.py
5. Add knowledge docs to knowledge/builtin/your_domain/
6. Add at least 2 eval scenarios to evals/scenarios/
7. Submit a PR — CI requires all of the above

#Development

make dev          # Start FastAPI + Next.js
make test         # Run Python tests
make eval         # Run eval suite
make lint         # Run ruff + mypy
make docker       # Build and run Docker stack

# Unit tests only (no API calls required)
pytest packages/core/tests/unit/ -v

#Evaluation System

evals/ contains 29 scenarios covering all 8 domains, scored by claude-opus-4-7 as an LLM-as-judge. Each scenario defines a query, simulated company context, expected topics, required specialist routing, and a domain-specific rubric. Five scoring dimensions (persona coherence, domain accuracy, company context utilization, routing quality, actionability) are each rated 1–5. The CI gate requires ≥ 3.5/5 average; any dimension dropping > 10% vs main fails the PR.

#Privacy

Everything in company/ is gitignored — the profile YAML, uploaded documents, and the ChromaDB vector store. None of this leaves your local machine (or your own volume in cloud deployments) except as part of prompts sent to the Anthropic API. Anthropic does not train on API data.

#Contributing

See .github/CONTRIBUTING.md. All PRs must include:

• Working implementation (no stubs)
• Tests for new behavior
• Eval scenarios for new agents or prompt changes

#License

Apache 2.0 — free to use commercially, requires attribution.