Enterprise Architecture & CQRS Principles 🏛️
WooPilot AI is engineered with a Strict CQRS (Command Query Responsibility Segregation) design, separating read-only analytical queries from store-mutating commands.
Rather than overloading the AI model with dozens of overlapping API tools (which causes token bloat and routing confusion), WooPilot AI equips the LLM with 4 deterministic CQRS tools:
🧠 6-Layer KV-Cached Prompt Assembly Engine
To achieve lightning-fast response times and minimize AI costs, cloud-core structures its context into 6 decoupled prompt layers:
- Layer 1 (System Core): Immutable safety invariants, tool execution rules, and CQRS directives (100% static).
- Layer 2 (Store Metadata): Store name, currency symbol, timezone, WooCommerce version, and HPOS mode (cached for 24h).
- Layer 3 (DDL Schema Manifest): Introspected MySQL schema, table prefixes, and HPOS lookup mappings (cached for 24h).
- Layer 4 (Static Daily Date Anchor): Daily reference date (
YYYY-MM-DD 00:00:00) preserving byte-identical prefix caching.
- Layer 5 (Sliding Window Memory): Last 10 conversation turns from Redis.
- Layer 6 (Custom Tone of Voice & User Query): Merchant-defined Tone of Voice rules + dynamic local store clock injected at the bottom.
By pinning Layers 1 through 4 into a static prefix, WooPilot AI leverages modern LLM KV-caching (DeepSeek / Anthropic / OpenAI), saving up to 85% in latency and prompt costs.
⚡ “Compile Once, Execute at Edge” (WooAuto)
When merchants create event-driven automations, WooPilot AI does not execute slow, expensive LLM calls during live customer checkout sessions.
- Compilation in Cloud: The user’s natural language instruction is translated by the LLM into a deterministic AST JSON Blueprint.
- Edge Execution in WordPress: The blueprint is saved directly in WordPress memory (
autoload = true). When native WooCommerce hooks fire (woocommerce_checkout_order_created), WordPress executes the condition tree in native PHP with 0ms network latency and $0 AI token costs.
