Technology

Single-Agent Principle

One robot = one persistent agent. Capabilities load through ECM. Behavior is constrained by governance. Not a multi-agent ensemble. Not a model wired directly to hardware.

Δ

One Agent Per Robot

Each robot hosts a single persistent agent that maintains continuity of identity, state, and learned experience across its operational lifetime.

◊

Capabilities Are Modules

Agents don't contain capabilities — they load them. ECM packages are installed, versioned, upgraded, and rolled back independently of the agent itself.

λ

Governance Is Not Optional

Every capability call passes through the governance engine. Safety is architectural, not aspirational. Audit is complete, not sampled.

Architecture

Five-layer runtime stack

Click each layer to see its responsibilities and key components.

Layer 5: Agent

The application layer where decision-making logic runs. Each agent is a persistent entity with a frozen identity, episodic memory, and a typed persona.

Frozen Identity v0.10.0 7-field IdentityManifest, byte-equal hash across upgrades — deep dive
Layer 2 Semantic Memory v0.10.0 4 deterministic fact kinds, outbox-pattern persistence — deep dive
Active Dreaming v0.10.0 Offline reflection runner + scheduler — deep dive
Decision Engine v0.9.0 Foundation model integration, planning, reasoning

Layer 4: Governance

The policy enforcement layer. Every capability invocation is validated against active policies before execution. v0.10.0 adds the adaptive persona — the governance layer between the LLM and the actuator.

Adaptive Persona v0.10.0 Asymmetric trust matrix: tighten = auto, relax = operator-signed — deep dive
Policy Engine v0.9.0 Declarative DSL for defining operational constraints
Watcher System v0.9.0 Real-time invariant monitoring and violation detection
Recovery Orchestrator v0.9.0 Four-level structured response: log, alert, intervene, halt
Audit Recorder v0.9.0 Ed25519-signed immutable log of every decision, action, and state change

Layer 3: ECM Package

The capability layer. Agents load capabilities as versioned, contract-bound modules that can be installed, upgraded, and rolled back.

Contract Registry Six-dimensional typed interfaces between agents and hardware
Package Manager Install, upgrade, rollback with atomic transactions
Compatibility Checker Pre-install validation against hardware and policy constraints
Shadow Executor Run new capabilities in parallel without affecting production

Layer 2: Runtime

The execution layer. Manages the agent lifecycle, schedules tasks, runs the sense-decide-act loop, and handles failures.

Lifecycle Manager Init, start, pause, resume, stop, restart state machine
Task Scheduler Priority-aware scheduling with preemption and deadlines
Execution Loop Closed-loop sense-decide-act with timeout protection
Fault Handler Retry, fallback, degrade, halt — structured recovery

Layer 1: Embodiment

The hardware abstraction layer. Normalizes heterogeneous sensors, actuators, and compute into a uniform interface.

Sensor Abstraction Cameras, LiDAR, IMU, force/torque — unified data format
Actuator Interface Arms, wheels, grippers, legs — normalized control API
Resource Monitor CPU, GPU, memory, battery — real-time resource tracking
Hardware Registry Capability discovery and device enumeration
v0.10.0 Deep Dive

The four pieces that make governance adaptive

v0.9.0 shipped the governance bones. v0.10.0 adds the interior. Identity, persona, memory, dreaming — each piece is a separate subsystem with its own contract, its own audit chain, and its own regression test. They compose around one invariant: the identity hash never flips while the agent learns.

Layer 5 v0.10.0

Frozen Identity

One robot = one persistent agent. The agent's identity is not a name. It is a 7-field IdentityManifest, hashed once at provisioning and frozen for the agent's operational lifetime.

What's in the hash

  • Embodiment fingerprint (which robot)
  • ECM registry (which capability names)
  • Policy rule set (which governance rules)
  • Environment policies (which constraints)
  • Operator pubkey (who can sign)
  • Schema version (manifest format)
  • Genesis timestamp (when provisioned)

What's NOT in the hash

  • Episodic memory contents
  • Layer 2 / Layer 3 semantic facts
  • Persona events (delta against the manifest)
  • Active dream output
  • Anything derived — not load-bearing
HR-1 invariant

Adding new memory rows, evolving persona, refining a fact — none of these flip the identity hash. Renaming a capability, swapping an operator key, bumping the schema version — any of these MUST flip it. The HR-1 regression runs on every PR; CI fails if either direction breaks.

