Ajay Kumar on running MCP in production inside a regulated enterprise

From an experiment to a dedicated MCP team

Ajay: There is a difference in mindset from last year to this year. Last year people asked, what is MCP, and the first question was always, what happens when it hallucinates, what happens when it takes actions on my behalf. Those were the questions we had to answer, and they were the right questions. But I see a shift now. People still ask, what happens when it goes and orders things on my behalf, and the answer is that is not going to happen. They are much more open to the conversation now.

Matt: Hello everybody. You are listening to Agents After Dark, powered by Prefactor. I am Matt Doughty, your host, CEO and co-founder of Prefactor. Prefactor is building the agentic control plane that lets regulated enterprises track, manage, and control their agentic stack, build a single source of truth for the organization, drive return on investment, and get the board off your back.

Today I am very pleased to be joined by Ajay Kumar, Head of MCP Services at InfoTrack. Ajay brings more than 17 years of experience across banking giants like Bank of America, prop-tech, insurance, and government, and now leads InfoTrack’s Model Context Protocol business unit. He shapes how AI moves from experimentation into core production workflows. His background spans engineering, architecture, identity, and enterprise-scale delivery, and he is focused on embedding AI directly into platforms, not just running pilots. Ajay, thank you so much for joining me today.

Ajay: Thanks, Matt. That was a very nice introduction. Maybe I will listen back to this recording.

Matt: We can clip it, and you can send it to anyone you like.

Ajay: It is good to be here. Thanks for having me, Matt.

Matt: So Model Context Protocol, MCP for those who know, was released around November 2024. It got real traction towards the middle of last year. There are not many organizations investing in headcount specifically focused on MCP. It normally gets embedded into internal workflows and exposed to customers. What triggered the decision to formalize MCP as part of your role and the wider business, instead of treating it as another AI experiment?

Ajay: It is a two-sided story. InfoTrack is a legal-tech and prop-tech organization, but we are technology-driven. We focus a lot on how we can use new technology where it makes sense, service our existing clients better, and expand our horizons. MCP came about because our founder, Christian Beck, listened to a podcast while he was driving, where OpenAI was experimenting with Shopify. The idea was that you could use OpenAI to order things off Shopify. So you do not just ask ChatGPT to suggest gift ideas for Valentine’s Day, you go ahead and buy that gift from within ChatGPT. That was a really good thought.

Internally, like any organization, it started with developers trying agentic AI, code completions, that kind of thing. We have used AI for a long time, from AWS Textract to extract documentation to using OpenAI. When the developers were using agentic AI, we found that it was good, but it needed MCP. It needed connections to make it more productive. So we explored MCP-enabling our internal services, like our front-end component library, to support the developers.

If you think about it, for AI agents, developers are clients. We are clients to AI agents, using them to be more productive. And if we need MCP for ourselves, then our clients who are using AI agents need it too. The executives went on a strategy exercise to see where MCP fits and what could be beneficial for the industry. Then we deliberately took a decision to disrupt ourselves. We could treat AI as an experiment, or we could deliberately change and put serious effort and resources behind it and see how we scale. We chose the second. Change management inside our organization has always been a strength, and the messaging was crisp: the right resources for the right reasons. That is how the journey started.

Why bet on the protocol itself

Matt: Where do you see MCP specifically? From an AI perspective there is a huge amount to talk about, but from an MCP perspective, why invest so heavily there? What is the underlying thesis behind putting so much time and effort into Model Context Protocol?

Ajay: Model Context Protocol is a protocol. Today, human users are our clients, ordering searches and certificates from us. But down the line, human users are going to use robots or AI agents to order that. How do you service that market. If a client comes to you and says, I have an AI agent and I want it to order a title from you, we needed a product that could service that. That is the trigger.

MCP is the industry-wide protocol. Anthropic introduced it in November 2024, and since then it has evolved from an Anthropic-specific protocol into an industry one. The donation to the Linux Foundation last December cemented that. More and more people are adopting it, and it is making AI agents productive. For us the goal was simple: we want our products and services to be used by AI agents. The best way to make that happen was to MCP-enable them. Everyone out there is trying to build AI agents, and that is fine, you can use any provider you want, OpenAI, Anthropic, your enterprise AI. But we wanted to be the electricity that every AI agent needs, and the only way to achieve that is to MCP-enable it.

