OpenExecutive: An Eight-Agent Executive Team Behind a Single AI Voice

What OpenExecutive Actually Solves

OpenExecutive targets a specific pain: leaders who want AI advice that spans finance, strategy, HR, legal, operations, marketing, product, and board communications, but who do not want to manage eight separate chat threads with different AI personas. The README describes a single coherent executive voice backed by eight specialist agents, so the user interacts with one persona while internal routing dispatches to the right domain expert. The intended user is a company executive or founder who needs structured, cross-functional input on decisions like fundraising, competitive positioning, or hiring, and who wants that input to reflect their own company documents, not just generic knowledge. It is not a general-purpose assistant; it is a domain-structured advisory system with a fixed set of roles. That focus is both its value and its constraint, because the quality of advice depends entirely on the underlying Claude models and the retrieval context.

How the Orchestrator Routes to Eight Specialists

The architecture diagram in the README shows a clear data flow: a user message goes to an Executive Orchestrator, which is claude-sonnet-5, and that orchestrator uses tool use to make parallel calls to the eight specialist agents. Each specialist then retrieves relevant context from ChromaDB before responding. The retrieval has two layers: built-in MBA-level Markdown knowledge that is git-tracked and seeded into ChromaDB at startup, and uploaded company documents that are chunked and stored in a separate company_docs collection. The RAG context is injected into the user turn, not into the cached system prompt, which is a deliberate design choice to keep dynamic content out of the prompt cache. The orchestrator synthesizes the specialist outputs into a single executive response. This design means the user never sees the internal agent architecture, which is a UX decision that trades transparency for coherence. One limitation is that the orchestrator becomes a single point of failure for response quality, because every message must pass through it.

Episodic Memory and the Scheduler: Persistence with a Catch

OpenExecutive goes beyond simple Q&A by maintaining episodic memory of past decisions and initiatives. After every response, a background claude-haiku-4-5 pass extracts key decisions, initiatives, and advice into SQLite. On the next session, the system opens with a past_decisions block so the executive can recall what it recommended previously. That is a concrete mechanism for continuity across sessions, which many chat-based tools lack. The scheduler is another persistent component: a built-in job runner claims due actions using an UPDATE ... RETURNING statement to prevent double-firing. The README is explicit that the API must run as a single instance and should not be horizontally scaled without gating the scheduler first. That is a hard architectural constraint. If you deploy multiple instances without that gating, the scheduler could either double-fire or miss actions, depending on how the database locking behaves. This is a real failure mode that any team evaluating OpenExecutive must plan for.

Getting It Running: Commands, Config, and First-Run Weight

The quick start is straightforward if you use make. Clone the repo, copy .env.example to .env, add your ANTHROPIC_API_KEY, and optionally fill the AUTH_* block for Google sign-in, then run make dev. All configuration lives in the repo-root .env, which both make dev and make docker load for the API and the UI. The UI also reads packages/ui/.env.local for UI-only keys, but the root .env takes precedence for keys present in both. For contributors not using make, the README gives direct commands: cd packages/core, run uv sync, activate the venv, and start uvicorn on port 8000; in a second terminal, cd packages/ui and run npm install and npm run dev. The first run is heavy: it requires Python 3.11+ and Node 22+, and the initial uv sync pulls ChromaDB plus sentence-transformers and PyTorch. The first boot downloads a small embedding model of about 90 MB to build the local vector index. The README warns that the first make dev takes a few minutes before the app is ready. That is a real setup cost, and teams on slow networks or with disk constraints should budget for it.

The Built-In Knowledge vs. Your Documents: A Two-Tier RAG

The knowledge design is one of the most distinctive parts of OpenExecutive. Each specialist call retrieves from two separate ChromaDB collections: one for built-in MBA-level Markdown that is git-tracked in knowledge/builtin/, and one for company_docs that holds uploaded company documents. The built-in knowledge is seeded at startup, which means the system has a baseline of business frameworks without requiring the user to upload anything. The company_docs collection is populated from user uploads, chunked, and stored separately. This separation prevents the built-in knowledge from being polluted by user-specific content, and it allows the retrieval to weight company context differently. However, the README does not specify how the two retrieval layers are combined or ranked in the final prompt. That is a gap in the documentation. The RAG context is injected into the user turn, never the cached system prompt, which is a sound practice for cache correctness but means every turn carries retrieval overhead. The quality of answers likely depends on how well the chunking and retrieval handle varied company document formats, but the README gives no details on chunk size or embedding model beyond the ~90 MB download.

Prompt Caching: A Cost-Saving Design with a Strict Rule

