AeionClaw Technical Specifications
Architecture reference for the native AI intelligence layer. 7 core services, a dozen-plus data models in your own tenant database, a persona auto-routing classifier, an event-driven Reaction Engine, a 5-tier memory system, per-tenant spend governance, a 9-provider gateway, a Skill Factory with sandbox testing, and platform-wide RBAC + immutable audit. No magic — everything is auditable, replaceable, and runs inside your tenant.
Service Architecture — 7 Focused Services
Conversation
lifecycle: create, append, summarize, archive
Persona
8 default personas + tenant overrides; the auto-routing classifier
Skill
47 shipped skills + tenant custom skills; manifest registry + tool-scope resolution
Memory
6-type semantic memory: preference, decision, fact, relationship, workflow, goal
Reaction Engine
event-driven AI automations with full filter + tool dispatch
Workflow
multi-step LLM + tool chains with variable interpolation + branching
Budget
per-tenant, per-user, per-persona, and per-reaction spend governance
Data Model — Everything Lives in Your Tenant Database
AeionClaw stores its state — conversations, messages, personas, skills, memory, the spend ledger, and an immutable action log — entirely inside your own tenant database, under the same multi-tenancy guarantees as the rest of the platform. Nothing routes through a separate AI-vendor datastore.
Persona Auto-Routing
A lightweight classifier call maps every incoming prompt to one of the 8 default personas (or a tenant custom persona) in under 150ms, using a small, inexpensive model (Haiku, GPT-4o-mini, or a self-hosted Llama) at sub-cent cost.
Provider Gateway — Persona-Aware Routing + Failover
On top of the platform-wide AI gateway (the 57-provider router), AeionClaw layers persona-aware provider preferences, automatic failover, and per-call cost tracking tuned for conversational workloads.
Reaction Engine — How a Reaction Actually Fires
The Reaction Engine is the most consequential subsystem — it turns AeionClaw from "AI you talk to" into "AI that acts on your behalf." Every enabled reaction subscribes to its trigger event on the platform event bus. When a matching event lands, the engine runs it through a fixed pipeline before anything happens:
Memory — Five Categories, Not "Throw It All Into a Vector DB"
AeionClaw's memory model is more structured than a single embeddings dump. Five categories serve different recall purposes:
Budget Governance — Per-Tenant Enforcement
Spend governance runs inside AeionClaw itself, not the LLM provider — so caps are enforced consistently even for self-hosted providers where there's no provider-side spend limit to lean on.
Skill Factory — Custom Skills Without Writing Platform Code
Custom skills extend AeionClaw with tenant-specific experts, defined through a manifest — id, name, description, system prompt, tool scope, example prompts, and guardrails (which actions require approval, hard limits on destructive actions, max tokens per turn) — rather than by writing code against Aeion's internals.
RBAC + Immutable Audit Log
Every AeionClaw action passes through the same platform RBAC engine that protects the admin panel, then writes to an append-only audit log that cannot be edited or deleted except via a logged admin escalation.
Performance + Scale
Latency budget per conversation turn (p50):
FAQ
Yes. The Aeion node itself runs on 2 vCPU + 4GB RAM. LLM inference can be remote (Anthropic/OpenAI) or local Ollama. For Ollama: Llama 3.3 70B needs ~40GB GPU memory (4090 or A100). Smaller models (8B-13B) fit on 24GB cards. The platform isn't the bottleneck.
LangChain is a library you compose yourself; AeionClaw is a complete native subsystem. We give you persona auto-routing, tool scope enforcement, semantic memory, an audit log, budget governance, a skill factory, and a UI — out of the box. LangChain hands you primitives and leaves the rest to you. Both are valid; the trade-off is build vs. buy.
Yes. Bring your own provider through the BYOM adapter pattern — point AeionClaw at an OpenAI-compatible endpoint, or implement the provider interface for something custom, add the API key, and it's treated identically to a shipped provider.
Enable AeionClaw, disable the conversation UI for non-admin users via per-role policy, but keep the Reaction Engine active. Reactions still subscribe to the event bus and act on platform events. Use case: AI-augmented automation without exposing the AI to end users.
Three levels: (1) per-service health checks — the admin health view shows each Claw service's status, (2) Prometheus-compatible metrics for scraping (per-persona latency, per-provider error rate, per-tenant spend), (3) the AeionClaw admin dashboard with a live conversation feed, anomaly highlights, and audit-log search.
Tenant admins can override the classifier's system prompt, model, and confidence threshold (default 0.6). Lower threshold = more aggressive routing; higher = more fallbacks to the general-purpose assistant. Tune based on observed misroutes in your conversation log.
No. The audit log is mandatory by design — without it, the compliance story falls over. You CAN configure the retention period and you CAN configure who has access to read it (default: tenant admin + compliance role).
Yes. Every query passes through the platform's tenant-scoping middleware, and the database itself is partitioned by tenant at the row level. Cross-tenant data access is impossible via the API. Cross-tenant access via direct database access is possible only for platform admins, and that path is always audit-logged.
Server-Sent Events (SSE) over the standard conversation API. Tokens stream incrementally as they're generated, tool dispatches stream as they fire, and a final event carries the total token count and cost.
Yes — the per-skill kill-switch instantly disables it, and the per-tenant deny-list blocks it from being redeployed. Full per-version rollback (roll back to any prior version in one action) is on the near-term roadmap (see /platform/claw/roadmap); until it lands, disable-then-redeploy the known-good version.