You know Herman, I was looking at the setup Daniel uses to send us these prompts every week, and it struck me just how strange it is. Here we are, deep into the era of agentic artificial intelligence, discussing the most sophisticated systems on the planet, and yet the primary way we interact with these agents is through apps like Telegram or Slack. It is almost like we have built a Ferrari engine but we are steering it with a pair of old bicycle handlebars.
Herman Poppleberry here, and Corn, you have hit on one of the most fascinating bottlenecks in the industry right now. It is what I call the U I Gap. We have these incredibly capable agents that can browse the web, write code, and manage entire workflows, but because building a custom frontend is such a massive chore, everyone just defaults to the easiest path. And right now, that path leads straight to a chat box designed in the mid two thousand tens. Our friend Daniel is a perfect example. He uses Telegram as his control surface because it is always there, it is cross platform, and the API is incredibly easy to hook into. But as we are going to explore today, that convenience comes with some really heavy technical debt.
It is the Telegram as a backend paradox. It feels like a hack because it is a hack. But it is a hack that has become the industry standard for independent builders and people using platforms like n eight n. Today we are diving into why we are stuck in this messaging app loop, the actual technical limitations of using Slack or Discord as an operating system for agents, and whether we are finally seeing the birth of a true agent native interface. This is episode one thousand fifty six of My Weird Prompts.
It is funny you mentioned n eight n, because that is where a lot of this started. If you are a builder and you create a complex workflow that automates your entire calendar or your research process, you need a way to trigger it. You could build a custom React app, host it on Vercel, manage authentication, and figure out a mobile layout. Or, you can just grab a Telegram bot token in thirty seconds and have a working interface on your phone immediately. The friction difference is astronomical. When you are in that prototyping phase, you don't want to spend three days fighting with C S S grid layouts; you want to see if the agent can actually book the haircut.
Right, but that ease of use hides a lot of structural problems. We are basically forcing high dimensional intelligence through a one dimensional straw. When you are using a messaging app as your U I, you are restricted by whatever that platform allows you to do. You are playing in their walled garden. So, Herman, let's frame this for everyone. Why are we building the future of intelligence on top of platforms that were originally designed for human to human gossip?
It comes down to the distribution and the notification layer. A messaging app solved the two hardest problems of software for you for free. First, it is already on your device and you already look at it fifty times a day. Second, it has a built in push notification system that actually works. If an agent needs to ask you a human in the loop question, like, hey, should I buy this flight or not, a Telegram message is a thousand times more likely to get an immediate answer than an email or a custom dashboard that you have to remember to check. But, as you said, we are pushing intelligence through a straw. These platforms were never meant to handle complex state, or multi modal feedback, or the kind of asynchronous callbacks that a true agent needs.
I want to get into the technical weeds here because I think people underestimate how much the API design of these apps shapes the behavior of the A I. For instance, let's talk about Telegram versus Slack. I have noticed that most agent builders prefer Telegram. Is that just because it is more open, or is there something specific in the API that makes it a better control surface?
Telegram is currently the gold standard for hacky agent U Is for a few very specific reasons. The first is the inline keyboard. If you have ever seen those little buttons that appear right under a message, that is a huge deal for agents. It allows the agent to present discrete choices to the user without the user having to type anything. It turns a conversation into a structured interaction. But the real game changer, and something we have seen explode in the last year, is the Telegram Mini Apps platform. It basically allows you to launch a full screen web view inside the chat. So you get the distribution of a chat app but the flexibility of a real frontend. As of early twenty twenty six, these Mini Apps have become the go to move for anyone trying to bridge the gap between a simple bot and a real application.
Compare that to Slack. I have used some A I integrations in Slack and they always feel a bit more clunky.
Slack uses something called the Block Kit. It is very structured and very corporate. It is great for building forms or simple approvals, but it is incredibly rigid. If you want to do anything dynamic or high frequency, Slack starts to feel like a straightjacket. Plus, Slack has some pretty aggressive rate limits. If you have an agent that is thinking out loud and sending ten updates a second as it processes information, Slack will shut that down real fast. Telegram is generally much more permissive with that kind of high frequency messaging. And let's not even get started on Discord. Discord is great for communities, but their bot API is built around the idea of a listener, not necessarily a personal assistant. You have to deal with complex permission scopes and the constant threat of being flagged as a spam bot if your agent gets too chatty.
This brings up the issue of state management. In a normal app, the frontend and backend share a common understanding of what is happening right now. But in a chat app, the only state is the message history. If the agent needs to remember that three messages ago you were talking about a specific file, it has to parse that history every single time. How does that affect the latency and the cost of running these things?
That is a massive pain point. We talked about this a bit in episode nine hundred thirty eight when we discussed the Agent Operating System. When you use a chat app as your U I, you are essentially stateless. Every time the user sends a message, your backend gets a webhook. It has no idea what happened before unless you have built a separate database to track the conversation I D and the context. Developers end up having to build this whole middleware layer just to bridge the gap between a stateless chat API and a stateful A I agent. You are essentially building a second brain just to help the agent remember what it said in the chat box. It is incredibly inefficient.
And then you hit the context window problem. Because messaging platforms often truncate history or make it difficult to pull old messages efficiently, right?
If you want to give your agent the full context of a long project discussed over three weeks in a Telegram group, you can't just expect the API to hand that to you easily in a way that is ready for a large language model. You end up building a custom vector store just to manage the chat history of the very U I you are using. It is redundant work. You are paying for the storage, you are paying for the embedding tokens, and you are paying for the compute to search that history, all because the U I layer doesn't have a native memory.
I also want to touch on the latency issue with the polling versus webhook models. Most of these bots rely on webhooks, where the messaging platform sends a data packet to your server whenever something happens. But that adds layers of network hops. If I am trying to have a low latency voice conversation with an agent, surely Telegram or Discord is the worst place to do it?
Oh, it is terrible for voice. If you are trying to do real time audio, like we see with the latest models that have sub five hundred millisecond response times, the overhead of a messaging app API kills the experience. You are adding maybe two hundred or three hundred milliseconds of just API overhead before the model even starts thinking. This is why we are seeing a shift away from these platforms for anything that involves voice or high speed interaction. Discord is a bit better because they have native voice channels and a more robust Web Socket connection for their gateway, but even then, you are still fighting their protocol rather than building your own optimized one. You are trying to stream audio through a system designed for text packets. It is like trying to run a marathon in a deep sea diving suit.
It feels like we are in this awkward middle ground where the tools for building agents have outpaced the tools for interacting with them. We have these powerful frameworks like LangChain or n eight n, but they are all just pointing toward a webhook U R L for a chat app. What happens when these platforms change the rules? I am thinking about platform risk. We have seen this before in the early days of Twitter or Facebook where developers built entire businesses on their APIs only to have the rug pulled out.
That is the second order effect that worries me the most. If you build your entire agentic workflow around Slack's Block Kit, and Slack decides to change their pricing model or their API structure, your U I is dead. Or even worse, if your agent starts performing tasks that the platform deems a violation of their terms of service, they can ban your bot and you lose your entire interface to your users. We actually touched on this a bit in episode eight hundred thirty five when we talked about red teaming your user experience. If your agent is the one interacting with the U I, you have to worry about the U I itself being a point of failure. You are building on rented land, and the landlord can change the locks at any time.
So if the current state is these hacky workarounds on Telegram and Slack, what does the alternative look like? Are we seeing the rise of dedicated messaging apps that are built specifically for agents? I mean, the prompt asked if there is something out there that supports both voice and text and can plug into various backends.
There are a few emerging players, but it is still early days. We are starting to see the rise of what I call Agent Native U Is. Think of something like the Vercel A I S D K four point zero, which came out late last year. It is not an app you download, but it is a set of tools that makes it so easy to build a custom, high performance agent frontend that the excuse of using Telegram is starting to vanish. It supports things like generative U I, where the agent can actually decide to render a chart or a map or a set of buttons dynamically, rather than just sending text. This is a huge shift because the agent isn't just talking to you; it is building the interface you need in real time.
That is a huge distinction. In Telegram, the agent sends text that might look like a button. In a generative U I, the agent actually sends the code to render a functional component. It is the difference between a waiter describing a menu and a chef actually putting the plate in front of you.
And that leads us to the idea of the Agent Dashboard. If you look at how professional teams are starting to manage agents, they are moving toward local first, Electron based applications. These are apps that live on your desktop, have direct access to your file system, and use Web Socket connections for near zero latency. They don't look like chat boxes; they look like command centers. You have a log of what the agent is doing, a window for its current browser session, a set of toggle switches for its permissions, and yes, a chat box for giving it instructions. But the chat is just one part of the whole.
It sounds like the transition from the command line to the graphical user interface in the eighties. We started with just text because that was what we knew, but eventually we realized that windows and icons and folders were a better way to represent what the computer was actually doing.
That is a perfect analogy. We are in the command line phase of A I agents. Text is the lowest common denominator, so we use it for everything. But agents are not just text generators anymore; they are action engines. They need a way to show you their state. If an agent is halfway through a complex three hour task, a chat app is a terrible way to monitor it. You don't want to scroll through five hundred messages to see where it got stuck. You want a progress bar. You want a status indicator that turns red if there is an error. You want an interrupt button that actually works instantly. Imagine trying to use Photoshop but you have to type move layer three pixels left instead of just dragging it. That is what using Slack for agents feels like right now.
Let's talk about that human in the loop requirement. One of the biggest friction points in agentic workflows is when the agent needs a human to approve something. In a messaging app, that usually looks like a message saying, hey, can I do this? And you type yes. But in a more sophisticated U I, you could have a side by side comparison of what the agent wants to do versus what it was told to do, with a single click to approve or edit.
And that is where the dedicated platforms are starting to win. There are new tools like LangGraph and specialized frontends built on top of it that allow for this kind of granular control. But the problem is distribution. How do I get that sophisticated dashboard onto my phone so I can check it while I am walking the dog? That is why people keep going back to Telegram. It is the only platform that has solved the mobile distribution problem for independent developers. It is a bit of a tragedy, really. We have the technology to build better U Is, but we don't have a better way to get them into people's pockets without going through the App Store gatekeepers.
It is the ultimate convenience trap. You know it is bad for you in the long run, but it is so easy right now. But Herman, I have to ask, what about the privacy and security side of this? If I am running my agent through Discord, Discord sees every single instruction I give it and every single piece of data the agent sends back. For a lot of people, especially in the corporate world, that should be a deal breaker.
It absolutely should be. We covered this in episode ten seventy, discussing the agentic secret gap. When you use a third party messaging app as your U I, you are effectively giving that platform a front row seat to your most sensitive workflows. If your agent has access to your company's financial data and it is reporting its findings to you via a Slack channel, that data is now living on Slack's servers. For a lot of high security environments, that is a non starter. This is why we are seeing a massive push for local first agent interfaces that use encrypted protocols to talk to the backend, bypassing the big messaging platforms entirely. If you are building for enterprise, you cannot use Telegram. Period. You have to build a custom, secure shell.
So, let's look at the specific tools that are trying to bridge this gap. You mentioned Vercel, but are there any standalone apps? Like, if I want an app on my phone that is just for talking to my agents, and it has a great API that I can plug my n eight n workflows into, does that exist yet?
There are a few projects trying to be the browser for agents. One that has been gaining traction is called LibreChat. It is open source, you can self host it, and it acts as a centralized hub for all your different A I models and agents. It has a much more robust U I than a simple chat app, and it supports things like file uploads and custom presets. But even LibreChat is still fundamentally a chat interface. The real holy grail is a platform that treats the agent as a first class citizen, not just a participant in a conversation. We are seeing some movement with things like the MultiOn browser or specialized agents like Devin for software engineering. They don't use Telegram. They build their own custom environments because the work is too complex for a chat box.
What would that look like in practice? If you were designing the perfect agent interface from scratch, what are the three things it must have that Telegram and Slack don't offer?
First, it needs a native state visualization. I should be able to see the agent's thought process, its current task list, and its memory in real time without it cluttering the chat. Think of it like a sidebar that updates as the agent works. Second, it needs multi modal input and output as a core feature, not an afterthought. That means low latency voice, image generation, and the ability to interact with U I elements like sliders or maps directly. Third, it needs a standardized permission system. Instead of just giving an agent full access to my Slack workspace, I should be able to grant it temporary, granular permissions for specific tasks through the U I itself. Like, you have permission to read this one folder for the next ten minutes.
That third point is huge. The current model is very all or nothing. You either give the bot token full access to a channel or you don't. There is no nuance. And that nuance is what we need for agents to become truly useful in our daily lives. We need to be able to trust them.
And trust comes from transparency and control, two things that are very hard to achieve inside someone else's messaging app. When you are on Slack, you are subject to Slack's transparency rules. When you have your own U I, you can see exactly what the agent is doing at every step. This is the difference between a black box and a glass box.
I want to go back to the idea of the agentic operating system. In episode nine hundred thirty eight, we talked about the backend of that, the orchestration layer. But the U I is really the shell of that operating system. If we look at the history of computing, the shell is what defines the user's relationship with the machine. If our shell for A I is a chat box, we will always treat A I as something we talk to. If our shell is a set of tools and dashboards, we will treat it as something that works for us.
That is a profound shift. And I think we are seeing the beginning of that transition right now. In late twenty twenty five and early twenty twenty six, we have seen an explosion of specialized agent environments. These don't use Telegram. They build their own custom environments because the work is too complex for a chat box. The hacky workarounds are mostly for the general purpose, personal assistant type agents. But even those are going to outgrow the chat box soon. We are moving from the era of the chatbot to the era of the agentic workspace.
So if I am a builder right now, and I am currently using Telegram because it is easy, what is the signal that it is time to move off? When have I outgrown the hack?
The signal is when the limitations of the interface start affecting the performance of the agent. If you find yourself having to write complex code to parse user intent because you can't just give them a dropdown menu, you have outgrown it. If your agent is failing because it loses context that the messaging API didn't preserve, you have outgrown it. If you are spending more time managing Slack rate limits than you are improving your agent's logic, you have outgrown it. And most importantly, if you are worried about the security of the data flowing through that third party platform, you should have moved off yesterday.
That is a great rubric. I think a lot of people are at that tipping point and they just don't realize that the tools to build something better are already here. It is no longer a six month project to build a custom frontend. With modern S D Ks like the Vercel A I S D K four point zero, you can do it in a weekend. You can have a streaming, multi modal interface that looks professional and works exactly how you want it to.
It is the difference between being a hobbyist and being a professional in this space. The hobbyists will stay on Telegram because it is fun and easy. The professionals will build their own control surfaces because they need the reliability, the security, and the rich interaction models that a real U I provides. It is about taking ownership of the entire stack, from the model to the mouse click.
We have covered a lot of ground on the technical side, but I want to bring it back to the practical takeaways for our listeners. If you are building agents or even just using them, how should you be thinking about this U I gap?
The first takeaway is to decouple your agent's logic from the delivery mechanism. Do not bake Telegram specific code into your core agentic workflow. Use a middleware layer, something like LangServe or a custom Fast API gateway, so that you can swap out the U I whenever you need to. If you build everything around Slack's specific formatting, you are locking yourself into a dying paradigm. Keep the brain separate from the mouth.
That is smart. It makes your system future proof. What is the second one?
The second takeaway is to start experimenting with agent native U Is. If you haven't looked at things like the Vercel A I S D K or even just building a simple Streamlit dashboard for your n eight n workflows, you are missing out on a lot of power. You will be amazed at how much more capable your agent feels when it has a proper place to display its work. Even a simple dashboard that shows the agent's current task list can make the experience feel ten times more professional.
And the third takeaway for me is the human in the loop aspect. We need to stop thinking of human intervention as a failure of the agent and start thinking of it as a collaboration. A good U I makes that collaboration seamless. A bad U I, like a chat app, makes it a chore. If you find yourself annoyed by your agent's questions, it might not be the agent's fault; it might be that your interface is making the interaction more difficult than it needs to be.
I love that. It is all about reducing the friction of intelligence. Whether that intelligence is artificial or human, the interface is what connects them. If the connection is poor, the results will be poor. This really reminds me of our discussion back in episode five hundred fifty eight about the briefing gateway. We talked about how to stop being pecked by ducks by creating a middleware that filters communication. A dedicated agent U I is effectively a more sophisticated version of that gateway. It is a way to manage the flow of information so that it is useful, not overwhelming.
So, as we look toward the future, do you think we will ever see a universal agent control protocol? Something like H T T P but for interacting with agents, where any U I can talk to any agent backend?
There are people working on it. We are seeing proposals for things like the Agent Protocol, which tries to standardize how we define tasks, steps, and artifacts. If that gains widespread adoption, then the U I gap will naturally close because builders will be able to create one frontend that works with every agent framework. That is the dream. A world where you have your favorite agent browser, and you just plug in the U R Ls for your various agents, and it just works. You get your preferred interface, your preferred security settings, and your preferred notification system, regardless of who built the agent.
A browser for the agentic web. I like the sound of that. It feels like we are right on the cusp of it. It is the natural evolution of the internet. We went from static pages to interactive apps, and now we are moving to autonomous agents. Each step requires a new kind of window into the world.
We are. The infrastructure is being laid down as we speak. The transition from these hacky messaging app workarounds to proper, native interfaces is going to be one of the biggest stories in A I over the next year or two. It is going to be the moment where A I stops being a novelty we chat with and starts being a tool we truly live with.
Well, I think that is a perfect place to wrap up this deep dive. It is clear that while Telegram and Slack have served us well as a starting point, they are not the end state for how we will interact with artificial intelligence. They were the training wheels, and it is time to take them off.
Not even close. We are just getting started. And hey, if you have been enjoying these deep dives into the plumbing of the A I revolution, we would really appreciate it if you could leave us a review on your favorite podcast app. It genuinely helps other people find the show and keeps us motivated to keep digging into these weird prompts.
It really does. Thank you to Daniel for sending this one in. It is a topic that has been on my mind every time I open Telegram to check on our episode notes. You can find all of our past episodes, all one thousand fifty six of them, at my weird prompts dot com. We have a search feature there that works quite well if you want to find those specific episodes we mentioned today, like episode nine hundred thirty eight or episode eight hundred thirty five.
And we are on Spotify as well. Thanks for listening to My Weird Prompts. I am Herman Poppleberry.
And I am Corn. We will see you in the next one.
Until then, keep your agents close and your U Is closer. Goodbye everyone.
