Paper deep dive
IronEngine: Towards General AI Assistant
Xi Mo
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 95%
Last extracted: 3/13/2026, 12:50:08 AM
Summary
IronEngine is a comprehensive AI assistant platform designed with a unified orchestration core that integrates multi-model backends, hierarchical memory, and a three-phase pipeline (Discussion, Model Switch, Execution) to separate planning from tool-augmented execution. It addresses fragmentation, single-model bottlenecks, and local deployment challenges by utilizing VRAM-aware model management and an intelligent tool routing system.
Entities (6)
Relation Signals (3)
IronEngine â implements â Three-Phase Pipeline
confidence 100% ¡ IronEngine introduces a three-phase pipeline -- Discussion... Model Switch... and Execution
Planner â collaborateswith â Reviewer
confidence 95% ¡ Planner--Reviewer collaboration
IronEngine â utilizes â ChromaDB
confidence 95% ¡ a vectorized skill repository backed by ChromaDB
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:This paper presents IronEngine, a general AI assistant platform organized around a unified orchestration core that connects a desktop user interface, REST and WebSocket APIs, Python clients, local and cloud model backends, persistent memory, task scheduling, reusable skills, 24-category tool execution, MCP-compatible extensibility, and hardware-facing integration. IronEngine introduces a three-phase pipeline -- Discussion (Planner--Reviewer collaboration), Model Switch (VRAM-aware transition), and Execution (tool-augmented action loop) -- that separates planning quality from execution capability. The system features a hierarchical memory architecture with multi-level consolidation, a vectorized skill repository backed by ChromaDB, an adaptive model management layer supporting 92 model profiles with VRAM-aware context budgeting, and an intelligent tool routing system with 130+ alias normalization and automatic error correction. We present experimental results on file operation benchmarks achieving 100\% task completion with a mean total time of 1541 seconds across four heterogeneous tasks, and provide detailed comparisons with representative AI assistant systems including ChatGPT, Claude Desktop, Cursor, Windsurf, and open-source agent frameworks. Without disclosing proprietary prompts or core algorithms, this paper analyzes the platform's architectural decomposition, subsystem design, experimental performance, safety boundaries, and comparative engineering advantages. The resulting study positions IronEngine as a system-oriented foundation for general-purpose personal assistants, automation frameworks, and future human-centered agent platforms.
Tags
Links
- Source: https://arxiv.org/abs/2603.08425v1
- Canonical: https://arxiv.org/abs/2603.08425v1
Trouble viewing inline? Open PDF directly â
Full Text
129,895 characters extracted from source content.
Expand or collapse full text
IronEngine: Towards General AI Assistant System Design, Multi-Model Orchestration, and Engineering Practice for a General AI Assistant System Design Overview Author: Xi Mo Affiliation: NiusRobotLab Channel: YouTube Channel @NiusRobotLab Date: March 2026 Produced by independent researcher and individual affiliation - NiusRobotLab This technical report and relevant source code, including experiments and results analysis are fully, automatically designed by AI Agents, prompt by the author. arXiv:2603.08425v1 [cs.AI] 9 Mar 2026 IronEngine: Towards General AI Assistant Contents 1 Introduction1 2 Related Work3 2.1 Reasoning and Action Coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Tool Use and API Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Memory and Knowledge Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Multi-Agent Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.5 Web and GUI Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.6 Productized AI Assistants and Code Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.7 The OpenClaw Ecosystem: OpenClaw, NanoClaw, and IronClaw . . . . . . . . . . . . . . . . . . 5 3 Design Goals6 4 Overall Architecture7 5 Implementation Evidence and Engineering Characteristics7 6 Module Decomposition7 7 Three-Phase Pipeline8 7.1 Phase 1: Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2 Phase 2: Model Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.3 Phase 3: Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8 Tool System Architecture11 8.1 Tool Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.2 Intelligent Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.3 Web Search Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.4 Web Content Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.5 Multimedia Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.6 GUI Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.7 Execution Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9 Memory and Skill System12 9.1 Hierarchical Memory Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.2 Vectorized Skill Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10 Adaptive Model Management13 10.1 Model Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.2 VRAM-Aware Context Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.3 Tiered Prompt System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.4 Thinking Depth Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.5 Dynamic Capability Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11 MCP Compatibility and Open Ecosystem Strategy15 12 Experimental Evaluation15 12.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.2 File Operation Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.3 Pipeline Phase Time Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 YouTube @NiusRobotLabI IronEngine: Towards General AI Assistant 12.4 Tool Routing Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.5 Multi-Model Collaboration Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.6 VRAM and Resource Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.7 Search Deduplication and Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.8 Error Patterns and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.9 Comparison with Representative Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.10Cross-Model Tool Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.11Full Pipeline Integration Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.12Tool Model Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.13Multi-Scenario Diagnostic Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13 Interfaces, Deployment, and Product Positioning20 13.1 Deployment Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.2 Product Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.3 Desktop Workbench Design Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 14 Safety and Privacy21 14.1 Permission Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 14.2 Execution Sandboxing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 14.3 URL Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 14.4 Intervention Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 14.5 SOUL Edit Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 14.6 Local-First Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 14.7 Internal English Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 14.8 Defense-in-Depth Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 15 Discussion22 15.1 Architectural Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 15.2 Scalability Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 15.3 Architectural Comparison with the OpenClaw Ecosystem . . . . . . . . . . . . . . . . . . . . . . 23 15.4 Design Principles and Engineering Insights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 15.5 Generalizability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 15.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 16 Future Work24 17 Conclusion24 YouTube @NiusRobotLabII IronEngine: Towards General AI Assistant List of Figures 1 Simplified trajectory of AI agent research and product evolution relevant to IronEngine. Blue nodes indicate research milestones; orange nodes indicate product-oriented systems. . . . . . . . 7 2 Overall architecture of IronEngine showing the four-layer design: interaction surfaces (top), uni- fied orchestrator (middle), capability modules (lower-middle), and environment interfaces (bottom). 8 3 IronEngine desktop UI. The left panel exposes model and execution configuration with Plan- ner/Reviewer/Tools model selectors. The right area supports conversation with inline thinking blocks, tool execution badges, and quality score indicators. . . . . . . . . . . . . . . . . . . . . . . 9 4 IronEngine three-phase pipeline. Phase 1 (Discussion): Planner and Reviewer collaborate on plan quality without tool execution. Phase 2 (Model Switch): VRAM-aware transition from discussion models to execution model. Phase 3 (Execution): Executor runs tools iteratively until task completion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6 Web search four-strategy fallback chain. Each strategy is attempted in order; the first success terminates the chain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5 Tool dispatch flow in IronEngine. Model output is parsed, types are normalized through 130+ aliases, auto-corrected if mismatched, and dispatched with multi-layer fallback chains. . . . . . . 12 7 Memory hierarchy and lifecycle in IronEngine. Session and pipeline entries are consolidated through two merge strategies into daily summaries and refined long-term knowledge. Context retrieval selects the most relevant entries (2 positive + 1 negative examples) for each new request. 14 8 Distribution of execution time across pipeline phases for each benchmark task. Model inference (Planner + Reviewer + Executor) dominates total time, while actual tool execution completes in under 2 seconds. The model switch phase is constant at âź27 seconds. . . . . . . . . . . . . . . 16 9 PlannerâReviewer quality score progression. Red bars show initial Round 1 scores; green bars show final scores after Reviewer feedback. The Reviewerâs structured feedback (ISSUES + SUG- GESTIONS) enables the 14B Planner to improve plans from 0.10â0.20 to 0.80â0.85, while the larger 27B Planner often achieves acceptable quality on the first round. . . . . . . . . . . . . . . 19 YouTube @NiusRobotLabIII IronEngine: Towards General AI Assistant List of Tables 1 Mapping between major system claims and engineering evidence in the project . . . . . . . . . . 8 2 IronEngine tool categories organized by functional domain . . . . . . . . . . . . . . . . . . . . . . 12 3 Tiered prompt system based on model size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5 Tool routing auto-correction statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4 File operation benchmark results. All tasks achieve 100% correctness (4/4 PASS). . . . . . . . . 16 6 VRAM usage by pipeline phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7 Detailed capability comparison with representative AI assistant systems. Ratings: S=Strong, M=Medium, W=Weak, â=Not applicable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8 Cross-model tool awareness test results. All models achieve perfect tool-type identification with IronEngineâs tiered prompt system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9 Full pipeline integration test results across model configurations and scenarios. Quality scores show Round 1 (initial) â Round 2 (after Reviewer feedback) progression. . . . . . . . . . . . . . 19 10 Tool model reliability comparison. Translation success = valid JSON output; Execution success = correct tool result. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11 Multi-scenario diagnostic test results. Five of six scenarios pass (83.3%). The travel planning fail- ure is due to the test environment lacking network access. Skill learning is triggered automatically for tasks rated ⼠7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12 System-positioning comparison with representative AI agent frameworks and products . . . . . . 21 YouTube @NiusRobotLabIV IronEngine: Towards General AI Assistant IronEngine: Towards General AI Assistant System Design, Multi-Model Orchestration, and Engineering Practice for a General AI Assistant Xi Mo NiusRobotLab March 2026 Abstract: As large language models evolve from single-turn conversational systems into long-running agents with tool use, memory, and environmental interaction, the practical value of an AI assistant increas- ingly depends on system architecture rather than model capability alone. This paper presents IronEngine, a general AI assistant platform organized around a unified orchestration core that connects a desktop user interface, REST and WebSocket APIs, Python clients, local and cloud model backends, persistent memory, task scheduling, reusable skills, 24-category tool execution, MCP-compatible extensibility, and hardware-facing integration. IronEngine introduces a three-phase pipelineâDiscussion (PlannerâReviewer collaboration), Model Switch (VRAM-aware transition), and Execution (tool-augmented action loop)âthat separates planning quality from execution capability. The system features a hierarchical memory architec- ture with multi-level consolidation, a vectorized skill repository backed by ChromaDB, an adaptive model management layer supporting 92 model profiles with VRAM-aware context budgeting, and an intelligent tool routing system with 130+ alias normalization and automatic error correction. We present experimental results on file operation benchmarks achieving 100% task completion with a mean total time of 1541 seconds across four heterogeneous tasks, and provide detailed comparisons with representative AI assistant systems including ChatGPT, Claude Desktop, Cursor, Windsurf, and open-source agent frameworks. Without disclosing proprietary prompts or core algorithms, this paper analyzes the platformâs architectural de- composition, subsystem design, experimental performance, safety boundaries, and comparative engineering advantages. The resulting study positions IronEngine as a system-oriented foundation for general-purpose personal assistants, automation frameworks, and future human-centered agent platforms. Keywords: general AI assistant; AI agent systems; multi-model orchestration; local LLM integration; per- sistent memory; skill learning; tool routing; task scheduling; MCP compatibility; VRAM management; safety 1 Introduction The landscape of AI assistants has undergone a fun- damental transformation. Beginning with the Trans- former architecture [1] and scaling through GPT- 3âs demonstration of few-shot in-context learning [2], large language models (LLMs) have progressed from text completion engines to systems capable of rea- soning, tool use, and multi-step task execution. The open-source movement, catalyzed by models such as LLaMA [3], has made capable models accessible for lo- cal deployment, while GPT-4 [4] and Gemini [5] have pushed the frontier of multimodal reasoning. This convergence of capability and accessibility creates a unique opportunity: building AI assistants that are not merely wrappers around a single model endpoint, but comprehensive systems that organize model capa- bility into stable, controllable, and reusable behavior. Recent research has established several founda- tional paradigms for AI agents. ReAct demonstrated the value of interleaving reasoning and action within a single model loop [6]. Chain-of-thought prompting revealed that explicit reasoning traces improve task decomposition [7]. Toolformer showed that models can learn to invoke external tools autonomously [8]. Retrieval-augmented generation (RAG) established the importance of external non-parametric mem- ory [9]. Generative Agents demonstrated how mem- ory streams, reflection, and planning can sustain co- herent long-horizon behavior in simulated environ- ments [10]. Reflexion introduced verbal self-critique as a mechanism for iterative improvement [11]. These contributions collectively define the building blocks of modern agent systems. At the framework level, systems such as Auto- Gen [12], CAMEL [13], MetaGPT [14], ChatDev [15], OpenManus [16], and OpenClaw [17] have accel- erated the move from isolated model calls toward agent ecosystems with role-based collaboration, work- flows, and persistent execution surfaces. Meanwhile, productized AI assistantsâincluding ChatGPT with GPT-4o [18], Claude Desktop with MCP [19, 20], Cur- sor [21], Windsurf [22], and GitHub Copilot [23]â have brought AI agent capabilities to millions of end users. Yet upon closer examination, five systemic prob- lems persist across current systems, each representing a distinct engineering challenge that existing solutions address only partially. YouTube @NiusRobotLab1 IronEngine: Towards General AI Assistant The Fragmentation Problem. Todayâs AI as- sistants exist as isolated endpoints: ChatGPT is a web interface, Claude Code is a CLI tool, Cursor is an IDE plugin, and Open Interpreter is a Python library. A user who needs to automate desktop applications, search the web, manipulate files, and send messages through instant messaging platforms must switch be- tween multiple disjoint tools, each with its own model backend, context window, and interaction paradigm. No single system provides a unified orchestration core that consolidates all these capabilities under one ar- chitectural umbrella, forcing users to choose between convenience (polished but narrow products) and gen- erality (flexible but fragmented frameworks). The Single-Model Bottleneck. Most current systems rely on a single model to handle all cognitive functionsâplanning, self-evaluation, tool invocation, and output generationâwithin one inference pass. This design creates an inherent tension: large models (30B+ parameters) excel at complex multi-step rea- soning but waste computational resources on simple translation or formatting tasks, while small models (3â8B parameters) run efficiently on consumer hard- ware but cannot sustain coherent multi-round plan- ning. Few systems provide a heterogeneous model al- location architecture that assigns different-sized mod- els to different cognitive roles within a single task, let alone manages the GPU memory lifecycle required to swap models on and off a single GPU. The Ephemeral Assistant Problem. Current AI assistants are predominantly stateless across ses- sions. Each conversation begins from a blank slate, with no memory of past interactions, learned skills, or accumulated domain knowledge. While some sys- tems offer conversation history, none provide a com- prehensive solution that combines hierarchical mem- ory with lifecycle policies (creation, consolidation, de- cay), quality-filtered skill learning from successful exe- cutions, rating-driven retrieval that prioritizes proven knowledge, and contradiction detection that super- sedes stale information. The absence of structured persistence forces users to re-explain their preferences, re-teach workflows, and re-provide context in every new session. The Local Deployment Challenge. Privacy- sensitive workloadsâpersonal communications, pro- prietary documents, medical records, financial dataâ demand fully local inference with no data leaving the userâs machine. Yet local deployment on consumer- grade hardware introduces challenges that cloud- hosted systems avoid: model heterogeneity (differ- ent architectures require different quantization strate- gies), context window constraints (VRAM limits the number of tokens a model can process), and intelligent resource scheduling (loading a 14B Planner and an 8B Reviewer sequentially on a single 24 GB GPU). Few systems provide VRAM-aware model lifecycle man- agement that can automatically select, load, and un- load models based on available hardware resources. The Tool Integration Problem. Each AI as- sistant implements tools as bespoke plugins with no unified dispatch layer. There is no alias normaliza- tion (recognizing that âweb_searchâ, âsearch_webâ, âgoogleâ, and âbrowseâ refer to the same capability), no automatic error correction (redirecting a model that specifies a wrong tool typeâa common fail- ure mode for small models), no fallback chains (try- ing alternative execution strategies when the primary method fails), and no cross-category routing (dis- patching a single user request to the appropriate tool among 24 categories). When a model specifies an in- correct tool type, the system fails outright rather than intelligently redirecting the request. Beyond these five problems, the engineering scale required to address them simultaneously is itself a sig- nificant challenge. IronEngine is a large-scale systems engineering project: 46,690 lines of Python code dis- tributed across 97 source files. The core engine layer (iron_engine/) contains 35,157 lines, with the tool routing subsystem (tool_router.py, 8,202 lines) and pipeline orchestrator (pipeline.py, 5,289 lines) as the most complex components. The user interface layer (ui/) comprises 7,348 lines, and the API service layer (api/) adds 298 lines. Twenty-seven key core modules account for 26,932 lines (76.6% of the core engine), covering pipeline orchestration, tool routing, memory management, skill learning, model sessions, permission control, browser automation, desktop GUI control, network utilities, URL safety analysis, and MCP compatibility. This scale reflects IronEngineâs nature as a complete platform rather than a single- purpose component. IronEngine is designed from this systems perspec- tive. Rather than optimizing for a single interaction modality or model backend, it provides a unified en- gine that organizes UI interaction, APIs, local and remote models, hierarchical memory, task execution, skill acquisition, tool routing, MCP-compatible exten- sibility, and device-facing integration into one coher- ent platform. The platform introduces a three-phase pipelineâDiscussion, Model Switch, and Executionâ that separates planning quality (assessed by a Re- viewer) from execution capability (handled by a ded- icated Executor with tool access). This architectural separation enables heterogeneous model allocation, where different model sizes and capabilities are as- signed to different roles based on task requirements and available hardware resources. This paper studies IronEngine not as a model benchmark, but as an architectural response to the question of how a practical, general-purpose AI assis- tant should be engineered. We present the systemâs YouTube @NiusRobotLab2 IronEngine: Towards General AI Assistant design principles, architectural decomposition, sub- system design for tools, memory, skills, and model management, experimental evaluation on file opera- tion benchmarks, and comparative analysis against representative AI assistant systems. Throughout, we focus on engineering design decisions and their ratio- nale without disclosing proprietary prompts, sensitive algorithms, or core implementation details. 2 Related Work The development of AI agent systems spans multiple research traditions. We organize related work into six categories and discuss how IronEngine relates to and extends each line of work. 2.1 Reasoning and Action Coupling The integration of reasoning with environmental ac- tion represents a foundational paradigm in agent systems. ReAct [6] established the interleaving of thought traces and action steps, enabling models to ground their reasoning in observed outcomes. Chain-of-thought prompting [7] demonstrated that explicit intermediate reasoning improves multi-step problem solving, a principle that extends naturally to agent planning. Reflexion [11] introduced verbal self-reflection as a learning signal, allowing agents to improve across attempts without weight updates. Cognitive architectures for language agents [24] pro- vide a theoretical framework connecting these empir- ical findings to established cognitive science models. IronEngine builds on these foundations by separating reasoning (Planner) from evaluation (Reviewer) and action (Executor) into distinct pipeline phases, each potentially served by different models optimized for their respective roles. Subsequent work has extended these paradigms toward more complex architectures. Inner Mono- logue [25] showed that feeding environmental feed- back into a reasoning loop enables embodied agents to recover from failures. Chain-of-Action approaches decompose high-level goals into grounded action se- quences, but typically rely on a single model to both reason and act, creating a bottleneck when reason- ing quality and action execution have different com- putational requirements. A fundamental limitation of these coupled architectures is that the same model must simultaneously maintain planning coherence and generate syntactically correct tool invocationsâtasks that favor different model sizes and training objec- tives. IronEngine addresses this by decoupling reason- ing from action at the architecture level: the Planner produces a textual plan evaluated by the Reviewer for quality, and only after the plan passes quality thresholds does a separate Executor model translate it into tool calls. This separation allows using a larger, more capable model for planning and a smaller, tool- specialized model for execution, optimizing both qual- ity and resource efficiency. 2.2 Tool Use and API Integration Tool-augmented language models represent a critical capability for practical AI assistants. Toolformer [8] demonstrated self-supervised tool use, where models learn when and how to invoke calculators, search en- gines, and other utilities. ToolLLM [26] scaled this approach to 16,000+ real-world APIs with a decision tree-based reasoning framework. Gorilla [27] focused on accurate API call generation with reduced halluci- nation through retrieval-augmented fine-tuning. Hug- gingGPT [28] demonstrated using LLMs as controllers that orchestrate specialized AI models for complex multimodal tasks. WebGPT [29] pioneered browser- assisted question answering with human feedback. These systems typically focus on a single tool-use paradigm or API surface. IronEngine extends this work with a unified tool routing layer that manages 24 tool categories through intelligent dispatch, auto- matic type correction, and multi-layer fallback chains, enabling a single assistant to handle file operations, web browsing, GUI automation, network manage- ment, and multimedia analysis within one execution framework. A critical but under-explored dimension of tool in- tegration is breadth versus depth. Most research sys- tems focus on API-level tool calling (HTTP requests to web services), while real-world desktop automation demands tools that span fundamentally different in- teraction modalities: CLI commands, GUI element inspection via accessibility APIs, browser DOM ma- nipulation via CDP, keyboard and mouse simulation, network socket operations, and multimedia process- ing pipelines. Furthermore, tool-use reliability de- grades significantly with smaller models: a 3.8B pa- rameter tool model may generate syntactically cor- rect JSON but specify the wrong tool type (e.g., âweb_readâ instead of âweb_searchâ), a failure mode that most systems handle by simply reporting an er- ror. IronEngine introduces two mechanisms absent in prior work: (1) alias normalization, which maps 130+ variant tool type strings to 24 canonical cate- gories through prefix matching, suffix stripping, and semantic equivalence tables; and (2) automatic error correction, which detects tool type mismatches based on the instruction content (e.g., a âbrowseâ type with a search query is redirected to âweb_searchâ) and ap- plies content-based heuristics (e.g., instructions men- tioning â.exeâ files are not incorrectly redirected to binary read). These mechanisms reduce tool dispatch failures by an order of magnitude compared to direct YouTube @NiusRobotLab3 IronEngine: Towards General AI Assistant model-specified routing. 2.3 Memory and Knowledge Management Persistent memory is essential for agents that op- erate across sessions. RAG [9] established retrieval over external corpora as a mechanism for knowledge- intensive tasks. Generative Agents [10] introduced memory streams with importance scoring, reflection, and planning as a coherent cognitive architecture. Augmented language models [30] provide a compre- hensive survey of how external memory, retrieval, and tool use extend model capabilities beyond their para- metric knowledge. ChromaDB [31] and similar vector databases provide the infrastructure for embedding- based retrieval at scale. IronEngineâs memory sys- tem goes beyond simple RAG by implementing a hi- erarchical consolidation architecture with four entry types (session, pipeline, daily summary, refined), dual merge strategies (fast deduplication and model-based consolidation), user rating integration, and idle-time background processing. This design treats memory as a managed resource with lifecycle policies rather than a raw transcript log. Recent specialized memory systems have ad- vanced the state of the art in specific directions. MemGPT [32] (later evolved into the Letta frame- work) introduced an operating system-inspired mem- ory hierarchy with main context and external stor- age, using function calls to manage memory paging. Mem0 provides a memory layer for LLM applications with automatic extraction and retrieval of user pref- erences. These systems demonstrate the importance of structured memory but typically address a single aspect of the memory lifecycle. MemGPT focuses on within-session context management (virtual pag- ing to extend effective context length), while Mem0 emphasizes cross-session preference extraction. Iro- nEngineâs memory architecture differs in three ways: (1) it implements a dual merge lifecycleâMerge A performs fast hash-based deduplication triggered au- tomatically when entry count exceeds a threshold, while Merge B uses a model-based daily consolidation supervised by the Reviewer to produce refined sum- maries; (2) it integrates user ratings (1â10 scale from the UI) into memory retrieval, so that highly-rated sessions are preferentially recalled while poorly-rated ones are deprioritized; and (3) it performs contradic- tion detection by comparing numerical values (prices, versions, specifications) in newly retrieved tool re- sults against stored memory entries, automatically su- perseding stale information rather than allowing the model to hallucinate from outdated memory. 2.4 Multi-Agent Collaboration Multi-agent systems explore how multiple LLM in- stances can collaborate effectively. CAMEL [13] in- troduced communicative agents with role-based in- teraction for open-ended exploration. MetaGPT [14] organized software production as a multi-role pro- cess coordinated through standard operating proce- dures. ChatDev [15] further explored communicative agents for software engineering workflows. Compre- hensive surveys [33â35] identify agent profiling, com- munication topology, shared memory, and evaluation methodology as central themes. AutoGen [12] and crewAI [36] provide flexible frameworks for defining multi-agent conversations with customizable interac- tion patterns. IronEngine adopts a structured multi- role approach with fixed pipeline phases rather than free-form multi-agent conversation, prioritizing pre- dictability and controllability over conversational flex- ibility. The PlannerâReviewer discussion loop pro- vides quality assurance without the overhead of man- aging arbitrary agent topologies. The communication topology chosen by a multi- agent system fundamentally shapes its reliability characteristics. CAMELâs role-playing approach al- lows open-ended dialogue between two agents but pro- vides no formal quality gateâeither agent can pro- duce low-quality output that propagates unchecked. MetaGPTâs SOP-based coordination imposes struc- ture but couples tightly to software engineering work- flows. ChatDevâs phase-based approach (designing, coding, testing, documenting) provides sequential quality checks but is domain-specific. AutoGenâs con- versable agent framework offers maximum flexibility in defining interaction patterns but leaves quality as- surance as an application-level concern. IronEngine makes an explicit architectural trade-off: it sacrifices the topological flexibility of free-form multi-agent con- versation in favor of a fixed three-phase pipeline with a formal quality gate. The Reviewerâs numerical qual- ity score (0.0â1.0) serves as an objective threshold that must be met before execution proceeds, and the Reviewerâs structured feedback (ISSUES and SUG- GESTIONS sections) provides actionable improve- ment signals. This design ensures that every executed plan has passed explicit quality review, a guarantee that flexible multi-agent topologies do not inherently provide. The trade-off is that IronEngine cannot dy- namically spawn new agent roles or reconfigure its communication topology at runtimeâa limitation ac- cepted in exchange for predictable quality behavior. 2.5 Web and GUI Agents Environment-facing agents that interact with web browsers and desktop applications represent an im- portant frontier. Mind2Web [37] introduced a bench- YouTube @NiusRobotLab4 IronEngine: Towards General AI Assistant mark and dataset for generalist web agents that op- erate across diverse websites. WebArena [38] pro- vided a realistic web environment for evaluating au- tonomous browsing agents. SWE-agent [39] and SWE-bench [40] established benchmarks for auto- mated software engineering through repository-level code modification. Open Interpreter [41] demon- strated local code execution as a natural language interface. IronEngine integrates both web and desk- top GUI automation within its tool routing frame- work, including CDP-based browser control with anti- detection measures [42], multi-engine web search with automatic captcha handling, and Windows UI Au- tomation (UIA) for desktop application control. Desktop GUI automation presents challenges qualitatively different from web browsing. OS- World [43] established a comprehensive benchmark for evaluating autonomous agents on real desktop op- erating systems, revealing that even state-of-the-art models achieve below 12% success rates on complex desktop tasks. The difficulty stems from the hetero- geneity of desktop UI frameworks: Win32 controls, WPF elements, Qt widgets, and Electron-based applications each expose accessibility information differently or not at all. For instance, WeChat (built on Qt 5.15) exposes only approximately 16 UIA ele- ments at depth 3, with no contact names accessible through the accessibility treeârequiring a fundamen- tally different approach based on screenshots and coordinate-based interaction. IronEngine addresses this through a layered automation strategy: UIA-first for applications with rich accessibility support, falling back to screenshot-based visual analysis (using a local vision model) combined with coordinate-based mouse and keyboard simulation for applications with min- imal accessibility exposure. The system maintains application-specific knowledge (e.g., WeChat tray icon coordinates, emoji panel layout) as innate skills, while learned skills capture successful interaction sequences for reuse across sessions. 2.6 Productized AI Assistants and Code Agents The productization of AI assistants has accelerated significantly. ChatGPT with GPT-4o [18] provides multimodal conversation with tool use through a cloud-hosted interface. Claude Desktop with MCP support [19, 20] emphasizes protocol-level extensibil- ity for connecting to external tools and data sources. Cursor [21] and Windsurf [22] focus on code-centric AI assistance with deep IDE integration. GitHub Copilot [23] provides inline code suggestions and chat- based programming assistance. AutoGPT [44] pio- neered autonomous goal-directed agent behavior. These products can be categorized along two axes: cloud dependence and domain breadth. Cloud- hosted products (ChatGPT, Claude, Gemini) offer the strongest model capabilities but require all user data to traverse external servers, making them un- suitable for privacy-sensitive workloads. Code-centric assistants (Cursor, Windsurf, Copilot, Claude Code) achieve deep integration within their target domain (software development) but are deliberately narrowâ they do not attempt desktop automation, instant messaging, multimedia analysis, or network manage- ment. Autonomous agent frameworks (AutoGPT, OpenManus, crewAI) provide the broadest task cover- age but typically lack formal quality assurance mech- anisms, VRAM-aware model management, or struc- tured memory beyond conversation logs. IronEngine occupies a distinct position in this landscape: it com- bines local-first deployment with heterogeneous model backends (Ollama [45], LM Studio [46]), broad tool category coverage spanning 24 categories beyond code editing, formal quality assurance through the Re- viewer role, and a unified orchestration layer that serves desktop UI, REST API, and Python client sur- faces through the same pipeline logic. 2.7 The OpenClaw Ecosystem: OpenClaw, NanoClaw, and IronClaw The OpenClaw project [17] and its derivative variants represent a rapidly evolving ecosystem for personal AI assistants. OpenClaw itself is positioned as an always- on personal AI assistant with a gateway-centric archi- tecture. Its design emphasizes multi-channel message routing (Telegram, WhatsApp, SMS, email), persis- tent skills, device node management, and a control plane that spans user-owned devices. The system ex- cels at maintaining continuous availability across mes- saging surfaces and treating the assistant as a long- running service rather than a session-based tool. NanoClaw [47] adapts the OpenClaw architecture for edge deployment on resource-constrained devices (Raspberry Pi, mobile SoCs). It achieves this through aggressive model quantization, a stripped-down skill set, and a lightweight gateway that proxies to a more capable upstream node when local inference is insuffi- cient. NanoClawâs contribution is primarily in deploy- ment flexibility: it demonstrates that the personal assistant paradigm can extend to IoT and embedded environments, albeit with reduced autonomy and tool coverage. IronClaw [48] specializes the OpenClaw frame- work for hardware-oriented AI agent scenarios, tar- geting embedded systems, robotics control, and indus- trial automation. It introduces sensor data ingestion pipelines, actuator command abstractions, and safety interlocks for physical-world interactions. IronClawâs primary contribution is bridging the gap between con- YouTube @NiusRobotLab5 IronEngine: Towards General AI Assistant versational AI agents and real-time hardware control loops. PicoClaw [49] pushes the OpenClaw paradigm to its extreme miniaturization: microcontroller tar- gets including Arduino, ESP32, and STM32. Pic- oClaw employs pre-compiled skill sets with no run- time model inference, instead relying on an upstream NanoClaw or OpenClaw instance for planning and decision-making. The microcontroller executes only deterministic skill procedures received from its up- stream node. PicoClaw represents an exploration of AI agent deployment at the absolute hardware minimum, where the âagentâ is reduced to a skill executor with no local intelligence. Its contribu- tion is primarily conceptualâdemonstrating how far the agent paradigm can be decomposed across a de- vice hierarchyâthough practical applications in sen- sor networks and simple actuator control are feasible. Together, the OpenClaw ecosystem spans a re- markable range from cloud-scale gateway (Open- Claw) through edge devices (NanoClaw) and indus- trial hardware (IronClaw) to bare-metal microcon- trollers (PicoClaw). While this breadth is impres- sive, certain limitations are shared across the ecosys- tem. No variant implements formal plan quality review (equivalent to IronEngineâs Reviewer role). Multi-model collaboration within a single task is not supportedâeach variant uses one model per request. Tool dispatch relies on keyword-based skill matching without alias normalization or automatic error cor- rection. Memory systems are flat (skill-level persis- tence) without hierarchical consolidation or contra- diction detection. IronEngine differs from the OpenClaw ecosystem in several fundamental ways. Orchestration depth. OpenClaw uses a message-routing gateway model where incoming messages are dispatched to skill handlers. IronEngine instead implements a structured three-phase pipeline with explicit planning, quality review, and execution phases, providing formal quality assurance through the Reviewer role that is absent in the OpenClaw architecture. Multi-model collaboration. The OpenClaw ecosystem typically uses a single model per request. IronEngine assigns up to four distinct models (Plan- ner, Reviewer, Executor, Tools) to different cognitive roles within a single task, with VRAM-aware lifecycle management that enables running models larger than available GPU memory through sequential loading. Tool system sophistication. IronEngineâs 24-category tool router with intelligent dispatch, 130+ alias normalization, automatic error correc- tion, and multi-layer fallback chains provides signif- icantly deeper tool integration than the skill-based dispatch in OpenClaw. The auto-correction mech- anism aloneâwhich detects and redirects mistyped tool types without user interventionâis a unique re- liability feature. Memory architecture. IronEngineâs hierarchi- cal memory with four entry types, dual merge strate- gies, user rating integration, and idle-time consolida- tion provides more structured state management than the flat skill memory in the OpenClaw ecosystem. Desktop workbench paradigm. While Open- Claw optimizes for headless multi-channel messaging, IronEngine provides a full desktop workbench with real-time orchestration visibility (thinking blocks, tool execution badges, quality scores), making the AIâs decision-making process observable and debuggable. Figure 1 summarizes the research and product tra- jectory most relevant to this paper, highlighting the progression from foundational techniques to system- level integration. 3 Design Goals IronEngine is designed around six goals that address the engineering gaps identified in the introduction. G1: Unified interaction surfaces. All user-facing entry pointsâdesktop UI (PySide6 [50]), REST/WebSocket API, and Python clientâshare the same orchestration logic. A task submitted through the UI follows identical planning, review, and execu- tion paths as one submitted through the API. G2: Role-based model collaboration. Rather than relying on a single model for all cognitive func- tions, IronEngine assigns distinct roles (Planner, Re- viewer, Executor, Tools model) to potentially dif- ferent models. This enables cost-effective allocation where large models handle complex planning while smaller models execute tool translations. G3: Local-first and hybrid deployment. The platform is designed to run entirely on consumer hard- ware through integration with Ollama [45] and LM Studio [46], while also supporting cloud API back- ends. This dual capability ensures that privacy- sensitive workloads can remain fully local. G4: Persistent and proactive behavior. Through hierarchical memory, learned skills, sched- uled tasks, and an idle-time Pulse system, IronEngine maintains continuity across sessions and can perform background consolidation without user prompting. G5: Protocol-level extensibility. MCP (Model Context Protocol) [19] compatibility enables the system to discover and integrate external tools at runtime, extending its capability surface without modifying core code. G6: Safety with controllability. Permis- YouTube @NiusRobotLab6 IronEngine: Towards General AI Assistant 2017 2020202220232023 2024 20252026 Transformer attention mechanism GPT-3 / RAG in-context & retrieval CoT / WebGPT reasoning & browsing ReAct / Reflexion action-reason loop Generative Agents CAMEL / MetaGPT GPT-4 / Toolformer MCP / AutoGen Cursor / Windsurf Claude Code / Copilot IronEngine local orchestration Figure 1: Simplified trajectory of AI agent research and product evolution relevant to IronEngine. Blue nodes indicate research milestones; orange nodes indicate product-oriented systems. sion management, execution sandboxing, intervention points, and role separation ensure that the assistant operates within user-defined boundaries. The sys- tem never executes shell commands directly and val- idates all tool invocations through a structured dis- patch layer. 4 Overall Architecture IronEngine is organized as a four-layer architecture consisting of interaction, orchestration, capability, and environment layers, as shown in Figure 2. The interaction layer provides three entry points: a PySide6 desktop workbench with model se- lection, execution monitoring, and theme customiza- tion; a FastAPI-based REST/WebSocket server for service integration; and a pure Python client for em- bedding and scripting. All three share the same pipeline instance. The orchestration layer implements the three- phase pipeline (Section 7) and manages the lifecycle of each request: context assembly, role-specific model loading, planning, quality review, tool execution, in- tervention handling, memory storage, and skill learn- ing. The capability layer consists of modular sub- systems: the provider registry (Ollama, LM Studio, OpenAI-compatible cloud APIs), the memory sys- tem (MemoMap with hierarchical consolidation), the skill repository (ChromaDB-backed vectorized stor- age), the tool router (24 categories with intelligent dis- patch), and the task scheduler (recurring daily/week- ly/monthly tasks). The environment layer connects the system to external resources: MCP-compatible tool servers, lo- cal file system and storage, web browsers (via CDP and Playwright), desktop applications (via UIA), net- work utilities, and hardware devices. A major benefit of this architecture is that all en- try points share the same orchestration logic while providers, tools, and storage remain modular. Adding a new model backend, tool category, or interaction surface requires changes only at the corresponding layer boundary, not across the entire system. 5 Implementation Evidence and Engi- neering Characteristics Several central capabilities of IronEngine can be grounded in observable project structure and docu- mentation. Table 1 maps major system claims to en- gineering artifacts in the codebase. The goal is not to disclose sensitive implementation details, but to demonstrate that the system description corresponds to real engineering artifacts rather than an abstract proposal. This evidence mapping suggests that IronEngine is distinguished not by a single component but by the way multiple components are integrated into one orchestration-centered runtime. 6 Module Decomposition The system comprises eight major modules that to- gether form a long-running, extensible platform rather than a single chat front-end. Desktop UI module. The PySide6-based inter- face functions as an operational console rather than a simple chat shell. Figure 3 shows the current in- terface. The left panel consolidates model selection (Planner, Reviewer, Tools, Vision), execution con- figuration, and permission settings. The right panel combines the conversation surface with runtime mon- itoring including thinking blocks (collapsible reason- ing traces), tool execution badges, quality scores, and intervention prompts. The UI supports 10 proce- durally generated sci-fi themes with glassmorphism effects and continuous background rendering across panels. API and client layer. The FastAPI server exposes REST endpoints for synchronous requests and WebSocket channels for streaming events. The Python client (IronEngineClient) provides callback- based integration, while IronEngineQtClient adds Qt signal forwarding for GUI embedding. Both client types support the full 17-callback interface includ- ing thinking, conclusion, tool execution, permission prompts, quality scores, model selection, and phase transition notifications. Multi-model collaboration module. The pipeline assigns distinct rolesâPlanner, Reviewer, Executor, and Tools modelâto potentially differ- YouTube @NiusRobotLab7 IronEngine: Towards General AI Assistant Desktop UI PySide6 REST / WebSocket API Service access Python Client Embedding and scripting Unified Orchestrator Plan / Review / Execute / Intervention Provider Layer Local + Cloud Models State and Memory History / Memo / Skill Task and Execution Scheduler / Tool Runtime MCP-Compatible Extensions Configuration and Storage JSON / File / Session External Systems Scripts / Devices / Robotics Figure 2: Overall architecture of IronEngine showing the four-layer design: interaction surfaces (top), unified orchestrator (middle), capability modules (lower-middle), and environment interfaces (bottom). Table 1: Mapping between major system claims and engineering evidence in the project Evidence locationCapabilityInterpretation main.pyMulti-entry runtime ui, api, cli modes under one engine docs/API.mdService interfacesREST, WebSocket, Python client surfaces docs/ARCHITECTURE.md Pipeline designPlan/Review/Execute, skills, memory, MCP pipeline.pyThree-phase orchestration Discussion, Switch, Execution; 17 callbacks tool_router.py24-category dispatch Routing, auto-correction, 130+ aliases memomap.pyHierarchical memory Session/pipeline/summary/refined entries skill_store.pySkill repositoryChromaDB, embedding search, learning mcp_client.pyMCP client bridgeServer connection, tool discovery, dispatch model_session.pyVRAM management Model loading/unloading, GPU monitoring main_window.pyDesktop workbench Model selectors, tool monitoring, themes ent model instances. Each role loads only its rele- vant SOUL (System Operating Under Limitations) sections, reducing input token consumption. The provider registry supports Ollama, LM Studio, and OpenAI-compatible cloud APIs through a unified in- terface. Memory and skills layer. Described in detail in Section 9. Task scheduler. The PlannedTaskStore man- ages recurring tasks (daily/weekly/monthly) with JSON-based persistence and thread-safe operations. The Pulse system provides idle-time background pro- cessing, triggering memory consolidation and task ex- ecution when the system detects 5 minutes of user inactivity. Local LLM integration layer. Described in detail in Section 10. MCP-compatible extension layer. Described in Section 11. Hardware-facing compatibility layer. The system can dispatch tool calls to external scripts, de- vice controllers, and robotic systems through its struc- tured execution interface, enabling integration with Arduino-based platforms and other hardware environ- ments. 7 Three-Phase Pipeline The core of IronEngineâs orchestration is a three- phase pipeline that separates planning quality from execution capability. This design is motivated by the observation that the cognitive demands of task de- composition (requiring broad world knowledge and reasoning) differ fundamentally from those of tool ex- ecution (requiring precise syntax and format compli- ance). Figure 4 illustrates the three phases. YouTube @NiusRobotLab8 IronEngine: Towards General AI Assistant Figure 3: IronEngine desktop UI. The left panel exposes model and execution configuration with Planner/Re- viewer/Tools model selectors. The right area supports conversation with inline thinking blocks, tool execution badges, and quality score indicators. 7.1 Phase 1: Discussion In the Discussion phase, the Planner model generates a task decomposition plan based on the user request, assembled context (conversation history, loaded mem- ories, relevant skills, tool manifest), and its SOUL be- havioral guidelines. The plan specifies what tools to invoke and in what order, but no tools are actually executed during this phase. The Reviewer model then evaluates the planâs quality, checking for hallucination (plans that claim results without tool calls), memory recycling (reusing stale memorized data instead of fetching fresh infor- mation), completeness, and feasibility. The Reviewer assigns a quality score and provides structured feed- back. If the score falls below a configurable threshold, the plan is returned to the Planner for revision with the Reviewerâs feedback appended. This Discussion loop iterates for up to max_rounds (typically 3â5) or until the quality threshold is met. Four anti-hallucination mechanisms operate during this phase: 1. Memory duplication detection: Extracts information-bearing tokens from loaded memory, checks whether the model cites them without any tool call (threshold: 40% token overlap AND âĽ3 hits). Numerical values (prices, versions) receive special treatment: âĽ2 shared non-trivial numbers trigger a warning. 2. Forbidden phrase rejection: Six banned phrases (âI cannot browse,â âunable to access,â âas an AI,â etc.) are pattern-matched and auto- rejected with a score of 0.00. 3. Scoreâtext contradiction detection: If the Re- viewer usesâĽ2 rejection phrases (âdoes not meet,â âinsufficient,â âlacksâ) but assigns a score âĽ0.60, the score is clamped to 0.40. This prevents small models from verbally rejecting a plan while numer- ically approving it. 4. Memory contradiction detection: Compares numerical values in tool execution results with values in loaded memory. When discrepancies are found, stale memory entries are automatically flagged and a warning is injected before the Re- viewer evaluates. 7.2 Phase 2: Model Switch Once a satisfactory plan is approved, the system tran- sitions from discussion to execution. This involves un- loading the Planner and Reviewer models from GPU VRAM and loading the Executor model. The VRAM management system monitors GPU memory through provider-specific APIs and ensures safe model transi- tions. The model switch follows a four-step process: (1) finalize the approved plan text; (2) unload Planner and Reviewer from GPU VRAM via provider-specific APIs; (3) select and load the Executor model (user- configured or auto-selected from 3â14B tool-capable YouTube @NiusRobotLab9 IronEngine: Towards General AI Assistant Phase 1 Receive request via UI / API / Python client Assemble context: history, memory, skills, task state, tool manifest Planner generates plan with tool requirements (text only, no execution) Reviewer evaluates plan quality and provides score + feedback QualityâĽthreshold? Phase 2 Unload Planner/Reviewer VRAMâLoad Executor model Phase 3 Executor reads plan + user request, emits tool call markers Tool Router dispatches: file_ops / web_search / browser / GUI / network / ... FINAL_ANSWER or max steps? Return conclusion, update memory, evaluate skill learning yes no: iterate yes no: next step Figure 4: IronEngine three-phase pipeline. Phase 1 (Discussion): Planner and Reviewer collaborate on plan quality without tool execution. Phase 2 (Model Switch): VRAM-aware transition from discussion models to execution model. Phase 3 (Execution): Executor runs tools iteratively until task completion. models); (4) prepare the execution context including the plan, user request, and relevant skill procedures. Generative task detection. The system uses regex-based detection to identify creative/generative requests (writing stories, code, poems, tables). A sep- arate detector checks whether the plan contains tool indicators (file save, run, debug, web search, applica- tion control). If the task is purely generative AND the plan has no tool indicators, the system allows direct output without tool execution. Hybrid tasks (write code + save/debug) still enforce tool execution. Simple-plan optimization. If the approved plan contains four or fewer tool calls, or if the task is purely generative, the Planner model is reused as the Executor, skipping the model switch overhead (ap- proximately 27â90 seconds depending on model sizes). This optimization reduces latency for straightforward tasks while preserving the full pipeline for complex ones. 7.3 Phase 3: Execution The Executor model receives the approved plan and original user request, then iteratively generates tool call markers in a structured format: [TOOL_CALL: instruction | type: cli/file_ops/...| context: ...]. Each marker specifies an in- struction (what to do), tool type (which handler), and optional context. The Tool Router (Section 8) dispatches these calls and returns timestamped re- sults, which are fed back to the Executor for the next step. Skill integration. Before the first execution step, the system searches the skill repository using the user message and plan summary as queries. Match- ing skills have their procedures expanded (with nested skill references recursively resolved up to 3 levels deep) and provided to the Executor as contextual guid- ance. The Executor can also invoke skills explicitly via [SKILL: name | param: value] markers. The Executor operates for up to 10 steps. It termi- nates by emitting a FINAL_ANSWER marker, which sig- nals the conclusion to be presented to the user. If the Executor emits both tool calls and a FINAL_ANSWER in the same step, tools are executed first so the con- clusion can incorporate actual results. A premature FINAL_ANSWER guard detects when the Executor at- tempts to conclude at step 1 without any tool calls (for non-generative tasks) and injects a correction prompt for retry. Conclusion source logic. The final conclusion presented to the user is selected through a priority chain: (1) Plannerâs FINAL_ANSWER text if it contains substantive content (not planning-like language such as âTo provide. . . â or âStep 1:â); (2) Reviewerâs out- put with meta-review commentary stripped; (3) the last Executor stepâs output. This logic handles edge cases where models place answers in thinking tags or YouTube @NiusRobotLab10 IronEngine: Towards General AI Assistant where the Reviewer self-executes. After execution completes, the system stores the interaction in memory (with user rating if provided), evaluates whether the experience constitutes a learn- able skill (based on ratingâĽ7 and cosine distance>0.5 from nearest existing skill), and updates task state if applicable. 8 Tool System Architecture The tool system is a central differentiator of Iro- nEngine, providing 24 distinct tool categories within a single unified routing framework. Unlike systems that rely on function-calling APIs or plugin architectures, IronEngineâs tool router performs intelligent dispatch with alias normalization, automatic error correction, and multi-layer fallback chains. 8.1 Tool Categories Table 2 lists the 24 tool categories supported by Iro- nEngine, organized by functional domain. 8.2 Intelligent Routing The tool routing system implements several mecha- nisms to improve reliability: Alias normalization. Over 130 aliases are mapped to canonical tool types. For example, âshell,â âterminal,â âcmd,â and âpowershellâ all normalize to cli; âdownload,â âfetch,â and âscrapeâ normalize to web_read. This reduces the burden on the Planner to use exact tool type names. Bidirectional auto-correction. When a model specifies an incorrect tool type, the router detects the mismatch and redirects. For example, a cli call containing file path patterns (copy, move, delete operations) is automatically redirected to file_ops, with CLI-specific flags (e.g., /b, -l) stripped. Con- versely, web URLs in a file_ops call are redirected to web_read or browser. Multi-layer fallback chains. Each tool type defines fallback strategies. Web search, for instance, follows a four-strategy chain: (1) CDP-based Google search via persistent Chrome instance, (2) Duck- DuckGo HTTP POST, (3) Bing HTTP GET, (4) vis- ible browser Google+Bing. If any strategy succeeds, subsequent strategies are skipped. Figure 5 illustrates the tool dispatch flow from model output to execution. 8.3 Web Search Architecture Web search is the most complex tool category, requir- ing multiple strategies to handle search engine rate limiting, captcha challenges, and JavaScript-rendered content. The primary strategy uses a persistent Chrome instance with CDP (Chrome DevTools Pro- tocol) on port 19222, navigating Google Search with human-like random delays (3â8 seconds between ac- tions). Results are parsed directly from the DOM without screenshots, and Google redirect URLs are automatically decoded. For result enrichment, the system auto-fetches up to 10 top URLs with safety filtering (phishing block- list with 10-point heuristic scoring, e-commerce URL detection, junk URL filtering). When HTTP fetch- ing fails for JavaScript-heavy or bot-blocking sites, a CDP fallback opens the URL in a new browser tab, reads the rendered DOM, and closes the tab. Anti-detection measures include patchright [42] (an anti-bot Playwright fork), EasyList-based ad blocking (90K rules with search engine domain whitelisting), and Cloudflare Turnstile captcha auto- solving through CDP mouse event simulation with randomized offsets. Figure 6 illustrates the four-strategy web search fallback chain. Strategy 1: CDP Google (persistent Chrome, port 19222) Strategy 2: DDG HTTP POST (no JavaScript needed) Strategy 3: Bing HTTP GET (with browser-like headers) Strategy 4: Visible Browser (Google + Bing with captcha) fail fail fail Figure 6: Web search four-strategy fallback chain. Each strategy is attempted in order; the first success terminates the chain. 8.4 Web Content Extraction When fetching web page content, the system follows a multi-stage approach: (1) HTTP GET with browser- like headers; (2) if text extraction yields fewer than 200 characters, an OCR-based vision fallback seg- ments the page into screenshots and analyzes each with a vision model; (3) if both fail, a CDP browser fallback opens the URL in a new tab, waits for render- YouTube @NiusRobotLab11 IronEngine: Towards General AI Assistant Table 2: IronEngine tool categories organized by functional domain DomainTool typesDescription File systemfile_ops, file_write, archive, binary_read List, copy, move, rename, delete files; create/overwrite files; compress/extract archives; read binary file metadata Webweb_search, web_read, browser Multi-engine search with captcha handling; HTTP content extraction with OCR fallback; full browser automation via CDP Communication wechatAutomated messaging, file transfer, sticker sending, and message reading for WeChat Desktop GUIgui_auto, app_control, auto_input Mouse/keyboard automation; window management and UIA element interaction; automated form input Mediaimage_gen, image_read, speech_tts, speech_stt, video_analyze, audio_analyze Image generation and vision analysis; text-to-speech and speech-to-text; video frame analysis with audio transcription Systemcli, classify, networkSandboxed command execution; text classification; WiFi, FTP, ping, DNS, port scanning Model output withtool call markersExtract tool calls(regex parser)Normalize type(130+ aliases) Type correct? Auto-correct type+ strip invalid flags Dispatch tohandler Success? Try fallbackstrategy Return resultto Executor yes no yes no Figure 5: Tool dispatch flow in IronEngine. Model output is parsed, types are normalized through 130+ aliases, auto-corrected if mismatched, and dispatched with multi-layer fallback chains. ing, reads the DOM, and closes the tab. E-commerce URLs are automatically redirected to the browser handler before HTTP fetch, as these sites typically require JavaScript rendering. Each successful fetch includes a freshness header with the retrieval times- tamp. 8.5 Multimedia Analysis The tool system supports video and audio analysis through dedicated composite tools. Video analysis extracts frames at 1 frame per 10 seconds (up to 30 extracted, 8 evenly-spaced frames sent to the vision model), filters blank frames (<5KB), auto-detects au- dio tracks for transcription via OpenAI Whisper, and provides both visual and auditory analysis. Audio analysis handles both audio files and video files (ex- tracting the audio track first), using a singleton Whis- per model loader for efficient repeated use. 8.6 GUI Automation IronEngine provides comprehensive desktop GUI au- tomation through three tool categories. Window management supports launching, closing, and fo- cusing applications with a built-in application name mapping and registry-based discovery. Mouse and keyboard automation uses a dual-strategy approach: pyautogui as the primary method (proper scan codes via MapVirtualKeyW), with ctypes SendInput as fall- back. Text input uses clipboard paste (pyperclip + Ctrl+V) for reliability. UIA interaction provides el- ement discovery, listing, and interaction through Win- dows UI Automation, supplemented by screenshot- based visual analysis when UIA exposure is limited. 8.7 Execution Safety All tool execution follows strict safety principles. The CommandExecutor never uses shell=True for sub- process calls. Template placeholders in commands are detected and rejected before execution. URL safety checks combine a phishing blocklist with 10- point heuristic scoring (IP-in-URL, suspicious TLD, brand impersonation, homoglyph detection, danger- ous protocol detection). File operations validate paths and never execute arbitrary code. The permis- sion manager provides three levelsâauto, ask, denyâ configurable per tool category. 9 Memory and Skill System IronEngineâs memory system treats persistent state as a managed resource with lifecycle policies, in con- trast to systems that simply log conversation tran- scripts. The system comprises two interconnected subsystems: hierarchical memory (MemoMap) and a vectorized skill repository (SkillStore). 9.1 Hierarchical Memory Architecture The MemoMap system organizes memories into four entry types with distinct lifespans and consolidation strategies: 1. Session entries capture individual conversation turns with user ratings, tags, and reflection text. These are the raw material from which higher-level memories are derived. 2. Pipeline entries record complete pipeline exe- cutions including plans, tool calls, outcomes, and quality scores. YouTube @NiusRobotLab12 IronEngine: Towards General AI Assistant 3. Daily summaries consolidate a dayâs sessions into thematic summaries through model-based summarization (Merge B). 4. Refined entries represent long-term consolidated knowledge that has been validated across multiple interactions. Two merge strategies manage memory consolida- tion. Merge A (fast deduplication) triggers auto- matically when the session count exceeds a threshold (default 20), removing near-duplicate entries based on content similarity. Merge B (model-based con- solidation) runs during idle time through the Pulse system, using a dedicated summarization model su- pervised by the Reviewer to produce coherent daily summaries from raw session data. Figure 7 illustrates the memory hierarchy and life- cycle. Memory retrieval for new requests uses a relevance-based strategy: loading 2 positively-rated sessions and 1 negatively-rated session (to learn from mistakes), combined with an anti-duplication warning that prevents models from recycling memorized data without fresh tool verification. User ratings (1â10 scale, mapped to 1â5 internally) influence future retrieval priority and feed into the reflection update mechanism. 9.2 Vectorized Skill Repository The SkillStore manages reusable procedural knowl- edge through ChromaDB [31] as its sole persistent backend. Each skill is a structured record contain- ing a name, category, tags, step-by-step procedure, parameter definitions, and success/failure counters. Skill representation. Skills are embedded using the nomic-embed-text model (768-dimensional vec- tors) via Ollamaâs embedding API. A deterministic hash-based fallback is available when Ollama is un- available. The HNSW index with cosine similarity enables fast nearest-neighbor search across the skill corpus. Innate vs. learned skills. The system ships with 26 innate skills covering common scenarios: WeChat messaging (5), web operations (3), media handling (4), file management (4), application control (3), network operations (3), and shell commands (2). Each innate skill maps to one concrete scenario with hyphenated action-phrase tags for search matching. Skill composition. Skills can reference other skills through inline markers (e.g., a âsend WeChat textâ skill references âopen WeChatâ and âselect con- tactâ skills). A recursive expansion mechanism re- solves these references up to 3 levels deep when pro- viding skill context to the Executor. Skill learning. When a pipeline execution re- ceives a user rating of 7 or above and the task is suf- ficiently novel (cosine distance> 0.5 from the nearest existing skill), the system automatically extracts the executed tool call sequence into a new learned skill. Conversely, ratings of 3 or below trigger a correction request, initiating a new pipeline session to refine the skill procedure. English normalization. All internal processing, including skill tags and procedures, is maintained in English regardless of the userâs input language. A CJK detection and translation mechanism converts Chinese queries to English for consistent skill match- ing. 10 Adaptive Model Management Running multiple model roles on consumer hardware with limited GPU memory requires careful resource management. IronEngine implements an adaptive model management system that optimizes token bud- get, prompt complexity, and model selection based on available hardware resources. 10.1 Model Catalog The system maintains a catalog of 92 model pro- files, each containing the modelâs parameter count, architecture family, known capabilities (completion, tools, vision, thinking, embedding), and estimated VRAM requirements at various quantization levels. This catalog enables automated model selection and resource planning without requiring users to under- stand model-specific technical details. 10.2 VRAM-Aware Context Budgeting Context length directly impacts GPU memory con- sumption through KV-cache allocation. IronEngine computes an effective context length for each model invocation based on three constraints: ctx eff = min (ctx native , ctx mem , ctx user ) (1) where ctx native is the modelâs native context win- dow, ctx user is any user-configured maximum, and ctx mem is computed from available VRAM: ctx mem = (VRAM free Ă 0.85)â overhead C kv (2) HereC kv is the KV-cache cost per 1K tokens (which varies by model parameter count: 0.08 MB/1K for â¤3B models to 1.2 MB/1K for>30B models) and the 0.85 factor provides a safety margin against VRAM fragmentation. RAM spill is allowed but YouTube @NiusRobotLab13 IronEngine: Towards General AI Assistant Session entries (per-turn, rated) Pipeline entries (plan + execution) Merge A fast deduplication Merge B model summarization Daily summaries (thematic) Refined entries (long-term) Context retrieval (2 good + 1 bad) threshold: 20 idle-time Pulse Figure 7: Memory hierarchy and lifecycle in IronEngine. Session and pipeline entries are consolidated through two merge strategies into daily summaries and refined long-term knowledge. Context retrieval selects the most relevant entries (2 positive + 1 negative examples) for each new request. capped at 2Ă VRAM to prevent excessive slowdown from memory-mapped access. 10.3 Tiered Prompt System Different model sizes have different capacities for pro- cessing complex instructions. IronEngine implements a three-tier prompt system based on model parameter count: Table 3: Tiered prompt system based on model size TierTool docsSOULStrategy Small (â¤10B) âź733 tok âź44 tok Identity only; minimal tool descriptions Medium (10â25B) âź1964 tok âź623 tok Core SOUL sections; standard tool docs Large (>25B) âź2236 tok âź1309 tok Full SOUL with all behavioral sections; comprehensive tool docs The SOUL (System Operating Under Limita- tions) document defines each roleâs behavioral guide- lines. Rather than sending the full SOUL to ev- ery model, the SoulManager extracts role-specific sec- tions: Planner receives Identity, Core Principles, Au- tonomy, Communication Style, Boundaries, and Plan- ner Behavior; Reviewer receives Identity, Core Prin- ciples, Communication Style, Boundaries, and Re- viewer Behavior; Executor receives only Identity and Executor Behavior. This role-specific loading saves 450â1300 tokens per message compared to sending the full SOUL. 10.4 Thinking Depth Control For models that support explicit reasoning traces (via <think> tags), IronEngine implements adaptive thinking depth control. A task complexity classifier evaluates each request and determines whether ex- tended reasoning is beneficial: ⢠Simple tasks (file listing, direct answers): think- ing disabled (think=False), reducing latency by eliminating reasoning token generation. ⢠Complex tasks (multi-step planning, analy- sis): thinking enabled (think=True), allowing the model to reason through the problem before re- sponding. ⢠Uncertain tasks: thinking left to model default (think=None). 10.5 Dynamic Capability Detection The system dynamically detects each modelâs capabil- ities through the Ollama /api/show endpoint, which returns a capabilities array (completion, tools, vision, thinking, embedding). This enables automatic rout- ing decisions: models with tool-calling capability can skip the auxiliary translation model; models with vi- sion capability serve as their own image analysis back- end. Hardcoded capability tables serve as fallbacks for models whose APIs do not report capabilities. YouTube @NiusRobotLab14 IronEngine: Towards General AI Assistant 11 MCP Compatibility and Open Ecosystem Strategy MCP (Model Context Protocol) [19] is emerging as an open interface for connecting models to external tools and resources. IronEngine implements MCP client support for tool discovery, server connection man- agement, name qualification, and merged dispatch between built-in capabilities and externally provided tools. This creates a layered extensibility strategy. The first layer consists of deeply integrated local capabil- ities (24 tool categories) optimized for low-latency, high-control operations. The second layer opens the system to external ecosystems through MCP- compatible integration, enabling discovery and use of tools provided by third-party MCP servers at runtime. The MCP client manager handles server lifecycle (connection, health monitoring, reconnection), tool schema discovery, input validation, and result for- matting. Externally discovered tools are merged into the same dispatch pipeline as built-in tools, with name qualification to prevent conflicts (e.g., mcp_server_name/tool_name). This approach allows IronEngine to preserve its native strengths in desktop control, local model work- flow, and hardware integration while benefiting from the broader MCP tool ecosystem. As MCP adoption grows, IronEngine can extend its capabilities without requiring internal code changes for each new tool in- tegration. 12 Experimental Evaluation To validate the practical effectiveness of IronEngineâs architecture, we conduct experiments measuring task completion accuracy, execution time, tool routing re- liability, and multi-model collaboration efficiency. All experiments use local models on consumer hardware. 12.1 Experimental Setup Hardware. All experiments are conducted on a sin- gle workstation equipped with an NVIDIA RTX 3090 (24 GB VRAM), 32 GB system RAM, running Win- dows 10 Professional. Software. Models are served through Ollama [45] and LM Studio [46]. The pipeline configuration uses: ⢠Planner: qwen3.5:27b (27B parameters, served via Ollama) ⢠Reviewer: gpt-oss:20b (20B parameters, served via LM Studio) ⢠Tools model: phi4-mini:3.8b (3.8B parameters, served via Ollama) This heterogeneous configuration demonstrates the systemâs ability to assign different model sizes to different roles based on their computational require- ments. 12.2 File Operation Benchmark We design a four-task benchmark that tests the sys- temâs ability to handle file operations with challeng- ing path formats (spaces, quotes, special characters). Each task is submitted as a natural language request through the Python client API. The results (Table 4) show 100% task comple- tion accuracy across all four tasks. The mean exe- cution time of 385 seconds per task includes Plan- ner reasoning (âź45s), Reviewer evaluation (âź35s), model switching (âź27s), Executor reasoning (âź30s), and tool execution (âź2s), with the remainder con- sumed by context assembly and communication over- head. The relatively high per-task time is attributable to the use of local models with limited computational resources; cloud-hosted models would significantly re- duce inference latency. 12.3 Pipeline Phase Time Distribution Figure 8 shows the distribution of time across pipeline phases for the four benchmark tasks. The figure reveals that model inference dominates execution time (70â80%), while actual tool execution is negligible (<1%). This confirms that IronEngineâs performance is primarily bound by local model infer- ence speed rather than tool dispatch or system over- head. The constant model switch time ofâź27 seconds per task suggests potential for optimization through the simple-plan reuse mechanism (Section 7). 12.4 Tool Routing Accuracy We analyze the tool routing systemâs ability to cor- rectly dispatch tool calls across the benchmark tasks and additional stress tests. Table 5: Tool routing auto-correction statistics Correction typeCountSuccessNotes cli â file_ops12100%Path pattern detected browse â browser 3100%Alias normalized web_read â browser 2100%JS-heavy site detected Alias normalization 47100%130+ aliases No correction needed 89100%Direct dispatch The tool routing system achieves 100% accuracy across all tested scenarios, with auto-correction han- dling the most common model error (specifying cli YouTube @NiusRobotLab15 IronEngine: Towards General AI Assistant Table 4: File operation benchmark results. All tasks achieve 100% correctness (4/4 PASS). #Task descriptionTime (s)RoundsResult Key observations 1List files in a directory with spaces and quotes in path 3792PASSPath with special characters correctly handled; file_ops auto-selected 2Move a file from one directory to another (cross-drive) 3112PASSTwo-path parsing with âtoâ separator; cross-drive move succeeded 3a Create a new text file with specific content4212PASSfile_write tool correctly dispatched; content verified 3b Delete a specific file by path4302PASSfile_ops delete operation; existence verified pre/post deletion Total154184/4Mean: 385s per task; 2 rounds per task average List FilesMove FileCreate FileDelete File 0 200 400 52 39 64 70 95 78 110 120 27 27 27 27 85 72 90 88 120 95 130 125 Task Time (seconds) Planner reasoningReviewer evaluationModel switchExecutor + tools Communication overhead Figure 8: Distribution of execution time across pipeline phases for each benchmark task. Model inference (Planner + Reviewer + Executor) dominates total time, while actual tool execution completes in under 2 seconds. The model switch phase is constant at âź27 seconds. instead of file_ops for file operations). No false- positive corrections were observed (e.g., web_search was never triggered for local-only tasks). 12.5 Multi-Model Collaboration Analysis The three-phase pipelineâs effectiveness depends on productive collaboration between the Planner and Re- viewer. We analyze the quality score distribution and iteration patterns: ⢠Round 1 pass rate: 65% of plans are approved in the first round with quality scores ⼠0.85. ⢠Round 2 pass rate: 30% of initially rejected plans pass after Reviewer feedback incorporation. ⢠Round 3+ rate: Only 5% of tasks require more than 2 discussion rounds. ⢠Quality score range: Approved plans typically score 0.85â0.92; rejected plans score 0.10â0.40. The Reviewerâs anti-hallucination detection is particularly effective: plans that cite data without tool calls are rejected with scores of 0.10 (fabricated), and plans that recycle memorized prices or specifica- tions receive 0.20 (training data contamination). 12.6 VRAM and Resource Usage A key characteristic of the three-phase pipeline is that models do not simultaneously reside in GPU memory. Table 6 shows VRAM usage across pipeline phases. Table 6: VRAM usage by pipeline phase PhasePeak VRAM Notes Discussion (Planner) âź17.5 GB qwen3.5:27b Q4 quantized Discussion (Reviewer) âź13.0 GB gpt-oss:20b Q4 quantized Model switch âź2 GBPost-unload residual Execution (Executor) âź17.5 GB Reuses Planner or dedicated model Tool translation âź2.5 GBphi4-mini:3.8b On the RTX 3090 (24 GB VRAM), qwen3.5:27b (âź17.5 GB Q4_K_M) can coexist with phi4- mini:3.8b (âź2.5 GB), but cannot be loaded si- multaneously with gpt-oss:20b. The Discussion phase therefore involves implicit weight swapping between Planner and Reviewer turns. The VRAM-aware con- text budget mechanism ensures KV-cache allocation never exceeds 85% of available VRAM. YouTube @NiusRobotLab16 IronEngine: Towards General AI Assistant 12.7 Search Deduplication and Caching The pipeline includes a search cache mechanism (_WebSearchCache) that deduplicates similar queries across rounds (70% word overlap threshold) and en- forces a 10-search hard limit per pipeline execu- tion. In a pipeline integration test (17.3 minutes, 10 GUI browser searches), 14 deduplication hits were recorded, all searches completed successfully with 0 errors. The cache significantly reduces redundant net- work requests caused by the Reviewer requesting sup- plementary searches. 12.8 Error Patterns and Recovery Despite 100% completion in benchmarks, broader us- age reveals several systematic error patterns and their recovery mechanisms: Tool type misspecification. Local models (â¤14B) systematically prefer cli over file_ops for file operations and browse/web_read over browser for browser operations. The three-layer correction mechanism (alias normalization, context-aware auto- correction, fallback chains) intercepted and corrected all such errors in experiments, demonstrating that in- telligent routing is a reliability necessity when using capability-limited local models. Planner hallucination and refusal. Approxi- mately 15% of first-round Planner outputs triggered anti-hallucination detection (generating answers with- out tool execution). All were corrected in the second round through correction prompts. Memory contamination. When loaded his- torical memory contains stale information (outdated prices, changed file paths), the memory contradic- tion detector compares numerical values in tool results against loaded memory, auto-flags discrepancies, and injects warnings before Reviewer evaluation. Web search degradation. The four-strategy fallback chain achieves âź98% combined success rate. CDP Google search has âź85% first-attempt suc- cess (Cloudflare Turnstile occasionally blocks); DDG HTTP POST handles most fallback cases. The re- maining âź2% failures are due to network issues or simultaneous rate limiting across all engines. 12.9 Comparison with Representative Sys- tems Table 7 provides a detailed comparison of IronEngine with representative AI assistant systems across 12 ca- pability dimensions. The comparison uses qualitative ratings based on publicly documented capabilities and our direct evaluation where possible. The comparison reveals several key differentiators for IronEngine: Broadest tool coverage. With 24 tool cat- egories spanning file system, web, communication, GUI, media, and network domains, IronEngine pro- vides the broadest tool coverage among all compared systems. Code-centric assistants (Cursor) cover only programming tasks; conversation products (Chat- GPT) focus on web and code; the OpenClaw ecosys- tem offers moderate tool coverage through skills but lacks the intelligent routing layer with alias normal- ization and auto-correction. Unique multi-role quality assurance. Iro- nEngine is the only system in the comparison that implements a formal quality review phase within its pipeline. The PlannerâReviewer discussion loop with anti-hallucination detection, scoreâtext contradiction checking, and memory recycling guards provides a level of output quality assurance that is absent from both the OpenClaw ecosystem (which uses direct skill dispatch) and cloud products (which rely entirely on single-model capability). Local-first with full capability. While Open- Claw, NanoClaw, and Open Interpreter also support local models, IronEngine uniquely combines local de- ployment with multi-role orchestration, persistent hi- erarchical memory, vectorized skill learning, VRAM- aware model lifecycle management, and 24-category tool routingâcapabilities that no other local-first sys- tem provides together. Skill learning with quality filtering. Iro- nEngineâs ability to automatically extract reusable skills from successful task executions, with novelty- based deduplication (cosine distance threshold), user- rating-driven quality filtering (only learning from highly-rated interactions), and correction mechanisms (re-learning from failures), is more sophisticated than OpenClawâs static skill definitions or the absence of skill learning in other compared systems. Orchestration observability. The desktop workbench provides real-time visibility into the AIâs decision-making process through thinking blocks, tool execution badges, quality score indicators, and phase transition notifications. This observability is a unique advantage over both headless systems (OpenClaw, NanoClaw) and cloud products where the internal rea- soning process is opaque to users. Complementary positioning vs. OpenClaw ecosystem. While OpenClaw excels at multi-channel messaging and always-on availability, NanoClaw at edge deployment, and IronClaw at hardware inte- gration, IronEngine occupies a distinct niche as an orchestration-deep desktop workbench with the most sophisticated planning pipeline, tool routing, and memory management among local-first AI assistant platforms. The systems are complementary rather than directly competitive: OpenClaw optimizes for YouTube @NiusRobotLab17 IronEngine: Towards General AI Assistant Table 7: Detailed capability comparison with representative AI assistant systems. Ratings: S=Strong, M=Medium, W=Weak, â=Not applicable. IronEngineChatGPTClaudeOpenClawNanoClawIronClawCursorAutoGenOpen Interp. Local models SWWSSMMMS Multi-role pipeline SWMWWWMSW Tool categories S (24) MMMWMMMM Memory system SMWMWWWWW Skill learning SWWMWWWWW Task scheduling SWWMWMâMW MCP compat. SWSMWWMMW GUI automation SWWWWMâWM Web browsing SSMMWWWMM VRAM mgmt SâWMWâWM PrivacySWMSSSMMS Open sourceâWWSSSWSS Multi-channel MMWSMWWMW Hardware facing MWWMMSâW Table 8: Cross-model tool awareness test results. All models achieve perfect tool-type identification with IronEngineâs tiered prompt system. ModelParams Score Time (s) cogito:8b8B10010.5 cogito:14b14B10013.5 lfm2:24b24B10033.7 qwen3.5:27b27B10050.2 breadth of messaging channels; IronEngine optimizes for depth of task orchestration. 12.10 Cross-Model Tool Awareness A key hypothesis of IronEngineâs tiered prompt sys- tem is that even small models can achieve reliable tool dispatch when provided with appropriately structured tool documentation. To test this, we evaluate four models spanning 8B to 27B parameters on a WeChat tool-type identification task, where the model must correctly classify the tool category from a natural lan- guage instruction. Table 8 shows that all four models achieve 100% accuracy on tool-type identification. Inference time scales approximately linearly with model size (from 10.5 s for 8B to 50.2 s for 27B). The key finding is that even the smallest 8B model achieves perfect tool dis- patch when IronEngineâs tiered prompt system pro- vides appropriately scoped tool documentationâthe small model receives a condensed 733-token tool man- ifest rather than the full 2,236-token version used for large models. This validates the design decision to tier prompt content by model size rather than using one-size-fits-all prompts. 12.11 Full Pipeline Integration Tests To evaluate the complete three-phase pipeline under realistic conditions, we conduct eight integration tests across two model configurations and four task scenar- ios, measuring both the PlannerâReviewer discussion quality and the end-to-end task completion. Figure 9 visualizes the quality score progression, highlighting the Reviewerâs corrective effect. Several findings emerge from the integration tests (Table 9). First, the Reviewerâs corrective feedback is most impactful for smaller Planners: the 14B cog- ito modelâs quality scores improve from 0.10â0.20 to 0.80â0.85 after a single review round, demon- strating that the Reviewer effectively compensates for the smaller Plannerâs initial planning weaknesses. Second, larger Planners (27B) frequently pass qual- ity thresholds on the first round, reducing total ex- ecution time by eliminating the second discussion round. Third, the single failure (travel planning) is attributable to the test environment lacking net- work access rather than a pipeline deficiencyâthe Reviewer correctly identified the plan as insufficient (score 0.40) when web search results were unavailable. Fourth, generative tasks (story creation) consistently pass on the first round with high scores, validating Iro- nEngineâs generative task detection mechanism that bypasses tool-execution requirements for purely cre- ative tasks. YouTube @NiusRobotLab18 IronEngine: Towards General AI Assistant Table 9: Full pipeline integration test results across model configurations and scenarios. Quality scores show Round 1 (initial) â Round 2 (after Reviewer feedback) progression. Model ConfigScenarioQuality ScoreTime (s)Result Observations cogito:14b + cogito:8b Shell command execution 0.20 â 0.85139.6PASSReviewer feedback improved plan specificity cogito:14b + cogito:8b PDF processing0.15 â 0.80152.2PASSTwo rounds needed; tool selection corrected cogito:14b + cogito:8b WeChat messaging0.10 â 0.8581.8PASSSkill-augmented execution; fastest completion cogito:14b + cogito:8b Story creation0.85 (R1)321.4PASSGenerative task; passed on first round qwen3.5:27b + cogito:8b MCU comparison0.75 (R1)172.0PASSWeb search required; larger Planner beneficial qwen3.5:27b + cogito:8b Travel planning0.20 â 0.40309.8FAILNo network search available in test env qwen3.5:27b + cogito:8b Shell command execution 0.80 (R1)145.3PASSLarger Planner passed on first round qwen3.5:27b + cogito:8b PDF processing0.75 (R1)168.7PASSLarger Planner reduced rounds needed Shell-14b PDF-14b WeChat-14b Story-14b MCU-27b Travel-27b Shell-27b PDF-27b 0 0.2 0.4 0.6 0.8 1 0.20 0.15 0.10 0.85 0.75 0.20 0.80 0.75 0.85 0.80 0.850.85 0.75 0.40 0.80 0.75 Test Scenario Quality Score Round 1 (initial)Round 2 (after review) Figure 9: PlannerâReviewer quality score progression. Red bars show initial Round 1 scores; green bars show final scores after Reviewer feedback. The Reviewerâs structured feedback (ISSUES + SUGGESTIONS) en- ables the 14B Planner to improve plans from 0.10â 0.20 to 0.80â0.85, while the larger 27B Planner often achieves acceptable quality on the first round. 12.12 Tool Model Reliability The tool translation model converts natural language instructions into structured JSON commands. We evaluate three candidate models to assess the trade-off between model size, translation accuracy, and execu- tion success. Table 10 reveals a nuanced relationship between model size and tool execution reliability. phi4-mini (3.8B) achieves the best overall performance: 98.2% translation success and 70.6% execution success, offer- ing the optimal balance between resource efficiency and reliability. functiongemma (270M) is too small for reliable tool translation, with only 54% of outputs producing valid JSON. Surprisingly, ministral-3 (14B) Table 10: Tool model reliability comparison. Transla- tion success = valid JSON output; Execution success = correct tool result. ModelParams Translate Execute phi4-mini3.8B98.2%70.6% (109/111) (77/109) functiongemma 270M54.0%25.9% (27/50)(7/27) ministral-314B100%20.0% (40/40)(8/40) achieves perfect translation (100%) but the lowest execution rate (20%)âthe model generates syntac- tically correct but semantically incorrect commands (e.g., correct JSON structure but wrong parameter values or missing required fields). This finding under- scores that tool model evaluation must consider both syntactic validity and semantic correctness, and that larger models do not necessarily produce better tool commands. 12.13 Multi-Scenario Diagnostic Tests To evaluate IronEngineâs breadth across diverse task types, we conduct diagnostic tests spanning six sce- narios that exercise different subsystems (tool routing, skill learning, web search, multimedia, and generative capabilities). The diagnostic results (Table 11) demonstrate sev- eral aspects of IronEngineâs architecture. First, the system handles diverse task typesâfrom low-level shell commands (139.6 s) to complex multi-step PDF processing (152.2 s, 7 tool calls) to creative writing (321.4 s)âthrough the same pipeline without task- specific configuration. Second, skill learning is au- tomatically triggered for successfully completed tasks rated⼠7: four of five passing scenarios produced new learned skills, which would accelerate similar future tasks through the skill-augmented Executor prompt. YouTube @NiusRobotLab19 IronEngine: Towards General AI Assistant Table 11: Multi-scenario diagnostic test results. Five of six scenarios pass (83.3%). The travel planning failure is due to the test environment lacking network access. Skill learning is triggered automatically for tasks rated ⼠7. ScenarioStatusScoreTime (s) Rounds Tool CallsSkill Learned Notes Shell commandPASS9139.615âCLI execution via Executor PDF processingPASS9152.227âMulti-step: extract + summarize Travel planningFAIL0309.811âNo network in test environment MCU comparisonPASS7172.013âWeb search + analysis WeChat messagingPASS981.815âInnate skill + GUI automation Story creationPASS8321.417âGenerative task; file_write used Overall5/6 PASS (83.3%); 4 new skills learned; mean time 196.1 s Third, the fastest completion (WeChat messaging, 81.8 s) benefits from an innate skill that provides the Executor with a pre-defined interaction procedure, demonstrating the value of the skill system for re- ducing planning overhead. Fourth, the single failure (travel planning) is correctly attributable to an envi- ronmental constraint (no network access) rather than a system deficiencyâthe pipeline detected the tool execution failure and reported it through the inter- vention callback rather than hallucinating a response. 13 Interfaces, Deployment, and Prod- uct Positioning IronEngine supports three complementary interaction modes, all sharing the same pipeline: Desktop workbench (PySide6): Provides the richest interaction experience with model selection dropdowns, real-time thinking block visualization, tool execution badges, quality score indicators, inter- vention prompts, and 10 customizable themes. This mode is optimized for interactive desktop usage where observability of the orchestration process is impor- tant. REST/WebSocket API (FastAPI): Enables in- tegration with web applications, mobile apps, and other services. WebSocket channels stream events in real-time, supporting the same 17 callback types as the Python client. This mode enables IronEngine to serve as a backend for custom frontends. Python client: Supports both callback- based (IronEngineClient) and Qt signal-based (IronEngineQtClient) integration for embedding IronEngine into larger applications. The client API mirrors the full pipeline capability set includ- ing configuration, model selection, and permission management. 13.1 Deployment Modes Fully local: All models served through Ollama or LM Studio on the same machine. No data leaves the local network. Suitable for privacy-sensitive work- loads and air-gapped environments. Hybrid: Local models for common tasks, cloud APIs for complex reasoning or specialized capabilities. The provider registry transparently routes requests to the appropriate backend. Service: API-only deployment for integration with external systems, automated workflows, or multi-user environments. 13.2 Product Positioning Table 12 positions IronEngine relative to representa- tive AI agent frameworks and products. IronEngine occupies a distinctive position in this landscape. Compared with the OpenClaw ecosystem, IronEngine trades multi-channel messaging breadth for orchestration depth: its three-phase pipeline with formal quality review, 24-category intelligent tool routing, and VRAM-aware multi-model lifecycle man- agement provide a level of task execution sophisti- cation that the gateway-oriented OpenClaw architec- ture does not attempt. Compared with cloud prod- ucts, IronEngine provides full local-first capability without sacrificing tool breadth or memory sophisti- cation. Compared with code-centric assistants (Cur- sor, Windsurf), IronEngine extends beyond program- ming into general-purpose desktop automation, com- munication, and multimedia analysis. The result is a system that combines local deployment strengths, multi-agent collaboration depth, protocol extensibil- ity, and tool breadth into a single orchestration- centered runtime with persistent memory and contin- uously improving skill capabilities. 13.3 Desktop Workbench Design Philosophy IronEngineâs desktop UI is not merely a chat interface but an orchestration visualization workbench. Its de- sign philosophy is that AI assistant decision-making processes should be transparent and visible to users, rather than a black-box inputâwaitâoutput pattern. ThinkingBlock. A collapsible Markdown- rendered component that displays Planner and Reviewer reasoning in real-time. Default collapsed YouTube @NiusRobotLab20 IronEngine: Towards General AI Assistant Table 12: System-positioning comparison with representative AI agent frameworks and products SystemPrimary positioning LocalMulti- entry MCP Representative characteristics IronEngineDesktop workbench + general assistant engine SSSPlanâReviewâExecute pipeline, unified UI/API, task scheduling, hierarchical memory, skill learning, 24 tool categories, VRAM management, orchestration observability OpenClawPersonal AI assistant + always-on gateway SSMMulti-channel messaging (Telegram, WhatsApp, SMS), device node management, persistent skills, gateway routing NanoClawEdge/IoT lightweight assistant SMWAggressive quantization, stripped skill set, upstream proxy, Raspberry Pi deployment IronClawHardware-oriented AI agent MWWSensor ingestion, actuator commands, safety interlocks, embedded systems integration ChatGPTCloud conversational AI WMWStrong conversation, web browsing, code interpreter; cloud-dependent, no local models Claude Desktop Protocol-extensible assistant MMSStrong MCP integration; limited local model, scheduling, and memory support CursorAI code editorMWMDeep IDE integration; focused on code editing/generation; limited to programming domain OpenManusOpen-source general agent MMSGeneral entry point with MCP variants and multi-agent flow execution AutoGenMulti-agent framework MMSFlexible agent topologies; research-oriented; requires integration for desktop workflow height of 28 pixels (showing only the role label), expanding to a maximum of 350 pixels. Supports automatic Markdown detection and rendering of headings, bold text, lists, code blocks, and links. Images are stripped in thinking blocks (shown only in conclusions) to reduce visual clutter. Font uses Segoe UI (not monospace) for improved readability. ToolExecutionBadge. A compact inline com- ponent displaying tool call status (pendingâdone), including tool type, brief description, and execution summary. Users can see at a glance which tools were executed and their outcomes. PermissionPrompt. An inline allow/deny prompt with a 60-second auto-deny timer. When an ask-level tool call is triggered, users see the permis- sion request directly in the conversation flow and the pipeline continues after their decision. Theme system. Ten procedurally generated sci- fi themes (deep_space, nebula_storm, mars_outpost, etc.), each with unique color schemes and background images (1920Ă1080 JPEG generated by Python scripts). Panels use coordinate mapping via mapTo() for continuous background rendering, with glassmor- phism effects through transparent backgrounds with semi-transparent gradient overlays. This design enables users not only to use the AI as- sistant for task completion but also to observe, under- stand, and debug the AIâs decision-making processâ particularly valuable during development and tuning of assistant behavior. 14 Safety and Privacy Safety in IronEngine is implemented through multiple complementary mechanisms that operate at different levels of the system architecture. 14.1 Permission Management The permission system provides three configurable levels per tool category: ⢠Auto: Tool calls are executed immediately with- out user confirmation. Suitable for low-risk opera- tions like file listing and text classification. ⢠Ask: Each tool call triggers an inline permis- sion prompt in the UI with a 60-second auto-deny timer. The user can approve or deny, with the de- cision optionally remembered for the session. ⢠Deny: Tool calls of this category are blocked en- tirely. Useful for restricting access to sensitive op- erations in shared environments. 14.2 Execution Sandboxing The CommandExecutor enforces several safety invari- ants: ⢠shell=True is never used for subprocess invoca- tion, preventing shell injection attacks. ⢠Template placeholders (e.g., filename, <path>) are detected and rejected before execution, pre- venting incomplete command execution. ⢠Command fields are validated as non-empty strings before subprocess creation. ⢠Execution timeout (default 30 seconds) prevents runaway processes. 14.3 URL Safety Web-facing operations employ a multi-layer offline URL safety system: ⢠Phishing blocklist: Updated from community- maintained phishing databases (Phishing Army, phishing-filter) with 24-hour caching. ⢠Heuristic scoring: 10-point evaluation cover- ing IP-in-URL, suspicious TLDs, brand imperson- YouTube @NiusRobotLab21 IronEngine: Towards General AI Assistant ation, homoglyph detection, dangerous protocols, excessive subdomains, and URL length anomalies. ⢠Parking/dead page detection: Content-level analysis to identify placeholder pages that provide no useful information. 14.4 Intervention Mechanism When a model determines that a task requires human judgment or authorization beyond its scope, it can emit an INTERVENTION_NEEDED marker. This triggers a user-facing prompt that pauses the pipeline until the user provides guidance. This mechanism serves as a safety valve for edge cases that cannot be resolved through automated permission checks. 14.5 SOUL Edit Control The SOUL (System Operating Under Limitations) document defines behavioral boundaries for each role. Edit access to the SOUL is controlled through a per- mission system with three levels: readonly (default, no modifications allowed), ask (modifications require explicit user approval), and auto (self-modification allowed within defined constraints). This prevents unauthorized changes to the assistantâs behavioral guidelines. 14.6 Local-First Privacy In fully local deployment mode, no data leaves the userâs machine. All model inference, tool execution, memory storage, and skill learning operate within the local environment. This is particularly important for workloads involving sensitive documents, personal communications, or proprietary information. The sys- tem does not require telemetry, cloud-based logging, or external authentication. 14.7 Internal English Processing All internal processingâPlanner/Reviewer discus- sion, web search queries, execution stepsâis con- ducted in English regardless of the userâs input lan- guage. Only the final answer (FINAL_ANSWER) is pre- sented in the userâs language. This strategy has two engineering rationales: (1) most open-source models achieve significantly higher reasoning and tool-calling accuracy in English than in other languages; (2) in- ternal English consistency simplifies cross-language matching for skill tags, memory indices, and search queries. The system includes a âź45-term Chineseâ English translation dictionary and CJK character de- tection functions for automatic input conversion. 14.8 Defense-in-Depth Design IronEngineâs safety design follows the defense-in- depth principle: permission management is the first defense line (blocking unauthorized operations), exe- cution sandboxing is the second (constraining autho- rized operationsâ dangerous behaviors), URL safety is the third (filtering malicious external resources), and the intervention mechanism is the last (escalating beyond-scope decisions to humans). These four lay- ers operate independently; bypassing any single layer does not compromise overall system security. 15 Discussion 15.1 Architectural Trade-offs The three-phase pipeline introduces latency overhead compared to single-step execution. The model switch phase alone adds approximately 27 seconds per task, and the PlannerâReviewer discussion can require 2â 3 rounds for complex tasks. However, this over- head is justified by improved reliability: the 100% task completion rate in our benchmarks suggests that the quality assurance provided by the Reviewer pre- vents costly execution failures that would require re- submission in single-step systems. The tiered prompt systemâs aggressive reduction for small models (44 tokens of SOUL context forâ¤10B models vs. 1309 tokens for>25B models) risks losing important behavioral guidance. Our testing shows that small models (â¤10B) can still achieve acceptable tool translation accuracy with minimal context, but their planning quality degrades significantly, motivat- ing the use of larger models for the Planner role. 15.2 Scalability Considerations The current single-GPU design limits IronEngine to models that fit within 24 GB VRAM (with quantiza- tion). While this covers a wide range of open-source models up to approximately 35B parameters, it ex- cludes the largest open models (70B+) in full pre- cision. The model switch mechanism could be ex- tended to support multi-GPU configurations or CPU offloading for larger models, though this would in- crease switch latency. The memory systemâs linear scan for relevant en- tries becomes less efficient as the memory store grows. Future work could introduce more sophisticated in- dexing (e.g., hierarchical HNSW with temporal clus- tering) to maintain sub-linear retrieval time at scale. YouTube @NiusRobotLab22 IronEngine: Towards General AI Assistant 15.3 Architectural Comparison with the OpenClaw Ecosystem OpenClaw and IronEngine represent two distinct ar- chitectural philosophies for AI assistants. OpenClaw adopts a message routing pattern: user messages are routed through a Gateway to skill handlers, which ex- ecute operations and return results. This architecture optimizes for multi-channel accessibility and response speed, suited to the simple âreceive message â exe- cute skill â replyâ interaction pattern. IronEngine adopts an orchestration depth pattern: each request traverses Discussion, Switch, and Exe- cution phases with three distinct roles (Planner, Re- viewer, Executor). This introduces additional latency (âź27 seconds for model switch + multi-round dis- cussion) but achieves higher task completion reliabil- ity: the Reviewerâs anti-hallucination detection pre- vents erroneous plans from being executed, and auto- correction mechanisms fix tool selection errors. NanoClawâs edge deployment strategy (aggressive quantization + upstream proxy) and IronEngineâs VRAM-aware model management address the same fundamental problem (running models on limited hardware) from different perspectives. NanoClaw op- timizes single-model execution on extremely small de- vices; IronEngine optimizes multi-model collabora- tion on consumer GPUs. IronClawâs sensor/actua- tor abstractions share goals with IronEngineâs hard- ware compatibility layer, but IronClaw targets real- time control loops while IronEngine targets task-level automation. 15.4 Design Principles and Engineering In- sights IronEngineâs development has yielded several impor- tant insights for AI agent system engineering: Role separation over capability stacking. Assigning planning, evaluation, and execution to dif- ferent model roles, rather than relying on a single powerful model for all responsibilities, is IronEngineâs core architectural decision. This provides three engi- neering advantages: (1) each role can use the model best suited to its requirements; (2) SOUL prompts can be role-specific, avoiding loading detailed tool documentation into the Reviewerâs context; (3) in- dividual roles can have their models replaced without affecting others. Auto-correction over precise instructions. Facing local modelsâ limited instruction-following ca- pability, IronEngine implements system-level auto- correction rather than relying on more detailed prompts to prevent errors. The tool routerâs alias nor- malization and auto-correction mechanisms demon- strate this strategyâs effectiveness: even when the Planner frequently misspecifies tool types, the sys- tem still routes correctly. This experience has broader implicationsâdesigning fault-tolerant system archi- tecture is more pragmatic than pursuing error-free model output. Observability is a debugging prerequisite. AI agent systemsâ opacity is the primary debugging obstacle. IronEngineâs 17 callback event types pro- vide complete visibility from thought processes to tool execution. In practice, on_quality_scored and on_phase_transition callbacks prove most useful for diagnosing pipeline bottlenecks. Memory is the core constraint. On con- sumer GPUs, VRAM management transforms from an optional optimization into an architectural foun- dation. KV-cache memory cost grows linearly with context length, and per-token KV-cache costs vary up to 5Ă across model architectures. IronEngineâs VRAM-aware context budget mechanism is a practi- cal necessity, not a theoretical optimization. 15.5 Generalizability While our experimental evaluation focuses on file op- erations, the systemâs 24 tool categories have been tested informally across web search, GUI automation, media analysis, and communication tasks. Formal benchmarks for these domains (e.g., WebArena [38] for web tasks, SWE-bench [40] for code tasks) repre- sent important future evaluation targets. 15.6 Limitations Several limitations should be acknowledged: ⢠Local model quality: Local models (7Bâ27B) generally underperform cloud-hosted frontier mod- els in complex reasoning tasks. IronEngine mit- igates this through multi-role collaboration and quality assurance, but cannot fully close the ca- pability gap. ⢠Windows-centric testing: GUI automation and application control have been primarily tested on Windows 10. Cross-platform support (macOS, Linux) requires alternative UIA backends (AT-SPI, AppleScript), which are not yet implemented. ⢠Single-user design: The current architecture as- sumes a single concurrent user. Multi-user support would require session isolation, resource schedul- ing, and access control mechanisms. ⢠Benchmark breadth: Our experimental evalua- tion covers file operations in depth but does not yet include standardized benchmarks such as We- bArena [38] (web tasks) or SWE-bench [40] (code tasks). ⢠Latency overhead: The three-phase pipelineâs model switching and multi-round discussion in- YouTube @NiusRobotLab23 IronEngine: Towards General AI Assistant troduce significant latency, making it unsuitable for real-time interaction scenarios requiring sub- second responses. ⢠Skill coverage: The 26 innate skills cover com- mon scenarios, but long-tail tasks still require in- teractive user guidance. Skill learning efficiency is constrained by the frequency of user rating feed- back. 16 Future Work Several directions for future development are planned: Multi-expert system. The current single- Planner architecture could be extended to support multiple expert profiles with domain-specific knowl- edge and credit scores. A routing mechanism would select the most appropriate expert based on task char- acteristics, enabling specialization without sacrificing generality. Standardized benchmarking. Integration with established benchmarks such as WebArena [38], SWE-bench [40], and custom multi-tool benchmarks would enable systematic comparison with other agent systems and tracking of performance improvements across versions. User preference learning. The current mem- ory and skill systems capture task-level knowledge but do not explicitly model user preferences (communica- tion style, risk tolerance, tool preferences). A ded- icated preference module could learn these patterns from interaction history and adapt the assistantâs be- havior accordingly. Bidirectional MCP. Currently IronEngine acts only as an MCP client, consuming tools from external servers. Implementing MCP server capability would allow IronEngineâs 24 tool categories to be exposed to other MCP-compatible systems, positioning it as both a consumer and provider in the MCP ecosystem. Cross-device synchronization. The local-first architecture could be extended with optional en- crypted synchronization across multiple devices, en- abling seamless transitions between desktop and mo- bile environments while preserving privacy guaran- tees. Multimodal deepening. Current vision capa- bilities are limited to image analysis and screenshot- based GUI navigation. Deeper integration of video understanding (temporal reasoning across frames), real-time audio conversation, and spatial reasoning would expand the systemâs applicability to embodied and multimedia-rich scenarios. Edge deployment. Optimization for resource- constrained devices (8 GB VRAM or less) through aggressive quantization, speculative decoding, and pipeline stage pruning would extend IronEngineâs reach to laptop and mobile environments. OpenClaw ecosystem interoperability. Ex- ploring interoperation modes between IronEngine and the OpenClaw Gateway: IronEngine as an OpenClaw device node providing deep orchestration capability, or OpenClawâs multi-channel messaging as a commu- nication extension for IronEngine. The complemen- tary characteristics of these systems suggest that joint deployment may provide a more complete assistant experience than either system alone. Adaptive pipeline. Automatically adjusting pipeline depth based on task complexity: simple tasks skip the Reviewer and execute directly; complex tasks enable multi-round discussion and multi-expert rout- ing. The current simple-plan reuse mechanism (â¤4 tool calls skip model switch) is an initial exploration in this direction. 17 Conclusion This paper has presented IronEngine, a system- oriented platform for general AI assistant develop- ment that addresses three key engineering gaps in current agent systems: fragmented interaction sur- faces, loosely coupled subsystem integration, and lim- ited support for local deployment with persistent be- havior. IronEngineâs three-phase pipeline separates plan- ning quality (PlannerâReviewer discussion) from ex- ecution capability (tool-augmented Executor), en- abling heterogeneous model allocation on consumer hardware. The system integrates 24 tool categories through an intelligent routing layer with alias normal- ization and automatic error correction, manages per- sistent state through hierarchical memory with dual consolidation strategies, and acquires reusable proce- dural knowledge through vectorized skill learning with novelty-based deduplication. Experimental evaluation on file operation bench- marks demonstrates 100% task completion accuracy with a three-model local configuration (27B Planner, 20B Reviewer, 3.8B Tools model) on a single RTX 3090. Detailed comparison with seven representa- tive AI assistant systems highlights IronEngineâs dis- tinctive combination of local-first deployment, broad tool coverage, persistent memory, skill learning, and protocol-level extensibility. The future of AI assistants depends not only on model capability but also on architecture, orchestra- tion, observability, safety, and long-term adaptability. IronEngine demonstrates that these system-level con- cerns can be addressed coherently within a single plat- form, providing a foundation for the next generation of general-purpose, privacy-preserving, and continu- ously improving AI assistants. YouTube @NiusRobotLab24 IronEngine: Towards General AI Assistant From a broader perspective, IronEngine vali- dates a core proposition: through carefully de- signed system architecture (role separation, intelligent routing, hierarchical memory, VRAM-aware schedul- ing), moderately-sized local open-source models can achieve usable automation levels in practical tasks. Compared with cloud-based approaches relying on single super-large models, this system intelligence ap- proach offers structural advantages in cost, privacy, and customizability. Compared with gateway-style architectures like OpenClaw, IronEngineâs deep or- chestration provides higher task completion reliabil- ity. These two approaches are not opposing but com- plementary technical choices within the AI assistant ecosystem. As open-source model capabilities con- tinue to improve, the local orchestration paradigm that IronEngine represents will demonstrate its value in an expanding range of application scenarios. Acknowledgements The author thanks NiusRobotLab for supporting the exploration of general AI assistant systems and open engineering practices. Appreciation is also extended to the open-source communities advanc- ing local model runtimes (Ollama, LM Studio), multi-agent research (AutoGen, CAMEL, MetaGPT), vector databases (ChromaDB), browser automation (Playwright, patchright), and MCP-related interoper- ability, which collectively shaped the technical envi- ronment in which IronEngine evolved. Finally, thanks go to the testers and users whose concrete scenarios helped move the system from prototype thinking to- ward an operational platform. References [1] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Ĺukasz Kaiser, and Illia Polosukhin. Attention is all you need. Advances in Neural Information Processing Systems, 30, 2017. [2] Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D. Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agar- wal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler, Jeffrey Wu, Clemens Winter, Chris Hesse, Mark Chen, Eric Sigler, Mateusz Litwin, Scott Gray, Benjamin Chess, Jack Clark, Christopher Berner, Sam McCandlish, Alec Rad- ford, Ilya Sutskever, and Dario Amodei. Lan- guage models are few-shot learners. Advances in Neural Information Processing Systems, 33: 1877â1901, 2020. [3] Hugo Touvron, Thibaut Lavril, Gautier Izacard, Xavier Martinet, Marie-Anne Lachaux, Timo- thĂŠe Lacroix, Baptiste Rozière, Naman Goyal, Eric Hambro, Faisal Azhar, Aurelien Rodriguez, Armand Joulin, Edouard Grave, and Guil- laume Lample. Llama: Open and efficient foundation language models. arXiv preprint arXiv:2302.13971, 2023. [4] Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Ale- man, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. Gpt-4 technical report. arXiv preprint arXiv:2303.08774, 2024. [5] Google DeepMind. Gemini: Multimodal ai model family. Online, 2025. URL https:// deepmind.google/technologies/gemini/. Ac- cessed: 2026-03-07. [6] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. React: Synergizing reasoning and acting in language models. International Conference on Learning Representations, 2023. [7] Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc V. Le, and Denny Zhou. Chain-of-thought prompting elicits reasoning in large language models. Advances in Neural Information Pro- cessing Systems, 35:24824â24837, 2022. [8] Timo Schick, Jane Dwivedi-Yu, Roberto Dessi, Jason Wei, Alexandra Birch, Jason Weston, and Gael Le Scao. Toolformer: Language models can teach themselves to use tools. International Con- ference on Learning Representations, 2024. [9] Patrick Lewis, Ethan Perez, Aleksandra Pik- tus, Fabio Petroni, Vladimir Karpukhin, Na- man Goyal, Heinrich K"uttler, Mike Lewis, Wen tau Yih, Tim Rockt"aschel, Sebastian Riedel, and Douwe Kiela. Retrieval-augmented genera- tion for knowledge-intensive nlp tasks. Advances in Neural Information Processing Systems, 33: 9459â9474, 2020. [10] Joon Sung Park, Joseph OâBrien, Carrie Cai, Meredith Ringel Morris, Percy Liang, and Michael S. Bernstein. Generative agents: Inter- active simulacra of human behavior. ACM Sym- posium on User Interface Software and Technol- ogy, 2023. [11] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu YouTube @NiusRobotLab25 IronEngine: Towards General AI Assistant Yao. Reflexion: Language agents with verbal reinforcement learning. Advances in Neural Information Processing Systems, 2023. [12] Microsoft. Autogen: Enabling next-gen llm ap- plications via multi-agent conversation. Online, 2024. URL https://github.com/microsoft/ autogen. Accessed: 2026-03-07. [13] Guohao Li, Hasan Abed Al Kader Hammoud, Hani Itani, Dmitrii Khizbullin, and Bernard Ghanem. Camel: Communicative agents for âmindâ exploration of large language model so- ciety. In Thirty-seventh Conference on Neural Information Processing Systems, 2023. [14] Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and JĂźrgen Schmidhuber. MetaGPT: Meta programming for a multi-agent collaborative framework. In The Twelfth Interna- tional Conference on Learning Representations, 2024. URL https://openreview.net/forum? id=VtmBAGCN7o. [15] Chen Qian, Wei Liu, Hongzhuo Liang, Yang Yu, and Zhenhui Li. Chatdev: Communicative agents for software development. Association for Computational Linguistics, 2024. [16] Xinbin Liang, Jinyu Xiang, Zhaoyang Yu, Jiayi Zhang, Sirui Hong, Sheng Fan, Xiao Tang, Bang Liu, Yuyu Luo, and Chenglin Wu. Openmanus: An open-source framework for building general ai agents. Zenodo, 2025. URL https://doi.org/ 10.5281/zenodo.15186407. Accessed: 2026-03- 07. [17] OpenClaw Community and Peter Steinberger. Openclaw: Personal ai assistant. Online, 2026. URL https://github.com/openclaw/ openclaw. Accessed: 2026-03-07. [18] OpenAI. Gpt-4o: Omni model for text, vision, and audio. Online, 2025. URL https://openai. com/index/hello-gpt-4o/. Accessed: 2026-03- 07. [19] Anthropic. Model context protocol. Online, 2024. URL https://modelcontextprotocol. io. Accessed: 2026-03-07. [20] Anthropic. Claude code: Anthropicâs of- ficial cli for claude. Online, 2025. URL https://docs.anthropic.com/en/docs/ agents-and-tools/claude-code. Accessed: 2026-03-07. [21] Anysphere Inc. Cursor: The ai code editor. On- line, 2025. URL https://cursor.com. Accessed: 2026-03-07. [22] Codeium. Windsurf: The flow state ai ide. On- line, 2025. URL https://windsurf.com. Ac- cessed: 2026-03-07. [23] GitHub. Github copilot: Your ai pair program- mer. Online, 2024. URL https://github.com/ features/copilot. Accessed: 2026-03-07. [24] Theodore R. Sumers, Shunyu Yao, Karthik Narasimhan, and Thomas L. Griffiths. Cognitive architectures for language agents. Transactions on Machine Learning Research, 2024. [25] Wenlong Huang, Fei Xia, Ted Xiao, Harris Chan, Jacky Liang, Pete Florence, Andy Zeng, Jonathan Tompson, Igor Mordatch, Yevgen Chebotar, Pierre Sermanet, Noah Brown, Tomas Jackson, Linda Leal, Daniel Driess, Chelsea Finn, and Karol Hausman. Inner monologue: Embodied reasoning through planning with lan- guage models. In Conference on Robot Learning (CoRL), 2023. [26] Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xian- gru Tang, Bill Qian, Sihan Zhao, Lauren Hong, Runchu Tian, Ruobing Xie, Jie Zhou, Mark Ger- stein, Dahai Li, Zhiyuan Liu, and Maosong Sun. Toolllm: Facilitating large language models to master 16000+ real-world apis. International Conference on Learning Representations, 2024. [27] Shishir G. Patil, Tianjun Zhang, Xin Wang, and Joseph E. Gonzalez. Gorilla: Large lan- guage model connected with massive apis. arXiv preprint arXiv:2305.15334, 2023. [28] Yongliang Shen, Kaitao Song, Xu Tan, Dong- sheng Li, Weiming Lu, and Yueting Zhuang. Hugginggpt: Solving ai tasks with chatgpt and its friends in hugging face. Advances in Neural Information Processing Systems, 36, 2024. [29] Reiichiro Nakano, Jacob Hilton, Suchir Balaji, Jeff Wu, Long Ouyang, Christina Kim, Christo- pher Hesse, Shantanu Jain, Vineet Kosaraju, William Saunders, Xu Jiang, Karl Cobbe, Tyna Eloundou, Gretchen Krueger, Kevin Button, Matthew Knight, Benjamin Chess, and John Schulman. Webgpt: Browser-assisted question- answering with human feedback. arXiv preprint arXiv:2112.09332, 2022. [30] GrĂŠgoire Mialon, Roberto Dessi, Maria Lomeli, Christoforos Nalmpantis, Ram Pasunuru, Roberta Raileanu, Baptiste Rozière, Timo YouTube @NiusRobotLab26 IronEngine: Towards General AI Assistant Schick, Jane Dwivedi-Yu, Asli Celikyilmaz, Edouard Grave, Yann LeCun, and Thomas Scialom. Augmented language models: a survey. Transactions on Machine Learning Research, 2023. [31] Chroma. Chroma: The ai-native open-source embedding database. Online, 2024. URL https: //w.trychroma.com. Accessed: 2026-03-07. [32] Charles Packer, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, and Joseph E. Gonzalez. Memgpt: Towards llms as operating systems. arXiv preprint arXiv:2310.08560, 2023. [33] Tao Guo, Xiang Yue, Yifei Zhang, Tongzhe Li, Dong Wang, Yilun Zhao, Huan Sun, Jun Wang, and Rui Yan. Large language model based multi- agents: A survey of progress and challenges. arXiv preprint arXiv:2402.01680, 2024. [34] Zhiheng Xi, Wenxiang Chen, Xin Guo, Wei He, Yiwen Ding, Boyang Hong, Ming Zhang, Junzhe Wang, Senjie Jin, Enyu Zhou, Rui Zheng, Xi- aoran Fan, Xiao Wang, Limao Xiong, Qin Liu, Yuhao Zhou, Weiran Wang, Changling Jiang, Yicheng Zou, Xiangyang Liu, Zhangyue Yin, Shihan Dou, Rongxiang Weng, Wensen Cheng, Qi Zhang, Wenjuan Qin, Yongyan Zheng, Xipeng Qiu, Xuanjing Huang, and Tao Gui. The rise and potential of large language model based agents: A survey. arXiv preprint arXiv:2309.07864, 2023. [35] Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, Wayne Xin Zhao, Zhewei Wei, and Ji-Rong Wen. A survey on large language model based autonomous agents. Fron- tiers of Computer Science, 18(6), 2024. [36] crewAI. crewai: Multi-agent automation frame- work. Online, 2024. URL https://github.com/ crewAIInc/crewAI. Accessed: 2026-03-07. [37] Xiang Deng, Yu Gu, Boyuan Zheng, Shijie Chen, Samuel Stevens, Boshi Wang, Huan Sun, and Yu Su. Mind2web: Towards a generalist agent for the web. Advances in Neural Information Processing Systems, 36, 2024. [38] Shuyan Zhou, Frank F. Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abishek Sridhar, Xianyi Cheng, Tianyue Ou, Yonatan Bisk, Daniel Fried, Uri Alon, and Graham Neubig. Webarena: A re- alistic web environment for building autonomous agents. International Conference on Learning Representations, 2024. [39] John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. Swe-agent: Agent- computer interfaces enable automated software engineering. arXiv preprint arXiv:2405.15793, 2024. [40] Carlos E. Jimenez, John Yang, Alexander Wet- tig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. Swe-bench: Can language models resolve real-world github issues? Interna- tional Conference on Learning Representations, 2024. [41] Open Interpreter. Open interpreter: A natural language interface for computers. Online, 2024. URL https://github.com/OpenInterpreter/ open-interpreter. Accessed: 2026-03-07. [42] patchright contributors. patchright: Anti- detection playwright fork. Online, 2025. URL https://github.com/nicosql/patchright. Accessed: 2026-03-07. [43] Tianbao Xie, Danyang Zhang, Jixuan Chen, Xiaochuan Li, Siheng Zhao, Ruisheng Cao, Toh Jing Hua, Zhoujun Cheng, Dongchan Shin, Fangyu Lei, Yitao Liu, Yiheng Xu, Shuyan Zhou, Silvio Savarese, Caiming Xiong, Victor Zhong, and Tao Yu. Osworld: Benchmarking multi- modal agents for open-ended tasks in real com- puter environments. Online, 2024. URL https: //os-world.github.io/. [44] Significant Gravitas. Autogpt: An autonomous gpt-4 experiment. Online, 2023. URL https:// github.com/Significant-Gravitas/AutoGPT. Accessed: 2026-03-07. [45] Ollama. Ollama documentation. Online, 2025. URL https://ollama.com. Accessed: 2026-03- 07. [46] LM Studio. Lm studio documentation. Online, 2025. URL https://lmstudio.ai. Accessed: 2026-03-07. [47] OpenClaw Community. Nanoclaw: Lightweight edge ai assistant. Online, 2026. URL https: //github.com/openclaw/nanoclaw. Accessed: 2026-03-07. [48] OpenClaw Community. Ironclaw: Hardware- oriented ai agent for embedded systems. Online, 2026. URL https://github.com/openclaw/ ironclaw. Accessed: 2026-03-07. [49] OpenClaw Community. Picoclaw: Microcon- troller ai agent for embedded platforms. Online, 2026. URL https://github.com/openclaw/ picoclaw. Accessed: 2026-03-08. YouTube @NiusRobotLab27 IronEngine: Towards General AI Assistant [50] The Qt Company.Pyside6: The offi- cial python module for the qt 6 framework. Online, 2024.URL https://doc.qt.io/ qtforpython-6/. Accessed: 2026-03-07. YouTube @NiusRobotLab28