The other advantage is that we have been a trusted provider of authoritative data for over 25 years. Data is not a byproduct for us, it is the product. By enabling this, we can expand into other domains. We do not have to be restricted by what we are today, because anyone building AI agents might need data for different use cases. We may be a bit early starting this journey, but earlier is better, because we have got a lot of learnings out of it and we are on the right track.

Matt: That makes sense, and for anyone listening, Prefactor was originally focused on the identity piece around MCP, so we have been very embedded too. We are coming at this from similar perspectives, thinking about MCP from a production use case. What was the first real use case that made you think, this is not just playing around anymore, this is real?

Ajay: Inside the organization, we are part of a wider group of companies that are also building AI agents. The idea was, how do we surface our information and services to them without restrictions and without anything specific we have to do. MCP was the single winning answer. It was not one single service, to be honest, it was a big bang. We decided consciously that we were going to MCP-enable every single service. We strategically picked services like title search, ASIC, and a few other things we offer that could resonate with the industry easily. We MCP-enabled the title search first. The use cases were compelling: as a lawyer, when you want to sell or buy a property, the first thing you do is order a title. Enabling them to do that without leaving the agentic interface they are in is a clear win. That is the starting point, but there was no single service trigger. It was a conscious decision to go all in and MCP-enable all our services.

The first production use cases

Matt: When you talk about external services and say title, what you are referring to is that lawyers can go into ChatGPT, connect to your MCP server, and query title data on InfoTrack, and the same for ASIC data, which is an Australian regulator. What about internal use? I love hearing about customer use cases, but a lot of organizations invest in MCP internally first. Where have the biggest wins been from internal productivity?

Ajay: Before I answer, on lawyers and ChatGPT: they usually do not just use ChatGPT. They have guardrails and enterprise-grade AI that they use. So yes, arbitrarily that is what they do, but through those systems.

Internally, the biggest thing was MCP-enabling our front-end library. We have a proprietary front-end library called Zenith. When I set out to lift and shift a legacy application to modernise it using an AI agent, I was using Claude Code, and I saw an immediate increase in my own productivity once I MCP-enabled that. Before, I used to give Claude Code the whole GitHub repo and say, here is the front-end library, use this theme and these components, and it could not figure it out. When I created my own quick MCP, that is when I realised this was something serious. It took much more deliberate actions. It knew what to do. That was the hooking point, and that is how internal productivity started: MCP-enable our internal services and products so the developers get a boost.

The gap outside engineering

Matt: What about outside the engineering department? It makes sense that you would use your engineering ability to build MCP servers to develop faster, but most of the organization is not using Claude Code. They are probably using other AI tools. Did you identify any easy wins there?

Ajay: Outside engineering, I would say we are still exploring. There is no MCP server that we have nailed yet, primarily because the common perception is that there are not enough MCP servers out there to make us more productive in other areas. This is also a call to action, because people still look at MCP as knowledge-providing tools. They do not see that MCP can give you not just data but tools you can execute actions on.

We could not find relevant tools out there for, say, the sales team to use. Recently people.ai hooked into a sales AI MCP, I read about it this week, so the transition is happening. But when we started looking internally at which other department could benefit, honestly there was not a lot of meaningful MCP out there for the teams to use. That is a big industry gap.

Matt: It is interesting, because with OpenAI announcing agent apps towards the end of last year, there was a lot of enthusiasm about where this was going. Our view is that adoption is not quite there because the big LLM organizations have not quite nailed the experience. One of my aha moments with MCP was connecting Fireflies, which we use to record customer calls, and then querying all of those calls through the MCP server I connected to Claude. It was one of those moments you experience rarely, where I had just instantly improved my productivity: summarising calls, turning them into follow-ups, sending to socials, informing our strategy. I do not know why more people are not doing that. Why do you think adoption has not been there, and what needs to happen to make it go mainstream?

Ajay: You need to build use cases. The biggest thing I have seen, starting from developer tools, is that if you take the Microsoft Agent Framework, it does not have rich support for MCP clients. We looked to use AG-UI and even contacted them, followed up, and it was, we are not going to do it now. It becomes a case of, you use it and we will build it, versus, we will build it and you use it.

