Four-Layer Package Architecture
Since v4.6.122+, PraisonAI ships as four independently-installable PyPI packages. Dependencies flow upward — each layer only knows about the layers below it:praisonaiagents alone for pure SDK embedding, praisonai-code for the terminal CLI without gateway/bot features, praisonai-bot[gateway,bot] for a standalone gateway + channel bots without the wrapper, or praisonai for the full stack. Old wrapper imports (praisonai.bots, praisonai.gateway, praisonai.scheduler.executor) still resolve via alias_package shims — no code change required to migrate.
Protocol vs ABC
| Aspect | Protocol | ABC |
|---|---|---|
| Location | Core SDK | Wrapper |
| Purpose | Minimal interface for mocking | Full implementation contract |
| Inheritance | Not required (duck typing) | Required |
| Use when | Users might mock/test | Internal implementations |
praisonaiagents; their implementations live in praisonai-bot, not the wrapper.
Adding a New Feature
Step 1: Core SDK - Protocol + Default
Step 2: Wrapper - Heavy Implementations
Step 3: Export from Core
Usage
Production
Testing (Mock)
Decision Tree
File Structure
Benefits
| Benefit | Explanation |
|---|---|
| Testable | Mock via Protocol, no LLM/DB costs |
| Fast imports | Heavy deps only loaded when used |
| Optional deps | pip install praisonai[redis] |
| Clean separation | Core = interfaces, Wrapper = implementations |
| Community extensions | Anyone can implement Protocol |
Existing Examples
| Feature | Core Protocol | Wrapper Implementations |
|---|---|---|
| Agent | AgentProtocol | N/A (Agent is in core) |
| Memory | MemoryProtocol | Future: RedisMemory, MongoMemory |
| Tool | ToolProtocol | Custom tools in praisonai-tools |
| State | N/A (wrapper only) | RedisStateStore, MemoryStateStore |

