Automation is not a silver bullet for CMC or bioprocess challenges—misapplied, it just adds costly complexity. The real edge? Thoughtful system design anchored in process understanding, not chasing the latest robotics hype.

Anthony Catacchio, CEO of Product Insight and a specialist in translating industrial robotics for high-value bioprocess and CMC operations, joined David Brühlmann on the Smart Biotech Scientist Podcast to unpack why most automation projects fail—and how to ensure yours doesn’t.

Key Topics Discussed

• Avoiding overengineering by clearly defining the problem before building automation solutions.
• Using phased development and structured requirements to reduce risk and accelerate timelines.
• The shift of industrial robotics into biotech labs and high-value, low-volume environments.
• Adapting proven robotics technologies for lab and medical use instead of reinventing them.
• Designing hybrid systems that optimize material flow while balancing human expertise and automation.
• Advances in vision-guided robotics, AI, and AGVs expanding automation capabilities in bioprocessing.
• Separating hype from impact through ROI-driven, case-by-case automation decisions.
• Collaborative, upfront system design processes that uncover hidden requirements and ensure practical ROI.

Episode Highlights

• Why biotech's "special case" mindset around automation is costing companies time and money — and what industrial robotics already has figured out [02:45].
• How Anthony's cross-industry career — from surgical devices to warehouse robotics — shaped a process-first approach to system design [05:05].
• The automation paradox: how to increase throughput and reduce errors without eliminating the expert human judgment your process depends on [09:13].
• Vision-guided robotics, AGVs, and quadrupeds: what has genuinely changed in capability and what that means for bioprocess applications [11:21].
• Human-bot testing: the low-cost validation method that reveals workflow flaws before a single robot is purchased [15:07].
• The $1M vs. $10K decision: a real case study where the right answer was walking away from automation entirely [15:54].
• Why talking a client out of an expensive project is sometimes the highest-value service a technical consultant can deliver [17:38].
• Building long-term credibility by recommending the simplest solution that actually solves the problem [19:24].

In Their Words

Fundamentally the purpose of a product is to embody a process. And so I've always sort of kept that same thread of thinking again, whether it's surgical equipment or it's industrial robotics, it doesn't really matter as long as you take the time to really understand the process that you're trying to affect and that you're trying to improve and you build real system requirements and you really explore the solution space and understand what you're looking at. In a lot of ways, everything translates really well as long as you take the time to understand the process. All the technology translates incredibly well.

Why Most Bioprocess Automation Projects Fail Before the Robot Is Even Ordered - Part 1

David Brühlmann [00:00:33]:
Bioprocess hardware development sounds straightforward until you try to build it. Anthony Catacchio, CEO of Product Insight, has spent years helping biotech companies navigate the challenges. Because most automation projects fail because teams never clearly define the problem they're solving and overengineer solutions with unnecessary complexity. Today, he reveals his phased approach to developing robotics and AI-driven systems that actually work. Reducing risks, accelerating timelines, and producing validation-grade data without burdening internal teams with complexities they are not equipped to handle. Let's dive in.

Welcome, Anthony. It's great to have you on today.

Anthony Catacchio [00:02:32]:
Yeah, it's great to be here, David. Really excited. I can talk about robots forever, so I'm always excited when I get a chance to.

David Brühlmann [00:02:38]:
That's awesome. Anthony, share something that you believe about bioprocess development that most people disagree with.

Anthony Catacchio [00:02:45]:
I guess I don't know what everybody agrees or disagrees with me, but one of the things I think that's going to be really interesting to see over the next several years is as we see more and more generalized robotics and sort of industrial robotics technologies all kind of creeping further and further into lab processes of all kinds. I mean, absolutely in the CMC and bioprocess world on the manufacturing side, but also on the research side as accessibility goes up and up, then deployment should go up and up with it. And so that's what we see a lot of, whether it's cobots or AGVs — wheeled robots that move stuff around in labs — we expect more and more of that kind of stuff.

I think there's this idea that biotech and labs are wholly different from industrial robotics. And realistically, I think that's going to be the biggest thing that people see over the next several years. It's not so much that you're going to see tons and tons of lab-specific or bioprocess-specific robotics and AI. You're going to see a lot of the stuff that's been cutting edge or has been really well proven out in a lot of these industrial spaces start to make that move from the manufacturing line or assembly — whatever it is — into some of these higher-value spaces. Obviously these high-value spaces are very risk-averse, but the robotics industry has a pretty long history of bringing automation to complex processes. And I think we're going to see more and more of that kind of migrate across from industrial logistics and those sorts of spaces where a lot of this stuff's been developed and refined into these somewhat lower-volume, higher-value use cases. I think that's maybe the biggest thing. A lot of people sort of view their niche as — I don't want to say special — but special. That we, oh, you can't just use that robot that you use on a factory floor or in a warehouse.

