Ecosystem Overview
Five packages, one coherent framework: library, API, CLI, MCP gateway, and frontend.
Orchid is delivered as five separable packages with a clear, one-direction dependency graph. Each package can be replaced or forked independently — the only coupling is the HTTP API contract between the server-side packages and their consumers.
Core framework library — ABCs, GenericAgent, LangGraph graph, RAG, persistence
Read docs →FastAPI server — REST and streaming endpoints, auth, admin
Read docs →CLI tool — interactive chat, config validation, indexing
Read docs →Next.js 15 multi-chat UI — forkable starting point
Read docs →MCP gateway — exposes Orchestrator Index to any MCP-capable host LLM
Read docs →Package summary
| Package | Kind | Depends on | Purpose |
|---|---|---|---|
| orchid | pip package | — | Core framework: ABCs, GenericAgent, LangGraph graph, RAG pipeline, document parsing, MCP client, chat persistence |
| orchid-api | pip package | orchid (Python) | FastAPI server — REST and SSE streaming, auth, admin, diagnostics |
| orchid-cli | pip package | orchid (Python) | CLI tool — interactive chat, config validation, RAG indexing |
| orchid-frontend | boilerplate | orchid-api (HTTP) | Next.js 15 multi-chat UI — forkable starting point |
| orchid-mcp | boilerplate | orchid-api (HTTP) | MCP gateway — exposes Orchid agents to any MCP-capable host LLM |
Why this split?
The library (orchid) contains only ABCs, the GenericAgent implementation, and framework infrastructure with no vendor or product coupling. It is installable as a standalone pip package so teams can build their own server, CLI, or integration on top of it without pulling in FastAPI, a specific auth system, or a frontend framework.
Plugin dependencies by configuration
The core orchid-ai library ships with null and in_memory backends only — no Qdrant, no PostgreSQL, no ChromaDB. Concrete backends live in separate plugin packages that auto-register via Python entry points. The table below shows which plugin to install for each configuration choice:
| If your config uses this… | Install this | Backend provided |
|---|---|---|
rag.vector_backend: qdrant | pip install orchid-rag-qdrant | Qdrant vector store + doc store |
rag.vector_backend: chroma | pip install orchid-rag-chroma | ChromaDB on-disk vector store |
rag.vector_backend: neo4j | pip install orchid-rag-neo4j | Neo4j graph store |
storage.class: orchid_storage_postgres.* | pip install orchid-storage-postgres | PostgreSQL chat persistence |
checkpointer_type: postgres | pip install orchid-storage-postgres | LangGraph Postgres checkpointer |
| Events with PostgreSQL backends | pip install orchid-storage-postgres | Postgres signal queue + event storage |
Missing a plugin raises a clear startup error. For example, setting
vector_backend: qdrant without installing orchid-rag-qdrant produces:
ValueError: Unknown vector backend 'qdrant'. Install the missing
plugin: pip install orchid-rag-qdrant. Registered built-ins: ['null'].orchid-api and orchid-cli are thin consumers. They import orchid as a Python dependency, add the runtime surface (HTTP routes, CLI commands, Docker entrypoints), and delegate all agent execution back to the framework library. Because the split is at the Python package boundary, the framework can be upgraded independently of the serving layer.
orchid-frontend and orchid-mcp talk to orchid-api over HTTP only — they have no Python import dependency on the framework. This makes them portable boilerplate: fork either one, point it at any orchid-api deployment, and it works. The MCP gateway, in particular, is designed to be forked by integrators who want to expose Orchid agents inside their own MCP host infrastructure without touching the Python layer.