There was some confusion at first between MCP and the AI agent. When MCP came out, it was supposed to be the single thing where agents could use MCP to do complex tasks or surface data. That was not really happening until around 2026, because with MCP apps it is now possible to do much more, with elicitation and people providing the technical frameworks. Even major AI providers did not support the SDK out of the box. Elicitation is one of the major features.

Keeping a human in the loop

Ajay: We have very complex products at InfoTrack, and we want the human in the loop. When you order something, and we tell you it will cost you, even if it is $10, we want the human to say, yes, I am okay with that. Elicitation was the only way we could do that, and we found that none of the major agentic providers out there supported elicitation. So the limitation, the slow adoption in agents and MCP clients conforming to the MCP standards, is what is holding it back. That is why it is not mainstream yet, and I feel that is changing this year.

Matt: MCP apps is a big deal, and plenty of companies are focused on building that experience. The thing I often hear is that MCP can be a bit temperamental. How do you handle the risk of using MCP when it breaks, or hallucinations, as an organization?

Why hallucination is an agent problem, not an MCP problem

Ajay: It is a very interesting point. MCP in itself should not hallucinate, because there is no LLM in the path. Only when you introduce MCP sampling will it hallucinate, because then you are connecting to an LLM. If you do not use sampling, it is basic: your agent calls your tool, the tool performs an action, as simple as that.

That is what we hooked into. We built a gateway that says, these are the tools available, and every call comes to that gateway, which analyses the right tool to serve. We expose a search-and-invoke pattern, and we vectorise all our tools to match against the description. Going back to hallucination, I personally feel that responsibility sits more on the agent side, not the MCP side. If you are using a legacy, poor agent, then yes, it is going to hallucinate. You need to bring your agents up to the right technology. It is only as good as the data you give it, and if the data is poor, it is going to hallucinate. I do not think MCP can solve that. The only thing MCP assures is that it is deterministic. MCP will not hallucinate, as long as you call the tool.

What we have done at our end is take most of that on ourselves. When we started with some legacy models, they were not surfacing the right tools. So I thought, what can we do better. Give us the user query, and let us tell you the right tool to call, then you call the tool. It got better. Now it knows the tool it has to call, it calls the tool, and we surface the answer. That partially addresses it.

Inside the gateway: search and invoke

Matt: That is interesting, because I believe most MCPs do not see the actual raw query. You get part of it, but not the full amount. How does that work? What does the architecture look like end to end? Agent calls MCP server, the server goes through a gateway, then to your database. Is there anything else you add to make it more robust?

Ajay: We have a gateway where all our internal teams register their MCP servers. When they register a server, we take the description and vectorise the critical information of every server and every tool. What we surface to the outside world is a single endpoint with search and invoke. So when you register that as a connector anywhere, all the AI can see is search and invoke with InfoTrack. When someone says, I want to order a title with InfoTrack, or do a title search for this address, we have given server instructions that say, call search first to identify the tool.

That is an interesting point: not every agent respects server instructions. The agents that do will say, now I need to call InfoTrack with the user query, and it gives us the query the user is asking. That comes to the search pattern of our gateway, it searches the tools in the vector database, identifies the top two or three tools that match, and returns them to the agent. Then the agent knows it has to take that particular action and goes about its work. That is the architecture. It is simple but effective.

There are drawbacks. For instance, ChatGPT does not work the same way, because it has its own search-and-invoke pattern as far as I am aware, so it cannot search a search. You need to give it a list of tools, and we have some flexibility to expose our tools that way too. But mostly we say, just use search and invoke. The advantage is that we do not consume a lot of tokens. We have a lot of products and APIs at InfoTrack, and when you expose 200 tools, it eats up a lot of tokens from the agent’s perspective. The best way is to either group tools into simple chunks, or expose a pattern like this, where all the agent has to worry about is, anything with InfoTrack, I call search, it tells me what to do, and I invoke that.

Guaranteeing the right tool for risk-averse users

Matt: You said not all agents do what you want in terms of respecting instructions. How do you manage that when you are dealing with lawyers, high-profile, risk-averse stakeholders? If an agent is not guaranteed to complete the action a lawyer needs, does that not lose confidence if it does not work every time?