You can't use that here. And that might be true in some ways, but the fundamental principles are there. And it's really just about someone making the investment and taking the time to do it right and develop the right systems for whether it's bioprocess or other lab spaces or medtech spaces where the technology's already there. And the question is just: is someone going to take the time to design the system correctly and create the right quality levels and reliability levels?

David Brühlmann [00:04:57]:
Anthony, draw us into your story. What got you started in robotics automation and what were some interesting pit stops along the way?

Anthony Catacchio [00:05:05]:
I didn't really set out to be a roboticist. I'm a mechanical engineer by training. My whole career has really been kind of in the new product development space, starting in medtech, really. My first job out of college was all about surgical positioning equipment. It was a small company. The engineers did a lot of things there, and that included research and process mapping and really understanding how to bring mechanical systems that, again, aren't necessarily anything novel or specific to the medical world — or the technology isn't — but understanding how to design those systems in a way that worked well in a surgical setting.

So I did a lot of work in arthroscopy and in trauma care and that sort of thing, building medical devices. But really, even as far back as then, it didn't really matter. Are you making a medical device? Are you making something for a lab? Are you making something for the automotive industry? The principles are all the same. There's a different level of system design — that's fundamentally what it comes down to.

In labs or in CMC, your system and process are just so important because you have so much value flowing through those materials. And so it's not a technology problem. It's a system design problem.

As my career progressed, I moved from that company to a consulting group. When you go into consulting, you see a lot of different types of problems. I got a chance to work on some surgical robots. I worked on a bunch of other medical devices — whether it's a cart-based system, an implantable device, or whatever it is. You get to see all those same basic ideas of engineering and robotics. It’s like, now you're just applying them. You're building a different type of system around them.

It was in medical and surgical robotics where I got a lot of experience, as well as starting to move into the industrial robotics space. In the consulting world, as you well know, it's very referral-heavy. Sometimes you do a medical device project, and then someone leaves that medtech company and goes to work at a robotics company. They still call you — even though you're the med device guy — because they need ideas about how to do robotics and how to design systems so they can achieve their goals.

So I got a chance to start getting into the industrial robotics world. Over the last seven or eight years, I've leaned pretty heavily into that on the logistics side — warehouse robotics in particular.

That's really how I got here. My background is in product, but product has always meant system in my mind. I think of product development as the physical embodiment of a process. Products exist to enable processes — whether those processes physically aren't possible without that product, or you're building the product to make them higher throughput, more reliable, lower labor, or whatever it is you're trying to achieve.

Fundamentally, the purpose of a product is to embody a process. I've always kept that same thread of thinking — whether it's surgical equipment or industrial robotics. It doesn't really matter as long as you take the time to understand the process you're trying to affect and improve, build real system requirements, and explore the solution space to understand what you're looking at.

In many ways, everything translates really well if you take the time to understand the process. The technology translates incredibly well.
I've had the opportunity throughout my career to move across different industries and realize: this doesn't need to be different and special. We just need to use it the right way.

Maybe you can use the same robot that you use in a warehouse — you probably can. You might need to put an enclosure on it. You might need to make sure it stays out of the way or can operate in a sterilizable environment. You might need a different end effector with different requirements. But fundamentally, the core technology is the same.

That’s what I see in the future of biologics processing and labs in general — bringing the wall down a little bit and showing how these technologies can translate with good system design.

David Brühlmann [00:09:04]:
What kind of problems are you solving today in the bioprocess world so that people can see exactly what you're working on today?

Anthony Catacchio [00:09:13]:
Yeah, I mean, unfortunately, the consulting world — the big downside, fundamentally — is I can never really show anyone the stuff we're working on, right? Because we're always inside someone else’s R&D environment.

But a lot of what we're looking at today, and the kinds of things we're working on, involve understanding how to move materials around efficiently. That’s a lot of the work we see. And again, it sounds simplistic, but there’s this crossover where you need people who understand lab operations and lab automation. It’s very hard to remove all the people from the process.

There are many workflows where you still need expertise. You still need high-touch interaction. You can’t necessarily aim for fully lights-out automation all the time — and you shouldn’t.

So a lot of what we spend our time thinking about is how to design systems that accommodate today’s workflows — especially the parts that aren’t friendly to automation — while removing physically demanding work, repetitive work, or slow, high-risk-to-the-process tasks.

