Architecture v3.0

10-Layer Technical Architecture

From identity at Layer 1 to intelligence analytics at Layer 10. Every layer is versioned, rollback-safe, and deployed to 3 targets.

Layer Stack Overview

Kynetra Prime is a 10-layer operating system for intelligence. Layers 1–4 handle identity, perception, memory, and orchestration. Layers 5–7 handle execution, action, and reflection. Layers 8–10 handle learning, governance, and analytics.

L1
Identity & Role
Regent ID · Role Type · Permissions · Learning Scope · Risk Tier
L2
Perception
Intent Parser · Entity Extractor · Context Builder · State Reader · Confidence Scorer
L3
Knowledge Fabric
Semantic · Episodic · Procedural · Strategic Memory — four-tier storage with vector, postgres, and analytics backends
L4
Orchestration — PRIME Core
PRIME Router · Task Decomposer · Execution Planner · Policy Gate · 4 orchestration modes
L5
Skill Execution
Cognitive · Operational · Analytical · Creative · Coordination — versioned, testable, rollback-safe skill units
L6
Action Bus
4-ring safety model: Read → Low Write → Critical → Restricted. Circuit breaker + audit log on every action.
L7
Reflection Engine
Outcome Evaluation · Confidence Delta · Lesson Extraction · Learning Queue Population
L8
Learning Pipeline
5 learning paths: Memory · Prompt · Workflow · Retrieval · Routing. 4 modes: Conservative → Managed → Supervised → Restricted.
L9
Governance Engine
Permission Matrix · Confidence Thresholds · Version Control · Audit Logs · Compliance · Sandbox Simulation
L10
Intelligence Analytics
Task Success Rate · Hallucination Rate · Human Override Rate · Post-Learning Gain · Revenue Lift · Intelligence Index

Layer 4: PRIME Orchestration Core

The brain that routes, decomposes, plans, and coordinates. Every inbound request passes through a 7-step processing pipeline before any regent acts.

async process(input: RawInput): Promise<PrimeResult> {
  const context  = await perception.process(input);       // L2
  const domains  = await router.classify(context);
  const policy   = await policyGate.preCheck(context);    // block if restricted
  const subtasks = await decomposer.decompose(context);
  const plan     = await planner.plan(subtasks, context);
  const results  = await execute(plan, context);          // Head Regents
  await reflect(plan, results, context);                  // L7 learning loop
  return synthesize(results);
}

Orchestration Modes

ModeTriggerBehaviour
ReactiveSimple single-domain taskDirect route to Head Regent — no decomposition
DeliberativeComplex multi-step taskFull decomposition + planning + sequential execution
CollaborativeCross-domain taskMultiple Head Regents coordinated with dependency graph
SupervisoryHigh-risk or low-confidenceHuman-in-loop approval gates at critical points

Confidence Thresholds

ScoreAction
> 80Auto-execute
50–80Human review required
30–50Escalate to supervisor regent
< 10Block execution entirely

Layer 3: Knowledge Fabric

Four-tier memory system. Each type has a distinct storage backend optimised for its access pattern.

Memory TypeStoreContentRetention
Semanticpgvector / PineconePolicies, SOPs, domain rules, product knowledgeIndefinite, version-controlled
EpisodicPostgres (append-only)Past task executions, outcomes, human corrections, lessons12 months rolling, compressed
ProceduralDocument store + GitVersioned workflow steps, success rates, execution timesAll versions retained
StrategicPostgres + analyticsCross-domain patterns, evidence sets, confidence scoresUntil invalidated

Layer 6: Action Bus — Safety Rings

All external interactions are ring-classified before execution. Ring 3+ requires explicit approval. Every action is circuit-breakered and audit-logged.

RingCategoryExamplesApproval
Ring 1Readcrm.read · analytics.query · order.fetchNone
Ring 2Low Writetask.create · note.add · tag.updateNone
Ring 3Criticalorder.modify · pricing.update · campaign.launchRequired
Ring 4Restrictedpayment.process · refund.issue · contract.signRequired + audit

