Claude Code, Codex, or Gemini Can Suggest a Pump — But Never Skip These 5 Fluidic Checks

AI coding agents are becoming useful engineering assistants. Claude Code, Codex, and Gemini can read specifications, normalize tables, generate calculation scripts, and prepare comparison matrices much faster than a manual copy-and-paste workflow.

But a language model should not be the final authority for a microfluidic design.

If an agent confuses mL/min with μL/min, treats a free-flow pump rating as the actual operating point, or invents a missing material-compatibility value, the output can look convincing while being physically wrong.

The safer pattern is simple:

Let the LLM propose. Let deterministic code validate. Let an engineer approve.

The five-layer workflow

1. Convert the request into an explicit engineering schema

Do not start with: “Choose a pump for my analyzer.” Start with structured requirements that make missing data visible.

{
  "application": "automated reagent dispensing",
  "fluid": "aqueous buffer",
  "temperature_c": 23,
  "target_flow_ml_min": 12,
  "tubing_id_mm": 0.8,
  "tubing_length_mm": 650,
  "max_pressure_kpa": 80,
  "wetted_materials": ["PTFE", "PEEK"],
  "control": "PWM",
  "missing_fields": ["target_lifetime_cycles"]
}

An agent may help extract these fields from a requirements document, but it must not silently fill missing_fields with guesses.

2. Retrieve candidates, not conclusions

The retrieval layer should return candidate components and the evidence behind each field:

• source datasheet and revision;
• rated flow and the test conditions;
• pressure range;
• wetted materials;
• connector geometry;
• control interface;
• temperature and lifetime limits.

Every number needs provenance. “The model remembers this value” is not provenance.

3. Run deterministic unit and range checks

Before any physics calculation, reject inconsistent units, nonphysical values, and missing constraints.

from dataclasses import dataclass

@dataclass
class FluidPathInput:
    flow_ml_min: float
    tube_id_mm: float
    tube_length_mm: float
    viscosity_pa_s: float
    max_pressure_kpa: float

def validate(x: FluidPathInput) -> list[str]:
    errors = []
    if not 0 < x.flow_ml_min <= 10_000:
        errors.append("flow is outside the configured engineering range")
    if not 0.05 <= x.tube_id_mm <= 20:
        errors.append("tube ID is missing or implausible")
    if x.tube_length_mm <= 0:
        errors.append("tube length must be positive")
    if x.viscosity_pa_s <= 0:
        errors.append("dynamic viscosity must be positive")
    if x.max_pressure_kpa <= 0:
        errors.append("pressure limit must be positive")
    return errors

These ranges are project configuration, not universal laws. The important point is that they are explicit, testable, version-controlled, and independent of the model’s prose.

4. Call a physics calculator as a tool

The agent should pass validated inputs to a deterministic calculator rather than estimate pressure loss in free-form text.

For laminar flow in a straight circular tube, the Hagen–Poiseuille relationship highlights an important sensitivity:

ΔP = 128 μ L Q / (π d⁴)

Because pressure drop scales with the inverse fourth power of internal diameter, changing a tube ID from 1.0 mm to 0.5 mm can increase the theoretical straight-tube pressure drop by 16× when the other variables are unchanged.

Real fluid paths also contain valves, fittings, bends, filters, probes, entrances, contractions, and possibly non-Newtonian fluids. The model must preserve those limitations instead of presenting one equation as a complete system model.

For a practical check, the FOREACH Fluid Resistance Calculator supports known-flow or known-pressure-drop modes, fluid properties, tube segments, local resistance, and Cv-based elements. It is useful for early engineering estimates—not a replacement for bench validation.

5. Require human approval before execution

The final report should separate facts, calculations, assumptions, and unresolved questions:

PASS  Units are consistent
PASS  Candidate pressure rating exceeds calculated steady-state loss
WARN  Startup pressure spike was not modeled
WARN  Material compatibility requires supplier confirmation
FAIL  Target lifetime is missing

Only after an engineer resolves every FAIL and accepts each documented WARN should the design proceed to procurement, prototype testing, or device control.

What AI agents are genuinely good at here

Used with these guardrails, AI tools can provide real leverage:

• extract parameters from multiple datasheets;
• normalize naming and units;
• generate test matrices and Python notebooks;
• identify missing requirements;
• compare calculated results with logged bench data;
• draft a traceable engineering summary;
• prepare regression tests when the fluid path changes.

They are much less reliable as an unreviewed source of product limits, chemical compatibility, safety decisions, or “best component” claims.

A useful rule for engineering agents

Do not ask whether an AI agent can select a pump or valve. Ask whether the workflow can prove where every requirement, value, calculation, and approval came from.

That shift—from autonomous-sounding answers to traceable engineering evidence—is what makes an AI-assisted fluidic workflow useful.

---

Disclosure: I work with FOREACH, which develops microfluidic pumps, valves, sensors, tubing, fittings, and related components. The linked calculator is a free engineering resource from our website. Product selection and final operating limits should always be verified against the relevant datasheet and physical tests.