中文 | English

OpenAaaS — Open Us to the Agentic World

Website · Paper · Server Docs · Agent Core Docs · Usage Guide · Client Extensions · Desktop Client

📝 Design Blog: Don't Move Data, Distill an Administrator.skill

---

Intelligence flows, data stays still — bring AI to the data, instead of handing data over to AI.

OpenAaaS is building a new kind of scientific infrastructure: data stays where it was created, and analytical capabilities flow through the network to reach it.

The bottleneck of AI has shifted from model capability to the accessibility of scientific capabilities, while "data being forced to migrate" is a harder constraint than models. Every lab has accumulated unique data, algorithms, and workflows, but they are scattered in silos and cannot be discovered or invoked. OpenAaaS distributes Agent capabilities to data nodes locally, enabling any Agent to discover, invoke, and compose capabilities from scientific nodes around the world — data is processed in place, while code and instructions flow through the network.

Any Agent — whether Claude Code, pi mono, Kimi Cli, or a self-built system — can discover and compose capabilities from scientific nodes across the network through the web.

At the same time, we strive to minimize the barrier to using the network, even for general-purpose LLM apps on mobile phones.

Demo Video	Screenshots
OpenAaaS-phone-long-compressed.mp4	Connect Service View Service List Service Result Returned

---

📄 Paper

Technical design and implementation details: arXiv:2605.13618

---

Four Core Propositions

Data Stays In Situ, Capabilities Flow Across Nodes

The real solution to data silos is not moving all the data into one place — it is bringing analytical capabilities to where the data lives. Every lab's accumulated datasets, algorithmic workflows, and domain expertise become composable capability units that any Agent can directly invoke. Agents need not master the full depth of a field in advance; they simply discover, orchestrate, and invoke services from nodes around the world, continuously expanding their knowledge boundaries across materials science, biomedicine, astronomy, and beyond.

Zero Data Migration, Eliminating Migration Loss

Traditional solutions demand that data be aggregated into a centralized platform — inevitably introducing format conversion distortion, metadata loss, version divergence, and broken compliance audit chains. OpenAaaS builds no unified data warehouse. Data remains at its point of origin, preserved in its original storage format, directory structure, and access permissions. Analysis tasks arrive remotely as code and instructions; results are sent back. Raw data never leaves.

Schema-Free Onboarding, Raw Format as Service Capability

We impose no upfront format requirements on data. JSON, CSV, Excel, MATLAB .mat, HDF5, vendor-specific binary formats from instruments — the local parsing and processing scripts on each node are themselves part of the network's capability. Agents invoke a combined "parse + analyze" service, rather than being required to pre-clean, standardize, or structure the data. Whatever format a lab already has, it is service-ready from day one.

Near-Data Computing, Data-Movement Cost Approaches Zero

Computation happens next to the data, not the other way around. The network only transmits task descriptions and execution results (KB–MB scale); raw data is processed on-site. For TB-scale datasets and regulated sensitive samples, this means no upload wait, no bandwidth bottleneck, and no outbound compliance review — the marginal cost of moving data approaches zero.

Core Design Philosophy

Traditional cloud solutions require data to leave the premises: TB-scale datasets must be migrated and uploaded, sensitive samples are handed to third parties, and lab firewalls are forced to open inbound ports. OpenAaaS takes the opposite approach — deploying Agent execution nodes directly where the data resides. The network only transmits task descriptions, task files, and results; raw data stays in place.

	Traditional Cloud Solution	OpenAaaS Near-Data Solution
Data Flow	Local → Cloud → Local	Raw data stays in place
Network Transfer	Raw data (TB scale)	Task descriptions, task files, and results (KB–MB scale)
Firewall Requirements	Inbound ports required	Outbound HTTP only
Sensitive Data	Must leave the domain	Never leaves the lab
Latency	Bandwidth-limited	Local compute, extremely low latency

Architecture

Client Agent
(pi mono / Claude Code / Kimi Cli / Cline / Custom Agent)
        ▲
        │ Control flow: task description, heartbeat, results (KB scale)
        ▼
