Agents for the Engineering Software Stack – Argus AI by Cosmon

We interviewed Rui Aguiar, co-founder and CEO of Cosmon, to talk about how much of product development is busywork rather than engineering, what an agent can take off an engineer’s plate today, and where the tooling goes from here.

Replacing Busywork

What’s the problem you’re out to solve?

The problem is busywork. There’s a ton of it in what we call the design to production cycle, product development all the way from requirements documentation to a shippable product. Design, simulation, PLM management, stuff like that. All of it has to happen for the product to move forward and very little of it is the actual engineering.

So what’s the busywork engineers are spending their time on?

It depends which engineer you mean. Mechanical engineering is a big job and it’s a few different people. PLM admins, design engineers, simulation engineers.

Take a design engineer. Some of their work is the fun work. How do I design this thing, how do I build this CAD for manufacturability. Then there’s the not-so-fun work. 2D drawing creation for part breakdowns. Adding hundreds of mates to an assembly. Getting feedback from the simulation team saying your design failed and you need to adjust this. Updating the PLM.

A sim engineer is a different persona. Pre-processing, mesh setup, convergence studies, DOEs. Troubleshooting, where a simulation fails and you don’t know whether it’s you or the tool. And post-processing, report generation, building decks. Frankly, everyone spends a lot of time doing that with the tools they have.

I read the Peak Energy case study on automating simulations. What’s the bigger issue, time wasted on work that can now be automated, or simulations silently left undone?

It isn’t either/or, both are really important. I’m bullish about agentic simulation for two reasons. The first is that it’s hard. There are a lot of people who are extremely talented at CAD. They can rip through an assembly very quickly, and they don’t necessarily need an agent to go and fill in a million things.

Simulation isn’t like that. It’s not harder exactly, it’s slower. I have to really think about this, I have to set it up, I have to make sure my mesh is right, and it takes hours and hours to run one iteration. So having an agent do a pre-flight check on that saves a lot of time.

But ultimately what you’re going for is the outcome, and what the tool enables downstream is the more important of the two. Think about why someone buys a simulation tool. Not because they want to see pretty colours. You buy it because I better be sure this car does not crash when the thing tells me it does not crash. So the larger impact with something like Peak Energy is that shifting simulation into the design process gets you higher quality geometries and higher quality output faster, which is worth exponentially more than finding out in production, let alone not being able to test it in production at all.

For a seasoned engineer there’s no doubt a lot of use in automating CAD work and drawings. But what about engineers starting out? Going through the motions in CAD, checking the drawing, realizing the mistakes they’re about to make is where a lot of learning happens.

It depends. It is still really important to understand the principles under which you’re making your design, manufacturability intent, how it fits into a broader assembly, how you dimension and how you create a drawing and why. But there’s also no reason an engineer should spend 30 minutes updating a BOM when they already know what to do and just have to go and modify the PLM with it. So it’s a sweet spot. It’s similar to software, you shouldn’t lose the underlying principles of why you’re building something a certain way, and that never goes away, even if you’re a more junior engineer.

I think of it more as an accelerant for the stuff you don’t want to go through and do. I’m not sure anyone gets much value out of their job by updating 500 parts in a PDM and incrementing a revision counter.

AI for the Full Product Development Cycle

What does Argus do?

It’s a domain-specific AI for engineering knowledge work. You have companies like Harvey or OpenEvidence that are domain-specific AI for legal and medical. We’re that for product development. The agents run in your CAD tool, your simulation tool, your PLM tool, and execute high-fidelity long-horizon tasks at as optimal a cost and accuracy level as possible, beating generalist AI on the very difficult pieces of work.

They’re highly targeted agents that work well across domain-specific engineering tasks and help engineers accelerate their product workflows. We think about it as four buckets. CAD modelling, in 3D and 2D. DFM analysis, drawing review and validation. Simulation setup, troubleshooting and post-processing. And end-to-end integration with native PLM systems, data card updating, checking parts in and out.

When you say you accelerate their workflows, does that come from fewer iterations, or just going through the motions quicker?

Both, but the bigger one is that you can check whether the result is right. Just because you get a result doesn’t mean it’s correct. A unit that’s wrong, a mesh that isn’t fine enough, that’s not obvious in the output, so you have to be paranoid about your own work. Agents are now smart enough to catch it. You point one at a simulation tree and ask, is there anything weird here, and it catches a misconfiguration, a missing unit, a bad decimal point against a PDF specification, a mesh density issue. That’s especially helpful in a tool like Ansys, where knowing which of 500 options to click to check one load unit is a different skill from understanding simulation.

The other half is that more engineers get enabled. A design engineer isn’t going to match an FEA expert, and you still need that expertise for final validation. But often the real problem is the simulation team gets a design and says this isn’t simulatable. Shift it earlier so the design engineer can run it and that happens less.

Could you walk me through a real-world scenario that touches the different verticals?

One example is our Frore Systems case study, which is essentially about a fan. The engineer builds the part up manually in CAD, then the agent picks it up inside whatever they use, SolidWorks or AutoCAD, and hands it off to their CFD job, which rebuilds the mesh, sweeps boundary conditions, scripts the HPC submission, drives the solvers they use for multiphysics, and reverts back to the design team.

