Are internal developer portals dead? In this RedMonk conversation, Kate Holterhoff talks with Balaji Sivasubramanian, Senior Director, Product Management, Agentic AI Developer Platform at Red Hat, about why he isn’t convinced. While some thought leaders claim that developers will soon live inside their own coding agents, making portals obsolete, Balaji argues that enterprises still need the golden paths and guardrails IDPs provide. Balaji’s case is that a portal’s UI matters less now, while the curated, verified context behind it matters more. Along the way they get into MCP’s limits, context freshness, the rising cost of tokens, and why human judgment still beats an agent at some tasks.

This RedMonk conversation is sponsored by Red Hat.

Links

• LinkedIn: Balaji Sivasubramanian
• Balaji Sivasubramanian, “Why developer portals matter more in the age of AI agents,” Red Hat blog, 7 May 2026.
• Balaji Sivasubramanian’s Blog, Medium.
• DevAI – Hosted by Balaji Sivasubramanian, YouTube.

Transcript

[00:00:04] Kate Holterhoff: Hello and welcome to this RedMonk Conversation. My name is Kate Holterhoff. I’m a senior analyst at RedMonk. And with me today I’ve got Balaji Sivasubramanian. He’s the Senior Director, Product Management Agentic AI developer platform at Red Hat. Balaji, thanks so much for joining me on the MonkCast.

[00:00:19] Balaji Sivasubramanian: Thanks, Kate. Thanks for inviting me. Happy to see you at the Red Hat Summit last month, and good to see you in person and looking forward to this conversation.

[00:00:26] Kate Holterhoff: Yes, I know that was such a great event. I did a quick take as part of it, so got to collect my thoughts, but it was a lot of fun to have it in my own backyard here in Atlanta, but also just to be able to, to see so many interesting folks and have a lot of really exciting conversations here. So yes, and Balaji and I got to go out to dinner, which was awesome. So it’s always great to get out of just talking via Zoom.

[00:00:48] Balaji Sivasubramanian: Yeah, absolutely.

[00:00:49] Kate Holterhoff: Well, let’s just begin by having you introduce yourself. Can you tell me a little bit about what you do at Red Hat?

[00:00:54] Balaji Sivasubramanian: Yeah, I manage the developer tools and experiences product portfolio for Red Hat. I joined Red Hat three years ago. At that time, ChatGPT was just introduced and the AI was revolutionizing the coding, and this was a great place to be. And because I touch different parts of it, from desktop tools to Claude developer environments to a portal. So it’s a great place to be. And it’s been a great journey the last three years with developers in the center of AI, everything they’re doing. The world has completely changed. So exciting place to be.

[00:01:30] Kate Holterhoff: I have noticed that as well. Yes, the world has completely changed, especially for developers here. Okay, so you know, I invited Balaji on here to talk about a blog post that he wrote recently. I mean, he maintains his own personal blog, which, which is very active, super interesting content there, but also published one on Red Hat’s blog. And the title was Why Developer Portals Matter More in the age of AI Agents, which I can’t think of a more pertinent question and really ties back to actually a lot of the s that we were having at the summit. So this post opens up by saying that there’s a whole bunch of folks who are declaring that internal developer portals are dead here. So, you know, talk to me about the history of this. I mean, we love talking about things being dead, right? You know, DevOps is dead. This is the sort of exaggerated language to try to get attention common in the tech industry here. But where did you first hear that?

[00:02:24] Balaji Sivasubramanian: One of the analysts reposted somebody else’s post echoing the same sentiment. And I’m like, I think it misses a point. So definitely you could potentially use Claude code or things to deploy in certain scenarios. For example, I maintain my own little website and I just use Claude code to deploy via Vercel and deploy everything without going anywhere. It goes into portal, of course, a small one person team, but in a large regular enterprise, it’s not right. So I’m going to try to actually explain why it’s not the right approach.

[00:02:56] Kate Holterhoff: Yeah. Okay. So some thought leaders were coming out with these things. And the idea is that we’re all just going to be using our individual Claudes, Codexes, etc., as, as personal portals. But you’re arguing that in the enterprise that just isn’t the case and it doesn’t make sense. I tend to agree with you here, but I would say just taking a step out that that sort of larger around using a multi-purpose agentic platform versus using really targeted one is ongoing. And I feel like your piece sort of contributes to that. We’re trying to work out what, what’s that going to look like in the future here. So you give those skeptics of the IDPs some credit up front, but how much of their case do you actually buy? Here is the portal is a place you visit genuinely finished versus unfashionable, is maybe another way of framing it.

