LSAS — Layered Safety & Abstraction Stack

Architecture for
production AI systems.

LSAS defines 9 distinct layers of responsibility in a production AI system — from raw tool integration up through application logic. ElectriPy implements each layer as composable, interoperable Python packages.

The Problem

Why AI systems need architecture.

Most AI systems grow organically — prompts, tool calls, and guardrails added ad hoc. The result is fragile systems with no clear failure domains, no consistent observability, and no way to enforce policy systematically.

Failure isolation

Without clear layer boundaries, a model provider outage cascades through every layer to your users. Architecture defines where failures are caught.

Observability surface

Without layers, there is no consistent place to instrument. Architecture creates a natural instrumentation surface that applies to all requests.

Policy enforcement

Without a governance layer, policy is scattered across application code. Architecture gives policy a single enforcement point.

The Stack

9 layers. One runtime.

Each layer is implemented as a separate, installable Python package. Use only what you need — the layers are designed to compose cleanly.

L09Application

Agent personas, skills packaging, business-domain logic

ElectriPy Primitives

AgentSkillPersonaTaskManager
L08Orchestration

Workflow coordination, multi-agent routing, execution planning

ElectriPy Primitives

WorkloadRouterWorkflowPlannerAgentCoordinator
L07Memory

Session state, cross-session history, context window management

ElectriPy Primitives

SessionStoreContextManagerHistoryBuffer
L06Knowledge

Retrieval-augmented generation, embedding pipelines, semantic search

ElectriPy Primitives

VectorStoreEmbeddingPipelineRetrievalChainSemanticSearch
L05Tools

MCP client/server, tool registry, capability discovery, auth hooks

ElectriPy Primitives

MCPClientMCPServerToolRegistryCapabilityDiscovery
L04Model Runtime

LLM gateway, provider abstraction, token tracking, streaming support

ElectriPy Primitives

LLMGatewayProviderAdapterTokenTrackerStreamManager
L03Reliability

Circuit breakers, retry logic, fallback chains, rate limiting

ElectriPy Primitives

CircuitBreakerRetryHandlerFallbackChainRateLimiter
L02Observability

Distributed tracing, span collection, cost metadata, OTEL export

ElectriPy Primitives

TracerSpanDecoratorCostMetadataOTELExporter
L01Governance

Policy enforcement, approval gates, audit trails, violation logging

ElectriPy Primitives

PolicyEnginePolicyGatewayAuditLoggerViolationTracker

Design Principles

Built on clear principles.

LSAS is not a framework in the traditional sense — it is an architectural contract that guides how components relate to each other.

Separation of concerns

Each layer has a single, well-defined responsibility. Application code stays in the Application layer. Infrastructure stays below.

Incremental adoption

Start with one layer — Observability or Reliability — and adopt additional layers as your system matures. There is no minimum viable layer count.

Provider independence

The Model Runtime layer abstracts all provider-specific concerns. Switching models or providers requires no changes to application or orchestration code.

Observable by default

Every interaction that passes through any layer is automatically traced. Observability is structural, not bolted on.

Policy as infrastructure

Governance is not a wrapper around your application logic. It is a layer of the runtime that all requests pass through.

Composable primitives

Each layer exposes composable primitives that can be assembled in different patterns. The runtime does not dictate your architecture.

Ready to build on LSAS?

Start with a single layer. The architecture scales with your system.