IGRIS — Continuous Learning Architecture for Embodied AI

The problem with frozen models

Most modern AI systems share a structural weakness: they are trained once on a fixed dataset and then deployed in a frozen state. After that point, the model cannot update its own weights based on what it sees in the real world. If the environment shifts, if new categories of input appear, or if the operator points out a mistake, the model has no way to absorb that feedback without an offline retraining pipeline.

This works well for tasks where the world is static — translating a fixed language, classifying photos of dogs and cats — but it falls apart for embodied agents: robots, drones, autonomous instruments, anything that interacts with the physical world. The physical world is not static. Sensors drift. Lighting changes. New objects show up. Operators have preferences. A frozen model treats all of this as an out-of-distribution failure to be handled by some external retraining loop that happens weeks or months later.

IGRIS is a research effort at ErenLabs to close that loop.

What IGRIS is

IGRIS is a continuous learning architecture for embodied AI. It is not a single model. It is a runtime — a set of cooperating components that let an agent ingest signals from its environment, update its internal representations, and act on those updated representations, all without leaving the deployment environment.

The acronym stands for the four properties the system is designed to provide:

• I — Incremental: updates happen one observation at a time, not in monolithic retraining batches.
• G — Grounded: learning is tied to real telemetry from real sensors, not synthetic samples.
• R — Reflective: the agent can examine its own past decisions and revise them.
• I — Integrated: the learning loop and the execution loop share state — they are not two separate systems.
• S — Situated: the agent is aware of where it is in the world and adjusts behavior accordingly.

Architecture overview

At a high level, IGRIS has three layers that map cleanly onto the three real engineering problems any continuous learning system must solve:

• The learning runtime — the part that actually updates internal parameters in response to new data.
• The telemetry pipeline — the part that gets clean, timestamped signals from physical sensors into the runtime.
• The cognitive execution bridge — the part that turns a learned representation into a concrete action on a device.

Each of these is built as an independent module that communicates through a typed message bus. That separation matters because it means each layer can be tested, replaced, or rate-limited without touching the others. The runtime can be paused without losing telemetry. The telemetry can be replayed without re-running the runtime. The execution bridge can be locked out during high-risk operations.

The learning runtime

The learning runtime is the most experimental part of IGRIS. Its job is to take new observations, decide whether they carry information worth retaining, and update internal parameters accordingly. Several design decisions distinguish it from a conventional training loop:

Selective updates. Not every observation triggers a weight update. The runtime maintains an internal estimate of how surprising an observation is given what it already knows. Low-surprise observations are logged but do not cause updates. High-surprise observations do. This keeps the system from overfitting to the most recent few seconds of input.

Bounded drift. Each update is rate-limited and constrained relative to a checkpoint. If the agent's behavior drifts too far from its last verified-safe checkpoint, the runtime pauses learning and asks for human confirmation. This is essential for any system that touches the physical world.

Local context windows. Rather than retraining over the entire history, the runtime maintains a sliding window of recent observations plus a smaller archive of representative past observations. This is closer to how biological memory consolidation works than to standard offline training.

Telemetry pipeline

The telemetry pipeline is the unglamorous part that determines whether the whole system works. A continuous learning agent is only as good as the signals it sees. The pipeline has to handle:

• Multi-rate sensors — IMU at 1 kHz, camera at 30 Hz, environment probes at 1 Hz. Each stream needs to arrive timestamped and aligned.
• Lossy transports — radio links, USB serial, intermittent cellular. The pipeline assumes losses and tags every packet with a sequence number and a hardware timestamp.
• Sensor health — a dead sensor must look different to the runtime from a sensor reporting zeros. The pipeline carries a confidence channel alongside every value.

This is built on a small embedded firmware layer (the DAQ unit) that runs on a microcontroller close to the sensors, plus a higher-level Python service that aggregates DAQ output into the typed message bus. The DAQ unit firmware is also tracked as a separate research log because the embedded engineering work is substantial.

Cognitive execution bridge

The cognitive execution bridge is the layer that turns a decision from the learning runtime into a physical action — moving a motor, firing an actuator, sending a command to another microcontroller. The bridge enforces three rules:

• Every action is reversible or logged. If it cannot be undone, it must at minimum be recorded with the full decision context that produced it.
• Every action has a confidence threshold. The runtime publishes its confidence in every recommendation. Actions below the threshold are deferred to a human-in-the-loop queue rather than executed silently.
• Every action is rate-limited per device. A motor cannot be commanded faster than its mechanical settling time. A radio cannot be told to transmit faster than its duty cycle allows.

The bridge is intentionally boring. Its value is exactly that it does not do anything clever — it only translates decisions into hardware commands in a predictable, auditable way.

Why build this

The honest answer is that most existing AI infrastructure assumes an offline training environment with a large dataset, a GPU cluster, and a deployment pipeline that ships frozen weights to inference servers. That is the wrong shape for the work happening at ErenLabs, which involves embedded hardware, real sensors, and instruments that need to keep learning after they leave the bench.

IGRIS is the smallest viable architecture that supports that mode of work. It is not trying to be a general-purpose AGI. It is trying to be a credible runtime for a specific class of problem — embodied agents that operate continuously and must adapt to their environment without a human round-trip every time something changes.

If that class of problem turns out to be more general than it looks, that is a happy accident. The near-term goal is to ship something that works for one real device.

Current status

IGRIS is an active research effort, not a released product. The current state, as of May 2026:

• Learning runtime v1 design — complete on paper, partial implementation in the lab.
• DAQ unit firmware — first revision running on bench hardware, talking to the telemetry pipeline.
• Telemetry pipeline — partial; multi-rate alignment and sensor health channels implemented, archive compression pending.
• Cognitive execution bridge — design phase; first action types defined, confidence-threshold dispatcher in progress.
• Public API — api.erenlabs.com reserved; not yet serving telemetry.

Progress is documented in the research logs, and weekly build sessions are recorded on the IGRIS YouTube channel. If you work in this space and want to collaborate or follow the work more closely, the contact page is the right starting point.