[00:03:49] Balaji Sivasubramanian: Yeah. I mean, before a few years ago, I used to Google to search for things. I go to the Google portal essentially to search for things. Now I don’t, I just go to ChatGPT or Claude to ask the same question. Anything I want I ask ChatGPT because it’s already giving me the right answer. So I think the same way applies to portal also. At the end of the day, humans going to a website is definitely diminishing and people are essentially using developers, particularly or want in their workspace, in their IDE, in their Claude code, for example, and be able to get the information. I think the part that sort of maybe true in that there’s truth to every argument and there’s always something right about it. That’s why it’s actually interesting point. Definitely, if you look over time today, let’s say people are going to a portal more percent than agents. Over time, it’s going to shift. The agent will be the primary consumption of the information in the portal versus a human going and clicking through five clicks to get something. So the real argument is missing the system to the UI. UI is just an interface to that data. The context that’s in there. And so that’s what I was like saying the portal, the UI part may be used less, but the information in there is still highly relevant. And we will talk more about that as we go along in our conversation. Why UI is still relevant in some cases.

[00:05:14] Kate Holterhoff: Yeah, yeah. And the impression that I got was that your own approach to UIs and agents as users has been evolving, that you’re still trying to figure out what that’s going to look like here in the future, even today, right across multiple verticals and, you know, different ways that folks are approaching these tools. So you’ve said that the agent, as a consumer came to you later, that it’s been evolving. Maybe 18 months ago, you hadn’t thought of it, of it in this particular way. So talk to me about what that evolution looked like. How have you, I guess maybe what proof points have occurred in your thinking that have made you change the way that you think through this consumer model of agent behavior as it relates to portals.

[00:05:55] Balaji Sivasubramanian: Yeah. 18 months ago when I wrote the blog in March was before MCP was even discovered. Net net was, I was thinking the portals are a great place for humans to discover learn because that was a phase the world of AI was in an enterprise context. People didn’t know what is it and how do I learn it? How do I discover it? And how do I know what models and what things are appropriate for my enterprise? It’s still a debate even going on right now, but back then it was more like, I don’t know what to run. Am I supposed to run this or not? So for me, the portal was great already. It has a catalog and tech docs and API which supposedly show what is the right way, right way to do other things. Portal could be an AI distribution. It still is true. For example, it’s evolving now. We’re going to soon release something AI catalog essentially models, agents, skills that are relevant for developers to discover. He uses approved skills. Here are the approved agents. So that this still remains either the platform or the portal has a distribution layer of AI content enabling that.

[00:06:58] I think the part that sort of changed, obviously, the introduction of MCP and agent as a consumer. The first iteration was for me was add on a chat bot to the portal and ask questions. Instead of clicking five links, I can just ask a question and then chatbot will answer for me. Instead of me trying to figure out where to click the link. If you look at a typical portal, there’s lots of links and lots of catalog items, lots of information until you have to go through search. Maybe other things, but let’s use chatbot and support [unintelligible]. So that was sort of the evolution where the AI is enabling better use of the portal. What flipped was essentially agent as a consumer and that really was enabled by MCP. The world has evolved. Now agents are essentially how people are wanting to access data. And that’s why this whole thesis came about. Essentially, people are saying, hey, you know, if I don’t need portal anymore, because now I’m sitting in an agent Claude core and be able to get the information. But where are you going to get the information from?

[00:07:54] Kate Holterhoff: Yeah it is. You’re so right about the 18 months thing and so much changes so quickly. I feel like we’re all just sprinting to keep up. Thinking of terms like vibe coding, which hasn’t even been around for two years at this point. Yes. So much moving so fast. We all kind of have to revisit our prior assumptions. This ongoing way that maybe, unprecedented isn’t the right word, but certainly sped up, accelerated. Absolutely. So yeah, I love these ideas. I want to hear from your privileged place of expertise within Red Hat about what you’re seeing in the enterprise specifically here. So you’ve got this great line about agents being confident, hallucination machines, which, you know, from one writer to another is just a great line. Love that. And so, you know, I want to hear maybe about where you’ve seen that play out. Can you give us some concrete examples of hallucinations that you’ve encountered either with some of the folks that you work with at Red Hat, or maybe even in some of your own hobby projects, kicking the tires.

[00:08:56] Balaji Sivasubramanian: Yeah, I think this happens almost every day. You ask an agent to scaffold a new Python project and Python service, for example, and it does a great job. And he pulls the image. It pulls it from the Docker hub, Python 3.7 image. It actually even writes the Kubernetes Yaml file and actually deploys. That’s great. So if you look at it, it does a unit testing, it does every testing it passes and it actually is right. But the problem was, if you’re an enterprise context, now you have a certified or validated images that you want to use in your organizations. For example, you have UBI image of the same Python 3.11 that you should be using. If you pull from Docker Hub, it has 47 vulnerabilities, but via images has zero vulnerabilities that the enterprise already curated for the developer. But the developer, when you use a Claude code, for example, this is actually happened in one case. The agent doesn’t even know that I have an enterprise policy. The problem is the agent is doing the right thing from his perspective, and he actually is okay. But in an enterprise context, you do want to ground it to the enterprise approved images and that’s where the problem comes. Essentially, it’s great at hallucinating something and it’s not trying to be malicious. It’s actually trying to do the right thing, but it doesn’t know the enterprise context. For me, in a real enterprise production use cases, these things really matter, right? A human would know that there’s a policy at the company they work at, but the agents needs to have that information.

