OpenAaaS: An Open Agent-as-a-Service Framework for Distributed Materials-Informatics Research

This paper introduces OpenAaaS, an open-source, distributed Agent-as-a-Service framework that enables secure, multi-agent collaboration for materials informatics by adhering to a "code flows, data stays still" principle, thereby allowing institutions to integrate isolated data and computational resources without compromising data sovereignty.

The Gist

Imagine you are trying to solve a massive, complex puzzle, like designing a new super-strong metal for a jet engine. To do this, you need to consult three different experts who are sitting in three different countries:

1. The Librarian in Beijing, who has read every paper ever written on metal alloys but can't leave her library.
2. The Database Manager in New York, who holds a 17-terabyte (17,000 gigabytes) collection of secret metal formulas that he is legally forbidden from sending over the internet.
3. The Supercomputer Operator in Berlin, who has a giant machine that can simulate how metals behave, but it's too slow to send data back and forth.

In the old way of doing things, you would have to ask these experts to mail you their entire libraries and hard drives. The Librarian would have to photocopy millions of pages, the Database Manager would have to ship a truckload of hard drives, and the Supercomputer Operator would have to wait weeks for the data to upload. It's slow, expensive, and often impossible because of security rules.

OpenAaaS is a new, open-source framework that changes the rules of the game. Instead of asking the experts to send their data to you, you send your questions to them.

Here is how it works, using simple analogies:

The Core Idea: "Send the Chef, Not the Ingredients"

Think of the data (the metal formulas, the papers, the simulation results) as fresh ingredients sitting in a kitchen.

• The Old Way: You ask the chef to pack up all the ingredients and ship them to your house so you can cook. This is slow, and the ingredients might spoil or get lost in customs (security firewalls).
• The OpenAaaS Way: You send a digital chef (an AI agent) to the kitchen. The chef walks in, cooks the meal using the ingredients right there, and then sends you back only the finished dish (the answer). The ingredients never leave the kitchen.

The Three Parts of the System

1. The Master Agent (The Project Manager)
This is the AI you talk to. You tell it, "I need to find a metal that doesn't melt at 2,000 degrees." The Master Agent doesn't know the answers itself. Instead, it acts like a smart project manager. It breaks your big question into smaller tasks and sends them out to the network. It never sees the raw data; it only sees the final answers.

2. The Network Hub (The Dispatch Center)
This is a lightweight server that acts like a phone switchboard. It keeps a list of all the available "kitchens" (nodes) and what they are good at. When the Project Manager needs help, the Hub routes the request to the right kitchen. Crucially, the Hub never touches the ingredients. It just passes the instructions.

3. The Agent Cores (The Local Chefs)
These are the computers sitting right next to the data.

• The Librarian's Node: Runs the AI that reads the papers. It finds the answer in the library and sends back a summary.
• The Database Node: Runs the AI that queries the 17TB secret database. It does the math right there on the server and sends back a tiny report (maybe just 2 megabytes) instead of the whole 17TB database.
• The Supercomputer Node: Runs the simulation and sends back the result.

Why This is a Big Deal (The "Last Mile" Problem)

The paper argues that we already have amazing AI models and huge amounts of data. The problem is that we can't connect them securely across different organizations (like universities, companies, and governments) because of data sovereignty (the rule that data must stay where it belongs).

OpenAaaS solves this by creating a "Secure Delivery Service" for AI.

• No Data Migration: The raw data never leaves its home.
• Zero Format Hassle: The local "chefs" can handle any file format (Excel, PDF, weird binary files) because they are already there. They don't need the data to be cleaned up before they start working.
• Security: Because the data never moves, it doesn't have to pass through firewalls or worry about being hacked during transit.

Two Real-World Examples from the Paper

1. The "Deep-Reading" Librarian (AlphaAgent)
The researchers built a special "chef" to read materials science papers. When asked a complex question like, "How does heat treatment affect this specific alloy?", a normal AI might just guess or find a paper that looks similar but isn't quite right.
This AlphaAgent chef:

