A new offering from CoreWeave offers to embed its data engineers within customer teams to build and deploy Physical AI using their proprietary data, while the customer retain control of data and models.
CoreWeave engineers that come from automotive, aerospace and mechanical engineering work alongside a customer’s own team, building models from data the customer already owns, like test bench results, simulation output, production sensors and live telemetry. Each model is validated against the real physics of the customer’s systems until it holds up in practice.
Physical AI Field Engineering, looks to build, validate and deploy AI across the full engineering lifecycle, from research and development through in-field operations. Built on the team and methods CoreWeave acquired with Monolith AI, the service runs on CoreWeave’s own platform and integrated engineering AI solution.
For the Aston Martin Aramco Formula One Team, CoreWeave engineers were embedded on site during live race weekends and built a transcription model that reached production accuracy after being trained on 7 hours of hand-annotated race audio and refined across 75 iterations.
The platform now processes 40 radio channels at once, fast enough to answer a tyre strategy question inside a pit window that closes in under 30 seconds.
Coreweave explains that this work demands rare expertise: engineers that understand combustion dynamics or aerospace loads and can also build and validate a machine learning model.
For AI-native teams, the gap runs the other way: the modeling expertise is there, but the physics of the systems those models are meant to serve is not.
Thework runs on CoreWeave’s integrated engineering AI solution, spanning Weights & Biases for experiment tracking and model management, Marimo for data exploration, and CoreWeave Aria for driving continuous model and agent improvement, paired with domain libraries purpose-built for anomaly detection, test reduction and system optimisation. It’s the same environment behind every engagement, not a one-off build each time.
“Engineering teams don’t adopt a new method because a vendor proved it once in a demo. They adopt it once they’ve seen it hold up on their own systems,” said Richard Ahlfeld, senior VP of Physical AI at CoreWeave.
“That is why we send engineers who speak the same language as the team across the table, and why we build on the customer’s own data instead of handing back a report the customer still has to implement. The infrastructure is ours, the engineering AI stack is ours, and the engineers are ours.”
CoreWeave describes its Physical AI Field Engineering engagements as beginning with a ‘scoping workshop’ on-site with a customer’s team to map their engineering workflows, biggest pain points and to align on priorities and a realistic timeline before any model is built.
They prototype the solution end to end alongside the customer’s team, and remain involved until it’s running in production, not just a demo, across four areas:
- Strategy: Identifies which problems are actually worth solving with AI, and which data is worth building on.
- Simulation infrastructure: Stands up the GPU, storage, and simulation stack a specific use case needs. For full infrastructure design and scale beyond that, field engineers connect customers into CoreWeave’s broader physical AI platform.
- Real-world data: Turns scattered test, sensor, and production data into a model that predicts an outcome, catches an anomaly, or explains a failure, instead of leaving that signal buried and unused.
- Agentic learning: Turns what a model finds into something that changes the physical world – a system recalibrated to run better, a fault caught and corrected before it becomes a failure, or a robot executing a trained skill a customer’s team built and deployed.
Engagements deliver working applications, optimisers, and dashboards deployed directly into existing workflows, not a static report someone else has to build out.
A customer’s own engineers help define the problem and watch the model get built, so once it’s deployed, they’re the ones operating it, making changes, and retraining it as needed, not calling CoreWeave to do it for them.
