Introducing CurieOS: From the Atoms Up

CurieOS is the operating system for agentic AI in science and engineering: the one we needed to power an AI industrial company that builds breakthrough hardware products from the atoms up, from materials through to manufacturing. As we announce our first public partnerships using CurieOS, starting with BASF ECMS, I want to explain why it had to exist.

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 except for the most challenging problems.

The technologies being deployed at scale in the AI build-out place some of the most demanding performance requirements on every layer, from the materials from which they are made to rack design and data-hall topology. NVIDIA famously operates at the "speed of light" and acts as a central orchestrator for the ecosystem of OEMs required to maintain a relentless GPU product roadmap. When new operational constraints are announced, the ramifications of that change cascade throughout every coupled part of the stack. Increased cooling duty, size constraints, rack topology and orientation all affect the optimal system design, with effects that span multiple disciplines: chemistry, mechanical engineering, electrical engineering. These meetings, handoffs and formal procedures are transaction costs in Coase's sense: the cost of coordinating across specialised teams and firm boundaries. The cost is high enough that co-design, meaning co-optimising the system as a whole, is often reserved only for the most performance-demanding products. At Orbital, we are showing that AI can make co-design not an expensive exception but the default way to design products. CurieOS is the tool that we built to do this.

Building it meant solving three things at once:

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

Dissolving silos with CurieOS

No individual human can possibly have the expertise to span the deep technical domains that must coordinate to bring high-performance hardware products to market. Understanding how changes in your domain impact decisions downstream takes emails, meetings and translational work, even in areas as seemingly related as computational and experimental chemistry. AI agents, however, do have this broad expertise: OpenAI's o1 exceeded PhD-level expert performance on GPQA Diamond, a benchmark of graduate-level scientific reasoning, in 2024. AI's continued progress has democratised access to esoteric scientific software stacks that previously only specialists could operate. CurieOS builds on that with rich skill libraries that encode organisational 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 standardised interface lets us handle scientific output formats natively, so a simulation visualisation 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 the model and harness to the problem, and run red-team/blue-team reviews across providers.

Building for heterogeneity

Science and engineering are deeply heterogeneous: no two scientists organise their experimental work the same way, and test rigs have problem-dependent, bespoke control flows, sensor placement, cycling protocols and output data formats. Instead of hunting for unifying standards, we designed CurieOS to make handling heterogeneity a core feature. Software engineering discourse broadly separates software into two buckets, "vibe-coding" and "professional software", with vibe-coding often used as a pejorative. Building for heterogeneity means taking the flexibility that makes vibe-coding powerful and putting it on a hardened, performant base to create software which is truly malleable. CurieOS users can then create bespoke tooling built on strong primitives, without having to worry about deployment, interoperability, access control or other important features of modern software systems. Three core primitives combine to make this possible:

01

The context graph

A shared data layer across any CurieOS organisation. The data definitions are 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 organisation'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 that weren't known at design time, 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 essential for the cross-disciplinary reasoning employed in systems design.

02

Workflow orchestration

An agent orchestration system which is tightly coupled to the context graph. CurieOS connects individual agent runs together into complex or multi-stage workflows that enable long-horizon tasks in science and engineering. Agents must complete their tasks by making a structured edit to the context graph, defined by an explicit contract and backed by strong validation guarantees. This combines the flexible intelligence of agents with the determinism of code: for example, once a literature review has surfaced a set of papers, CurieOS can guarantee that every one of them is processed, because the review creates and persists structured objects for each paper and agents are called in a loop over them. This has proved more powerful than we expected. With a few minor tweaks, every agent pattern the field has produced so far, including subagents, evaluation loops and multi-stage pipelines with human review gates, has turned out to be expressible as a simple CurieOS workflow configuration.

03

The application itself

A traditional app is a client plus a private backend, with its own database, business logic and API. In CurieOS, the context graph and its user-defined schemas form the database, workflows can apply arbitrary business logic with strong validation guarantees, and a universal API handles communication. An application is then simply 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. These are real-time, interoperable applications, perfectly suited to the job they need to get done, and shareable and forkable by colleagues. At Orbital, we have experienced a Cambrian explosion of applications which now underpin all of our core processes, from software factories and engineering PLNs to procurement systems.

Collapsing cycle times

Research and development progresses in iterative cycles of proposal, measurement and refinement. There are two mechanisms to speed this up: reducing the amount of time each cycle takes and reducing the number of cycles. Speeding up each cycle means accelerating how quickly the impact of a requirements change is reflected throughout the system. The second is reducing the number of cycles needed by learning more from each cycle and more accurately predicting the most promising steps to take. Most of what we've outlined above is aimed at cycle speed, but we are also working to reduce the number of cycles required.

Focusing on cycle acceleration, let's return to an example from our own work in GPU thermal management to see what that looks like in practice. When chip manufacturers release specifications for upcoming GPUs, they set hard technical requirements that our products must satisfy, 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. Each individual capability, from computational materials screening to calibrating hardware digital twins against device data, is built permissionlessly by the team closest to the domain. The one-time cost of mapping dependencies drastically reduces handoff costs and meeting overhead while flagging issues arising from knock-on effects far earlier.

When a spec change can propagate through the hardware development stack that much faster, co-designing technologies for maximum performance becomes a repeatable capability. AI lets companies like Orbital bring better products to market faster by optimising across a broader design space. As skills and data compound in the central graph, each new product can be developed more quickly and efficiently than the last. This compounding capability is at the heart of a new generation of AI industrial companies: firms that will build the critical technologies of the future from the atoms up, repeatably and at scale.

What's next

We didn't set out to build a software platform; we set out to build products. What we learned is that doing that repeatably requires a new type of software, malleable enough to be used by the entire multidisciplinary organisation and to enable systems design capabilities that only a shared system can provide. Building it required us to change how we think about software engineering: to move towards designing the guardrails around a system rather than the system itself. Our two-phase direct-to-chip cooling system was the first product through this platform, and there are more coming down the pipe.

We're opening access to CurieOS to select partners, starting with BASF ECMS. If you have hard multidisciplinary 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