From Personal Productivity To AI Operating-Model Change — A Conversation With Zoetis CTO Kumar Venugopal

Most AI efforts I see are still living inside personal productivity. People are 20% faster with ChatGPT, Claude, or Copilot, and leaders are pointing at that productivity as evidence that the AI strategy is working. It is a fine starting point, but it is not where the real value lives. The deeper opportunity is to move past individual augmentation into workflow-level and operating-model-level change — redesigning how decisions get made, how work flows, what teams own, and what the organization should build versus buy. In a recent conversation on Scaling with Agility, Kumar Venugopal, CTO of Zoetis (the world’s largest animal health company), walked me through what that move looks like from inside a Fortune 500 — including a concrete bet to compress an infrastructure workflow from 25 days to 2-3 days using agentic AI, a working prototype of a SaaS replacement built in days, and a clear-eyed view of where AI fluency actually comes from.

The throughline of the conversation is that AI stops being a tool rollout the moment you stop asking “which product should we buy?” and start asking “how do we want the business process to work in a year, and which parts of it should agents now own?” That is an operating-model question, not a procurement question. It pulls in design thinking, prompt framing, basic model mechanics, agile cycles, build-vs-buy assumptions, and a workforce conversation that is honestly more about job security than change resistance. This post is a deep dive on that shift, with Kumar’s quotes carrying the weight of the inside view and my commentary connecting them to the operating-model patterns I see across the organizations I work with.

I have learned to be skeptical of anyone who tells me a technology wave is fundamentally different from the last one, because the people saying that are usually trying to sell something. So I started the conversation with Kumar by asking the most boring version of the question on purpose: across 30 years in technology, from the .com era to today, does this AI wave actually feel different, or is it more of the same? His answer was unambiguous:

“It feels different. I can tell you that the .com 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… 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. But we were still shopping before. This one feels like tomorrow’s version is completely different than yesterday’s version.” — Kumar Venugopal, CTO of Zoetis

The distinction I want to sit with there is add-on versus systemic. If a technology wave is an add-on, the leadership job is mostly procurement, integration, and adoption — you bolt the new capability onto how the business already works. If a technology wave is systemic, the leadership job is different in kind. You are no longer asking which vendor to pick. You are asking how the business itself should be redesigned so that the new capability is not just usable but load-bearing. Almost every AI program I see is still running on the add-on assumption, which is why most of them stall once the easy productivity wins are claimed. Kumar’s framing matters because he is naming the shift from the inside, not from a conference stage.

Inside Zoetis, that systemic framing shows up everywhere from the science to the back office. Diagnostics, genetics, and almost every product line they sell to veterinarians is being affected, but Kumar was quick to redirect me away from the product angle and into the operating-model angle, which is where the harder organizational work actually is.

“It’s not just about going out and buying a product, Salesforce AI, Agentforce. It’s not just about getting the things bought, but 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?” — Kumar

The sentence I would underline there is the second one: how do we get this to change our business process? That is the line between AI as a tool and AI as an operating-model question. Most organizations are still on the procurement side of that line. The ones that cross it are doing harder work that does not show up in vendor scorecards.

When Kumar described where Zoetis actually is today, he did not over-claim. Personal productivity is real and meaningful, but he was clear-eyed that it is not where the strategic value lives:

“It’s personal productivity today. It’s not ingrained into business processes. But if I’m looking at here’s my five risks that I’ve come up with for this particular item, and then I go into the ChatGPT thinking model or any of the others, and I figure out that this is a prompt I want — it tells me what’s an additional set of risks that I haven’t thought about. It tends to help me think holistically. It helps me think in more detailed ways, and that’s the decision making that I was talking about.” — Kumar

That is a useful description of the early state because it does not pretend the gains are nothing. Knowledge workers are genuinely thinking more holistically because they have a second pair of eyes that does not get tired, does not have political loyalties, and is willing to stress-test their thinking on demand. Across Zoetis, Kumar estimates that productivity gain at roughly 20% per person — lawyers, scientists, finance, the works — and notes that it is not consistent across the organization but is broadly real. If you stop the AI story there, you have a respectable productivity initiative, and a lot of large enterprises are doing exactly that and calling it an AI strategy.

The reason it is not enough is that 20% per person, applied across an organization that still has the same decision rights, the same handoffs, the same WIP, and the same coordination overhead, does not compound into 20% better business outcomes. It often does not even compound into measurable function-level improvements, because individual productivity gains get absorbed into the queues, meetings, and coordination work that fill the calendar back up. To get past that ceiling, you have to redesign the workflow itself, not just hand people a better tool. That is where the next levels of AI integration come in.

This is the part of the conversation where I offered Kumar a frame I have been using with leaders to make the progression concrete. It is my framing, not his — and I want to flag that explicitly because it is easy to blur the line in an interview write-up. He validated it with where Zoetis sits on each level, which is the useful part.