The end goal is that whole loop running with a human as editor. How do I defeature, how do I build the CAD, how do I get my physics constraints onto the geometry. Then run CFD, run some analysis, back to CAD, now update this. The power is in the loop being self-reinforcing, optimising the geometry over time. That’s nascent today, and a lot of tools are focused on single-tool applicability, including us sometimes.

Many startups in this space, including ones I’ve interviewed, tackle a single vertical. You’re taking a full-suite approach. Why?

Because AI is capable. If you were starting this company two or three years ago it would make sense to niche down. But if you can provide value in thousands of places, why not? Look at where companies are most successful in coding. It’s not AI for coding in C++ that’s the ten billion dollar outcome. It’s an agentic software engineer working across GitHub and Linear and Slack and VS Code, end to end.

The risk is not doing it as well because you’re not as focused, but the foundation models are powerful enough that you don’t give up much. And your market is bigger. Some teams care a lot about drawings and some don’t. Some care a ton about simulation because it’s all they do, and some don’t because it’s cheap to build the thing and test it.

What does Argus still get wrong, something that bothers you and that you’re determined to solve?

Speed is a big one. Even when it gets things right, sometimes it just gets too tripped up on itself. The agent doesn’t know why it’s doing something, or loses context or memory, and it fails. That may go away as the foundation labs ship ten million token context windows, but it’s a problem today, especially if you’re trying to manage cost.

The second is design intent. Argus makes good drawings quickly if you set it up with your standards, but it doesn’t know why you’re building something. Tell it to make a car and it’ll make a car, but that’s not how you make a car. Prompting gets you part of the way, but nobody wants to call out every dimension when they could just do the drawing. So we think about how you encode design intent, and when the agent should ask instead of assume.

For drawing creation, what about GD&T? How does it determine the datum surfaces? Does it look at the assembly as well?

It looks at the assembly. It’s a context game. It can understand the 3D and map that down, or if the user tells it what the datum should be and how to select those, it does that as well. You either do human in the loop or full agent end to end, depending on how you prompt it.

Software for Users Not Expecting Magic

Who was your first customer that confirmed you were on the right path?

We started off with a couple of forward thinking university labs. I got emails at three in the morning. Someone working in CATIA reverse engineered an entire design from a scan and said this is the craziest thing I’ve ever seen in my life, it saved me three days of work.

The nice thing, and sometimes the not so nice thing, about building for engineers is that they’re vocal. They’ll tell you when something works and they’ll tell you when your product sucks. A lot of customers told us where the product needed to mature, but a lot also said I want to introduce this to my entire team. That was the early sign of product market fit.

Who are you really for? The site says hundreds of hardware teams run Argus, from university labs to the Fortune 500, which is quite a wide range.

It is. Aerospace, automotive, electronics, data centres, academic labs and consumer products are all qualified to benefit from this. But selling into some of them is much harder than others. Aerospace is far more regulated. You’ve got to go on premise, you’ve got to be compliant, no data getting exfiltrated. So the ideal customer is a team inside one of those companies where the work isn’t hypersensitive and you don’t need 20 layers of approval to deploy.

The other one is people forward thinking about AI in general. There’s a big difference in the success of a pilot depending on how capable someone is at prompting the tool. It looks simple because you’ve got a text box, but there’s a huge difference between saying make a drawing and saying make a three-view drawing. That’s something engineers have to learn.

Have you turned anyone down because you thought they weren’t a good fit in terms of their ability to use AI?

A couple of times. Generally we turn people down if they don’t have a strong business use case. If AI is cool but they don’t know what they want to use it for, that’s not a great use of either of our time.

Then sometimes people are way too ambitious with the tool. I want to upload a picture of an entire stroller and it needs to zero shot this thing or I won’t touch it. You’ve got to meet me in the middle. This isn’t magic, it’s technology. Someone told me they uploaded a picture of a plane wing and it didn’t build the thing to be manufacturable, and I’m thinking, what are we hoping for here? Someone vibe coding a plane is never going to happen, and frankly I don’t think you’d want it to.

How long from signing up to getting output an engineer actually benefits from?

The ceiling is three months. If you’re not seeing value in three months, either we’ve picked the wrong problem, or your standards are too hard, or people aren’t willing to use it. Generally, 90% of the time we see value within six weeks, and about a month of that is setting the thing up. If you want to run a POC across multiple teams, three months is the ceiling, and frankly you’ll know within half that.

Have you seen customers finding creative use cases you didn’t intend for?

Definitely. One customer had a 50-page document of supplier feedback and just put the whole thing on the platform. In ten minutes it took screenshots of every single place there was feedback in the assembly and suggested changes for each one. It created its own images with bounding boxes everywhere it needed to make a change, mapped to the component part. That was something I’d never seen before.

Pay for What You Need

The breadth of software in use at these companies is pretty wide. What can you plug into?

