What AIMAXXING Is

AIMAXXING is a local-first autonomous agent runtime built around one public front agent and many narrow worker agents.

The product direction is Windows native first. WSL/Linux paths are used for development, compatibility checks, and bridge-based testing, but they are not the default product deployment story.

The current architecture optimizes for:

• one clear user-facing agent: aimaxxing is the public conversation entry point
• specialist workers: worker agents equip narrow tools or skills instead of dumping every tool into the front prompt
• local model ownership: local GGUF/ONNX/Windows ML style model flows are treated as first-class citizens
• governed memory: short-term continuity, long-term facts, RAG, and sensory writeback are separated but coordinated
• safe execution: tools, skills, browsers, shell commands, and external runtimes run behind explicit security and policy boundaries
• observable runtime behavior: traces, witness records, task state, resource pressure, and failures are meant to be diagnosable

Current Runtime Shape

User / Panel / Gateway
        |
        v
aimaxxing front agent
        |
        | delegate / shared board / memory / RAG / voice coordination
        v
specialist worker agents
        |
        | explicitly equipped builtin tools or installed skills
        v
files, browser, knowledge base, models, media, OS runtimes

The front agent should stay small and focused. It routes, remembers, retrieves, coordinates, and explains. Specialized workers execute the concrete tools.

Applications

Crate Map

The crate list below is based on the current crates/*/README.md files. Each crate owns a narrow part of the system; detailed behavior should live inside the crate README, not in this root document.

Agent Brain And Runtime Policy

Memory, Knowledge, And Compression

Models, Sensory, And Resource Control

Tools, Skills, And Execution

State, Scheduling, Telemetry, And Infrastructure

Communication And Protocols

Design Commitments

Windows Native Is The Product Path

AIMAXXING may use WSL bridges during development to test Windows-native model and browser behavior from a Linux workspace. The product target remains native Windows execution, with Windows model/runtime configuration exposed through the panel instead of hidden scripts.

Model Selection Belongs To Users

Language models are equipped on agents. Global small models and sensory models are configured through panel-owned model bindings. Runtime code should resolve models from configuration and factory detection, not from hardcoded model names.

Memory And RAG Are Related But Not The Same

Personal memory is governed fact and continuity state. RAG/knowledge is durable retrieval over imported or captured documents. Both share storage/retrieval infrastructure, but user intent and routing must keep them separate.

Tools Are Equipped, Not Assumed Global

Installed skills and most builtin tools are not automatically available to the front agent. A worker agent equips a narrow tool or skill, and the front agent delegates when needed. This keeps prompts smaller and failures easier to debug.

Real Agent Tests Matter

For agent behavior, panel/gateway chat tests are preferred over mock-only tests. Unit tests still matter, but routing, memory, multimodal, browser, and tool orchestration must be validated through real runtime paths when they affect user behavior.

Documentation Entry Points

• Documentation Hub, Chinese
• Documentation Hub, English
• Development Standards
• Memory Core
• Builtin Tools
• Engram
• Compression Migration Plan

Development Notes

Before changing architecture or shared behavior, read docs/DEVELOPMENT_STANDARDS_AGENTOS.md.

Useful checks:

cargo check --workspace
git diff --check

For narrower work, prefer crate-specific checks, for example:

cargo check -p aimaxxing-brain
cargo check -p aimaxxing-memory-core -p aimaxxing-memory-api
cargo check -p aimaxxing-builtin-tools

Built for local ownership, practical autonomy, and a Windows-first personal AI runtime that ordinary users can actually live with.