Zoetis CTO on AI Operating-Model Change

Most organizations have personal productivity handled. People use AI every day and get meaningfully more done. The step almost nobody has taken is the one after that: getting AI into the business process itself, so the work is different rather than just faster.

I put that to Kumar Venugopal, CTO of Zoetis — the world’s largest animal health company, which spun off from Pfizer in 2013 — on the Scaling with Agility podcast. He has been in technology for almost 30 years, starting in the dotcom era. What follows is his answer to where the ceiling actually is, and what it takes to get past it.

It feels different. I can tell you that the dotcom era felt different than this one. It feels more systemic. It feels more revolutionary. It feels like it’s going to impact not just technology but technology as a means to transforming other areas.

It actually feels like it’s going to change things, not just be an add-on. The internet became an add-on, e-commerce became an add-on. We don’t shop in brick-and-mortar stores, we now shop online — okay, but we were still shopping before, we’re still shopping now. This one feels like tomorrow’s version is completely different than yesterday’s version.

I asked how that shows up inside Zoetis:

It shows up in our veterinarian products first and foremost — the ability to leverage AI to do better diagnostics, better genetics, better everything in almost every product line we sell. It really shows up in every department, in every conversation we have.

It’s not just about going out and buying a product. It’s really about how do we implement this? How do we get this to change our business process? And what are we trying to do with our workforce? We think people are still critical. It’s not going to replace people, the company can’t be run by agents. But there is going to be a big impact on how people work, how people function and operate.

When I talk to leaders like Kumar and ask what they are doing with AI, they see a lot of the potential — and then we get into what the levels of integration actually are.

There’s augmenting human thinking and human decision-making: chatting with Claude, chatting with ChatGPT, Copilot, whatever environment you’re in. That’s a good start, and it’s where most people begin.

The next level is still augmenting human beings, but in a much more structured way. Take contracts. It’s not that every time somebody in purchasing or legal needs to do something, they have to feed in the contract and do prompt engineering. We create a project for them — an environment where they only need to drop in an additional contract, and all the context and data is already available. That’s almost automated.

The next level after that is where you start to work in an environment with the ability to let the agent think on its own and develop things. Then there’s full agentic, where people don’t necessarily need to be in the loop — they’re only in the loop to build and fine-tune the agents.

Kumar was straight about where Zoetis sits:

We have personal productivity very high. People are using AI every day making themselves more productive. Let’s just say 20% more productive. So lawyers are 20% more productive, scientists are 20% more productive. That’s pretty well happening. It’s not consistent.

That leads to the second part, where we do have focused efforts on taking departmental workflows that are cross-functional in nature and building solutions that are a bit more defined — on the one hand fixed, on the other hand with some flexibility. So a team of medical writers can collaborate and become not 20% individually productive but 40, 50% productive as a department.

On the agentic front, the third and fourth category, we’re still in the early stage.

This is the part I found most useful, because it is a specific number rather than an aspiration:

One example would be infrastructure. I believe we can have a very modern AI-first infrastructure to do server provisioning, cloud provisioning, things that are anyway templated — but also identity access management, firewall access management, all the 25, 30, 40 tasks that happen when you do that. I believe all of that is agentic-capable now.

We’re in the process of making a bold decision to just make that fully agentic sooner than later. We’ll start with our current workflow, which takes 25, 26 days, and we’ll try to get it down to two to three days — because there are still humans in the loop, cyber security, some critical steps we can’t miss. Once we hit that, then we have to work on the next step to get more efficient.

My background is more in infrastructure than in pets, so I asked the obvious follow-up: is infrastructure-as-code a prerequisite, and what does agentic AI add beyond it?

The business customers or the functional IT side don’t know what they need, they don’t know what resources they want to pull, what Azure services to bring in. So there’s a whole host of agentic exploration on just the design component — setting up the blueprints, getting it organized.