[00:10:24] Kate Holterhoff: Right? Right, right. And in terms of what I’m hearing from buyers and folks who are in the industry, everybody’s throwing around the word determinism now because we’re all trying to look for replicable systems that still have the benefits of AI. And I think that that’s, that’s still a tough thing to achieve. And so trying to get past that hallucination.

[00:10:46] Balaji Sivasubramanian: Yeah. So to go back to you that you had that, hey, why do I need a portal in this context? The agent you would have a big vulnerability problem machine up there. You would think, oh, it worked. Of course it worked. You didn’t use a portal, but it worked. But then if you had a portal, you would use a scaffolder you would you would use an approved path, golden path. It already makes sure that you have the right image before you go to the production. That way, the developer does not have to know. The agent does not have to know what is the right way to go about it. It is already done for you. And that’s where I’m saying is you can’t just like throw away the golden path. And the concept of a portal is one part of it. The actual value of portals is what matters here. This is a good example of how you would avoid a problem in a production.

[00:11:30] Kate Holterhoff: Okay. Let’s dive in to the UI part of this a little bit. So you argue that human friendly UIs are not necessarily agent friendly APIs. So is serving agents genuinely different than in terms of building a portal? Or is it like the same sort of, you know, portal with the bolted on protocols just with, under a new name.

[00:11:54] Balaji Sivasubramanian: The agents can definitely leverage the existing scaffolders, for example. That’s why the MCP allows them to expose the same ways, but agents can use other protocols. I think I’ve seen people wanting to use CLI or even better documentation to serve the agent. Agents don’t have eyeballs, so you don’t have to worry about a UI way of providing information. Um, definitely use existing APIs and any of these things work. API, CLI, documentation, MCP, any of them work to answer agents what’s available inside the portal basically. Compared to humans, humans typically require UI based solutions.

[00:12:34] Kate Holterhoff: So you point out that agents break old machinery. So permission models, they don’t know what an agent is. Audit logs can’t capture, you know, what agent Y that ran X number of actions, right? And all of this leads to bottlenecks. And we’ve written a little bit about this at RedMonk. I guess I’m interested in which of these you consider to be the most difficult to address when it comes to portals.

[00:12:56] Balaji Sivasubramanian: Yeah. I think the main point is if you look at permissions. Agent acting on behalf of the humans, and that’s delegation, that’s understandable. But the problem with that is that humans, let’s say I have an approval to create a database, but then agent can create 30 databases. Is it right? I mean, I do have permission to create a database, but the problem with agents or they’re not deterministic, right? So for example, I can write a script right now that creates a database. It’s a deterministic script. It goes through steps and it creates a database. It is acting on behalf of me. And that’s a reasonable thing. But the problem with agents is obviously now you have an agent that could hallucinate something and agent could delegate to another agent. So basically I am the user. I just said, do something and I walked away. And then you could have four agents down and you could do something that I don’t know whether I actually even did to it. So it could be based on a context. You could say go delete the database or something. You have access to doing that. So that’s the problem. So the real question is not like, do we need a different permission model? Definitely, I think there’s work going on around creating a non-human identity. So it’s a human identity which is a non-human identity. And then you can have policies for that differently. So you don’t want to have the same policy.

[00:14:10] Humans you can say this, but then the agent acting on behalf of humans, you probably have to have some additional controls. You don’t want that 30 database creation problem because that’s not a normal human behavior. So humans will stop doing that. So I think that’s where the permission model needs to be probably have a policy attached to it. Or I think there’s some work going on with AWS, Okta and Microsoft, Entra. There is work going on around this. Essentially, you don’t treat agent and humans the same way. So that’s one part of it. When it comes to audit, the volume problem. With humans, you could see one action done by the humans. Now you have 200 actions done in such a rapid space. How it happened, you will probably have a hard time figuring it out. What caused what? Because if you’re just looking at actions by me in a real world, you’ll see, okay, I clicked this scaffolder it created a bunch of things. Very simple, very easy to follow. But if I look at the same audit log later, Balaji called like 200 things. And why did he do that? I can’t even answer the question because I didn’t do it. The agent did it. So we need to figure out how do I sort this out? How do I solve this problem? For example, if you look at SOC analysts or compliance people, they still want to hold it, right? Because at the end of the day, it doesn’t matter whether the agent did it.