───────────────────────────────────────────────────────────────────
OpenAaaS Server (Network Hub)
Rust + SQLite — Lightweight indexing layer
  • Service registration  • Task routing  • Node heartbeat  • File relay
        ▲
        │ Short polling (unidirectional outbound HTTP)
        ▼
───────────────────────────────────────────────────────────────────
Agent Core (Network Node)
Rust + Docker — Deployed locally where data resides
  • Register capabilities to the network  • Poll for tasks
  • Container sandbox isolation execution  • Report results
        │              │                   │
        ▼              ▼                   ▼
   [Local Dataset]  [Analysis Scripts]  [Specialized Hardware]
    (TB scale)      (Algorithms/Models)  (GPU/Instruments)

Layer	Component	Responsibility
Client Agent	pi mono / Kimi Cli / Codex / Open Code / Custom Agent	Understand tasks, discover network nodes, schedule remote capabilities, integrate results
Network Hub	Server — Capability registration and scheduling center (Rust + SQLite)	Service registration, task routing, node heartbeat, file relay
Network Node	agent-core — Capability execution node + Docker	Register capabilities to the network, poll for tasks, execute in sandbox isolation, report results

Design Rationale

Principle	Description	Effect
Rust + Single Binary	cargo build --release produces one executable	Zero-dependency deployment, copy and run
Embedded SQLite	Database starts with the process, no separate service	Zero operations, single node is sufficient
Docker Isolation	Each task runs in an independent container with workspace mounted	Secure and controllable, reproducible environment
Self-Organizing Nodes	Nodes actively register with the network and poll for tasks; Server only maintains an index. Raw data never leaves the domain; task files flow through the Server	Nodes need no public IP; unidirectional outbound is enough to join the network; data is processed on-site, naturally adapting to lab firewall environments

Features

Data In-Situ Retention & Cross-Node Capability Flow

• 🔌 Zero-Learning-Cost Agent Integration, Self-Describing API Auto-Exposes Service Docs — No authentication required; returns complete API documentation and usage instructions. Agents can understand and invoke all scientific services without any plugins.
• 🧩 Progressive Capability Discovery, Avoiding Context Overflow — Initial queries return lightweight summaries; detailed usage is returned on demand. A progressive disclosure design similar to SKILL.md protects the Agent's context window.

Zero Data Migration

• 🔒 Data Never Leaves the Premises — Agent execution nodes are deployed directly on lab servers or instrument workstations. Raw large datasets are processed in-place via local mounts; sensitive data never crosses the firewall. The network only transmits task descriptions, task files, and results; it never touches raw data.
• 💾 Single Binary, Zero Operations — SQLite database + local file storage; no Redis/MySQL required. A single node is enough for deployment, ideal for lab edge nodes.
• ⚖️ Nodes Join via Reverse Connection, No Public IP Needed — Nodes self-manage concurrency and task claiming; Server only does lightweight queue management. Lab nodes only need unidirectional outbound access to join; no open ports or SSH required.

Schema-Free Onboarding & Near-Data Computing

• 🐳 Independent Sandbox per Experiment, Reproducible Results — Each task runs in an isolated container with workspace mounts for input and output. Environment isolation makes results traceable and reproducible.
• 🔧 Zero-Config Node Onboarding — open-aaas-server run auto-generates config.toml, SQLite database, and keys on first launch. No manual configuration; ready to use out of the box.
• 🤖 MCP Standard Protocol Compatible — Through openaaas-mcp-adapter, any MCP-compatible client such as Claude Desktop, Cursor, or Cline can connect with one click, without writing any plugins.

Usage

Public Server: https://api.open-aaas.com

We provide three trial scientific services on the public server:

• IDM-Alpha Metal Materials Literature Research Assistant Based on Hundreds of Thousands of Real Papers
• Trillion-Scale Hexa-High-Entropy Alloy Descriptor Database
• Fuyao Multi-Agent Roundtable System

You can have your Agent connect to the public server to use them.

Quick Start

Scenario 1: Use the Public Server

No need to build your own infrastructure. Simply configure your Agent to connect to the public server and start invoking community-shared scientific services. Ideal for individual researchers to get started quickly.