Then you have the execution mode. We have preconceived infrastructure-as-code templated approaches that are very manual in effort today. Those are guardrails for the agent. You get the design blueprint from the design agent, then a human in the loop checks it, then from that you build actual infrastructure code that pulls out the build scripts based on your templates. And then a third agent, after human review, executes on all of the above.

In the end, the customer should feel: this is my need, these are my project documents, this is the SaaS solution I’m buying, this is the integration I need. That’s a complete overhaul of how infrastructure is done.

That is the same transition we’ve seen in software — from telling Cursor or Lovable “I want an app that does whatever,” to taking a step back and planning, what people now call spec-driven development. Kumar is describing an infrastructure-oriented version of the same spec.

The build-versus-buy line moves once vibe coding is real:

Can we replace SaaS applications through vibe coding — not just infrastructure as code but really software as code? We’re exploring a couple of options today. If we could get rid of some basic subscription-based SaaS applications we no longer need, could we use that same approach to build the replacement?

Monday.com is an example. For me that’s a very generic piece of software, and we could literally develop that. Why do we need to pay $30 per user per month per license? As a corporate you have hundreds of those.

And they did:

With intent from engineering, we did build a replacement for Monday.com in the span of a couple of days. A working prototype. Does it have bugs? Yes, of course. But actually it’s just prompts — the developer didn’t really do anything. Could a business person have done that with training? Absolutely. They’d still need help to integrate it.

I’ve never fully understood where the enterprise value in that category comes from either. But it raises the real question, which is not build-versus-buy — it’s who does this work, and who maintains it.

I’m trying to spearhead this thinking within the organization as the technology person, but almost everybody’s interested in joining this effort. There’s almost nobody who says “yeah, AI, I really don’t care about it, I pretend to just do my COBOL programming and I’m good to go.” Nobody in the technology function at least.

We’ve got a good variety of people, believe it or not, not just developers, interested in learning about vibe coding or how to automate infrastructure. And that’s been a shift — business people can use vibe coding to develop solutions. It might just be a prototype, but it’s a start. Business analysts on the IT side can do things they couldn’t do before.

We have ideas, we have a ton of people ready to execute on those ideas, we have tools we could give them access to. All we need to do is buy tokens, and that seems to be the big constraint — having enough to go around.

Kumar and I worked together in a previous organization where there was a similar vision with Power Apps: business users in R&D would build things themselves rather than needing IT for everything. As I recall, it was very hard to get traction. I wanted to know whether AI is genuinely different or whether we’re about to repeat that.

It’s different because Power Apps is really still a technology tool and behaves very much like one. If you want to integrate it to anything, all of a sudden you need much more sophisticated skills than just building a couple of forms. That’s easy, but nobody wants that — that’s useless. InfoPath and Google Forms can do all that simple UI work.

AI is different for us because we can offer the complete set of services. We can provide integration, databases, calls — things that were not easy to do in the past world, that are still not easy but becoming easier by the day. That seems to be a big difference-maker.

Tokens and access aren’t the constraint on quality. Everybody can build something. So what do people actually need in order to build something worth having?

Design thinking helps a lot, where you’re thinking in the overall structure, in the design language. Prompt engineering is a critical skill set — it sounds easy, I’m just going to ask the LLM, but how you ask the intent is very difficult to frame correctly.

The third is to learn how LLMs work, even at a middle-school math level. How do they form these neural networks? How do they tokenize? What is this Google paper that transformed the world of neural networks? I ask people to learn that because without it, I don’t think they can really understand how to use it well.

Learn how these models work, as detailed as your math skills allow you to go — because I’m not that skilled at math. Softmax functions, vectors, you lose me at that point. So I learn as much as I can.

I asked why thinking holistically matters so much, and what the anti-pattern looks like when people go straight at the solution:

You get a lot of pigeon-holed stuff. You get a lot of forms and kludgy user interfaces. I played with it for a couple of weekends and just left out the overall intent — didn’t tell the prompt what it was, just wrote exactly what I wanted — and totally different than what I expected came out.