The first level is augmenting human thinking. Chatting with Claude, ChatGPT, or Copilot in an open prompt. This is where most organizations start and where most of the activity still lives. The second level is structured augmentation: instead of every person prompting from scratch each time, a team builds a defined environment around a recurring workflow. Contract review, medical writing, infrastructure requests, customer support escalation — the context is loaded, the prompts are templated, the guardrails are in place, and the human only adds what is genuinely new to the case in front of them. The third level is agent-assisted work, where the agent does meaningful chunks of the task on its own and the human reviews the output rather than producing it. Think Claude Code or Codex for software, but the same shape applies to other domains. The fourth level is fully agentic, where humans are in the loop primarily to coach the agents and fine-tune the system, not to produce the work.

Kumar placed Zoetis honestly across the levels. Level 1 is “very high” — broad adoption, the 20% productivity gain, mostly consistent. Level 2 has “shown good results” in places like a medical-writing department that has moved from 20% individual productivity to 40-50% departmental productivity because the workflow itself is now AI-enabled rather than each writer prompting in isolation. Levels 3 and 4 are still early. The honesty there matters: most CTOs I talk to imply they are further along the curve than they actually are, which makes it harder for their peers to calibrate where they are.

When I pushed Kumar for a concrete example of where Zoetis is making the level 3-4 jump, he went somewhere I did not expect. Most AI demos lean on customer-facing examples because they are more photogenic. Kumar went to internal infrastructure, which I think is the more honest place to look:

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

The current workflow to provision the infrastructure behind a new project at Zoetis takes 25 to 26 days. Kumar’s stated target is to compress that to two to three days using agentic AI, with humans still in the loop for cybersecurity and the genuinely critical decisions. That is not “AI will transform everything” rhetoric. That is a measurable bet against a specific workflow with a known cycle time, and it tells me more about how Kumar thinks than any AI vision statement would.

The architecture he sketched is worth describing because it is a reusable pattern. He sees three agents working in sequence, with human review between each. The first is a design agent that takes the business intent and produces the infrastructure blueprint — what services are needed, which Azure components fit, what the shape of the integration should look like. A human reviews that blueprint, which is the part most teams want to keep human because the cost of getting it wrong is high. The second is a code agent — Codex or Claude Code style — that takes the approved blueprint and generates the actual infrastructure-as-code from the templated patterns the platform team already maintains. The third is an execution agent that actually runs the provisioning, again with human checkpoints at the steps that matter.

When Kumar described that pattern, I noticed it mirrors something product teams have been learning the hard way over the last 18 months. The teams that get good results from AI coding agents are not the ones telling Cursor “build me an app.” They are the ones who write specs first — what people are calling spec-driven development — and then let the agent execute against a tight, well-shaped intent. The same shift applies here. Infrastructure-as-code is not the bottleneck. The templated runbooks are not the bottleneck. The bottleneck is intent, captured well enough that an agent can act on it without producing the wrong thing very quickly. That is a discovery skill and a design skill, and it is the same skill product organizations have been building for years. AI does not eliminate it. AI raises the leverage on it.

The infrastructure conversation naturally pulled us into a different topic: what happens to the build-versus-buy default once an organization can stand up working software in days rather than months. Kumar went further on this than I expected:

“Could we get rid of some basic SaaS applications, subscription-based, that we no longer need? Could we then use that same approach to build out that software, implement it, get it out? Monday.com is an example. For me, that’s a very generic piece of software. We could literally develop that. Why do we need to pay $30 a user per month per license? And as a corporate, you have hundreds of those.” — Kumar

He was not theorizing. He told me they actually built a working Monday.com prototype “in a span of a couple of days,” prompts-only, no traditional developer effort. It has bugs, it needs integration work, and it is not a finished product. But the existence of that prototype is the signal. The gap between “buy generic SaaS” and “build it ourselves” is closing fast for the long tail of internal applications where the differentiated value of the vendor is honestly thin.

My take, for what it is worth: I would not run a full migration off that prototype, and I would not encourage a CIO to use this as a budget-cutting bludgeon either. The total cost of ownership math for SaaS includes a lot of things that do not show up in the $30-per-seat line — security review, support, vendor accountability when something breaks at 2am, integration upkeep, compliance posture. But Kumar is right that the question itself is shifting. It is no longer “which vendor should we buy?” by default. It is “what should we buy, what should we build, and what can our business people now safely shape with AI-enabled help?” The set of internal applications that pass the “obvious buy” test is genuinely smaller than it was 18 months ago. That deserves to be in every enterprise architect’s decision-making frame.

