AIDER — Predecessor Framework (Archive)

AIDER — Adaptive Intelligence for Dynamically Enhanced Reasoning — was the earliest predecessor in the lineage that led to ANIMA, Artux, and the Anima implementation. It was a self-improving AI assistant that dynamically learned, evolved, and optimised its own tools, workflows, and reasoning models.

This document preserves the architectural thinking and design decisions from the AIDER papers as research lineage.

Lineage

AIDER (archived)
  → ANIMA concept paper (cognitive architecture)
    → Artux (huginn + muninn) — first implementation
      → Anima — consolidated, refined implementation

The dual-spirit concept — Sagax as the stable backbone, Mirai as the adaptive imagination — originated in AIDER and persisted through every subsequent project.

AIDER 3.2 — The Source Project

AIDER 3.2 was a fully modular, self-improving AI system with these core capabilities:

• Multi-Modal Stimuli Processing — text, audio, system events, vision
• Real-Time & Deferred Actions — immediate execution and background task handling
• Self-Improving AI Reasoning — automatically enhanced its own decision-making models
• Automated Tool Creation & Optimization — built new tools and refined old ones
• Persistent Task Monitoring & Execution — never lost or forgot background tasks
• Adaptive Memory System — short-term and long-term recall with vectorised semantic search

Project Structure

AIDER_3.2/
├── core/
│   ├── process_manager.py        # Manages real-time AI interactions
│   ├── monitoring_system.py      # Listens for stimuli (text, voice, system events)
│   ├── memory_manager.py         # STM, LTM & memory purging logic
│   ├── vector_memory.py          # FAISS-based semantic recall
│   ├── context_manager.py        # Tracks ongoing conversation history
│   ├── profile_manager.py        # Manages user & entity relationships
│   ├── module_loader.py          # Loads AI tools based on benchmark performance
│   ├── dispatcher.py             # Executes dynamic function pipelines
│   ├── observation_chronicler.py # Stores real-time system & sensory events
├── memory/
│   ├── stm/                      # Short-term memory
│   │   ├── chronicler/           # Tracks recent environmental events
│   │   ├── conversation/         # Stores recent conversations
│   ├── ltm/                      # Long-term memory
│   │   ├── vector_store/         # Vector database for recall
│   │   ├── ltm_data.json         # Key-value storage of facts
│   │   ├── user_preferences.json # Stores preferences & behavior
│   │   ├── entity_profiles.json  # Tracks known people/entities
│   ├── archive/                  # Archived knowledge
├── passive/
│   ├── task_scheduler.py         # Manages background tasks with persistence
│   ├── learning_manager.py       # Improves AI decision-making
│   ├── pipeline_optimizer.py     # Optimizes execution pipelines
├── tools/
│   ├── thinking_tools/           # AI-driven reasoning models
│   ├── data_tools/               # Data collection APIs
│   ├── action_tools/             # Performs user actions
│   ├── lab/                      # Self-improving AI toolkit
│       ├── tool_generator.py     # Dynamically creates missing tools
│       ├── tool_updater.py       # Enhances existing tools over time

High-Level Workflow

1. Monitoring System captures stimuli — text, voice, system events, or vision input
2. Observation Chronicler logs data — FIFO memory stores recent events for decision-making
3. ThinkingEngine evaluates stimulus — selects best AI reasoning tool dynamically
4. Process Manager handles execution — immediate response or augmentation pipeline activation
5. Augmentation Pipeline generates improvements — new tools, updates, and optimisations
6. Passive System runs background enhancements — tool refinements, pipeline optimisations, AI learning
7. Memory Manager ensures context awareness — STM for ongoing interactions, LTM for deep recall

Example Scenarios

AIDER creates a new tool: When asked to process medical images, the Module Loader detects no tool exists. The Augmentation Pipeline schedules tool creation, the TaskScheduler runs the generator, the tool is benchmarked and added to the registry. Next time, AIDER automatically runs it.

AIDER detects a failing task and auto-fixes: When a scheduled improvement fails due to an unexpected error, the Passive System detects the failure, triggers the pipeline, calls the tool updater, and the model is improved. The task is marked as completed.

AIDER/Mirai — The Adaptive Spirit

Mirai was the modular, adaptive side of the AIDER framework. Unlike traditional assistants that simply react to commands, Mirai actively prioritised which tasks to engage with based on current context and user behaviour.

Core Components

• Perception Layer — handled all sensory input from the environment (audio, vision, system events) using listeners for real-time data gathering
• Attention Engine — filtered and prioritised incoming stimuli based on relevance, context, and urgency
• Process Manager — gathered context, interpreted stimuli, and decided what action to take
• Memory Stack — hierarchical memory system comprising STM, LTM, a diary (for reflections), and a notebook (for ongoing explorations)
• Output Manager — handled responses, delivering output through speech, text, or physical actions

Key Concepts

Journaling and Reflection. Unlike traditional logging, Mirai used journals for each tool, task, and pipeline to provide rich introspective data. These journals included context, reflection, actions taken, and results — allowing continuous self-improvement and transparency.

Adaptive Cognition. Mirai was designed with attention and intent-driven cognition. Through self-improvement loops, it learned which tools worked best for specific tasks and dynamically adapted its internal configurations.

Task-Specific Cloning. To handle concurrent tasks, Mirai could clone itself as needed, enabling task specialization while maintaining overall system integrity. Each clone was lightweight and independent, but communicated back to the main system.

Evolution and Growth. Mirai remembered past conversations, learned from them, and integrated feedback into future actions. Each instance was a unique, evolving agent tailored to its user.

AIDER/Sagax — The Stable Spirit

Sagax was defined as the Self-Adaptive Generative Autonomous eXperience — the stable backbone of the system. Its architecture included:

• Perception Manager — structured input processing
• Memory Manager — Chronicler, Recall(), Remember(), live/episodic/semantic memory
• Attention Manager — live memory filter, LTM clustering and compression, STM-to-LTM conversion
• Process Manager — Thinking Manager for reasoning
• Orchestrator — ran pipelines, coordinated components
• Tool Manager — managed tool lifecycle
• Task Manager — tracked work across sessions

The Sagax draft introduced the concept of taking a "snapshot from live memory" — combining rolling event profiles, task journals, active session memory, and retrieved LTM snippets — then using a thinking tool to decide what to do next.

What Persisted

The core ideas from AIDER carried forward into every subsequent project:

AIDER Concept	ANIMA	Artux
Sagax (stable backbone)	Sagax — dual spirit	Sagax — reasoning agent
Mirai (adaptive imagination)	Mirai — dual spirit	Distributed across architecture
Perception Layer	Perception Layer	Perception Manager
Memory Stack (STM/LTM)	Short-term/Long-term memory	STM / HTM / LTM (Muninn)
Attention Engine	—	Exilis (triage agent)
Process Manager	Orchestrator	Orchestrator (routing bridge)
ToolFactory	ToolFactory	Staging lifecycle
Journaling for self-improvement	Diary of thoughts	Contemplation blocks → STM
Task-specific cloning	—	HTM Tasks (multi-step work)

Access

These papers are preserved as archive documents. For the current work:

• ANIMA concept paper — the evolved philosophical framework
• Artux whitepaper — the first implementation