OpenAaaS: Distributed Materials Informatics
- OpenAaaS is an open-source, distributed Agent-as-a-Service framework designed for materials-informatics research that enforces data sovereignty by keeping raw data local.
- It employs a three-tier hierarchical architecture with a Master Agent, network hub, and local nodes to orchestrate near-data execution and agent collaboration.
- The framework facilitates secure and scalable cross-institution research by decomposing complex tasks while preserving proprietary data and operational constraints.
OpenAaaS is an open-source, hierarchical, distributed Agent-as-a-Service framework for materials-informatics research that is designed to support organized multi-agent collaboration across institutional boundaries without centralizing raw scientific data. It is motivated by a “last mile” problem: LLMs and autonomous agents provide strong reasoning capabilities, and materials science already has rich databases, HPC resources, and experimental platforms, yet conventional centralized SaaS, PaaS, and IaaS platforms do not provide an organizational infrastructure for secure cross-institution composition under proprietary, regulatory, and scale constraints. OpenAaaS addresses this by enforcing a single architectural principle—“code flows, data stays still”—so that a Master Agent plans and decomposes tasks, while near-data sub-agents retain sovereignty over local datasets, proprietary algorithms, and specialized hardware (Kang et al., 13 May 2026).
1. Definition, scope, and problem setting
OpenAaaS, expanded as “Open Agent-as-a-Service,” is presented as a framework for distributed materials intelligent design rather than as a monolithic agent system or a conventional centralized cloud platform. Its target domain is materials-informatics research characterized by long-term iteration, mechanistic complexity, and high domain expertise requirements, including high-temperature alloys, radiation resistant steels, and corrosion-resistant coatings. In this setting, the framework is intended to connect previously isolated “materials intelligence silos” while ensuring that raw data remains within its domain of origin (Kang et al., 13 May 2026).
The framework is explicitly situated against two existing patterns. The first is the centralized platform model exemplified by materials-data ecosystems that aggregate resources into a single location. The second is the monolithic agent model, which assumes a single trust boundary and centralized visibility into tools and data. OpenAaaS instead adopts distributed composition: only task descriptions, small input artifacts, intermediate reasoning artifacts, and final results move across the network, while TB-scale databases, proprietary experimental logs, and instrument files remain local to the institutions that control them (Kang et al., 13 May 2026).
A recurrent misconception is to treat OpenAaaS as a general-purpose remote execution broker. The framework is narrower and more structured than that. It is hierarchical, with a top-level Master Agent and specialized sub-agents; cross-organizational, with nodes at different institutions; and data-sovereign, with local “Agent Core” executors that expose capabilities without exposing underlying raw datasets. The stated objective is not only distributed inference, but a pathway toward “organized research” via agent collectives (Kang et al., 13 May 2026).
2. Three-tier architecture and runtime organization
OpenAaaS is organized as a three-tier architecture. Tier 1 is the Master Agent layer, which can be implemented by agents such as Kimi CLI, Claude Code, Codex, Pi-mono, or a custom agent. The Master Agent receives a natural-language research goal, decomposes it into sub-tasks, discovers remote services, orchestrates calls, and synthesizes results. Importantly, it does not access raw data directly; it operates on service metadata, task results, and structured outputs (Kang et al., 13 May 2026).
Tier 2 is the Network Hub, or OpenAaaS Server. This is a lightweight Rust HTTP server backed by a small SQLite database. It functions as a service registry, task router, node heartbeat monitor, and file relay. Nodes register capabilities with service names, domain tags, and input/output schemas; the server assigns tasks based on capability and liveness; and it relays only small files, with a default upper bound of about 50 MB and short retention. The server does not store or process raw scientific databases (Kang et al., 13 May 2026).
Tier 3 is the Network Node, implemented by a Rust “Agent Core” binary deployed close to the data. Each Agent Core registers services, polls the server for tasks, and launches isolated Docker containers for execution. These containers mount a local workspace and local data directories, read-only by default, and run node-owner-defined code such as Python scripts, domain-specific codes, or ML pipelines. Resource limits and timeouts are controlled locally, and containers have no access to the internal laboratory network unless explicitly configured (Kang et al., 13 May 2026).
A notable architectural feature is progressive capability discovery. Rather than exposing all service details to the Master Agent at once, OpenAaaS reveals information in stages: compact summaries first, detailed usage documentation on demand, and then interactive refinement through trial tasks if necessary. This is intended to reduce context-window pressure in LLM-based orchestration. The framework also exposes an MCP-compatible adapter, openaaas-mcp-adapter, which maps OpenAaaS operations to 14 MCP tools, and it provides additional plugins for Kimi CLI and Pi-mono. The codebase is MIT licensed and publicly available (Kang et al., 13 May 2026).
3. Data sovereignty, security model, and operational constraints
The central security invariant of OpenAaaS is that “raw data never leaves its domain of origin.” This is implemented structurally rather than as an after-the-fact policy layer. Data is mounted only inside containers on the local node, the server never receives raw database files, and client access is mediated exclusively through the services that node owners choose to expose. In the hexa-high-entropy alloy database case, this principle is formalized as protocol rules including Remote-Execution-First, Minimal Data Return, Database Isolation, Restricted Descriptor Exposure, and Multi-User Shared Computing (Kang et al., 13 May 2026).
The transport and execution security model is defense-in-depth. All traffic uses HTTPS. Nodes use outbound-only connectivity with reverse polling, which avoids exposing inbound ports through institutional firewalls. Authentication is based on API keys with HMAC-SHA256 signatures, and every client and node receives a unique key. Administrative operations require a separate admin key. Task execution occurs inside isolated Docker containers with explicit resource limits and controlled mounts, and host-network access is denied unless the node operator enables it (Kang et al., 13 May 2026).
Auditability is provided by server-side logs that record task submission, assignment, completion status, file transfers, timestamps, and actor identifiers. This provides provenance without requiring centralized storage of underlying scientific content. The framework therefore places effective control in the hands of node owners: they determine which directories are mounted, which services are available, what outputs may be returned, and which clients receive authorization. OpenAaaS supplies the transport and orchestration substrate, but each institution defines the admissible exposure surface (Kang et al., 13 May 2026).
This security model also clarifies what OpenAaaS is not. It is not a federated database that supports unrestricted querying across remote stores, and it is not simply an MCP tool host. It is a constrained service network whose interfaces are intentionally narrower than the full data and compute environments behind them. That distinction is especially important in settings involving proprietary data, export controls, or laboratory firewalls.
4. Workflow model and representative services
A typical OpenAaaS workflow begins with a natural-language research request submitted to the Master Agent. The Master Agent decomposes the request into literature analysis, database exploration, modeling, and synthesis; queries the server for relevant services; requests usage documentation for selected services; and then submits structured tasks to the appropriate nodes. Results are returned to the Master Agent, which may re-plan and issue follow-up tasks before generating a final synthesis (Kang et al., 13 May 2026).
Two representative services are used to validate this design.
| Service | Function | Key reported result |
|---|---|---|
| AlphaAgent | Evidence-grounded materials literature analysis | 4.66/5.0 on deep analytical questions |
| HEA-Executor | Near-data analysis of a 17.4 TB HEA descriptor database | ~2.3 MB returned from a 17.4 TB source |
AlphaAgent is a domain-specific executor for materials literature analysis. It supports retrieval-grounded question answering, targeted paper reading, and cross-paper synthesis over a curated metallurgy index of about 300k papers. Its workflow is split into a Retrieval Skill and a Reporting Skill. The retrieval stage rewrites requests into English search intents while preserving materials entities, validates snippet-level evidence against the requested materials context, and performs bounded reformulation when evidence is insufficient. The reporting stage performs document-level reading on selected papers, generates structured reports, validates them against a schema, and produces outputs such as HTML reports. On a benchmark of 40 metallurgical questions—20 deep analytical and 20 general—AlphaAgent scored 4.66 on deep analytical questions and 4.46 on general questions, compared with 2.67 and 2.58 for a single-pass RAG baseline, and roughly 4.0-level scores for general models such as GPT-5.5 and Kimi-K2.6 (Kang et al., 13 May 2026).
The second case study is an ultra-large hexa-high-entropy alloy descriptor database service. The database covers six-component HEAs drawn from 15 elements, yielding 5,005 unique elemental combinations and about candidate compositions, each with a 194-dimensional descriptor vector, for a total size of about 17.4 TB. Instead of allowing raw downloads, the HEA-Executor provides structured near-data services through a local pipeline coordinated by a “hea-master” agent with three sub-agents: hea-dba for DuckDB/Parquet querying with permutation-invariant composition matching, hea-ml-expert for scikit-learn modeling with K-fold cross-validation and fixed random seed, and hea-writer for report generation. In an example task on room-temperature plasticity optimization for MoNbTaW refractory HEAs, the system narrowed the global space to 55 MoNbTaW-containing combinations and identified Al–Mo–Nb–Ta–W–Hf as the optimal ductile system, with 9.80% highly ductile configurations, a 10.7× improvement over the Mo–Ti–Nb–Ta–W–Hf baseline. The returned artifact size was about 2.3 MB, the reduction relative to the 17.4 TB source was roughly seven orders of magnitude, and task orchestration overhead at the server was about 550 ms (Kang et al., 13 May 2026).
5. Position within the broader AaaS and cloud-systems lineage
The term “AaaS” predates OpenAaaS and has been used for several distinct service abstractions. In cloud reliability research, “Availability as a Service” was introduced as an auxiliary cloud-management mechanism providing runtime availability analysis, such as root-cause analysis, health monitoring, and failure prediction, through the EagleEye prototype (Chen et al., 2015). In software-defined infrastructure, “AI-aaS” framed MAPE-K loops as services spanning monitoring, analysis, policy, execution, and knowledge, with distinct training and operational planes and an ML/MKL sandbox for coherent multi-loop operation (Parsaeefard et al., 2019). Open-source on-premise AIaaS for small and medium setups likewise emphasized Kubernetes-based infrastructure automation, MLOps tooling, full control over data and platform, and avoidance of third-party dependence or vendor lock-in (Fortuna et al., 2022).
Within agent systems more specifically, “Agent-as-a-Service based on Agent Network” proposed a service-oriented multi-agent paradigm grounded in the Role-Goal-Process-Service standard. That framework models agents and agent groups as network vertices, uses HARD, SOFT, and EXT routes for collaboration, and employs a Service Scheduler with an Execution Graph for long-horizon coordination; it was validated on mathematical reasoning and application-level code generation tasks and released a dataset of 10,000 long-horizon multi-agent workflows (Zhu et al., 13 May 2025). OpenAaaS is closely adjacent to that line of work, but its distinguishing emphasis is cross-organizational, data-sovereign, near-data execution in scientific research environments (Kang et al., 13 May 2026).
At the infrastructure layer, OpenAaaS also resembles broader open, multi-tenant cloud-control patterns. EdgeNet’s native multitenant CaaS framework, for example, demonstrated how an open-source Kubernetes extension stack can expose shared control-plane services with hierarchical tenancy, quotas, slicing, and federation across cloud and edge environments (Senel et al., 2023). This suggests a useful distinction: OpenAaaS is not itself a multitenant container substrate, but it can be understood as a higher-level agentic service layer that presupposes similar concerns—registration, isolation, capability discovery, and federation—while moving the abstraction boundary from containers or models to organized agent collectives.
6. Misconceptions, limitations, and projected development
Several misconceptions are explicitly ruled out by the design and evaluation. OpenAaaS is not a centralized materials platform, because it does not require raw-data aggregation. It is not merely an MCP ecosystem, because MCP standardizes tool invocation and data exchange but does not define multi-agent collaboration across institutions. It is also not a fully autonomous peer collective: the current framework assumes a human-configured Master Agent that orchestrates subordinate services rather than a decentralized, supervisor-free agent society (Kang et al., 13 May 2026).
The present implementation also has clear limits. Network-scale evaluation has been performed with tens of nodes, not thousands, and the current server relies on SQLite, which the authors identify as a potential scaling bottleneck. Service discovery is tag-based rather than embedding-based. There is no built-in mechanism to guarantee that services are accurate, current, or faithful to their descriptions. The framework does not automatically solve supply-chain attacks on Docker images, side-channel attacks on shared hardware, or prompt-injection and tool-misuse problems in LLM-based agents; such issues are left to operational safeguards such as image signing, hardware isolation, and input sanitization (Kang et al., 13 May 2026).
The future directions are correspondingly ambitious. The authors identify autonomous design loops in which Master Agents generate hypotheses, design experiments or simulations, and iterate on outcomes; cross-scale integration linking DFT, MD, continuum models, and experimental characterization through distributed agents; and “verifiable agent collectives” incorporating formal verification and blockchain-based attestation for high-stakes domains such as aerospace, nuclear, and biomedical materials certification (Kang et al., 13 May 2026). A plausible implication is that OpenAaaS is intended less as a fixed application framework than as a substrate for scientific coordination under institutional fragmentation, where the decisive abstraction is neither a file, nor a model endpoint, nor a workflow DAG alone, but a data-sovereign network of specialized agent services.