Why Most Enterprise Support Stacks Aren’t Ready for AI Agents

As customer support teams move from first-gen genAI co-pilots to autonomous agents, the real risk is assuming AI will “automate everything” without changing how support actually works. In this CX Today interview, Vishal Sharma, CTO at SearchUnify, explains why most enterprises still aren’t ready for fully autonomous support and what needs to happen first. Sharma breaks down the operational shift from “find” to “assist” to “act,” and why workflows and the underlying support stack must be rebuilt for machines, not just humans. Sharma also walks through the guardrails that matter most, from grounding responses with retrieval and citations to privacy checks, toxicity controls, and escalation paths when the agent should say “I don’t know.” 
Sharma also shares what it takes to deploy multi-agent orchestration without chaos, including clear agent roles, shared memory, and a master orchestrator.

Transcript

SPEAKER_01 0:08

Hello and welcome to CX Today. I'm Nicole Willing. Joining me is Michelle Sharmer, CTO at Search Unify, an enterprise agentic AI platform focused on unifying knowledge to power intelligent search, AI agents, and analytics for customers support. Michelle, it's great to have you here.

SPEAKER_00 0:25

Thank you, Nicole. Happy to be here.

SPEAKER_01 0:28

Great. So as I mentioned, you know, we're hearing about this shift from, you know, the first gen of kind of generative AI co-pilots, and we're now moving into this brave new world of autonomous AI agents acting on behalf of enterprises and customers. So what's the biggest um operational change that that really brings for customer support teams?

SPEAKER_00 0:50

Great. I'm glad you asked that question because at Search Unify uh we've also had a similar journey from find, sort of like assist and then act. We started as an enterprise search engine for customer support teams, and the idea was to give them a single box that they can use to find out any information which is sitting inside their organization while they're working on a support ticket. The second stage of evolution was more of how do we make this search box more powerful? And can we end up actually assisting these agents in the final uh actions that they want to take with this information? Which was more of like, can we help them draft a response? Can we help them quickly summarize a case? Can we help them do a little bit of a swamming also while working on a ticket? Because we can help them find the right experts they should talk to. And then finally, obviously, the the current stage of evolution, I would say, is more of an act phase, uh, which is more of getting into the autonomous mode. So our journey has been pretty much uh close to that. Um, but honestly, if you ask me, um I don't think I don't think most of the organizations are ready at this point of time to do a completely autonomous um shift. Um so they've been doing co-pilots, but if you ask me why they're not on completely autonomous support at this point of time, um I see there are primarily two reasons. One, I feel uh the underlying workflows should be redefined for completely autonomous systems or even assisted AI also needs to if it has to work, those underlying workflows should be revisited. Um for AI, at the end of the day, it is going to amplify your current system. So if you've got a crap in place, it is going to make it worse. If you've got a well-designed system for AI to take advantage of, it's going to amplify and make it great. So that's one part that the existing workflows should be revisited. But I think the second most important thing that we've been noticing as part of a lot of implementations is the underlying stack also needs to be changed for agents to consume. At the end of the day, um the support stack is going to be used by agents now in the autonomous world, not by just the human human beings. To give you an example, I would say the knowledge base, for example, historically was consumed by human agents. Now it has to be consumed by AI agents. So some sort of restructuring in that knowledge base is required. Similarly, for I think the support consoles also and in general the ticket workflows also, the the traditional thinking was to reduce the UI UX cognitive load for support engineers. But now with AI agents and system, more thinking has to go towards how do we make it API driven, um, more MCPs driven, uh, very efficient, multiple calls in a few seconds. So, how do you do that sort of a setup? So essentially, if you if you work on those two underlying blocks first and set those pillars in place, then I think um you as an organization is probably ready to make that shift from um assisted, co-pilot uh to autonomous.

SPEAKER_01 4:15

Yeah, yeah, exactly. Because you mentioned, you know, um enterprises aren't ready, but they're going ahead doing it. So why do you think that is that they're kind of leaping in and missing that they need to do more preparation before they get to that stage?

SPEAKER_00 4:32