This is also where things get interesting for the people Kumar called “business analysts on the IT side.” He pointed out that business people are starting to use vibe coding to build working prototypes — not because they want to replace developers, but because the friction to express their intent in working software has collapsed. The Power Apps generation of citizen-developer initiatives never really worked at scale, and Kumar was direct about why: “Power Apps is really still a technology tool and still behaves very much like a technology tool. 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.” AI is different because it can offer the complete set of services — integration, data, calls to external systems — without forcing the business user to learn another platform’s idioms. That shifts what business analysts can do, and it shifts what they should be expected to do.

The part of Kumar’s answer that I think is most under-discussed in the broader AI conversation is what AI fluency actually requires. The default industry pitch is that prompt engineering is the skill people need to learn. Kumar’s answer is more demanding and, I think, more correct:

“I found that design thinking helps a lot, where you’re not thinking in the tactics, you’re thinking in the overall structure, you’re thinking in the design language. Of course, prompt engineering is a critical skill set. It sounds easy. I’m just going to ask the LLM, but how you ask the intent — that’s very difficult to frame correctly. It’s very difficult to put it the most optimal way. The third that I’ve told people all the time is to learn how LLMs work even at a middle school math level.” — Kumar

Three pillars, in his order: design thinking, prompt framing, and enough model mechanics to know what these systems are actually doing under the hood. I like that list because it keeps AI fluency out of the magic-tool bucket. Two of the three skills are not new — they are skills good product and engineering people have always needed. What is new is the third one, the model-mechanics layer. Kumar was very specific that he means tokenization, neural network basics, the self-attention paper, softmax, vectors — middle-school-math depth, not PhD depth, but real enough that people stop anthropomorphizing the model and start asking it the right kind of question.

I want to add one observation Kumar made that I think gets glossed over in most coverage of AI adoption. When I asked him about resistance and whether business users were pushing back on the design-thinking-plus-model-mechanics curriculum, his answer reframed the problem:

“It’s not like the resistance comes from the fact that I have to change. It comes from the fact that will I have a job tomorrow? If I’m able to get rid of majority of my redlining work as a lawyer, what am I going to do? That’s a fear that comes from within. But at least the interest is there.” — Kumar

That is a different problem than the usual change-management framing suggests. The standard playbook treats resistance as inertia or as a deficit of training. Kumar is naming it as a credible career fear. The right intervention for a fear about future employment is not another training module on prompt engineering. It is a credible story about what the role looks like on the other side of the change, and a willingness from leadership to actually walk into that conversation. Without that, the activity continues but the energy behind it gets thinner.

There is a version of the AI-and-agile conversation where the punchline is “AI killed agile” or “ceremonies are obsolete.” Kumar was direct that this is not his read at all, and his reasoning is more interesting than the headline would suggest. Cycles compress dramatically, but the discipline of breaking work into shaped, testable units becomes more important, not less:

“We are doubling down on Agile, and we are trying to be not just working on developer productivity, but 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.” — Kumar

What changes is the cadence. Sprints that used to take two weeks can compress into hourly or even minute-by-minute regeneration cycles. The GxP validation work that took six to eight weeks in their pharma environment is collapsing into a single week. PI planning, story shaping, test-script generation against the same stories, validation — the pieces of the lifecycle remain, but the time between them shrinks. The risk in that is obvious: if you do not maintain the discipline of stating clear intent, breaking it into shaped pieces, and validating against the intent, the speed becomes a way to ship the wrong thing faster. The agile lesson does not go away. It gets harder to ignore.

The other half of the cadence shift is who participates in it. Business people, in Kumar’s words, are still in the mindset of “we say what we want and it magically appears, and building is the role of technology.” That assumption is the constraint, not the technology. Getting business people to step into “I need to think about how I build it” is a multi-year cultural change, and it is the one Kumar called out as the unfinished part of the Zoetis story.

Kumar’s closing advice to other leaders was three steps: educate first, be open about how roles will change, and show people what is in it for them personally. I would add a fourth step that runs underneath all three: get specific about which business processes you are actually trying to change, and which parts of the operating model have to move to support that change.

That is the operating-model question, and it is the one most AI programs avoid because it is harder than buying tools. It pulls in funding models, decision rights, team structures, the build-vs-buy default, what counts as a job in a year, and how the organization measures impact. The reason Kumar’s framing matters is that he is treating those questions as the actual work, not as the residue that gets sorted out after the technology is deployed. Most AI programs do the reverse, and most AI programs are getting the results that approach earns.

The useful AI conversation is moving beyond personal productivity. The real question is not which tools to buy. It is where AI changes the way the organization makes decisions, designs workflows, and moves work through the system. That is where AI stops being a tool rollout and starts becoming an operating-model conversation.

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.

If your AI strategy still reads like a procurement plan, you are working on the wrong question. The real work is operating-model change — and it starts the moment you ask which business process you actually want to be different in a year.