[00:15:28] If you do financial violation, you can’t say, well, sorry, agent did it. Now you still pay the price. So I think it becomes a challenge. It’s a different problem. The last part I think you asked like what is still hard. Approvals is hard as well. Like you can see already in coding, humans create a code and then humans approve the code. It’s a lot easier 1 to 1. I can deal with it because there’s only one PR coming in once a month from a developer. Now it’s 100 PRs in a day or an hour. So who’s going to review it? So if agent approves everything, an AI review an AI, it becomes a bigger problem, essentially. Now 100 PRs came in, 100 PRs got approved. You can obviously have a level of approvals, something very simple, go approve it. But then it still creates a lot of human tasks. At the end of it, you were doing everything slowly. Everything was built for slow, but now everything is so fast. Like it created such a problem on certain areas, and it created another sort of problem on other areas. And since it’s all probabilistic, it’s put AI to solve AI. But all layers are probabilistic. In the real world, you don’t want to shoot a nuclear bomb because of some AI mistakes.

[00:16:38] Kate Holterhoff: Yeah. Oh, man. Yeah. So much interesting stuff you brought up there. It’s. It’s almost in the sci fi realm of ethics in terms of like, who’s responsible when the agent is the one who is creating these problems? Because at the end of the day, of course, it comes back on the human who at an enterprise organization, uh, it is a little bit difficult to assign accountability to, to, to say during a postmortem, you know, what actually went wrong here? And how do we keep this from happening again? And with the, the acceleration of CI/CD and all of these important parts of code, right? Code is cheap. Now, all, all of us, I think are, are reckoning with what this is going to look like in the future. So I love the idea of including portals in that.

[00:17:23] Balaji Sivasubramanian: Yeah. It’s really beyond coding. I think the real challenge happens in sort of the non coding situations. There’s a report from DX. The number of pull requests is like 30 to 60% higher. The business outcome is only 8 to 15% higher. So the thing is you created a huge PR, but that doesn’t mean you can actually take it to production. There’s definitely more to this problem.

[00:17:46] Kate Holterhoff: Mhm.

[00:17:47] Balaji Sivasubramanian: A non coding situation that’s even more higher stakes approving expense reports. You’ve seen examples where chatbot creates a refund policy, which is different from what the company says. And there’s a lot of real problems could happen if humans are not in the loop or humans couldn’t review in time. The policy has to be put in place like tight guardrails. It’s an evolving problem.

[00:18:08] Kate Holterhoff: I think it’s worthwhile to pause on that. So thank you for just drawing our attention to that, that macro idea because I agree it’s it’s beyond coding. It goes outside of that. I most of the conversations I have around security and acceleration actually have to do with supply chain security. So what you’re saying about PRs is absolutely part of that. Okay. So the next part of your blog that I found very interesting, again, you’re quite the wordsmith is when you talk about ticket queues with a portal on top, just to be like, what does that mean? When you when you talk about that, like help contextualize that idea.

[00:18:44] Balaji Sivasubramanian: Platform teams, if they’re still using like a ServiceNow ticketing system, they created an interface to it. But at the end of the day, it still creates a ticket and then you’re still solving it manually. There’s a large bank that used to work with. They have 10,000 tickets per month because they have a lot of developers, and then they create a lot of tickets, but they’re still doing it manually. So the platform engineering team essentially is solving whack a mole, basically. So I think the real thing is to be able to build these scaffolding so that self-service can be enabled. And that’s really how they solve the problem of doing that, essentially, so that the developers can self-serve themselves rather than the platform team, essentially solving the ticket queue so that the platform needs to be treated as a product so that people can self-service, for example. And so anyway, that was my point. So that the platform needs love to make it worthy. Now, with AI, it’s even more important because if you don’t have a good processes, AI cannot solve your problem just because you have Claude. Claude cannot solve a badly designed system. If it’s going to create a ticket, then you didn’t solve anything. You have Claude create a ticket for you. That’s that’s all you did. You haven’t done anything to, to really solve anything.

[00:19:56] Kate Holterhoff: Right, right, right. Which is making me again, think about this at a more organizational level. And so I’m wondering, because these these bottlenecks are shifting, right? And some things are easier to do. Some things are harder. Would you argue that resources within an organization then need to shift? Do we need to invest more in some that maybe didn’t need that sort of investment in the past?

[00:20:20] Balaji Sivasubramanian: Yeah, absolutely. Like I said, one of the team I was talking to, they have 20 people, so-called platform engineering, but they have to do a lot of things right. And if the volume of tickets is like 10,000 tickets, they can’t do anything else. So they need to feed away some time to invest in building these platforms so that that you can scale. And so absolutely, I think the investment has to be…The thing is, obviously, if you are getting that many volume of tickets, you’re never going to solve, you’re never going to get out of that jail on that because it’s already overwhelmed. But you need to figure out a way to a high value things you can automate, you can make it self-service and then try to get more time, more and more time so that you can actually do more things. I mean, obviously, they can use agents and other things to automate some of the decisioning themselves, but ideally you want to have everything bolted down to the platform. So the platform itself has the guardrails as the ability to do it for, for the developers.

