IOWarp

The question

Scientific computing spent decades getting better at moving bytes. The newer problem is deciding which bytes, which metadata, which tools, which history, and which constraints matter right now, especially once software agents take part in the workflow.

IOWarp is our attempt to make that tractable. I think of it as a context layer for scientific work: a runtime and a set of tools that can move data across storage tiers, preserve useful state, connect capabilities, and keep the boundary between automation and human approval explicit.

The architecture

Three layers, described in the documentation:

1. The IOWarp runtime, Chimaera, a distributed task-execution framework with the Context Transfer Engine for multi-tier buffering and placement and the Context Assimilation Engine for reshaping data across formats and domains.
2. CLIO Kit, MCP servers with well over a hundred tools for scientific computing.
3. CLIO Agent, the orchestration intelligence that coordinates agents with scientific workflows.

The Context Transfer Engine is the direct descendant of Hermes. The idea that a request should carry its intent comes from LABIOS. IOWarp is where those lineages meet the agent problem.

IOWarp and CLIO

People ask which name is which. IOWarp is the platform and the award: the runtime, the engines, and the collaboration among Illinois Tech’s Gnosis Research Center, The HDF Group, and the University of Utah. The award is led by Xian-He Sun as principal investigator; I am one of the co-PIs and the architect.

CLIO is the brand and architecture I lead on top of IOWarp: Context Layer for Input/Output. It is the agent-facing ecosystem, from the tiered context store to the coding agent. Through IOWarp, I am CLIO’s overall PI and architect, my team builds its components, and I personally build Clio Coder. If you want to run something today, start with CLIO; if you want to understand the data-systems foundations, start here.

What has shipped

Public code and documentation now cover the runtime, tool integration, agent interaction, remote execution, deployment, and supporting utilities. CLIO Core v2.2.1 and CLIO Kit v2.10.5 are two concrete release boundaries; the agent-facing components have their own maturity levels, which the CLIO story lists component by component. The release trail matters to me because it shows whether an architectural idea survives packaging, installation, versioning, and other people’s machines.

I am especially interested in the unglamorous seams: configuration, provenance, error boundaries, local-first operation, and the receipt a person can inspect afterwards. Those seams decide whether an agentic workflow is a useful instrument or an impressive-looking source of uncertainty.

My part, and the team around it

My role is architectural and organizational: framing the context problem, connecting it to the data-systems work that came before, defining the component boundaries, and building the team and release practices that let the idea become software. The implementation is collective. GRC researchers, collaborators at The HDF Group and the University of Utah, students, and open-source contributors shape what the platform can honestly claim. Their names are on the component repositories and in the CLIO story.

The complete institutional project record lives at GRC. This page is my account of the choices behind the system.

The current boundary

IOWarp is research infrastructure under active development, and its components do not all have the same readiness. Releases and documented behavior are evidence; architecture diagrams and roadmaps are plans. I keep this story tied to things you can install and will label planned capability as plan.

What I am asking next

• What is the smallest context contract that stays useful across scientific domains?
• Which provenance must be captured at runtime, and which can be reconstructed later?
• How do we make an agent’s authority legible before it acts, not only after something goes wrong?
• Can the same infrastructure feel natural to a scientist, a systems developer, and an automated tool?