We publish this in our documentation. We have around 16 connectors right now, and it’s not everything, because as you say there are 50 pieces of software to choose from. SolidWorks, Siemens NX, CATIA V5, Creo, Autodesk Fusion, Onshape. On the simulation side Ansys Mechanical, Fluent, Discovery and SpaceClaim, COMSOL Multiphysics, Abaqus, Star-CCM+, SolidWorks Simulation and HyperMesh. And of course PDMs like SolidWorks PDM and Teamcenter, as well as your classic Excel, Word, PowerPoint, the stuff you’d get out of the box at these other systems.

Of course people don’t use all systems at once, but you’d be surprised. The most I’ve seen at one company is seven, and that’s typical of larger firms that buy five solvers because each one is best of breed, plus two CAD platforms for different purposes.

There’s a free trial but no price listed anywhere. Can you shed any light on the pricing?

A professional plan for CAD packages starts from 200 dollars per month. Simulation tooling is a few hundred more on top, and full enterprise deployment including CAD, simulation and PLM is close to about 900 a month for a named license. Floating licenses are priced separately. That’s worth it if your engineer is spending a lot of time on this stuff, because you’re not really benchmarking against the tool, although an Ansys seat is a lot more expensive. You’re benchmarking against time.

You should put that on the website. I expected it to be a lot more expensive.

Maybe we should.

So companies can come in and pay for only a fraction of the capabilities.

That’s correct. We don’t sell the all-in-one to everyone. Some people do want the full autonomous thing, and some just care about CAD drawings. That’s fine, we offer a different pricing tier.

How much handholding do you provide?

We go pretty heavy in the first four weeks as you get to value, then decrease it over time. The main thing is how you set the skills and the workflows up. Once people understand that they’re much more capable on their own. So we usually suggest five to ten hours of meetings over about two months, the most important part being four to five hours in the first month of setups, working sessions and skill building.

A lot of this depends on a company’s own way of working. What does the agent learn from their existing files, standards and practices?

There are three areas where you can encode intelligence into an agent. The first is the general LLM knowledge base, which comes out of the box. The second is engineering-specific knowledge, encoding ASME and ISO standards, and not only encoding them but feeding them into the context window effectively when the time comes.

The last one, the most important, is the localised knowledge of the engineer. I want it to understand my drawing template, with these reference dimensions, with this date format on this part. That has to get encoded by the team, which is partly why we do the handholding in the first month.

How do you protect the user’s IP?

We can deploy on premise if needed, so we can go behind a VPC, and in a highly regulated industry that’s probably the better option.

On our enterprise tier we don’t save the data at all. It’s processed in the cloud ephemerally and sent back over. It isn’t worth it to us to have this data on our servers, because it’s their IP and it’s very valuable to them. So we decided internally that we’ll collect operational data, tokens, how much you’re using it, so we can bill you properly, but engineering data and traces we won’t store. We also contract the foundation labs for zero data retention, which means it’s not in the memory of the model either.

Agents as the Default Way to Do Engineering Work

You raised 31 million dollars. How far ahead does that put you compared to your direct competitors?

As far as I can tell we’re the farthest ahead on coverage and agentic capabilities, and I haven’t seen anyone particularly close. I don’t know what other companies are doing commercially, but we grew more than six times last quarter and are looking to maybe double again this quarter.

What’s probably going to happen is that this industry mirrors coding, where there’s a land grab and everyone adopts agents in the next two years, 2027 and 2028. I talk to almost no hardware design teams that have agents today. They’re still evaluating categories. That’s not going to be the case in 2030.

What will Argus look like in a matter of a few years?

It’s going to get closer and closer to the highest level of autonomy possible. Today we’re doing one tool, maybe two tools together. My hope is that it can be an entire system from design to production. Not even just mechanical, but ECAD, CAM, PLM, native integrations like HPC.

I view it as you spin up instances of this thing alongside members of your team, so engineers are coordinating five, ten, fifteen instances working across hundreds of tools. There’s a long way to go, in agent capabilities and in context. But I can’t imagine that in a decade, in 2036, agents aren’t the default way to do engineering work.

Argus is a product of Cosmon. Are we going to see other products from you?

For the next six to nine months we’re mostly focused on expanding what Argus can do. More PLM capability and ECAD capability are kind of new products, they just get rolled under the Argus umbrella. There could be room for other sectors with different agents in place, although that I’d prefer to discuss closer to a release.

What’s the industry overestimating about AI in engineering right now, and what’s it underestimating?

It depends who you talk to. Some people overestimate it. Others ask whether it can really make a drawing. So there’s overestimation of capabilities and underestimation of the rate of progress.

Any other interesting AI companies in this space you’d highlight?

The surrogate model space is really interesting, and we don’t touch it at all. We go pure agentic. But PhysicsX and the neural network approaches to building out surrogate models are a really cool adjacent approach to physics AI, and I think they’re complementary to agent workflows. You can have agents help construct the data needed for surrogate models. It’ll be interesting to see how the simulation world evolves as agentic tools make these things more accessible and surrogate models become a more proven technology for the really computationally expensive work.