Ajay: That is exactly why search and invoke was critical for us, because we know the right tool for a particular query. Most lawyers are not going to go to ChatGPT and say, order a title. They use enterprise AI, and we work on integrating our MCP into those enterprise AI systems. They usually have a defined use case or workflow, and most of the time we know which tools they need and we surface those.

When you register a server to our gateway, we also check that the tool does not overlap with another. When you send us a query, there will be only one tool matching. There is not going to be 20 tools matching. The issue you raised would happen if we had 30 tools with the same name and similar description, where we do not know the right tool. We take extra steps to understand the description better, and when registering the server we deliberately make sure the tools have distinct names and descriptions, and each tool does what it is supposed to.

Agents not adhering to that is mostly about server instructions. Where I raised that was when you want to dictate a workflow from MCP, which is being a bit cheeky. You want to say, call this tool first, then do this. Some agents ignore that, which is also good, because then you cannot prompt-inject anything, so you stay away from that. That is where we cannot force a workflow. But we have never faced an issue where they wanted to call a title and ended up getting an ASIC. That has never happened.

Matt: That makes sense. So the natural follow-up is, you have not had to shut anything down because of behaviour.

Ajay: No, not yet.

Security, risk, and the Aura incident

Matt: Hopefully never.

Ajay: We are learning. Every other day there is a new thing. There has been a security incident, the Aura health security incident, if you have read about it, where someone disguised themselves as the Aura MCP server and tried to collect health information. So we need to evolve. We are well prepared to face those issues, our MCP servers are well equipped, and we have a good history in security. But we need to be vigilant.

Matt: You definitely do. As with all new technologies, when you are exposing tools to customers, MCP is very new and you are dealing with risk-averse organizations. It is fairly easy to see the value of connecting to InfoTrack via an MCP server, but how do customers react when you talk about connecting to the data via MCP? Does it require a lot of education? What has the market reaction been?

How customers are reacting now

Ajay: We started this journey only late last year, so as of today we are talking to customers, and there is not a concrete use case yet where they are heavily using it. Many are trying it. There is a difference in mindset from last year to this year. Last year people asked, what is MCP, and the first question was, what happens when it hallucinates, what happens when it takes actions on my behalf. Those are the right questions to ask. Now I see a shift. People are much more open to the conversation.

Without revealing the name, we met with a client this week, and it was not a developer or a tech person. When we jumped on the call, he said, I have built an AI agent and I want to make it more productive, tell me how you can help. That is a big shift, a client telling us they have built this and asking how we can make their agent more productive. The secret sauce is MCP, so I did not have to say it. We did not have to sell or convince. It has taken time and it will take time, but there is a shift in the mindset of customers. It comes down to two things: the use case, what is in it for me, and why should I use it. We explain it like this: you hire an admin in your organization. When you give them work, do you want them to go figure out the information and come back and tell you what you have to do, or do you want the admin to do the work for you. If you want the admin to do your work, which is what you are paying for, you need the right tools. That is the value.

Matt: When you said they were building an agent, what was the agent doing originally, and what was the value once they connected to you?

Ajay: They were trying to automate incoming emails. It looked at incoming emails, drafted a response, said, I am working on this, I will get back to you, created files in their systems, and allocated the work to whoever had to take care of it. But it stopped there. You have the context and the organization context, but what is the next step. That is the point. They had a workflow and knew what they wanted to do, but every step told them, I have done this, now I need you to do this so I can proceed. They wanted to circumvent that and say, when I tell you to do something, go ahead and do it. That is the productivity they were expecting.

Matt: It is much more common and easier to build this stuff now than even six months ago. The narrative keeps shifting, and it does not surprise me that that type of organization is investing in agents and looking at MCP. From an MCP perspective there are still a lot of skeptics, the number of times you get asked, is it just an API wrapper.

Living with a fast-moving protocol

Matt: One observation I have made is that MCP’s journey over the past 12 months feels a bit confusing. When you have a protocol changing as frequently as it is, and you mentioned elicitation not being supported by the major SDKs, and there is plenty more. When we were building our MCP authentication tool, the full MCP authorization spec was not supported by any of the major players, and they changed it. As an enterprise working with enterprises, you deal in consistency. With so much change over a short period, even if AI is changing all around us, how do you manage that operationally? Do you stay tapped into everything to be up to date with the standards, or do you ignore it and stay confident in the solutions you have found?