Using the pi / Kimi Plugin

Just say in the conversation:

"Help me set the OpenAaaS server address to https://api.open-aaas.com, then submit a data analysis task"

The client Agent will automatically complete registration, service discovery, task submission, and result retrieval.

alpah+fuyao_compressed.mp4

Using an MCP Client

openaaas-mcp-adapter is available on PyPI. If you are using OpenClaw or any other Agent that supports MCP (Model Context Protocol), connecting to the OpenAaaS network is nearly zero-cost — no plugins to write, just one configuration entry to invoke all capabilities.

{
  "mcpServers": {
    "openaaas": {
      "command": "uvx",
      "args": ["openaaas-mcp-adapter"]
    }
  }
}

After configuring, restart the client, and you can invoke OpenAaaS's 14 standard Tools (set_server_url, register, list_services, submit_task, etc.) directly in conversation without installing any plugins.

Or better yet, you can have your Agent set it up for you directly.

See client-extension/openaaas-mcp-adapter/README.md for details.

Using the Desktop Client

If you prefer a graphical interface, use the OpenAaaS Desktop Client — a cross-platform desktop application based on Tauri, supporting macOS, Windows, and Linux.

The desktop client is ideal for:

• Non-technical users who don't want to configure command-line tools or plugins
• Managing multiple servers and browsing services visually
• Drag-and-drop file uploads and real-time task progress tracking

📖 See client-app/README.en.md for details.

macOS users: The app is ad-hoc signed. On first launch, go to System Settings → Privacy & Security → Security and click "Open Anyway".

Using a General Agent Framework

If your Agent does not have an OpenAaaS plugin, simply have it access https://api.open-aaas.com:

• No authentication required; complete API documentation and usage instructions are returned
• The Agent can then automatically complete registration, service discovery, and task submission after reading them

Scenario 2: Deploy on a Lab Server and Connect Local Capabilities

Launch OpenAaaS on a local server in your machine room or lab, and register local analysis scripts and specialized computing workflows as network nodes. Any Agent in the research group — pi, Kimi, Claude, or a self-built system — can query node status, submit analysis tasks, and retrieve result data through a unified entry point.

Local Deployment

Deploy Server (Scheduling Center):

cd server
cargo build --release
./target/release/open-aaas-server run

On first launch, config.toml and the SQLite database are auto-generated.

Deploy Agent Core (Execution Node):

cd agent-core
cargo build --release
./target/release/agent-core init
./target/release/agent-core register --token <registration_token> --name my-agent
./target/release/agent-core run

The registration_token must be obtained by creating a Service on the Server first. Admins can use the API Key from the Server logs to call POST /api/v1/services/ to create one.

The Agent executor image needs to be built in advance (under the agent-core directory):

cd executor-example && docker build -t open-aaas-executor:latest .

See agent-core/README.md for details.

Project Structure

OpenAaaS/
├── server/           # Network Hub (Scheduling Center) (Rust) — Task scheduling, queuing, auth, file relay
├── agent-core/       # Network Node (Execution Node) (Rust) — Registration, polling, Docker-isolated execution
├── client-app/       # Desktop Client (Tauri + Vue 3) — Service marketplace, task submission, result viewing
├── dash/             # Debug and admin tools (Python/Streamlit)
└── client-extension/ # Client extensions — pi plugin, Kimi plugin, MCP adapter (Claude Desktop / Cursor / Cline)

Research Vision

OpenAaaS's vision is to make every lab a composable node in the Agentic Science network. Data is no longer degraded by migration, and knowledge is no longer stalled by silos. Every research group's data morphology, analysis workflows, and domain methods — however unique their storage formats may be — can be discovered, invoked, and orchestrated by any Agent across the network.

When analytical capabilities can flow to where data lives, the knowledge boundary of an Agent expands from the closed loop of a single lab to an open ecosystem of global collaboration. The marginal cost of moving data approaches zero, meaning datasets of any scale can be invoked on demand by Agents anywhere. The frontier of scientific innovation is no longer limited by a single team's data volume or domain depth.

Open Source License

MIT License © IDM Explorer Lab