Yes, I think a lot of preparation is required because I think um most so one of the mistakes that I see uh a lot of enterprises are doing is that assuming that it is going to automate everything. Um and that I feel is not a great way to look at uh adoption of AI into customer support. There are like simple use cases. You would always want to start with them first, for example, looking at the readiness of the ticket which is coming into the system, um, maybe classification of the ticket, maybe triaging of the ticket. So there are like some simple use cases. I would always recommend to start with them first uh before assuming that everything can be automated uh on Demon itself, because then I think we're going to create more chaos in the enterprise. Yeah.

SPEAKER_01 5:19

Yeah, because that's the thing, isn't it? And there's so much enthusiasm and excitement about AI. It seems that sometimes teams want to be able to use AI for their task they might not necessarily need to. Um, you know, they want to just throw AI and say, well, you know, we're implementing this agent or this system, but actually the task they're looking to accomplish with it might not necessarily need that.

SPEAKER_00 5:42

Yes, yes, absolutely. There are a lot of stuff that can be done with simple automation as well. Um and you don't need uh that fancy AI uh to be implemented and make it more complex. And what what you also have to understand at the end of the day is that within enterprises, you always have to be you you you would value a deterministic setup versus more probabilistic setup, right? You would need an accurate, reliable system to work. Um yeah.

SPEAKER_01 6:12

Yeah. So then um before if a company decides that an AI agent is appropriate, what guardrails should they put in place before they allow it to interact with customers?

SPEAKER_00 6:24

So guardrails are extremely important, and especially in enterprises, I would say um they become very, very important. Um, somebody was saying to me the other day um that AI and LLMs are more of like those eager employees for you who really want to show you the impact. And guardrails are more of like those managers for you who would want to make sure that your uh most employees are not making the costly mistakes for you. Um so guardrails are extremely important, and there are multiple levels at which you can you can go ahead and implement those guardrails. Um, for example, just to start with ensuring that your system is fairly accurate and giving that credibility to the end user that that that that end user or the human or the support engineer or your customer can actually trust on that system is you would implement a simple um uh simple retrieval engine to ground the responses. Uh, you would use a good rag engine, underlying rag engine to to ground your responses so that it's not just going anywhere. Um, you would want to build citations. Um, so anything that you're showing, uh, you have to give the credibility to the end user that, okay, here is the context that I use, the reference that I used in order to produce my answer. Um, you also have to define um what is that fine line where you have to say, I don't know. Uh, I really don't know the answer to that. And then is there a seamless transition to assisted support? Um, also, that's very well defined there. Um, so that's those are the the kind of things that you can do on the on more on the accuracy and experience side. But then there are other guardrails also, for example, on security and privacy. Have you implemented the PII uh checks in place? Have you uh on the semantic side, have you ensured there's no toxicity in the system? It's not really talking about your competition, it's not going um outside the boundaries. Um, and then also on the UX, also, I think there are certain levels of um guardrails that you can implement. That's more of like, are we stuck in a loop? Um, because uh if that is the case, then you really don't want to come back and use that system again. So, yeah, I mean, there are like multiple levels, um, and everything that you do in terms of the guardrails, just like security, like every layer that you add, it's going to make the system more robust, but then obviously it's going to make the system a little bit of slower as well, slow as well. Um, so you have to take a call at the end of the day that, okay, where should I then draw that line? Okay, this is fairly balanced for me in terms of cost, accuracy, and then um the the delay or the the other thing as well. Yeah, speed as well. Yeah.

SPEAKER_01 9:04

Yeah, definitely. And then, you know, we're starting to see now this talk of orchestration between you know multiple agents, um, you know, companies introducing now layers and of agents kind of with different tasks all working together and that showing up in support environments. So what has to be in place before companies then move to that step of deployment?

SPEAKER_00 9:28