We spend a lot of time looking at how to structure the entire process flow to enable high-throughput automation in that space. You have to be very careful about how you delineate and protect the expert’s role in those environments. You can’t just throw in a bunch of large industrial robots, put everything in cages, and turn it into an inaccessible manufacturing line. It’s not realistic — and it’s not the goal.

The goal isn’t to eliminate human labor. The goal is to reduce errors, increase throughput, and improve reliability. It takes thoughtful system design to introduce automation in a way that doesn’t exclude human expertise but amplifies it. That’s really what we focus on. In robotics, a lot of the time, the core job is simple: pick something up and put it down somewhere else — without contaminating it, damaging it, or altering it along the way.

When people talk about AI in robotics, many of the real advancements in recent years have actually been in vision systems. The ability to identify objects, the scaling of edge computing to process visual data locally, and the improvement of machine learning models — that’s what has changed things.

What that enables is a broadening of acceptable inputs and outputs. Twenty-five years ago, you had to know exactly where the object was. You had a pre-programmed robot path that moved to a fixed coordinate and picked up the item.

Today, with vision-guided robotics, you can operate much more flexibly. You might know that the object is somewhere on a bench, and the system can locate it dynamically — something that simply wasn’t possible before modern computer vision capabilities.

So it’s really the merging of AGVs (autonomous guided vehicles), mobile robots, wheeled quadrupeds — which are an incredible emerging technology — and vision-guided robotic manipulation.

David Brühlmann [00:12:05]:
We have so many technologies at our disposal now, and you could do a lot of things. But the question I often ask myself is: what is really making the difference, and where is it just hype? Where is it just the tech person with a great idea? How do you advise people? What are the best areas to implement these automation or robotic systems?

Anthony Catacchio [00:12:28]:
It’s very much a case-by-case basis. The way our process generally works is that we always start with a really rigorous problem definition. “Implement automation” is not a problem statement. We need to know before we start: What is the goal? What are your challenges? Is the problem throughput? Is it that you can’t hire enough labor? Is it error rates? Compliance? What are we optimizing for? What are we trying to achieve?

Once we understand that, the next step is what we call system concept development or system architecture development. We take the time to look at: Now that we understand the problem, what are all the possible ways to solve it?

There’s a real challenge in this space. Many of the people who understand robotics capabilities and know what technologies should be used often don’t have aligned incentives. If you ask someone who sells a particular robot whether it will work for your application, they’ll try very hard to say yes.

So one of the first things we do is lay out all the different ways to solve the problem. At the end of the day, it’s about return on investment. We measure the potential impact and outcomes of different system concepts and layouts.

You might solve it with a single 6-degree-of-freedom robotic arm. That might require developing a custom end-of-arm tool. Maybe you mount it on a mobile robot. Or maybe you redesign the layout so the robot doesn’t need to move at all — place the robot in the center and arrange the work cells around it.

We typically walk through dozens of whiteboard-level concepts. How could this system be arranged? What are the true requirements? What’s the optimal way to meet these constraints and achieve the client’s objectives?

A large part of this phase is communication. Sometimes I’ll show a client five concepts knowing that none of them are correct. I’m not trying to present a final design in the first review. I’m trying to understand their problem more deeply.

People struggle to fully enumerate their requirements upfront. But when you show them a potential solution, they’ll say, “That would be great, except for this, this, this, and this.” And that’s valuable. They couldn’t articulate those requirements until they saw a concrete concept. That’s a huge part of our process — exploring the entire solution landscape before committing.

From there, we might simulate concepts, or what we call “human-bot testing,” where instead of deploying a robot, we assign people to behave like robots and test the workflow physically before automation is introduced.

David Brühlmann [00:15:21]:
So it starts with defining the problem extremely well, then exploring potential solutions. How do you guide your clients in balancing this? You could build an amazing system that costs millions. You could build something very simple. Or you might conclude that a robot isn’t necessary because people can do the job effectively. There’s always a balance between over-engineering, innovating, and inventing new things. What’s your take on that?

Anthony Catacchio [00:15:54]:
That’s exactly what we try to address in the concept phase. The last thing we want is to spend a client’s money and not deliver real value. That doesn’t lead to repeat business. It doesn’t lead to good morale.

There’s nothing worse than engineers working on something and thinking, “Why are we doing this? This doesn’t make sense.”