• Reads the papers carefully.
• Checks if the evidence actually matches the specific metal and conditions.
• Writes a report citing exactly which pages support the answer.
• Result: It scored 4.66 out of 5 on deep analytical questions, beating standard AI models that just skim the surface.

2. The "Secret Vault" Database (HEA-Executor)
They connected to a massive database of High-Entropy Alloys (complex metals with 6+ elements). The database is 17.4 Terabytes big.

• The Problem: If you tried to download this to your laptop to search it, it would take 17 days just to transfer the data.
• The OpenAaaS Solution: The AI chef went to the database server. It asked, "Which combinations of Molybdenum, Niobium, Tantalum, and Tungsten are the most ductile?" The server did the math instantly and sent back a tiny answer (2.3 MB).
• Result: The user got a specific answer about optimizing metal plasticity in seconds, without ever seeing or downloading the massive secret database.

Summary

OpenAaaS is like building a global network of specialized kitchens where you can order a custom meal without ever needing to own the ingredients. It allows scientists to collaborate on complex problems (like designing new materials for harsh environments) by sending AI agents to the data, rather than moving the data to the AI. This keeps secrets safe, saves time, and lets different organizations work together without breaking their security rules.

Technical Summary

Technical Summary: OpenAaaS

1. Problem Statement

The development of structural and functional materials for harsh environments (e.g., high-temperature alloys, radiation-resistant steels) faces a critical "last mile" bottleneck. While the Materials Genome Initiative (MGI) successfully established centralized platforms (SaaS, PaaS, IaaS) and Large Language Models (LLMs) have introduced autonomous reasoning capabilities, existing architectures fail to support cross-organizational collaboration under strict data sovereignty constraints.

Current systems face four specific limitations:

1. Long-term Horizon: R&D cycles span years, exceeding the context windows and persistence of single-session agents.
2. Mechanistic Complexity: Problems require cross-domain synthesis (electronic structure, defect chemistry, etc.) that isolated tools cannot handle.
3. High Domain Expertise: General-purpose agents lack the depth to reason reliably across specialized disciplines.
4. Sensitive Data Constraints: Proprietary compositions, unpublished results, and restricted models cannot be migrated to centralized platforms due to confidentiality, export controls, or institutional firewalls.

The core challenge is the lack of an organizational infrastructure to compose world-class models and vast data repositories securely across institutional boundaries without violating data sovereignty.

2. Methodology: The OpenAaaS Framework

To address this, the authors propose OpenAaaS (Open Agent-as-a-Service), a hierarchical, distributed framework built on the foundational principle: "Code flows, data stays still." Instead of migrating raw data to a central location, OpenAaaS distributes agent execution nodes to where the data resides, transmitting only task descriptions, intermediate reasoning artifacts, and final results.

2.1 Three-Tier Architecture

The system consists of three distinct layers:

• Master Agent Layer (Tier 1): General-purpose LLM agents (e.g., Kimi CLI, Claude Code, Codex) that understand user intents, decompose complex research problems, and orchestrate remote capabilities. Crucially, the Master Agent never accesses raw data; it reasons only over task descriptions and service metadata.
• Network Hub / OpenAaaS Server (Tier 2): A lightweight, single-binary HTTP server (implemented in Rust with embedded SQLite) that acts as a registry and router. It maintains a list of available services, routes tasks to qualified nodes, manages authentication, and relays small file artifacts. It never accesses or stores raw scientific data.
• Network Node / Agent Core (Tier 3): Domain-specific execution nodes deployed locally at data sites (labs, clusters). Each node runs in an isolated Docker sandbox, retaining full sovereignty over local datasets, proprietary algorithms, and hardware. Nodes expose local resources as composable services via a self-describing API.

2.2 Key Design Mechanisms

• Near-Data Execution: Computation occurs at the data source. For a 10 TB database, only query results (KB–MB scale) traverse the network, eliminating bandwidth bottlenecks and compliance reviews for data egress.
• Progressive Capability Discovery: To prevent context window overflow in Master Agents, service discovery is three-staged:
  1. Lightweight summary: Name, domain tag, and capacity.
  2. On-demand usage: Full documentation (schemas, examples) loaded only for active candidates.
  3. Interactive refinement: Preliminary prompts to clarify parameters.
