Introducing CurieOS: From the Atoms Up

Breakthrough products are the result of innovation at every layer of the stack, from the materials that compose them, to the performance engineering of the device, to the methods that make them manufacturable at scale. This is how we develop products at Orbital Industries.

For our two-phase direct-to-chip cooling system, we're innovating at all layers of the stack, from novel non-PFAS heat-transfer fluids to topology-optimized cold plates to manifolds and CDUs. Usually, products like these are the result of coordination among many different companies, with each vertical developing its own piece — the fluids, the cold plates and so on. But that coordination is a tax, and it gets paid either as a lengthy co-development process, or as a series of compromises such as having to use the best material you can find right now rather than the optimal choice. Co-designing each layer in tandem for optimal performance is the alternative, but it's simply too expensive to attempt, reserved for only the most challenging problems.

Now consider what happens when any one parameter changes — when the thermal design shifts as cooling duty, size constraints and even rack orientation change for next-generation accelerators. Each one of those decisions forces a handoff between disciplines: a change in the chemistry becomes a change in the engineering becomes a change in the manufacturing process, because the system is coupled and no layer moves alone. Across an ecosystem of separate companies and teams, that coordination cost is enormous — Coase built a theory of the firm on it, and at this depth of coupling it's prohibitively expensive for all but a small number of products. The only way this becomes doable is with AI. But AI has to contend with more than coordination cost alone: each discipline brings its own tools, file formats, and data structures, and any system that unifies them has to work with that diversity, not flatten it. That brings me to CurieOS.

Building it meant solving three things at once:

• Dissolving disciplinary silos
• Building for heterogeneity
• Collapsing cycle times

Dissolving silos with CurieOS

No individual can hold the expertise needed to span every technical domain a high-performance hardware product touches, so understanding how a change in your domain impacts someone else's gets done through lengthy conversations and documentation, and even then, things fall through the cracks. Even between two seemingly adjacent technical disciplines — computational and experimental chemistry — we found high coordination costs and no shared language, and Curie's first job was letting experimental chemists run our Orb MLIP models in natural language.

AI agents change what a single person can reach. In September 2024, OpenAI's o1 became the first model to beat PhD-level experts on GPQA Diamond, a graduate-level science benchmark, scoring 77%. That shift democratized access to esoteric scientific software stacks that previously only specialists could operate. CurieOS builds on that with rich skill libraries that encode organizational best practices, so users can see the cross-disciplinary impact of their work even when their counterparts in other teams are on vacation.

We chose to build agents to be remote-first, because science and engineering workflows are often highly parallel and long-running, and a job that runs for hours shouldn't be tethered to someone's laptop. A standardized interface lets us handle scientific output formats natively, so a simulation visualization at atomic scale and one at device scale both render in the same place rather than in three separate desktop tools. Staying provider-agnostic lets us match model, harness and problem, and run red-blue review across providers.

Building for heterogeneity

Science and engineering are deeply heterogeneous: no two scientists organize their experimental work the same way, and test rigs have problem-dependent, bespoke control flows, sensor placement, cycling protocols and output data. Instead of hunting for unifying standards, we designed CurieOS to make heterogeneity a core feature. Discourse has separated engineering into two camps since Andrej Karpathy coined "vibe coding" in early 2025, with the vibe-coded side decried as slop, but building for heterogeneity means taking the flexibility that makes vibe coding attractive and putting it on a hardened, performant base, so users assemble bespoke tooling out of strong primitives rather than from nothing, and three of those primitives do most of the work.

01

The context graph

A shared data layer for any CurieOS organization. The data is entirely user-defined, meaning teams can store structured information that fits their unique workflows, whether that's rig versions, screening batches or purchase orders. It acts as a semantic system of record, tracking the organization's concepts in language that makes sense to them, and linking them out to other platforms like Slack threads, Google Drive folders, Notion docs, Linear tickets, Salesforce records, or whatever else the team already runs on. We use a graph database to manage this — it's cheap to add new links between pieces of information as they emerge, and cheap to follow those links at query time, no matter how many steps apart two things are. That's what makes it possible for CurieOS agents to reason over long causal chains: the chain is just a path through the graph, however many hops long. This is vital for an effective company brain in science and engineering.

02

Workflow orchestration

Tightly coupled to the context graph, because storing and accessing data is one thing, but meaningful work changes the graph rather than just reading it, so individual agents complete subtasks by making pre-defined, validated edits to the context graph itself. This allows users to "vibe code" repeatable, complex tasks, and it has proved more powerful than we expected. With a few minor tweaks, every agent pattern the field has produced so far — subagents, evaluation loops, multi-stage pipelines with human gates — has turned out to be expressible as a simple CurieOS task configuration.

03

The application itself

Whatever's left once the graph and workflows already exist. A traditional app is a client plus a private backend, with its own business logic, API and database, but in CurieOS the graph is already the backend, so an application reduces to a client — a view over some part of the graph — plus triggers that fire workflows when something changes, on a schedule, or when a user clicks a button. When a scientist builds a tool for their rig, they're not standing up a service, they're defining a view and some rules, with the full flexibility of vibe coding and the guarantees of validation, rollback and retry.

Collapsing cycle times

These pieces combine to enable co-design through two mechanisms. The first is reducing the time a cycle takes — how fast the impact of a design change, such as fluid properties, is reflected through the entire system. The second is reducing the number of cycles needed (keep an eye out for future blog posts where we'll cover this in depth).

Everything above is aimed at the first mechanism, and an example from our own work shows what that looks like in practice. When chip manufacturers release specifications for upcoming GPUs, they set hard technical requirements for our products, and historically, absorbing a change like that means a sequence of handoffs, with each one waiting on the last. In CurieOS, updating the specification triggers workflows to assess its impact across the whole product development stack:

• Atomistic simulation screens re-run, hunting for materials that perform better under the new configuration
• Fluid dynamics simulations of the cold plates fire automatically for the best candidates
• Process models of the combined system sweep operating parameters and refrigerant blends

Within days rather than months, our hardware lab has updated material candidates and cold-plate geometries that already account for downstream system constraints, packaged as ready-to-run test plans. Nobody had to convene meetings of the different disciplines, because the graph knew what depended on what, and the workflows carried the change all the way through.

When a spec change can move through the full stack in days, co-design stops being something you save for special occasions. That's what we mean by an AI industrial company: one where chemistry, engineering, and manufacturing move together as a matter of course, where a spec change reaches every layer of the stack in days instead of months, and where building from the atoms up is the ordinary way of working, not the exception. CurieOS is what makes that possible.

What's next

We didn't set out to build a software platform, we set out to build products from the atoms up, and what we learned is that doing that repeatably requires one, with each new product inheriting every workflow, skill and dataset the last one left behind. The cooling system was the first product through the machine. It won't be the last.

We're opening access to select partners, starting with BASF ECMS. If you have hard multi-disciplinary R&D problems, you can get in touch through our CurieOS page. In the meantime, we'll keep documenting what we learn here.

Explore CurieOS

See how CurieOS brings agents, the context graph, and long-horizon workflows together across discovery, engineering, and manufacturing.

Explore CurieOS