Layer 8: Learning Pipeline

Five distinct learning paths, each improving a different aspect of regent behaviour. Controlled by 4 approval modes — nothing is auto-deployed above low risk.

ModeWhat ChangesRiskAuto-Approve
ConservativeRetrieval ranking, memory summariesLowYes
ManagedPrompts, policies, tool orderingMediumNo — requires review
SupervisedWorkflow templates, skill logicMedium-HighNo — sandbox pass + review
RestrictedModel routing, autonomy expansionHighNo — executive approval

Every learning candidate is: pattern-mined from reflections → hypothesis generated → sandbox-evaluated → approval-gated → version-released → 24h monitored with auto-rollback.

Unified LLM Gateway

Provider-agnostic model routing. Claude is primary. OpenRouter handles cost optimisation and provider redundancy. Selection is automatic based on task complexity score.

OPUS
claude-opus-4 · Primary
Complex reasoning, multi-regent synthesis, governance decisions. Triggered when complexity score > 80.
SONNET
claude-sonnet-4 · Fast
Standard regent tasks, classification, extraction. Complexity score 40–80.
HAIKU
claude-haiku-4 · Efficient
High-volume simple tasks, validation, formatting. Complexity score < 40.
ROUTER
OpenRouter · Fallback
Cost optimisation, provider redundancy, specialised models (Gemini 2.5 Pro for long context, Llama 4 for open-source fallback, DeepSeek R1 for cost-efficient reasoning).
// Intelligent routing logic
selectModel(complexity: TaskComplexity, constraints: Constraints) {
  if (complexity.requiresReasoning && complexity.score > 80)
    return models.primary;   // Claude Opus
  if (complexity.score > 40)
    return models.fast;      // Claude Sonnet
  if (constraints.costOptimize)
    return models.fallback;  // OpenRouter
  return models.efficient;   // Claude Haiku
}

Multi-Target Deployment

Kynetra Prime runs identically on 3 deployment targets. Application code is unchanged — only the DeploymentTarget adapter swaps.

Target 1 · Primary Cloud
Vercel + Supabase
Next.js API Routes Edge Functions Postgres + pgvector Realtime WS Row-Level Security Inngest Workflows
Target 2 · Edge-First
Cloudflare Workers + D1/R2
Workers (Regents) Durable Objects D1 SQL R2 Objects KV Cache Queues Vectorize
Target 3 · Self-Hosted
Docker Compose
Next.js :3000 Regent Runtime :4000 Nginx :80 Postgres + pgvector Redis :6379 NATS Events Temporal Workflows MinIO S3 OTEL Collector
// Platform-agnostic deployment interface
interface DeploymentTarget {
  name: "vercel-supabase" | "cloudflare" | "docker";
  db:          DatabaseAdapter;     // Supabase | D1 | Postgres
  storage:     StorageAdapter;      // Supabase | R2 | MinIO
  events:      EventBusAdapter;     // Inngest | Queues | NATS
  workflows:   WorkflowAdapter;     // Inngest | Workers | Temporal
  cache:       CacheAdapter;        // Supabase | KV | Redis
  vectorStore: VectorStoreAdapter;  // pgvector | Vectorize | pgvector
}

Layer 1: Regent Identity Contract

Every regent in the 334-strong fleet is registered with an immutable identity record. Version-controlled, domain-scoped, risk-tiered.

interface RegentIdentity {
  regentId:        string;            // "X2-007"
  name:            string;            // "ReturnProcessorRegent"
  domain:          DomainType;
  headRegent:      string;
  roleType:        "specialist" | "head" | "orchestrator";
  capabilities:    Capability[];
  toolPermissions: ToolPermission[];
  learningScope:   LearningScope;
  riskTier:        "low" | "medium" | "high";
  version:         string;            // semver "1.3.0"
  createdAt:       Date;
  lastUpdatedAt:   Date;
}
View All 334 Regents → ← Prime Overview