I even took the design language from tools like Duolingo and said, I want to use this design language, I want you to develop this. It was much more accurate. Just going to tactics brings a completely wrong solution. And people will throw it away, because they’ll say that’s not what I want. And then next thing you know, they lose confidence in that.

I hear user stories in that answer. I hear outcomes. So I asked directly whether agile is useless at this point, a given, or a prerequisite the way infrastructure-as-code is.

We do not think agile is useless at all. In fact we are doubling down on agile. Even the agentic approach has to be built with a minimum viable product approach, with proper user stories. You feed those into your prompts. You build step by step, because even AI cannot build sophisticated tools overnight with just one prompt.

The cycles are a lot faster. The ability to integrate and innovate, to deploy and run again — it’s hourly, it’s minute by minute, every 15 minutes it can regenerate. So that requires us to change maybe the sprint cycles. But I don’t see the process going away: the PI planning, thinking about what you want, putting that into proper epics and stories, getting that fed into a model, getting it QA tested by AI.

You were in the GxP world with me before. That would take us six, seven, eight weeks to run through all of that, document it, put a trace matrix together. In this new world I think we could do that within one week max. That changes the cyclical nature of it, and I like that.

My own belief won’t surprise anyone: agile might change, but agility is something you need even more in this space. The harder problem is the business side. People in IT may already know how to work this way. When you get to the business people, they often don’t have a development mindset at all — building is the role of technology, we say what we want and it magically appears. That was a challenge in the Israeli Air Force in the ’90s and it’s still a challenge in pharma companies in 2026.

Kumar was honest that this part is not solved:

There’s enough anxiety about AI that people are interested, even if they’re lawyers, to understand something. Personal productivity is the easiest thing to get them to understand. But what you’re talking about with agility, learning how to do this in a new way — I don’t feel like we’ve gotten there yet.

It’s not the resistance. The resistance comes from the fact that I have to change. It comes from: will I have a job tomorrow if I’m able to get rid of the majority of my redlining work as a lawyer? What am I going to do? That’s a fear that comes from within.

But the interest is there. If I tell them learn design thinking, learn how the models are built, learn proper prompt engineering beyond your personal space, let’s put together a product that can help you accelerate contracts — I don’t get too much resistance. They realize their skill sets have to change and are blending with technology. You cannot be a business person and say my role is not impacted by technology.

The shift I’m hearing described — and I fully agree with it — is that the role everywhere, even for lawyers and other business people, is to become architects. To become developers of a better and better legal function, or quality function, inside the organization. Not so the organization can run GxP without quality people, they’re always needed, but to accelerate the whole machine of getting more veterinary products to market, experimenting more, delivering more value with the same capacity.

I asked Kumar what advice he’d give leaders navigating that transition from AI as a technology to AI as a change in how people see their role.

That’s a very difficult question to answer. What I’ve learned is that education is first and foremost the key. You’ve got to teach yourself, which I had to do, and you’ve got to teach your people. We’ve hosted classes on how do NLPs work, how do you build a model, if we had to build our own how would we build one — not that we’re going to, but what would that look like?

Step two, be open about the change. Explore what it looks like. Your role could be different tomorrow.

Step three is really to see what’s in it for them. I try to tell people: here’s what’s in it for you. If you learn these skills you become marketable tomorrow. You don’t want to get left behind. College kids come out with innate knowledge, you need to keep up with that.

And we do all of this before we get into departmental workflow conversations — conversations that begin to shift work in the organization.

That last line is the whole sequence in one sentence. Education, then openness about the change, then what’s in it for the individual — and only then the conversation about changing how the work is done.

This article is based on my Scaling with Agility conversation with Kumar Venugopal, CTO of Zoetis. The full episode runs about 39 minutes and goes deeper on the agentic infrastructure example, the build-vs-buy threshold, and the workforce conversation.

Prefer audio? Listen on the episode page or directly on Spotify. Find Kumar on LinkedIn.

We think people are still critical. It’s not going to replace people. But there is going to be a big impact on how people work, how people function and operate.