[00:21:14] Kate Holterhoff: Okay. So the sense that I get is that it’s enterprise complexity that is this deciding factor. So does that mean that you are implicitly conceding that the skeptics are right for the small single Claude team that all sits on one Slack channel you know? So I guess where’s the line where this matters?

[00:21:34] Balaji Sivasubramanian: Yeah, if you’re a small team, like I was saying, I was the only dev in my own project, and I could do it without any portals. I don’t need a portal. Everything is in my head so I can do it. And I think if you have a small team where you can just slack somebody and ask a question, but it obviously breaks down in a larger company, I would say maybe you’re about less than 50 sort of company and you’re still maybe a single Claude, very constrained environments or very deterministic. You’re still in the early stages. I think it makes sense. But where I work, I don’t even see anybody because they’re distributed all around the world. And there’s no way that I could actually know what is right. I don’t want to do it myself either. I don’t want to make a mistake and cause a production down. So I think you need to build something that is available 24/7 and for humans and agents, and that requires some work. So I would say that would be the distinction. Multi team multi-Claude complex applications, higher security risks, like compliance, like regulated industries. I mean, you can’t just live code yourself. There’s no way.

[00:22:37] Kate Holterhoff: Yeah. It’s funny, I part of me as an inveterate hobbyist and a, a vibe coder, part of me does feel like I would benefit, even though it’s just me from having that sort of guardrail because I, when I come back to my projects, I forget like old Kate is not today Kate. I forget what I’ve done, I forget why I did it. And of course, who wants to write documentation for themselves. But you know, there’s no one that needs it more than you. So than me at least.

[00:23:05] Balaji Sivasubramanian: Having the skills, for example, we can create our own skills to guardrail ourselves so that you don’t have to tell Claude every time a new session starts what is right, what I want to do and how do I push something to production? Or how do I do certain things, I think. So you can solve with sharing of skills. Here’s a bunch of skills. All of us share the skills and that’s reasonable. But I think that’s just one part of solving the problem. How many skills would you create and and how do you audit if you have a scaffold or you can part it better than a skills auditing skills auditing essentially is knowledge you’re giving to the agent at the runtime to do some things. Again, you can’t audit that. And, and he could still go wrong because it is still probabilistic approach. I was talking to the CEO of Akka on one of my podcasts. You have to assume it’s never going to be 100% correct. Ai is neural networks. And it’s like humans also. Humans also aren’t ever a hundred percent right. You have to assume it’s going to go wrong. The question is, when you go wrong, what is your blast radius? And the more grounded you are, the more closer you can get to less blast radius.

[00:24:08] Kate Holterhoff: Right, yeah. Okay, that makes sense. So I want to talk about another project that you’ve written about. And I mean, my main takeaway from it was that you spun up a Redis project. You were kind of kicking the tires there and you were debating like, what is the, the line between the plumbing that you outsource and the things that you can’t like, wait, what? How do we discover where judgment fits in here? So instead of me trying to summarize what that project looked like, would you mind sharing with us? Like, what is it that you built and what were some of your takeaways?

[00:24:39] Balaji Sivasubramanian: Yeah, the models are really awesome. The models are not the bottleneck anymore. We just got Fable, the Claude model. And so I think the models are not the problem. The real problem essentially is the context. So when you want to build a production agent, we do that for our own products. How does it remember the conversation? For example, you’re talking to ChatGPT or Claude. You know that the agent is very smart because he remembers who you are. He doesn’t answer the same way for you versus for me because he understands who you are. So that kind of a short term memory session, memory, long term memory, these are really valuable aspects of production agents. And so that it doesn’t start cold every time it starts up. I don’t want to ask the same question. I know what your preferences are. I know what your background is. And these are some of the sort of components of production agents. There’s lots of like context, memory, like the organizational context, memory. The biggest thing you’re hearing nowadays is everybody is running out of tokens in one month or two months or three months. So cache is very important part where you’re if 5 developers ask the same question, you’re going to have five different times Fable is going to be used to, to generate some output. And that will be very expensive. So how do you store some of the cache? I think the biggest thing is that obviously those are nice, you know, where you can lower your API cost. You can have short term long term memory. But the real thing is there’s a lot of data in the enterprise that needs to be brought to the agent for it to make sense, and then the freshness of that information is also relevant.

[00:26:08] You don’t want data that’s not right. That’s not updated recently, for example. So that is the whole thing is, is a challenge. So there are different aspects. So the agent needs all of these things. Like every time every agent needs the same information like memory and caching and contextual data. I think these are all are the infrastructure problem. It has got nothing to do whether you’re working on a customer service chatbot or some other things. This information, this infra to get that information. The context varies obviously for different use cases, but this whole infra is just infra. And what my idea was that let’s just outsource that work. You don’t need to do that work because that there’s no value in it, particularly for platform engineers. I don’t want to figure all of this things out. I just want to worry about my other problem, which I just talked about. What is the scaffold where I should be building? Last thing I want to do is figure out this, this basic one layer down infra layer, right? So that’s what I was saying is that this is just one example. There’s more where you just want to buy the Vector DB or caching or retrieval. These are what you call commodity. Not commodity, but let’s just say that it’s a base thing as a as an application team or a platform team. I would rather get it, buy it from somebody else.

