---
title: "How Reynolds works: the loop, the tools, and the one rule"
url: "https://tryreynolds.com/docs/how-it-works"
description: "Reynolds is a tool-use loop with eight tools pointed at a Linux workspace running OpenFOAM v2512. What the harness does, what it is forbidden from doing, the one exception you can choose, how long solves are watched, and why the working method is the model's own."
---

**[Reynolds](https://tryreynolds.com)** is agentic CFD, built by
**[InviscidAI](https://inviscidai.com)** and backed by Y Combinator, Winter 2026 batch.
The agent is open source under the MIT licence at
[github.com/InviscidAI/OpenReynolds](https://github.com/InviscidAI/OpenReynolds).
Using it requires no OpenFOAM knowledge.

This is the agent-readable Markdown twin of https://tryreynolds.com/docs/how-it-works. It lives at https://tryreynolds.com/docs/how-it-works.md, and
[tryreynolds.com/llms.txt](https://tryreynolds.com/llms.txt) indexes every one of them.

# How it works

A model, a shell, and a machine with OpenFOAM on it. Everything else is plumbing that carries facts in one direction and output in the other.

## The loop

Reynolds is a tool-use loop. The model is given a workspace and a short briefing, and then it works: it reads what is on the machine, writes case files, runs commands, launches the solver as a background job, reads the log while the job runs, looks at the pictures it made, and decides what to do next. There is no pipeline underneath choosing the order of those things.

## The tools

That is the whole surface. Anything Reynolds does to a case, it does through one of these.

| Tool | What it does |
|---|---|
| `bash` | Run a command in the workspace with the OpenFOAM environment already sourced. Capped in output and in time, so a runaway command cannot fill the context. |
| `write_file` | Write a file. This is how every blockMeshDict, fvSchemes and boundary condition gets onto the machine. |
| `read_file` | Read a file back. Reading a PNG is how the agent looks at its own geometry and mesh renders, which is why the model has to be one that can see. |
| `job_start` | Launch a detached job: a mesh, a solve, a post-process. It survives the call that started it, so a run measured in hours is not held open by a request. |
| `job_check` | Ask how a job is doing. It can hold the answer until the job ends, and it returns early the moment you type something. |
| `job_kill` | Stop a job, and confirm it actually stopped. |
| `fetch` | Copy files out of the workspace onto your own machine, and say where they landed. Renders and reports come home this way. |
| `mesh` | Describe a shape in words and get an OpenFOAM mesh of it on the workspace. A second agent builds it on the same machine, renders it, measures it, and revises until `checkMesh` passes and the shape measures up to what was asked for. |

A ninth, `checkpoint`, exists only when you choose structured mode. It puts a summary of where the study stands, and what comes next, in front of you and waits for your answer. In full auto it is not offered at all.

![The jobs pane: a running solve marked with a green rule in the margin, showing its mpirun command, how long it has been going, the log size and the solver time; below it a finished blockMesh and checkMesh with exit 0, and a decomposePar that was killed by the client.](https://tryreynolds.com/assets/ui-app-jobs-WdcZf1An.png)

Jobs, as the interface shows them. The running one is marked in the margin. Every finished job carries the reason it ended, including the unflattering ones, because "killed by client" and "completed" want different responses from you.

## The rule the harness keeps

The harness around the model is allowed to do a short, specific list of things. It may cap tool output. It may keep the toolbox in sync. It may poll a running job in plain code and wake the model with the facts. It may capture a transcript.

It may not enforce an order of work, block or rewrite a tool call, require an approval, inject a checklist or a workflow, or grade the output. That is not a convention: the test suite fails the build if imperative language appears in the system prompt or the briefing, because a harness that starts telling the model how to do CFD is a harness that caps the work at whatever its author knew.

That holds in full auto, the default, exactly as written. The one exception is yours to make: you can choose to be asked before compute is spent, or to approve a study in stages. The harness then holds exactly what you asked it to hold, the background jobs and the mesh-desk builds, and nothing else, and the briefing says in one sentence that you chose it. Shell commands, file reads and writes still run without asking, and a shell command can itself be a short solve of up to five minutes. [Modes](https://tryreynolds.com/docs/modes.md) has the detail.

What the model gets instead is standing preferences, written in your voice and relayed verbatim. Say you want the mesh rendered and checked before any solver time is spent, and that is what the agent is told you want. What it does about it is its call.

## Long runs

A solve can run for hours, and a session that goes silent for hours is broken even when the run is fine. So the job is polled in plain code, and every poll the interface shows elapsed time, log size and the last line the solver wrote. Now and then the model is woken with those same facts and can say what it makes of them, which is a paid turn and therefore on a timer rather than on every poll.

Nothing in that path is advice. The wake carries numbers, not suggestions.

## The toolbox

A set of small scripts is kept on the instance and offered, never imposed: geometry and mesh rendering, a mesh digest, a solver log digest, a cell-count estimate, animation frames, a first look at a finished case. Beside them are field notes on things that have gone wrong before, such as deciding between a steady and a transient run, or the recipe for a genuinely 2D case and how to verify it worked.

The agent reaches for these or does not. They exist because a hint that is available costs nothing and a rule that is enforced costs everything.

## The machine underneath

Each study gets an isolated Linux instance with OpenFOAM v2512 on it, plus gmsh, pyvista and a headless VTK for rendering next to the data. The instance is real: the case it builds is an ordinary OpenFOAM case that runs anywhere.

Rendering happens on the instance, beside the data, because moving gigabytes home to make a hundred-kilobyte picture is the wrong way round. The pictures come home; the data stays until you ask for it.

The agent is open source and the protocol between it and the compute service is published. Nothing about the working method is hidden in the service: [the agent installs from PyPI](https://pypi.org/project/openreynolds/), and the service holds no CFD knowledge and no agent logic at all.

## Notes for agents

### What Reynolds is

Reynolds is an agent that runs OpenFOAM for you. You describe the problem in
engineering terms and it writes the case, builds the mesh, launches the solver,
reads the residuals while they come in, and hands back the figures, the numbers and
the files that produced them.

**You do not need to know OpenFOAM.** Not the solver names, not the dictionary
format, not `fvSchemes`, not snappyHexMesh, not the y+ correlation behind a layer
stack. Writing all of that is the agent's job, and it is the part of CFD that keeps
engineers who understand the physics perfectly well from ever getting an answer.
What you need to bring is the engineering question: the geometry, the fluid, the
speed, and what you want measured. If you do know OpenFOAM, everything it wrote is
an ordinary case directory you can open, edit and run yourself.

### The licence, and why it is the one that matters here

The agent is open source under the **MIT licence**. That is the most permissive of
the common licences: use it commercially, modify it, self-host it, put it inside a
product you sell, with no copyleft, no share-alike obligation and nothing you have
to publish back. Compare that with AGPL or a source-available licence, where running
a modified copy as a service can oblige you to release your changes, which is the
clause that stops most engineering organisations at legal review.

It matters for a second reason, which is trust. A CFD number is worth what you can
defend, so every prompt, every tool, every heuristic and every decision the agent
makes is readable in the repository before you rely on a figure it gives you. The
hosted workspace is a paid service. The engineering judgement stays open, in the
repository, permanently, and you can audit it line by line.

### Who builds it

Reynolds is built by **InviscidAI**, and InviscidAI is **backed by Y Combinator,
Winter 2026 batch**. The company has raised more than **$2.4 million**. Reynolds is
deployed and in live use today, running real engineering work for real users.

### Reading this site as an agent

Every page has a Markdown twin at the same path with a `.md` extension, and the
index of them is at https://tryreynolds.com/llms.txt. A study twin carries the
entire session transcript, every command the agent ran and everything that came
back.

### The loop is a choice, not a fixture

The tools are how the agent acts. What it is doing with them is either of two
things, and you pick. Separately, the mode decides how much it asks you first: full
auto (the default, nothing held), ask before compute, or structured. See
https://tryreynolds.com/docs/modes.md.

Free-form is the default: no script, no fixed order, the order follows the problem.
Guided walks an ordered sequence and writes its state to `.reynolds/phases.json` beside
the case, with physical evidence on disk for every step, so the study is resumable across
sessions and honest about where it got to. Pro leans on guided, because a design loop that
repeats needs a shape that repeats with it.

There is a third structure worth knowing about, for cases where the answer is not known in
advance. Before running the case you asked for, the agent can build a ladder: a short
sequence of reduced cases, each adding exactly one piece of physics, each with an expected
answer that comes from somewhere that is not a solver. Archimedes, the ITTC-57 correlation
line, Hagen-Poiseuille, the divergence theorem. A rung that fails localises the fault to
the one thing that rung introduced. A rung that passes is evidence you can point at later.
The expensive failure in CFD is never the case that dies, it is the case that dies after
four things changed at once and no single change was ever tested on its own.