Well, multi-hop system is a is a big leap, I would say. And honestly, if you ask me, um if you think your definition of agent is becoming too complex, too long, uh, there's always a possibility that this might just start um going south and hallucinate and then won't do the job. So it's always a good idea to break that into like small agents and have them work together. But then there are a lot of things that you have to keep in mind uh while designing a multi-agent system. Um and because at the end of the day, like one agent, very well defined outcome, very well defined job is fine. But then if there are multiple agents, coordination becomes a challenge. So um, as I said, like when you're defining a multi-agent system, the first thing you probably would want to do is that every agent has a very, very clear definition, what it is supposed to do, and then what are the outcomes uh of that agent. So that's number one. Second, I would say uh I think the the memory part is very important. Um, so because you don't want to be in a situation like um your front end, like the L1 support agent having a conversation with the customer, and then your LQ AI agent really has no idea what conversation was there uh with a with a frontline agent. So there has to be a concept of shared memory. You pass that signals and information from one agent to the other agent. That is extremely important as well. Otherwise, you really lose the whole context and there's no part of building a multi-agent system then. Um and I think the third point I would say, which is which kind of like crucial here, is that um a lot of times what you would see is that agents would start competing or blocking each other. Um, so general recommendation is that you really have a master agent doing the orchestration and then some sort of like you call them like uh the agents that are like uh following that master agent for the instruction. So this is why at least there's somebody sitting in the room and trying to unblock when you're like stuck on the same thing and trying to force each other that you should do this versus I should do that, that because that's like classic, we've seen that happening. Um so general recommendation is that like some orchestration needs to happen through a master agent as well. Um, but yeah, I mean, um we've we can see the the world is moving toward single agent system towards um multi-agent system, and then eventually, if you see like uh we've seen um different LLMs coming with different capabilities also. Once you design a multi-agent system, you get that flexibility to uh cut down the cost on on one use case because that specific agent is supposed to do just the summarization, right? For that, you don't need a very expensive LLM setup. Um so you can always plug to a low-cost LLM for that agent, and for somebody who's doing a deeper troubleshooting, you probably would want to run that uh with OPES or Sonnet or some of the entropic models as well. Um, so you have that flexibility in that multi-agent system, yeah.

SPEAKER_01 12:20

Yeah, yeah, exactly. So then uh I always like to end with the a forward-looking question. Um we the things move so quickly in AI that a few years anything can happen. But um, from your perspective um over the the near term, what do you think will separate the companies that get AI agents right from those that struggle?

SPEAKER_00 12:42

So, as I said, I think the definition of um documentation, I would say, of your current workflow is extremely important before you deploy any AI. You gotta make sure that you understand what is your current workflow, and you should be ready to take out certain items from there. Because I've seen a lot of companies coming back and saying that, okay, we need AI, we need agent TKI to work on uh on our existing setup, but uh but uh but they're not ready to change. And as I said, like for Agent TKI to work, you need to revisit your workflows and your processes and a lot of times at Tech Stack as well. Um, I think the organizations who are early adopters in terms of uh the ones who understand that some of these changes are required for these new EI agents to come and work, either as a coworker or in a completely autonomous fashion, uh, I think they're doing a great job. Uh, for example, like um deploying a frontline L1 support agent, uh, especially in high-tech, like where the cost of ticket can be $200, $200 to $250 per ticket. Uh, I see some customers taking huge success there for repetitive issues. Uh, they can deflect them through using AI agents. Similarly, a case quality, like you can like cover 100% of your tickets and do a case quality analysis now, versus historical days just taking one or two tickets. Similarly, for creating new knowledge base, um, now you're not dependent on one or two knowledge workers. Um, moment your ticket is closed, the resolution is captured somewhere in the closing comments. Uh, AI agent can capture that into a formal piece of knowledge space that can be used in future to avoid a similar ticket. So I think uh the organizations who are who are who understand that we have to make some changes in our existing environment for AI to come uh and help us, uh, they're seeing those early success.

SPEAKER_01 14:28

Yeah. It'll be exciting to see how uh these uh systems develop and the different um strategies that companies convey to do that. Thank you, Michelle, for taking the time. I really appreciate it. Um to for our audience, thank you for joining us and to learn more about um the issues that enterprises are facing in adopting a Gen CI. You can find more coverage on our website, cxday.com. Also, uh be sure to join our LinkedIn community and sign up for our newsletter. Thanks for watching, and we'll see you next time.

SPEAKER_00 15:03

Thank you, Nicole. Thank you, everyone.