[00:27:20] Kate Holterhoff: I think what you’re pointing to is, is something that I saw you flag in a number of your your blog posts here. And that’s the problem that, you know, keeping context current and authoritative as systems change is, is an extreme challenge right now. So, you know, in the Redis test, you know, the freshness piece seemed to be the component that you couldn’t even evaluate. So if I guess if freshness is the soft spot under the, the whole thing, are we just teaching agents to act confidently on stale data? I mean, perhaps I’m paying playing devil’s advocate here, but like, where does that fit in?

[00:27:55] Balaji Sivasubramanian: You’re on to something that is actually, I wrote a blog about it. It will come out in an hour. But basically the rag and other things we’ve built, industry has built is good at retrieving the content. So using semantic search to find the right content, he doesn’t know it’s right. So you have agent call up backstage portal and say, hey, who owns this service? It tells you it’s in catalog.aml and it’s team A, but the problem is it gives you the answer confidently and then agent says, okay, the service is done. Let me open up a ticket to TBA, but that’s not the right team anymore. It got the right information. It got what it thought it was the right information. It just retrieved it right now from a system of record, for example. And it is wrong or it is stale, basically. So it acted confidently. That’s the problem, right? Essentially, because as humans, we have a better sense of things. You will look at when it was updated. What is the freshness of the data? This was updated two years ago, but if you look at the service, Bob from team B is the one who’s maintaining the code right now, or Alice from team C is the one who’s on call duty.

[00:29:01] So it is multiple data points. We can correlate as humans and say, okay, you know what? There’s something wrong here because I don’t think team A is the right one because it’s stale, first of all. And so that’s the challenge that we need to solve as a industry, verification. So today it’s more like retrieved content you give to LLM and then you try to make a decision. Basically, the idea is that you have better retrieval. I have great semantically accurate retrieval, which is true, but it’s not. You don’t assume that it’s because you have the better retrieval doesn’t mean you’re better agent. So what you’re saying is we need to retrieve. That’s essentially the evidence. In fact, it will be multiple evidence. In some cases, you need to verify that information. So then you get the better context. That is the right information that you give to the LLM. So if you do that, then you’re, you’re much better off. And so basically you look at the source authority who, where the source coming from and what is the freshness, when was the last updated, for example. And then you want to validate with other sources and you want to see obviously the source freshness as well. And then you get a confidence score.

[00:30:04] So based on that, you give it to the LLM and say, here are three ways I found the data team A, team B, team C, and here’s my confidence level team A, most likely not because it was updated two years ago. Team B and C, more likely team B is more likely because Bob is maintaining that code and maybe he’s the one who’s going to respond. So that is what we need to get into. So it’s not like I’m going to shoot an MCP tool call, get an answer, go. I think, yeah, the world hasn’t gotten there. I mean, it’s almost like a Google search ranking if you think about it that way. How did Google kind of like do when you do a search, it ranks based on is it from the actual website or some blog that wrote about something? It actually tries to use the main website as a source of truth. But agents today don’t have that kind of a sense. It just gets something and then acts on it. So I think we need to figure out a way to go from sort of this to retrieve context to like a verified context. So that’s the blog about. You would see more of the writing. I tagged you.

[00:31:06] Kate Holterhoff: Awesome. Okay. Can’t wait to read it. So you mentioned retrieval. And we’ve also talked about 18 months ago, a lot of the IDP story as it related to AI had to do with like having a chatbot feature for, for the search functionality, right? And so rag was a big part of that in those early days. But now MCP seems to be the thing. You mentioned it earlier, but it’s still young. Are you bullish about MCP? Do you think that that’s where things are trending, or do you think it still lacks some of the functionality that you want in order to connect these disparate systems and ensure that they are fresh?

[00:31:41] Balaji Sivasubramanian: Yeah, exactly. So you already answered my question a little bit. So definitely I’m definitely bullish on a standardized agent access, which is MCP is obviously the first protocol doing it. And I think it has gotten quite a bit of traction. Every major vendor is creating MCP for their, for their products. I think it’s definitely on the way to becoming sort of the standard, at least for that side of the house. You still have other protocols like A2A and ACP recently. So there are different protocols coming to solve different aspects of the problem. But and by the way, MCP by itself, like we just talked about, an MCP agent to a catalog gets the stale information. It doesn’t solve the problem. I mean, it’s good that it got the information and it could go to confluence and go to GitHub and go to PagerDuty and get different information about the same problem. So it is just a retrieval method. It’s just a way to connect to something and get information back. It is not solving the problem. I just talked earlier, which is the verification of information. So in some sense is MCP the winner? I’ve seen like examples like one of the A16z VC was like CLI is the right way. And we have seen multiple even for our products, we are thinking about doing obviously a better documentation was a helpful thing. Obviously API already existed. CLI could be another one we could do to make it better. So these things will evolve. I’m not worried about it. I think MCP is definitely is a obviously accepted protocol at this point. It doesn’t solve your governance or trust or the quality issues that we talked about.