OpenExecutive structures its system prompt to exploit Anthropic's prompt caching. The README claims up to 85% cache hit rate after the first few turns, with the executive persona, company profile, and knowledge index cached separately. The strict rule is that no dynamic content ever goes in a cached block. That means the RAG context, which changes per query, is injected into the user turn, and episodic memory is injected as a past_decisions block at session start, presumably outside the cached persona. This design is a concrete cost optimization, because prompt caching reduces API spend on long system prompts. But it introduces a fragility: if a developer accidentally places a dynamic variable inside a cached block, the cache will serve stale context, and the executive will give advice based on outdated information. The README does not provide a code example of how the cache manager enforces this separation, so a user must trust the implementation. The 85% figure is a claimed hit rate, not a measured benchmark from this review, and it likely depends on session length and turn variability.

Limitations, Failure Modes, and When It Is the Wrong Tool

The most significant limitation is the single-instance requirement for the scheduler. The README warns explicitly: the API must run as a single instance; do not horizontally scale it without gating the scheduler first. That means any deployment that needs high availability or load balancing must add custom locking or disable the scheduler, which is not documented beyond that warning. Another limitation is the heavy first-run dependency on PyTorch and sentence-transformers, which makes the container image large and slow to start in ephemeral environments like serverless. The project also relies entirely on the Anthropic API, so it is not usable without an ANTHROPIC_API_KEY and incurs ongoing per-token costs that could be substantial for a busy executive team. The README does not mention any offline mode or local model support. For a regulated company that cannot send financial or legal documents to a third-party API, OpenExecutive is the wrong tool. Also, the built-in MBA knowledge is not a substitute for licensed professional advice, and the README does not include any disclaimer, which is a gap for a tool that claims to act as a General Counsel or CFO.

Alternatives and the Landscape of Multi-Agent Frameworks

OpenExecutive is not the only way to build a multi-agent advisory system. A direct alternative is to use a general-purpose agent framework like LangChain or LlamaIndex, where you assemble your own specialist agents, define routing logic, and manage your own vector store. The difference is that those frameworks give you full control but require you to implement the orchestration, memory, and scheduler yourself. OpenExecutive provides a complete opinionated architecture, so you skip that engineering work, but you inherit its constraints, such as the single-instance scheduler and the fixed eight-role roster. Another alternative is to use a single large model with a very long context window, such as claude-opus-5, and paste all relevant company documents into the prompt, avoiding RAG and multi-agent routing altogether. That approach is simpler but becomes expensive and unwieldy as documents grow, and it loses the specialized retrieval that OpenExecutive's two-tier RAG provides. The trade-off is between flexibility and out-of-the-box structure. OpenExecutive is a reference implementation of a specific design, not a framework, so teams that need custom agent roles or different memory stores will have to modify the source.

Maintenance, Licensing, and Upgrade Considerations

The repository is under Apache 2.0, as shown in the README badge and the LICENSE file, which is a permissive license that allows commercial use, modification, and distribution, though this is not legal advice. The project has no recent releases listed, which means there are no tagged stable versions to pin to; you would rely on the default branch, which changes as commits are pushed. The last push was 2026-09-08, so it is actively maintained, but the absence of releases suggests the project is in a pre-1.0 state. The README references docs/architecture.md and docs/auth.md, which are necessary for deployment, but their content is not included in the provided material. Upgrading the Anthropic model versions, such as moving from claude-sonnet-5 to a newer model, would require code changes in the orchestrator and agent definitions, and the eval suite in evals/ is the only safety net mentioned. The heavy dependency on PyTorch and sentence-transformers also means that any upgrade to ChromaDB or the embedding model could introduce breaking changes. Teams adopting OpenExecutive should budget for ongoing maintenance as the underlying model APIs and dependencies evolve.

Editorial conclusion

Adopt OpenExecutive if you are a founder or small leadership team that wants a structured, multi-perspective AI advisor without managing multiple chat personas, and you can accept a single-instance backend and a heavy first setup. Do not adopt it if you need horizontal scaling, real-time multi-user concurrency, or a production-grade legal or financial advisor, because the underlying models are not licensed for that and the scheduler forbids scaling. Before committing, verify the full architecture doc, test the eval suite with your own scenarios, and confirm that the Anthropic API costs and the ~90 MB embedding model fit your deployment environment. The project is a serious reference implementation of layered RAG and memory, but it is not a turnkey enterprise product.

Official sources

1. Issues
2. Project website
3. README
4. SenteLabsAI/OpenExecutive on GitHub