Documentation

Understanding CLIO

A plain-language guide to what CLIO is, who it's for, and how it works: so you can tell whether it fits your science before you install a thing.

What CLIO is

CLIO is an autonomous AI agent for scientific data. It runs locally: on your own models and your own data: so there's no cloud lock-in and nothing leaves your machine unless you decide it should. You point it at a question and your datasets, and it plans the work, picks the right tools, and carries it through.

CLIO is the intelligence layer of the IOWarp platform: the part that reasons about your data, while the rest of IOWarp handles moving and managing it.

Who it's for

CLIO is built for scientists, researchers, and data engineers who want an agent that actually operates on their datasets: HDF5, Parquet, CSV, and domain-specific formats: rather than just chatting about them.

You choose the model. Run a local model through LM Studio or Ollama to keep everything on your hardware, or connect a hosted model if that's what you prefer. CLIO works the same either way.

How it works

CLIO uses a three-tier design, each tier with a clear job:

• A main orchestrator reads your request, plans the approach, and routes work to the right place. It doesn't do the detailed work itself: it decides what should happen next.
• Domain experts each own one focused job: data acquisition, analysis, visualization, and so on: and each carries a small, curated set of tools suited to that job. Keeping each expert's toolset tight is what keeps its decisions sharp.
• Nanoagents are ephemeral helpers that fan out parallel sub-tasks when a step splits into many similar pieces, then disappear once they're done.

State lives in a local-first memory layer called ARC that every tier can read and write, so results and context flow between steps instead of getting lost. Tools reach the agent through an MCP tool gateway (built on FastMCP): HDF5 and Parquet inspection plus domain-specific servers.

One thing worth calling out: routing is agent-driven. The model itself decides the next step and hands off through a structured contract: the path isn't hardcoded into CLIO. That's what lets CLIO adapt to new questions and new domains instead of only handling the ones someone wired up in advance.

Blueprints

Blueprints are the heart of CLIO. A blueprint is a shareable agent package: a root orchestrator, the child experts under it, and the curated MCP tools and servers those experts need: all declaring how to solve a whole class of tasks, not just one.

You install blueprints from the marketplace and switch between them per session. Want to work on a different kind of problem? Load a different blueprint. Built something useful? Package it up and share it the same way.

A blueprint in action: EarthScope GNSS

Here's what a blueprint feels like to use. Suppose you ask, in plain language, about GNSS stations near a particular place. CLIO:

• geocodes the location you named into coordinates,
• discovers the relevant EarthScope / NDP datasets for that area,
• stages the station time-series data as CSV,
• profiles it to understand what's actually there, and
• plots the east, north, and up displacement.

Each step is grounded in real data, with the orchestrator delegating to whichever expert owns that step. And it's a conversation, not a one-shot: you can refine the plot, switch to a different region, or build on results from earlier in the session, and CLIO carries that context forward across follow-ups.

The interfaces

It's the same backend behind three front-ends, so you can pick whatever suits the moment:

• the terminal TUI, with clio,
• the web UI, with clio --web or the Docker image, and
• the native desktop app.

There's also a headless API for automation and scale-out, when you'd rather drive CLIO from a script or a larger pipeline than sit in front of it.

Status & links

CLIO is beta software: interfaces, blueprints, and on-disk formats may still change between releases. It's open source under BSD-3-Clause, and contributions are welcome.