• Security Model: Employs defense-in-depth including HTTPS communication, outbound-only connections (reverse polling) to bypass firewalls, HMAC-SHA256 authentication, and container sandboxing.
• Protocol Compatibility: The framework integrates with the Model Context Protocol (MCP), allowing standard MCP clients (e.g., Cursor, Cline) to connect via a dedicated adapter, while also providing custom plugins for specific agents.

3. Key Contributions

The paper formalizes and implements four primary contributions:

1. Architectural Formalization: Identifies the tension between cross-domain integration and data sovereignty as a central design constraint, proposing a hierarchical multi-agent architecture that addresses this gap.
2. OpenAaaS Implementation: A three-tier, open-source (MIT license) framework realizing near-data execution, progressive discovery, and standardized protocols.
3. AlphaAgent Case Study: A materials-literature analysis executor that grounds answers in validated retrieval evidence, outperforming single-pass RAG baselines.
4. HEA Database Case Study: A secure, ultra-large-scale (17.4 TB) hexa-high-entropy alloy descriptor database service demonstrating secure near-data execution and domain-specific workflows without raw data migration.

4. Results and Evaluation

4.1 Case Study I: AlphaAgent (Literature Analysis)

AlphaAgent was evaluated against a single-pass RAG baseline and general-purpose models (GPT-5.5, Kimi-K2.6) on 40 metallurgical questions (20 deep analytical, 20 general).

• Performance: AlphaAgent achieved an average score of 4.66/5.0 on deep analytical questions, significantly outperforming the single-pass RAG baseline (2.67) and general models (4.05 and 3.96).
• Mechanism: The system uses a "Scientific Execution Contract" to enforce evidence validation. It rewrites intents to preserve materials-specific entities, performs bounded query reformulation if evidence is insufficient, and validates that retrieved snippets match the material system and mechanistic focus before generating reports.

4.2 Case Study II: HEA Descriptor Database

The framework was tested on a 17.4 TB database containing ~5.4 × 10¹⁰ candidate hexa-high-entropy alloy compositions.

• Efficiency: The task involved optimizing room-temperature plasticity for MoNbTaW refractory HEAs. The HEA-Executor filtered the data, trained ML models, and generated reports entirely at the remote node.
• Data Transfer: The total returned data volume was ~2.3 MB (candidate compositions, predictions, and reports), compared to the 17.4 TB raw dataset. This represents a reduction of nearly seven orders of magnitude in data transfer.
• Latency: The OpenAaaS task-routing overhead was approximately 550 ms, negligible compared to the ~17.7 days required to transfer the full dataset over a standard 100 Mbps connection.
• Outcome: The system identified an Al–Mo–Nb–Ta–W–Hf system with 9.80% highly ductile configurations, a 10.7-fold improvement over a Ti-containing baseline.

5. Significance and Claims

The paper claims that OpenAaaS establishes a principled pathway toward "organized research" via agent collectives. Its significance lies in:

• Solving the Data Sovereignty Bottleneck: It enables the secure integration of isolated materials intelligence silos (academic, industrial, national labs) without requiring data migration, thereby respecting confidentiality and regulatory constraints.
• Shifting the Paradigm: It moves from "data moving to compute" to "compute moving to data," making the marginal cost of data movement negligible for TB-scale datasets.
• Scalable Foundation: It provides a reusable substrate for next-generation materials intelligent design platforms where specialized, persistent, and self-improving agents can collaborate across institutional boundaries.
• Progressive Trust: The architecture supports a federation model where trust is built incrementally (service-by-service) rather than requiring an all-or-nothing network membership.

The authors conclude that while challenges remain regarding network scale, semantic discovery, and quality-of-service guarantees, OpenAaaS offers a scalable foundation for transitioning from isolated digital infrastructures to an interconnected "Agentic Science" network.