[00:33:12] Kate Holterhoff: Yeah. That resonates. So I want to talk about again, some of these organizational issues that are newly important in our agentic era. And that has to do with like gatekeeping and making sure that golden paths support folks like product managers and these, you know, team leads who are now shipping agents, how do we make sure that they do it in a safe way? What sort of advice are you giving to the teams at Red Hat and other organizations you’re working with to make sure that we’re doing this in a way that ensures that these are secure, compliant, etc..

[00:33:46] Balaji Sivasubramanian: Like anything else, you want to do a crawl, walk, run sort of model. Obviously, this is a spectrum basically of what you can do initially and obviously start with the easier ones. Summarization, kind of use cases, maybe read only agents and then you slowly getting into autonomous activities. I mean human initiated versus agent initiated is another thing. Human initiated is maybe the first one. Humans can make a decision on when to initiate something and obviously make sure it works correctly. I do believe that you’re going to have lots of agents created by a lot of people, either personal agents they create for themselves, which acts on some data. Also I’m seeing is we talked about this portal where people bring their own agents. These are specialized agents that are created from people of authority. Let’s say I want to do migration, for example, and I know exactly how the migration framework works. And somebody creates it tested over a period of time, but they don’t just give it a production agent without testing it, validating it like a small team, gradually making it available to a larger audience. So I think it’s anything else adopting new technologies. You do this the crawl, walk and run approach.

[00:34:57] Kate Holterhoff: Okay. And then applying this to how you a lot of these lessons that you’ve learned and sort of your argument around like where the future of portals is heading, that they’re not dead, they just need to, to maybe adapt. How does Red Hat’s developer hub factor into all these things that you’ve noticed around platforms today.

[00:35:18] Balaji Sivasubramanian: They’re all just an example of a portal. I’m sort of, all the things I talked about I’m trying to make it happen in that portal. So we talked about, we started with enabling just access to information, the assets in the catalog and obviously templates and other things one can do as well. And people want to have access to agents and ability to enable MCP for everything. So the humans doesn’t have to come to the portal at all and trigger something. They could just trigger it from their Claude code, etc.. I think the other things that we’re looking at, I alluded to already, is that people want to build specialized agents and have them connect to the portal. So why would developers will come to a portal today? They used to come there or they’re coming there right now to look at certain information. The portal, for example, has a plugins that allows you to see five different tools in one place. That’s really powerful if you think about it. Let’s say I’m running an application, I’m using GitHub Jira tickets. I’m using different pipelines or deployment technologies. I’m monitoring Quay or Docker Hub to store stuff that’s like 10, 15 tools. There’s so many tools you can have. So today, the portal already gives you all the information in one spot. Humans are better at looking at this thing quickly, right? If I have to ask an agent and have it pull all this data over a long period of time, it’s going to cost me like $10.

[00:36:35] I could have just clicked it and gotten all the information. It may not even be right because I don’t know if it’s right. So I could have just go to the portal and just click it and be done with it. So in some ways it’s still going to remain. So. Now the same information can be shared from the agents also. Let’s say instead of agent going to these ten different tools, I could be the agent and I could be talking to Developer Hub and Developer Hub, it already has a curated data from the plugins, so it could serve that information to the agent. So the portal becomes sort of a tiered layer. I’ve already have curated data of that application. So you agent don’t have to go look around for it. I already have it. It’s called plugins and already have it, so I was going to give it to you. Don’t waste your time. So don’t waste your tokens. So we can actually give it to you. So anyway, the point is that’s a useful, interesting use case where you say why portal anymore? Because I have the data for you in an aggregated format and that’s a potential value people are moving from. I want to come to a portal to look at things to I want to take actions. So that’s where this integration with agents, your own agents make sense. For example, I see a problem, let’s say the service is down or having errors.

[00:37:44] Today I can only look at it. I’m like, okay, the service is down. Now I have to hop off to a Datadog or Dynatrace portal and figure out what the errors are. Instead, I could just be on the portal and say the service is down. Can you troubleshoot this? Then the portal is not trained to troubleshoot in your organization. So you could create an SRE agent that’s customized for you, that knows your organizational context, that knows what run books I can run to remediate the problem. From a developer point of view, though, he goes there, he sees something today, he can only see it and do something else later. Now he can take actions so he can actually say go fix it, and then it immediately goes and fixes it. So in a way, now portal becomes interesting. I go to portal because, hey, it actually does things for me now. So I mean, I think these are all different ways to skin the cat. You could obviously argue I could on Claude, do the same thing. That’s fine. I believe that the world will not be like one way for everything. I think there’ll be a long tail of people who want to still have a UI way to go about it, and people who want to just do an agentic way. Those are all fair games, and our job is to be neutral and serve you whichever way you want.