That’s why the early system concept phase is so important. A couple of years ago, a company approached us with a request. They had parts that needed to be wiped down with isopropyl alcohol (IPA) and boxed in a cleanroom environment. They sent us a 15-page RFQ with detailed specifications for a robotic solution.

Before even bidding, we reviewed it and asked ourselves: Why not just use a glove box and a person? Put the dirty parts in one side, wipe them down with IPA, place them in a box, and pass them out the other side. No need for a full cleanroom. No need for a robot.

We could absolutely build the robot. It would cost around $1 million. But we asked them: Are you sure you need this? You don’t have the throughput to justify it. You won’t eliminate all personnel anyway. This just isn’t complex enough to warrant automation.

So we gave them two answers:
Here’s the quote for the robot you requested.
And here’s a much simpler way to solve your problem.

Interestingly, I sometimes think the peak of our value proposition is talking people out of projects. It sounds counterintuitive — projects generate revenue. But many times, people jump straight to a solution and assume robotics is the answer.

Yes, you could solve the problem with a robot. But you shouldn’t.

Our goal in system concept development is to validate whether this is even the right project. If there’s a dramatically simpler and cheaper way to solve the client’s real problem, we’ll recommend that.

Because if we save someone from spending $1 million and solve it for $10,000 instead, the next time they face what looks like a million-dollar problem, they’ll call us.

We focus on validating problem-solution fit and ensuring we’re not off by orders of magnitude in cost. And the only way to do that is to invest time upfront exploring all possible approaches

If you skip that step and jump straight to buying a robot because someone said, “Go solve this with automation,” you often create unnecessary complexity.

Sometimes the better solution is simply to let a person do it. There’s something to be said about not trying too hard to replace the incredible machine that is a human being.

David Brühlmann [00:19:00]:
You’re making such a good point. What I’m hearing is that common sense matters. You can solve many problems with robotics, but some problems are better solved simply — cheaper and faster — without automation.

And I agree: telling a client, “Yes, we could build this, but you don’t need it,” builds long-term trust. That’s how you win in the long run, not just the short term.

Anthony Catacchio [00:19:24]:
Yeah — in the long term. It has its challenges in the short term, but it’s the right way to do it. Because eventually someone is going to notice that you could have solved this for $1,000 instead of $1 million. You generally want to be the person who notices that first. You don’t want to wait for someone else to point it out.

David Brühlmann [00:19:43]:
This wraps up Part 1 of our exploration of Product Insight’s hardware development approach and why data quality matters for GMP validation. We’ve also explored why a clear problem definition prevents over-engineering.

In Part 2, we’ll continue this conversation about building automation systems that actually solve bioprocessing challenges without unnecessary complexity. If these insights on hardware development resonated with you, please leave us a review on Apple Podcasts or your favorite platform to help other scientists discover this episode. Thank you for tuning in today, and I’ll see you next time.

All right, smart scientists, that’s all for today on the Smart Biotech Scientist Podcast. Thank you for tuning in and joining us on your journey to bioprocess mastery.

If you enjoyed this episode, please leave a review on Apple Podcasts or your favorite podcast platform. By doing so, we can empower more scientists like you.

For additional bioprocessing tips, visit us at smartbiotechscientist.com. Stay tuned for more inspiring biotech insights in our next episode. Until then, let’s continue to smarten up biotech.

Disclaimer: This transcript was generated with the assistance of artificial intelligence. While efforts have been made to ensure accuracy, it may contain errors, omissions, or misinterpretations. The text has been lightly edited and optimized for readability and flow. Please do not rely on it as a verbatim record.

Next Step

Book a free consultation to help you get started on any questions you may have about bioprocess development: https://bruehlmann-consulting.com/call

About Anthony Catacchio

Anthony Catacchio is Owner & CEO of Product Insight, where he leads the development of robotics and AI-driven systems that automate complex physical business processes. After joining the company in 2021 as Director of Engineering, he expanded the technical team and refined a specialized, phased hardware development process designed to significantly reduce risk and compress timelines. 

His approach emphasizes early validation, robust data generation, and clear system architecture—ensuring clients can make confident manufacturing and scale-up decisions without overburdening internal teams.

Connect with Anthony Catacchio on LinkedIn.

He is also a biotech technology innovation coach, technology transfer leader, and host of the Smart Biotech Scientist podcast—the go-to podcast for biotech scientists who want to master biopharma CMC development and biomanufacturing.  

Hear It From The Horse’s Mouth

Want to listen to the full interview? Go to Smart Biotech Scientist Podcast. 

Want to hear more? Do visit the podcast page and check out other episodes. 
Do you wish to simplify your biologics drug development project? Contact Us