Identity is the substrate that makes everything else governable. If you can't pin who the agent is, you can't audit what it did.

Layer 4 v0.10.0

Adaptive Persona — the asymmetric trust layer

Persona is not a prompt. It is a stream of typed events (PersonaAdaptiveEvent) that mutate the agent's effective policy inside the bounds of the frozen manifest. The trust matrix is asymmetric on purpose.

↓

Tighten direction

Confidence drops. Risk rises. The robot wants to constrain itself.

auto-emit Layer 2 fires the event automatically; runtime signs with resident Ed25519 key. No human in the loop.
↑

Relax direction

Confidence rises. Risk drops. The robot wants to relax a constraint.

operator-signed The operator must counter-sign through aeros agent review. No auto-relax. Ever.

Engineering details

  • Outbox pattern: emit candidates persist in the same SQLite transaction as facts upsert + cursor advance, so a crash mid-emit cannot drop a tighten cross
  • 20/day per-identity cap; cap denial is terminal (clamp metric + DELETE)
  • Delivery failure releases the cap slot — only successful signed emits consume cap
  • Durability contract pinned by a regression test that simulates emit failure mid-flush and verifies the next pass replays the lost crossings

Why asymmetric

Tightening is the robot taking power away from itself. Faster the better.

Relaxing is the robot asking for more power. The operator's signature is what makes it auditable to a third party. No signature, no relax.

This is the governance layer between the LLM and the actuator. The LLM proposes; the persona engine approves.

Layer 5 v0.10.0

Layer 2 Semantic Memory

Layer 1 of memory is the episodic stream — an append-only log of intent and execution rows. Layer 2 folds that stream into a small set of semantic facts: deterministic SQL aggregations keyed on (identity_hash, fact_type, fact_key).

skill_success_rate per-skill success/fail tally + frequentist confidence
object_property per-object numeric ranges from observed properties
zone_risk per-zone visit count + average / peak risk
interaction_pattern per-identity human-proximity rate + modal hours

Determinism contract

  • Pure SQL GROUP BY + Python arithmetic
  • No LLM, no RNG, no clock-as-input
  • Same episodic input always produces the same fact rows
  • Layer 2 is relapse-safe; Layer 3 is re-derivable from it

Triggers & safety

  • Fires when 100 unconsolidated events accumulate or 6h has passed
  • 5s wall-clock budget per pass; on timeout the SQLite transaction rolls back
  • 3 consecutive timeouts auto-disable the consolidator until bridge restart (fail-closed)
  • AEROS_CONSOLIDATION_ENABLED=false hard-rolls back schema creation as well
Layer 5 v0.10.0

Active Dreaming — offline reflection

When the robot is idle, it can run a structured reflection cycle that folds episodic data into persona deltas. Output is still tighten-only auto-emit; relax still requires an operator signature. Dreaming is not unsupervised learning — it is bounded, audited, and identity-stable.

Components

  • DreamRunner — reflection cycle on the episodic + Layer 2 stream
  • DreamScheduler — lifecycle-driven trigger, not cron
  • Placeholder LLM guard — refuses dream cycles when no real model is wired

Boundaries

  • Cannot mutate the identity manifest
  • Cannot auto-emit relax-direction events
  • All output flows through the same Ed25519 audit chain as the wake-time persona engine
  • Dreams are audited; they are not private
Positioning

AEROS and ROS 2

AEROS Architecture — How AEROS fits between agents and hardware

Different layer, different concern

ROS 2 is communication middleware — it handles message passing between nodes. AEROS sits above ROS 2 and manages how agents are run and governed.

The analogy: Linux is to Kubernetes as ROS 2 is to AEROS. Kubernetes isn't a Linux plugin — it's a different abstraction layer solving a different problem. AEROS isn't a ROS 2 plugin either.

ROS 2 manages Topics, services, actions, nodes, DDS transport
AEROS manages Agent lifecycle, ECM packages, governance policies, audit trails
Business Model

Open-core architecture

Core runtime is open source. Enterprise governance is commercial.

Governance Console Policy DSL, watchers, audit, recovery orchestration
Enterprise License
ECM Package System Standard format, contracts, versioning, compatibility
Apache 2.0
Runtime Core Lifecycle, scheduling, execution loop, fault recovery
Apache 2.0

Open core attracts developers. Governance generates enterprise revenue.

Read the research

Seven systematic papers cover the architecture, governance, evolution, contracts, federation, and benchmarking behind AEROS.

View Research Program View Source →