Ajay: We have built a strong foundation beneath this. We have a dedicated team building the platform, Alex and his team, whose job is only to make sure the MCP platform is stable and up to date with the spec. Whatever happens, we keep updating so the other teams do not have to worry. He updates the SDK, and other teams just update and release. They do not have to do anything specific. Even with elicitation, we wrote an internal SDK that wraps it, so other teams can use elicitation without changing what they are doing. Product teams can keep building without worrying about the next MCP change. That worry sits with the platform team, who also make sure the platform is stable, correct, and secure. That is why the gateway and platform responsibility sits with one team, while other teams build MCP products on their own. We do not ignore it. We keep it up to date, as we did last week for the new MCP spec.

On inconsistency: I was chatting with one of the guys the other day, and it was interesting. Before this we had APIs. There is a CMMI level for APIs, but I do not know how many people follow the protocol to the letter. Most people have their own flavour of API, a wrapper, SOAP, information out in JSON. So how is this different. No one follows a protocol to the letter. The frustrations we are having are the teething problems of anything new that is constantly changing, and somewhere down the line we will settle. Yes, it is another protocol, it is going to be different, it is going to be inconsistent, and we will live with it.

The real interesting point is how you work around that. You do not do something different, you follow the industry standard, but how do you make the best of both worlds. Async is a classic example. MCP async came out late last year, and none of the agents out there do it. So how do we support that. We are working on it now, and agents who want to work with us, we will tell them, InfoTrack MCP is different and this is how you use it. It follows the standard to the letter, and you also get the best of both worlds. If something is asynchronous, you can give us a webhook, or here is an event you can subscribe to, and get updates. I guess I answered your question in a long-winded way, but that is what we do.

Quickfire: advice before you start

Matt: Thank you for the detail. I have a couple of quickfire questions to tie us off. The first: you have talked a lot about your experience with MCP, some things that worked well and some that did not. If you could go back and change one thing about the adoption and implementation, bearing in mind you are still early, what would it be?

Ajay: It would not be anything, honestly, and it is not a thing, because every day it is changing, so it is difficult to say what I would have done differently. And this is not to boast, but I think we have done things right. We hooked into basic software engineering and architectural principles and relied on that strength, rather than relying on the protocol itself. So no, I would not do anything different.

Matt: Another clip of, we have not done anything wrong. I love it. Second quickfire: what makes customers nervous about AI or MCP that you have seen?

Ajay: Two things. One is change management, and two is, is it going to replace me. Both come back to change management. We are masters at dealing with change management. The fear will go away, as it does with any new tech. It is the fear of new things. There is nothing to worry about. Humans are always needed to do jobs, while AI can do tasks. That is how I look at it.

Matt: Fair enough. The final one: for organizations interested in the journey you have gone on and looking to implement this, if you were to give one or two pieces of advice before they start their MCP or agentic production journey, what would they be?

Ajay: Start with trusted data. Do not rely on just AI. AI is only as good as the data you give it. No amount of model tuning or fine-tuning gets you past better context and better data. Number two, treat AI as real. Do not keep experimenting with it. There is a report that said 62% of companies are trying something with agentic AI while only 28% are scaling, because you need real funding and real resourcing. Do not treat AI as a production experiment. Take it seriously and make it mainstream. If you treat it as a side project, it is not going to work. You need to treat it as a main project.

Matt: That is a really good piece of advice. You need to go all in, otherwise you are always second-guessing and never taking full advantage of it. Thank you so much, Ajay, for this afternoon’s conversation. This has been tremendously valuable, and thank you for the level of detail. I hope to have you back soon.

Ajay: Thanks, Matt. I would love to be back soon talking about success stories. I am interested in where you go, because I know you started with MCP and have now expanded into agentic AI. All the best. One last call to action: for anyone listening, connect with me on LinkedIn and let us talk about how you can leverage what we have done, whether that is understanding it or building use cases. It gives me satisfaction to help someone do something good with AI and MCP.

Matt: Absolutely. Anyone can get in touch with Ajay. We have been Agents After Dark. Thank you very much, and speak again soon.