Swapna Oundhakar is a product leader who builds enterprise AI for the workplace. Most recently, she was Vice President of Product Management at Kore.ai, where she led an agentic AI portfolio spanning the employee lifecycle across HR, IT, and recruiting, shipping autonomous agents on Slack, Teams, and the web for large enterprises. Swapna began her career in technology transformation consulting at Capgemini. She spent more than a decade at ADP, ending as Director of Product Management, where she built the first version of ADP Workforce Now, now a $1B+ revenue flagship. Before her most recent role at Kore.ai, Swapna also led Amazon’s global career development platform for a distributed frontline workforce and ran the enterprise payroll and tax portfolio at Business Software, Inc.
In our conversation, Swapna talks about designing AI around the work employees are already doing rather than asking them to adopt new habits. She discusses building trust in nondeterministic systems, the new evaluation practices AI products require, and why the future of enterprise AI lies in agents that can carry work across systems.
Making enterprise software disappear
You’ve built products across payroll, HR, recruiting, and workforce technology. What’s the biggest lesson you’ve learned about what employees actually need from the software that they use every day?
Employees just want to get the job done. They need the software itself to disappear. Nobody wakes up wanting to use an HR system — they just want to get paid correctly, get answers to questions they might have about policies, get a laptop replaced, that type of thing. Their problems have essentially remained the same despite changes in technology, and I’ve been through those technology transformations. People want to use the software to do what they need to do and then be on their way.
With Kore.ai’s AI for Work platform, what problem were you trying to solve beyond simply adding another AI assistant to the workplace?
This is true for any enterprise: the biggest problem employees have is needing to use 10 different systems to get their jobs done. Ideally, they should be able to go to one place to ask their questions and get the help they need.
The first question is, “Where do I need to go to do that stuff?” As everybody starts to add AI, the problem compounds. Even if I need to go to HR, do I need to go to a specific HR system for policy questions? And another for benefits? As an employee, that’s not a good process.
The problem that I was trying to solve is how to make employees’ lives easier using AI. We need to make it simple for people to do their work without having to go to 10 different systems. This starts with meeting them where they already work. That could be in Teams or Slack, or a web UI. We don’t need to make people develop a new habit.
Building trust into enterprise AI
Enterprise AI operates in regulatory environments where mistakes can have real business consequences. How does that change how you approach the product design, testing, and rollout?
Even in enterprise software, compliance has to come first. I’ve built those products from the ground up. Mistakes in payroll, compliance, and HR have huge consequences. It’s the same in AI, and that risk compounds even further.
You need to make sure answers are thorough and that humans are in the loop in sensitive areas. You need to be very careful about preventing hallucinations, providing accurate answers, escalating to humans when needed, and accounting for compliance-level rules. The overall compliance landscape should be thought through before you ever push something live. Building specific guardrails — like masking sensitive data, for example — is not an afterthought. It needs to be included in the design itself.
When you’re doing regression testing, you should have golden datasets and rules that you’ve already thought through. What types of policies and procedures will inevitably come up? These are called evals in AI. When you’re rolling the product out, you have to start with context grounded in the organization’s data so that the agent doesn’t hallucinate. If it can’t answer, there need to be correct fallbacks so that it doesn’t make things up. It should either escalate to a human or say, “I don’t know the answer to this question, but here’s a document for you to review or here’s someone you can ask.”
How do you mitigate the hallucination risk of LLMs and get the end user to trust an AI agent with sensitive data?
You have to build trust from the moment a product is rolled out. As a user, the first time I interact with a system, I expect it to do the job I want it to do — almost as well as a human does. If it doesn’t know the answer, it should send me to a human rather than make one up.
A company’s policy document repository is very important here. For example, I’ve worked with customers who have laid out “moments that matter.” In an HR scenario like a bereavement leave case, LLMs are very good at handling that type of sensitive information. But as soon as the situation involves sensitive data or something like an employment violation, those are the “moments that matter.” Once an AI detects that type of intent, it should give a very empathetic answer and pass the situation along to a human because mistakes in those contexts are very costly.
When you’re designing AI workflows, you need to understand those workflows end-to-end: what are the connection points between different systems and different users, and how do I now redesign and rethink this entire workflow while keeping humans in the loop at specific moments?
What new practices have become essential for evaluating an AI product before it ships?
One of the biggest things is evaluations — making sure the product is working correctly. There are two types: one happens during the build itself, and the other happens during internal rollouts or pilots. During the build, you anticipate what people might ask, but when you actually roll the product out and people start asking questions, you may realize that you haven’t thought of every scenario.
What’s different here is that you’re not evaluating a UI; you’re evaluating conversations. There’s no UI to speak of, so the design practices become different. Are you empathetic? It’s a whole new way of thinking. There also isn’t the single point of failure that you used to have in traditional software development. It’s generative so that the answer can be different every time. Pinpointing where something is going wrong requires investigating a whole range of possibilities: “Is it in retrieval? Where did it actually go wrong? How do I even fix this?” There’s not a straight answer.
It’s very different from traditional UI development because now you are dealing with conversations or voice. Traditional development practices are completely thrown out of the loop. Still, spec-driven and test-driven development concepts, which have existed in the software world, are now reflected in practices like evals and spec-driven development. They’re new practices that you need to adopt.
Rethinking product development for agents
Having worked in both traditional software and this non-deterministic new world, do you have a preference?
Currently, I do not know how I would go back to the old way. Now, I’m thinking in terms of agents and how to develop them. When I’m given a problem, I try to map the workflow, and my mind immediately goes to, “What agent would solve this workflow? What systems are involved?” My thinking has changed dramatically. I’m also thinking in terms of conversations. To paraphrase Satya Nadella’s term, AI has become the new UI. I find it difficult to go back to traditional software development at all.
Your team rolled out the platform internally first. What did that reveal that you couldn’t have learned through customer interviews or usability testing alone?
Initially, I was rolling it out to different users. We spoke to different user groups, really trying to chart out their days: “What’s your day-in-the-life like?” These are UX research practices that have existed for a long time in software development. Those practices are still important. Nothing substitutes for good UX and UX design, though the traditional terms have changed a bit. Talking to users, talking to customers, and finding the right problem to solve have not changed at all.
I spoke to our HR, IT, and sales departments to learn what their jobs-to-be-done are. Once we had a good set of interviews and a grasp of our internal systems and workflows, we evaluated whether the use cases we built were still applicable. What tweaks would we actually need to adopt it within the enterprise? We had the golden datasets, and we’d thought through the test sets, but when it came to rolling it out for real, there were surprises. People use every system differently, so we didn’t anticipate certain questions.
Like any software rollout, we learned as we went, adapted, and evaluated. It’s true for every single enterprise: Who are the users? What problems are they trying to solve? What systems are they touching? What workflows are they using? Then, after rollout, does it work? Have people actually adopted it? Are they coming back? Is it successful?
Can you share an example of something that surprised you in the rollout?
Initially, when we were working with policy documents, we had to configure the system so that the right countries’ policies were displayed to the right people. We only realized that during testing. It all came down to how you organize your documents and make sure answers come from the right documents in the right format.
Designing for adoption, not disruption
AI is changing how people work almost in real time. How do you design a platform that can evolve just as quickly without forcing employees to reinvent their workflows constantly?
You need to meet employees where they work — whether that’s in a chat or a web UI, you shouldn’t change that. The user’s habit actually lives in those systems. In most cases, it is in Slack or Teams, and anytime you make changes, the experience should survive every model upgrade, every capability change, and every new architecture change behind it.
That’s why the platform-first approach works. Models can be swapped, but you need to be able to do new regression testing. The workflows that people have already gotten used to should not break.
When you’re building an employee-experience platform, what signals tell you that the product is actually improving how people work?
This has always stayed the same in enterprise software — it’s about retention more than adoption. The first metric is whether or not people have taken to it. Then, the real test is whether they are coming back to use it.
For example, with HR software, you are often required to use it — there’s no other way for you to submit a time-off request. But if it is optional, and now you can submit a time-off request using AI, are people actually using it? Have they come back because they liked it and it made their work simpler? Further, are they now starting to use it for complex tasks? As we move to agentic AI tasks, a good example is a user telling the AI, “Plan my leave. Check my vacation, look at my policies, and tell me the best leave that I can take that optimizes my time off with my vacation days.” That’s a complex-level task that an agent can actually do.
In IT, for example, the AI can go in, check when your laptop lease is going to expire, and automatically send emails to an administrator that the laptop needs replacing. That’s a level of autonomy, but of course, I always stress having a human in the loop.
When people use it as their first stop because it’s that useful, that’s when you know it is successful. There are some easy metrics to track, such as lower ticket volume, because you can conclude that people are getting their questions answered by the AI. HR can then do higher-level tasks and focus on strategy rather than answering questions.
From conversations to end-to-end work
Looking ahead, what do you think the best enterprise AI platforms will do three years from now that today’s products aren’t yet capable of delivering?
They’ll be able to carry work across systems instead of just answering questions. You’ll hear about orchestration in the AI world — a typical enterprise will have 50-plus systems. There’s an end-to-end workflow that can execute across those systems rather than relying on these single points of contact with AI tools.
Further, today’s products are mostly conversational. They’ll summarize documents and answer questions, but the opportunity is to cut across workflows. For example, “I can manage your end-to-end day from morning to evening. In the morning when you come in, I can tell you what meetings you have. Here’s your dossier for them.” Work should be a lot simpler, and it still isn’t. These systems need to be proactive, anticipating what you need and taking that busy work away. This will make work more enjoyable because AI systems can do a lot of the grunt work.
As expectations for output accelerate alongside AI, how can AI help employees keep up?
It’s the cause of these increased expectations, but it can also help you. Nowadays, there’s no other way — to do your best work, people are being asked to do more work with less. It’s not stopping. So AI is an essential component.
We all talk about using humans in combination with AI. I truly believe in that and think AI should be seen as an asset rather than a replacement. If you view it this way, it can augment people to the point of driving higher satisfaction. That’s a win-win for both the organization and the employees who work there.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.