Europe 
Türkiye 
United Kingdom 
Global 
Login with my Xometry account 
Jordan Noone, co-founder and co-CEO of Zoo, told us why he had to rebuild the geometry engine before he could build the AI, what happened when one customer’s senior analysts could not tell his agent’s design from their own engineers’, and why he thinks the plugin route into AI CAD is a dead end.
Clicking on a Screen All Day
You spent a career solving the problem of getting rockets off the ground. Engineers being engineers, you found another one. What is it?
I ran USC’s Rocket Lab, which became the first student group to fly a rocket to space, went from there to SpaceX as a propulsion engineer, and then started Relativity Space in 2015, where I was CTO for the first six years.
So I have been a CAD user, a mechanical engineering software user, my whole life. And the theme across every company I have worked at is that the mechanical engineering toolkit is quite dated. You look at software today, there is automation, there is AI everywhere now, there are these wonderfully connected tools.
Then you go to mechanical engineering and everything is you clicking on a screen all day. Automation exists, but it is fragmented. Too much of the engineering workflow still depends on manual clicking and disconnected tools. You want AI to be able to do something for you, but it cannot even use that software. It cannot talk to the data. There are these silos.
Why has CAD stayed frozen while everything else moved? What is actually underneath it?
The CAD industry has historically been dominated by a small number of players, and many of them, it surprises people, are building on top of the same computational geometry engine, an engine called Parasolid that was developed in the eighties and nineties. That engine is the core where CAD instructions get turned into an actual 3D design, doing the surface intersections, turning primitives like sketch elements and lines and extrudes into the world’s most complicated geometries.
It is a significant mathematical core and it is what gates performance. Where that engine is hosted, how you interact with it, how visible the data is to other platforms, that is what affects automation. If you cannot see the data, you cannot train an AI model. So you get these walled gardens. It is a really ridiculous setup where the world’s most valuable industries are built on top of a set of software that is used identically to how it was 40 years ago.
So the engineer hands the clicking to an agent. What do they get back, and where do they have to stay in control?
I view automation and AI as leverage. As an engineer you can now guide a team of agents to do work for you. There is monotonous work you no longer have to do, and you can go back to the creative work, the satisfying work. But these tools really need to be built for hybrid interaction. Some things the AI is better at, some things the human is better at, and that changes day to day depending on model maturity.
If the AI is making something the human cannot edit, that is a non-starter, and that has been deeply, deeply missed by, I would say, 90 percent of the companies out there. An image or mesh is not a substitute for an editable engineering model. Even a STEP export does not preserve the native parametric feature history. Engineers need to be able to continue working with the design, not just view or import the output.
Your AI is not going to be perfect and it is not going to do the entire job, but it can get you a huge amount of leverage, exploring 800 designs in parallel instead of the one you can do by hand. And that is where it is still a human-led process. I do not think the human is going away any time soon, where you just say I want a rocket and you walk away.
A Full Platform for Engineering
What does Zoo Design Studio do today?
Design Studio is the most visible part of the platform, but we make our own AI models, our own GUIs, our own compute infrastructure on the computational geometry side, and our own manufacturing platform on the toolpathing side. We are a full platform company, not just a GUI company.
Design Studio itself is a hybrid GUI where you can do mechanical design just like you would traditionally. All the sketch tools, all the feature history, all the things you would expect in a traditional CAD tool. Then we extend it with Zookeeper, our agentic workflow. With Zookeeper you can do research, you can do shopping, you can edit CAD files, you can search historic CAD data, and you can have it be your partner to work through anything you do not want to do. And you can always edit those outputs. It is not making a file that you as a human cannot change.*
*The capabilities described here span the public Design Studio, custom enterprise deployments and work still in development; availability varies by deployment.
Most AI CAD tools work by driving an existing CAD package from the outside. Why does that matter?
Some AI tools interact with CAD primarily through computer use or computer vision, rather than through structured access to the underlying design data. That adds overhead to the interaction. We have our AI directly editing the CAD data at a low level, essentially bypassing the GUI when the AI is working. That allows significantly higher performance, significantly lower cost on the backend, a more pleasant experience where the AI is thinking through design.
It is not thinking through how to use a GUI. And that matters, because the mechanical engineering audience is often betrayed by software that says it can make a CAD model. A STEP export alone does not preserve the native parametric feature history and design intent engineers need to continue the same workflow.
Some founders have said building your own CAD is unfeasible, so they build on top of existing structures. Why take the harder road?
Yes, it is the most difficult part of the stack. There is a reason geometry engines are still rooted in that original generation of Parasolid and ACIS, because it is extremely technically rigorous. This is not gaming or VR where you tessellate a geometry to load quickly and look visually accurate. You need it to be ten-thousandths of an inch accurate depending on the application, and you need it to be repeatable and deterministic.
Computational geometry is a lost art. Maybe 40 years ago it was an interesting thing for applied mathematicians. Today they end up in AI, they end up in quantitative finance, they end up in anything other than computational geometry. So building a geometry engine today is arguably harder on a talent side than it was 40 years ago, because you are competing against someone trying to invent a new kind of AI, or someone trying to make five million a year as a high-frequency trader.
Zoo started in 2021, before the current AI wave really took hold. What did you build first?
At the time we would have called ourselves an infrastructure company. We started building the world’s first headless, API accessible, GPU-based, parallelizable geometry engine. Headless means it can basically run remotely. That took those algorithms, modernizing them, implementing them on things like CUDA to run on a GPU. There are real performance benefits there, because some of them are solving unsolvable math problems. They are brute-forcing equations in order to find how two surfaces intersect. Once you have that as a headless environment you can run in parallel in a data center, that is how you train AI models to understand the geometry, not just learn how to click in a GUI better.
Did we know exactly when language models would become capable enough to be the bridge into our stack? No. But if you were going to have modern software of any kind in the hardware design world, you had to rebuild the foundational tech first. Part of why we could do that is that Jess Frazelle, my co-founder and co-CEO, and I are both extremely technical. She was the original core maintainer at Docker. So I would say of all the companies in the sector, we are the most technically deep at the top.
If all the talent is going into AI now, can you not use AI to build the thing you need?
AI is very good where you have data. On the software side, the datasets AI is trained on are scraped GitHub, scraped front-end websites. That is what AI is good at today. I would argue computational geometry is the most shielded from short-term large language model software development. You can tell a vibe-coded GUI, and that is not even in a CAD context. You want the computational geometry to be robust. You are not going to vibe-code a CAD engine into existence. The training data does not exist, and even what does exist, Parasolid and others, is written for an architecture that is 40, 50 years old, single-core CPU. AI is not good at extrapolation.
No Telling the Difference Between Zoo vs Real Engineers
What level of complexity can Zookeeper handle today?
We have two sets of variants of our AI models. The first is our publicly available model, trained on some publicly accessible CAD data. It is decent. We have a lot of users on it. Anyone can use it today. I will be the first to admit it is good where it is good and it has gaps where it has gaps. There are moments it amazes you and it is magic, and moments where it is a complete idiot. That is AI for you, and that is a data problem.
The bigger thing is fine-tuned models for enterprises. We take enterprise data, convert it into what is essentially the scripting language part of our stack, and fine-tune Zookeeper on a corpus orders of magnitude larger than anything available publicly. And especially when it comes from a singular company, that understands how they talk about features, their specifications, their memos, their tolerancing styles, the context of what they are designing and what it is mated to. At this point 80 to 85 percent of our revenue to date is from enterprise customers.
But all of that history was built in other CAD packages.
We have a significant data pipeline effort turning those incumbent CAD files into our format. It is a painful, painful part of our stack that we have had breakthroughs on. If it is just a big binary blob of ones and zeros, the AI will never understand what those ones and zeros mean with respect to a feature tree, an analysis setup, or how some feature ties back to some requirement. That is the core of what makes the AI good, and that is where it is a different game. If your AI is only good at clicking in someone else’s CAD platform, every time you train it, you are training it to click a button better.
Give me a real example of what that buys a customer.
The best example I have is an enterprise customer with over 10,000 engineers, one of the world’s most recognizable companies and a tier-one company in their field. They shared millions of CAD files, millions of production records and analysis results, all ingested into our most complicated custom implementation to date. One of the big proof points was going from system requirement to completed structural and thermal analysis of what I have to be somewhat vague about, a vehicle-level assembly. That is going from literally a text file with hundreds of requirements generated from their database.
Zookeeper took that set, generated a very complicated structural assembly, set up a structural analysis, a thermal analysis and a modal analysis, ran them, and returned them for review. We wrapped it up with a multi-week hackathon, and on the last day we ran an A/B test against a team of their own engineers working the same problem in parallel. In this particular evaluation, the two approaches converged on nearly identical designs, and the Zookeeper result used roughly one hundredth of the engineering labour for that task. And if you want to explore that design space in parallel, you spool up as many as you want. Server cost, not labour cost.
The senior analysts reviewing both could not tell the difference, because they were both satisfactory. They could not. And there were people in that room who had doubted AI could set up anything resembling a human-acceptable design.
How do you know an AI-generated result is good?
You run an analysis. You run verification. How do you know a human result is good? A human engineer designs an I-beam for a building somewhere, and you run an analysis, you check it against specification, you run it by a senior engineer. What is the AI doing? It is running by specifications, verifying results, running analyses, and then running it by the human. Same workflow, if you set it up for that deterministic work. And then you add those results to the training loop as well.
So what happens to the teams shipping AI CAD as a plugin into an existing platform?
Those shortcuts have caught up to us in some ways, especially in public appearance. But GUI automation alone does not give you the structured enterprise data pipeline needed to fine-tune on a company’s engineering knowledge. That requires deeper access to the underlying design data, requirements and analysis results. So over the next 12 to 24 months I think you see a continued divergence, where the two dozen companies that took the shortcut into an incumbent CAD platform, and the incumbent platforms doing those shortcuts themselves, hit dead ends that I think get fully realized over the next year.
Publicly available agentic CAD tools, including ours, can already help engineers, but they still have gaps. Much of the world’s engineering knowledge is proprietary and is not available in public training datasets. Combining these tools with a company’s own design history, requirements and analysis results unlocks another level of capability. The engineer remains in control.
The Front Door and the Enterprise
If the public model is the weaker one, how do you get enterprises interested in the first place?
We call the publicly available Design Studio the front door, and it has to be good enough to open that conversation. The tough part is that the world’s most advanced enterprises do not publicly advertise who has inroads to all of their IP and all of their data, so we have partners I can talk about vaguely and partners I cannot talk about at all. It is an eternal balance internally too.
Enterprise accounts for most of our revenue today. The public Design Studio remains a core product and the entry point for engineers to try Zoo. The front door is a priority, the fine-tunings are a priority, enterprise custom features are a priority, and I would say we are the most vertically integrated of the CAD companies right now, so that stack gets pulled in different directions each day.
How many enterprises are actually on it?
We are in the dozens of enterprises that have onboarded at this point. The largest scale fine-tunings are a fraction of that, because getting to the level where you have carte blanche on internal data access takes significant trust and pilot work. That is a 12 to 18 month spool up. Those have turned into individually multi-million dollar minimum spend contracts, seven going on eight figures for some of them.
Some of these companies spend mid single digit billions a year in labour on engineering, so if we can get them a 5, 10, 25 percent productivity gain because of our software, they pay. That said, a small fraction of the engineering world uses us today. We are a small fish. It is uphill every day.
How do you price it?
On the self-serve side we have three packages – a free tier, a limited use tier called Plus at $20 a month, and an unlimited AI use tier called Pro at $100 a month. There is significant usage on both, but it is dwarfed by enterprise.
Enterprise is consumption-based, on API usage, on inference, on pre-training work, on the training itself, charged at a per second rate. Probably two thirds of that is AI training and inference. A third is our other API endpoints, for things like analysis, or taking a CAD file and automatically making manufacturing instructions and annotated screenshots for the factory floor. They are minimum spend contracts, but they resemble a cloud services contract more than a traditional CAD contract, because the usage ceiling is essentially unlimited. We have had customers six months in at ten times the usage they planned.
And where does the design data actually live?
We support on-prem. Our biggest deployment today is on-prem in a customer data center, a very compliant one for that company’s very specific US government requirements. We also have custom, shared and compliant cloud environments based on customer needs. These customers tend to not like their data moving around. That is always the first conversation, post-NDA or as part of the NDA, to guarantee that data is not going anywhere. That is both for IP protection and for the question of whether their data starts seeping into a third-party trainable foundation model, an OpenAI or an Anthropic. The answer to that is no, but they need guarantees on all of it.
What is the minimum threshold of data you need for training?
We are still exploring where that threshold is, because it depends on the quality of the data and the metadata. Is the CAD data well tagged? Does it come with analysis results, so you understand the performance? We had a company that had bought an industrial components manufacturer as part of a private equity deal, for the tooling and CapEx, and they wanted to reverse engineer what that company had actually done for decades. There were very, very few records of it left.
So we did a fine-tuning on hundreds of files, all thematically aligned, all the same kind of forged tooling, and the question was whether Zookeeper could fill the gaps based on trends in the rest of their drawings, production records and non-conformances. If this part had a drawing, what would it have been? How would it have worn over 30, 40 years in production? Very successful result, but the caveat is how thematically aligned it was. That was not an automotive company with 10,000 different kinds of parts. If you are a broad-based tier-one with a huge variety of processes and specifications, you are going to need a lot of data. If you make the same kind of component for 40 years, you can get away with a couple hundred.
What Deep Tech and Venture Get Wrong About Each Other
You are also a general partner at Embedded Ventures. What does each side misunderstand about the other?
I started Embedded alongside Jenna Bryant in 2020, between Relativity and starting Zoo, and we spun Zoo out of the fund. The misunderstandings are strong on both sides. The deep tech world is full of deeply technical people who do not understand venture timelines, venture incentives, venture portfolio construction, or the incentives of their financial counterparties.
And on the venture side there is a known naivety that leads towards being able to make those big bets. Portfolio construction is that you make 20 bets and you need one to return a thousand times, the rest can go to zero. If you actually knew every risk a deep tech company had in growing, you would never do it. You almost have to turn part of your brain off. That is a gap, but an almost intentionally structural one that I think has to be there to get venture-level bets done.
Simple consumer software is expected to get early traction that is reflected in numbers. How does a deep tech startup survive the early years if laying the groundwork takes years and there is no hockey stick formation to show?
You are not being financed for short-term revenue growth. You are being financed for de-risking, whether that is regulatory, team, infrastructure or technical. What is the number one thing you could de-risk, put all of your resources into that, and then raise the next money that is more excited to come in because that first risk is done.
The other part is knowing which investors to spend time with, because you can waste years trying to win over an investor base that will never understand you. Many of them just baseline short-term revenue growth as the sole thing they can understand, and if you do not have it, you are dead in the water to them, you are a joke to them. And remember their job is to talk to you, to reach out, to woo you, take you out for dinner. That does not mean they understand what you are doing. It means they are trying to find a needle in a haystack, and they are doing that to everyone.
End to End as the Formula for Success
What does Zoo look like in three years?
If you are going to have the best AI, you have to be full stack in the downstream areas. If you have the best CAD generation, how do you know it will pass a physics requirement, a thermal requirement, a vibration requirement? You have to build that into one platform so the AI starts reasoning about those downstream areas.
So right now we are proliferating downstream into CNC toolpathing, where you can generate toolpaths and get feedback on what is manufacturable and with what tooling. We are also expanding into analysis integrations, with announcements later this year, and the enterprises have been playing with that since around March or April. If you can take an AI-generated CAD model and run it through a deterministic physics model to verify thermal, structural and flow performance, that is a reinforcement loop that is invaluable.
In three or four years all of that will be in production, we will have models trained on all of it, and it will be available to the consumer cohort as well. If you are going to be successful in this sector, you have to be end to end.
What should engineers keep an eye on besides Zoo?
There is a large cohort on the AI engineering side, and as much as I want to come up with one to complement, I do not think any of them yet see that end-to-end need. It is a great short-term game, but there is no flywheel that comes out of it.
On the foundation models I will highlight xAI, and it is because Elon has just recently publicly tweeted about wanting to include engineering data in the Grok dataset. Those foundation models getting better at interacting with CAD data and having engineering results is exciting. AI touching the critical industries the world is built on top of, I think that will be transformative in a way that is well beyond AI chatbots or AI imagery. So what I would keep an eye on is which foundation model provider leans in the most aggressively, to take AI from something that is chat and pixels into the physical world.
Related Topics
Giuseppe D.
7
1
Comment(0)