[00:38:53] Kate Holterhoff: Fair enough. I got one last question for you and then we will wrap this up. So much good content here. I think I want to end on thinking about the future here and where you see portals going in the next five, ten years. So, I mean, we’ve already discussed that there is an energetic user for these portals, and that’s causing thought leaders like yourself to, to really have to reevaluate what it is that portals even can do here. Do you think that in the future, the the balance is going to tip toward agent users? And if that’s the case, then are we going to get rid of this whole single pane of glass sort of approach to the UI? And we’ll just let that, you know, crumble, right? We don’t need that anymore. That’s, that’s not important. We don’t, we maybe we’ll just have this in the CLI, like you had mentioned as like a, an access route. Are you anticipating that you, that like human users, users are not even going to be accessing these portals at some point in the, in the future and that it’ll be completely a computer resource that, that we just maintain and keep tabs on.

[00:40:00] Balaji Sivasubramanian: Yeah. First of all, a token costs money and it’s not free that you can just do agents. And I’m sure that the subsidization will go away. I try to look up who owns a certain product within my company, and I asked Claude, and it took me like five minutes to get back an answer. I could have just went to the directory page and looked at myself. In some ways, token costs money. Humans can make better judgments in some of the cases, and humans are faster for many of the tasks. I can look at a large UI dashboard with all kinds of services and where the problems are happening like that, because there’s a red button there versus everything else is green. If you ask an agent to figure the same information out, it’s going to take you ten minutes and it’s going to burn a lot of tokens and then come back and say the same answer. I’m not saying you won’t say the same answer, but then it took ten minutes to do something that I could have just looked at it visually and okay, there’s a red button there. So I think humans are also smarter for some tasks.

[00:40:55] I think we can quickly triage things. The AI is essentially trying to become a human, a better human, faster even in some cases. But we are actually the smartest brain in the world, so to say. And so I think we can do things faster too. So I think the right way to look at anything actually is not just a portal issue. It’s basically anything is what’s the fastest way to get the things I want. I think people will tend to do that. And I would argue that it’s not always CLI or agents. There’s a place for it. 100%. And it’s accelerating a lot of work. But there are certain cases where UI based solutions. I think we’re arguing for UI based solutions now, not just a portal, you know, like it still has a value. It’s still has a reason to exist. And so I think portal would be fine. Like I said, we’re going to evolve into a more useful context layer, verified context layer. If it can be. That would be the best way to essentially solve a real enterprise problem. Agents needs that and we can be the layer of that.

[00:41:55] Kate Holterhoff: Okay. So things are evolving. Absolutely. But the humans are still necessary. We still need taste, judgment, all of these things that our brains are well equipped to accomplish. You’re not worried about us being replaced anytime soon?

[00:42:11] Balaji Sivasubramanian: I hope not. We’d still be doing podcasts. Well, we’re already getting replaced. Google podcasts already does it itself. And I just dropped the notes and it will do a great podcast.

[00:42:21] Kate Holterhoff: Yeah. The horror. Yeah. No, well, I 100% with you. Let’s, let’s make sure that the humans are still doing the podcasts at least because I can’t take it. Okay. Well, Balaji, it’s been an absolute pleasure speaking with you today. Looking forward to reading your future blog posts on this subject. It’s super important. Extremely interesting. The folks at Red Hat are doing a lot of really important work around this, and just kind of thinking through what this future is going to look like because my goodness, you know, there’s, there’s so much at play right now. Things are moving so fast. So yeah, again, I appreciate you coming on here to to give me your perspective here.

[00:42:56] Balaji Sivasubramanian: Thank you. It was great talking to you. Appreciate you inviting me and glad we could do it. Yeah.

[00:43:00] Kate Holterhoff: Me too. Where are you directing folks in terms of your social media presence or your blog, how can folks, you know, get a taste of your writing for themselves?

[00:43:09] Balaji Sivasubramanian: I think medium is the way to go. Or I have a podcast called DevAI podcast. I try to bring thought leaders into the conversation as well. So maybe you can link it.

[00:43:19] Kate Holterhoff: Yes, I’ll include those in the show notes. Okay, so we’ve got your blog. We’ve got your podcast here, the blog post that’s from Red Hat. I’ll include all those in the show notes and let’s go ahead and wrap up then. Again, my name is Kate Holterhoff. I’m a senior analyst at RedMonk. My guest today has been Balaji from Red Hat. If you enjoyed this conversation, please like subscribe and review the MonkCast on your podcast platform of choice. If you’re watching us on RedMonk’s YouTube channel, please like and subscribe and engage with us in the comments.