Dev Interrupted

The Shift to Agent-Driven API Consumption | Speakeasy’s Sagar Batchu

• LinearB • Season 5 • Episode 16

Share episode

Think building killer APIs like Stripe or Twilio is purely a technical feat? Think again.

This week, we dive into why crafting successful APIs is fundamentally an organizational challenge, demanding internal excellence long before code is deployed. Sagar Batchu, co-founder and CEO of Speakeasy, joins us to unpack the crucial role of ownership, design principles, and why even internal APIs benefit from treating them like first-class products. Discover how Conway's Law dictates your API's fate and why achieving that coveted developer experience starts with your company's structure.

Getting these foundations right is more critical than ever, as the landscape now faces a dramatic shift with the rise of LLMs and agentic AI. This potentially multiplies API usage and introduces the concept of "Agent Experience" (AX), demanding even greater rigor around clear standards, documentation, and metrics like "Time to First 200." Sagar also explores the emerging Model Context Protocol (MCP) and explains why focusing on developer productivity today prepares you for the AI-driven future of tomorrow.

Check out:

Follow the hosts:

Follow today's guest(s):

Referenced in today's show:

Support the show:

Offers:

Andrew Zigler:

So welcome to Dev Interrupted. I'm your host, Andrew Zigler.

Ben Lloyd Pearson:

And I'm your host Ben Lloyd Pearson.

Andrew Zigler:

This week we're talking about how AI can talk to each other now, how it can use tools, and ultimately the cost of politeness.

Ben Lloyd Pearson:

Well, as someone who considers myself a polite person, I wanna start there.

Andrew Zigler:

Okay, so this was a story this week where people really broke down the cost of saying things like, please, and thank you to ChatGPT. And in this case, it was really going deeper at the cost of, you know, saying those words requires the LLM to process them, just like any other part of your query. Which ultimately uses more electricity, affects more of the environment and people were even quantifying it in terms of spend saying that being polite to ChatGPT costs the platform tens of millions of dollars. What do you think of this kind of a polite madness?

Ben Lloyd Pearson:

well first of all, what if being polite gets you better answers and you don't have to do a second prompt? Well, then suddenly it becomes an energy saver, does it not?

Andrew Zigler:

I completely agree with that. really the breakaway here is people were arguing that, saying Please, and thank you, is a powerful way of expressing your meaning as part of your request. and it also helps make the LLM understand the importance of what you're doing compared to other parts of your request. Ultimately, those words have function, right? It's like we say them to each other and we think that we might, they might be empty. Maybe we don't need to say them to a machine, but semantically they're playing a role in a lot of people's requests. But you know what, Ben? The one where maybe I agree with maybe we could get rid of it, is, uh, ending the chat session with just a thank you. I'm not sure what that does. Do you do that?

Ben Lloyd Pearson:

extra prompt. So, you know, I used to be polite with, uh, with my AI models, but. I've come to think that they probably appreciate brevity over politeness. You know, they have a natural tendency to be pretty polite, so I think they just kind of want to get to the point,

Andrew Zigler:

yeah, it's something I do commonly in scenarios where I get results that I do or don't like from an LLM, is I ask it to basically export, the instructions or the tone or the, concept of this conversation so I could share it with another LLM. And those kinds of, um, kind of like plug and play prompt things are always very brief, because the LLM knows that's talking to another LLM. It doesn't really need to be all that polite.

Ben Lloyd Pearson:

Yeah, and I mean, speaking of which we've covered on here, how, how AI chooses more efficient languages when it's speaking to other AI bots. You know, the, the human language is actually kind of inefficient. when it comes to conveying meaning, but, you know, ultimately I think it's kind of a, waste of, thought to think about the energy usage of stuff like this, you know? for one, like these things always become more efficient over time. Like we're already seeing massive, efficiency gains with ai. That's only gonna continue. And then we're gonna get to a point where the, models that people use day to day, like maybe there's gonna be some extreme ones that. Take a ton of energy to run, but the ones that we use day to today are probably gonna be very efficient and pretty cheap to run. but you know, if, if, if you wanna be polite, I think it's a good habit to have. So just do it. Um, It's probably more efficient to speak to AI and emojis anyways, so if you're not speaking in emojis, then you're already not as efficient as you can be. But, you know, make a habit of being polite. Just don't expect that you're gonna like, save the climate from doing so.

Andrew Zigler:

Completely.

Ben Lloyd Pearson:

Yeah. So let, let's talk about the, uh, AI talking to each other. What's our story on that one?

Andrew Zigler:

you know, we were talking just a moment ago about how we communicate with AI and how we can be polite or not well, new on the scene. From Google, if you're listening to this at Google. Next they announced the agent to agent protocol, which is a new protocol that allows an an AI agent and AI tool to call out to another ai, in a structured, repeatable way that allows then developers to build these interactions. Scale. it's similar to other things that have come onto the ecosystem lately that we're gonna talk about a little bit more in just a moment. But, agent to agent protocol or a to a protocol, if you've seen this come across your feed or in news. really just to break this down for you, it's kind of like the idea of your LLM in a local tool or in your client being able to call out almost like a, an an AI call center. Where there's another AI agent somewhere that can provide more in depth information related to the tool or the process that you're doing. So for example, if you have a local tool, that has an ai, built into it and it needs to access maybe cloud data information on a third party service or otherwise interact with another AI workflow somewhere, it could use a to a, to have a structured and repeatable conversation that both sides. Can understand. And so this opens a really, a whole new paradigm for how software developers should be thinking about building their products for LLM consumption. Uh, it's really showing that developers are not the only people that are gonna be using your tools. and there's more dimensions in which AI will be, acting in their behalf.

Ben Lloyd Pearson:

and Google is a, you know, they, they have a long history of establishing these sort of like industry standard organizations and practices in open source projects. So. in very familiar hands, when it comes to like a new protocol that we really need for this space. and they brought in some really big companies, like we're seeing OpenAI, Hugging Face, Vercel those companies already in the loop, there's I think like almost 50 of them are a part of this. But I think what we really need to think about here is that, AI is gonna fundamentally consume content and resources differently from humans. Like we have built the information aid to make it easier for humans to absorb information, process it, and do something with it. like you mentioned, human communication patterns often aren't the best for a AI to AI interactions. You even think about like an API, for example, we built APIs for human developers to write code to interact with them. some of those conventions will stay the same for ai, but, many of them I think are likely to change. which kind of gets into this, world that we're also seeing pop up a lot, like the model control protocol. Is that MCP, is that, the correct terminology?

Andrew Zigler:

Oh, the model context protocol.

Ben Lloyd Pearson:

Yeah, yeah, yeah. That's the one. Sorry. Yeah. Uh, you know, so like designing APIs and systems that are for machine consumption, which is pretty interesting. So, and we're hearing more of this concept of agent experience that's heating up and, you know, it's just another step along that journey. You know, I think this is what we all kind of expected that AI maturity was gonna look like.

Andrew Zigler:

it's really an evolving space, and this is even just one of the new things on the scene. You know, there's other tools, other plays at, at force here with what an LLM can use.

Ben Lloyd Pearson:

Yeah, and, and of course I already showed a little bit of my, naivete around this subject, but Andrew, I don't know why I need an MCP server and at this point, I'm kind of afraid to ask. I've been told that you might be able to explain that to me with this, this last article that we've got today.

Andrew Zigler:

Well, if you're asking yourself if you need one, well, I'm here to tell you that you need a lot of them. MCP servers are really gonna be the future of how you can get more out of the applications and the tools that you're using. Really just in simplest terms, an MCP allows you to communicate in natural language, into an application's actual process. And what this means is, for example, being able to talk to applications that don't have, traditionally accessible workflows or experiences for its users. and it's unlocking a lot of potential for people to get more outta the applications that they use every day. An example of a really great one from an article, that was out by, Andreessen Horowitz about MCP and its impact. one of the things to showcase there was a blender MCP server. Which I found very great and compelling for showing how it would allow you to talk to an LLM Talk to Claude to talk to ChatGPT, and then give it structured repeatable tools that it can use to apply your language to an application. So being able to talk to Blender effectively is what MCP will give you. Being able to talk directly to your applications without having to click a thousand buttons, without having to do that long intensive Google search without having to go to ChatGPT and ask it, Hey, how do I do this? Now you can tell ChatGPT to do it and it be able to make those tool calls for you. And it does that with MCP servers, MCP servers expose functionality APIs and services to be consumed by LLMs. this opens up an entire ecosystem where developers are thinking and reimagining how their tools and products are to be consumed by this new, kind of like really legion of, of, of consumers. as you're gonna learn from our guests, these consumers are, Calling these tools at a massive scale and there's a huge call to action to build and supply these types of tools. So does that kind of clear up what MCP is for you?

Ben Lloyd Pearson:

yeah, actually it clears it up very well, and I think what you're describing is vibe, productivity.

Andrew Zigler:

It is not too, far off, you know, uh, it really, it takes it one step further because you can even connect things like MCP servers to your maybe traditional, if you can call it that vibe coding client, so you could connect MCP servers. To cursor, to add that tool calling to your vibe coding experience. So, for example, something I did of this recently hacking around in Cursor and, um, what I was building a Telenet server and I, I used an MCP Telenet protocol, server. Within a cursor so that I would be able to talk to its own application. So now I could talk to Cursor, it could build and we could iterate through it together. And then it had the functionality to call and launch its own server and then talk to it over Telnet and figure out if it was working or if it was broken, or if it needed to iterate in a different direction. So that's a fully closed feedback loop. I could practically observe that as a developer, um, with very little influence. So, uh, it really opens up a whole new world of thinking and using.

Ben Lloyd Pearson:

yeah, I definitely feel the, so what I think I've taken away from this. we're entering a rapidly, entering a future where natural language is gonna become a pretty common interface to a lot of different tools. So think about any tool that you use out there, you're probably gonna start having a conversation with it, before too long. And I think blender's a great example'cause that is such an amazing application, but has such a steep learning curve that if you can use AI and natural language to get around that, I don't know how much this would help a seasoned blender veteran, for example, but someone who's new to it and needs to learn it. Like I could absolutely see this being a massive, massive benefit.

Andrew Zigler:

it really levels the playing field for everybody with creativity and determination to be able to enact change in ways that they haven't before.

Ben Lloyd Pearson:

Yeah. And if I'm not mistaken, I think we have a guest today that is gonna talk about MCP servers for the first time in Dev Interrupted history. Why don't you tell us about who we have today, Andrew?

Andrew Zigler:

Oh yes. So our guest today, his name is Sagar Batchu, and he's going to really reorient you about how you think about your APIs and your tools because if you think that your API problem is just some bad docs or clunky endpoints, well, I'm sorry, but the whole field has changed and Sagar's gonna break that down for us and show how. You and your team can take best advantage of it because it turns out that the real problem with your API design is probably in your org chart, so stay tuned.

Ben Lloyd Pearson:

The future of developer productivity is here and it's AI driven. Join LinearB B this week for a 30 minute demo showcasing groundbreaking AI powered productivity features. You'll see live examples of AI code reviews, automated PR descriptions, and smart iteration summaries. Plus get all of your questions answered in a live Q&A. Don't miss your chance to see how AI is transforming the way your engineering team works. Save your spot today.

Andrew Zigler:

Today we're discussing how building APIs isn't just a technical problem, it's an organizational challenge. And to break this down for us, we have Sagar Batchu, co-founder and CEO of Speakeasy. He spent years scaling enterprise APIs, tackling developer experience challenges, and now he's solving the messy reality of API adoption at scale. Sagar, welcome to the show.

Sagar Batchu:

Andrew, thanks so much for having me

Andrew Zigler:

Yeah, it's great to have you and we're really excited to dig in. APIs are, something that's been around for a long time, but they're constantly evolving. They're fickle monsters for sure, and the definitions for what makes something an API and what makes it successful seem to keep shifting. So I'm really excited to dig into this conversation, tap into some of your wisdom and what you're seeing out there in the field. I wanna start though by setting the stakes. You know, again, for our listeners, if you're a company with an API product, you probably want to be the next Stripe or Twilio, and you want to killer API. You want a developer friendly experience and you want that sweet, sweet self-serve adoption. You want it to be easy and you want it to be frictionless for people to actually integrate your API into what they're building and using. But even API first companies can struggle to make APIs a priority. So Sagar, where do you see successful APIs begin in a company?

Sagar Batchu:

Yeah, it's a great question. Andrew and I wholeheartedly agree with this idea that APIs are more an organizational problem than a technical one. The technology of running an API is largely commoditized. but what makes running great API comes down to how a company's set up to, bring that API to market, to evolve it, to design it, to serve customers. so I think it really starts internally with the, with the sense of excellence, right? Wanting to put out the best API out there for your business. I think for most companies, APIs are actually, a post product market fit problem In that you have to figure out what your business does. What super power does your business give users. whether they're developers or consumers or, you know, whatever part, whatever user out there. once you figure that out, an API can be a massive accelerant. It can be a differentiator, it can be a go-to market it can be a developer tool, kind of an ecosystem enabler. And I think because of that, it's, it's really a post PMF question. So I think obviously you. Once you do, I'm sure every founder, every business owner will say they want their product or business be the best. And I think in APIs different, it's a product. And so I think it starts with the center of excellence around that. Internally, very similar to, you know, how. Products are very visual. Like some of the best apps we use, like social platform apps, they have huge design teams internally that kind of obsess over every micro interaction, every component in the user experience. You know, like the stories of designers from Airbnb and Instagram and how they're kind of best designers in industry. Um, I think API design is similar. Like if you want the best designed API, you need people who know what that looks like, who have a pulse on the ecosystem of API development. what makes APIs maybe a more challenging than usual experience sometimes I think is or underappreciated, is that once you put an API out there, it's very hard to roll back. It's very, there's kind of this saying around APIs that all APIs are stuck on V one. It's very hard to evolve them because you, you're basically putting something out there that other businesses will build on top of, and so it becomes a dependency. And so change management is a very difficult concept for these businesses. so yeah, long-winded way of saying, I think it, it really starts the center of excellence, making sure someone internally owns how the API looks and feels. and I think that's a really good place to start.

Andrew Zigler:

you make a really good point, drawing some parallels between teams that care a lot about design or about the user experience. Investing resources into that, putting, uh, time and energy into those teams to actually. Prop up that experience. And so within a company, if a company is building, an API that they're going to serve to, their customers or to their end users, is there a specific place in the company where you see that most successfully start? Is that something that maybe is democratized between a bunch of teams or is it, is it siloed in one place?

Sagar Batchu:

I think when you're small, it's good to just have a single owner. And if you're a small business with a small API, just one API, then yeah, I think you just need one team owning it, end to end from design to deployment to, developer tooling and the ongoing maintenance. But once you get to scale, we find that individual products have their own a. this is where like Conway's law becomes really applicable, right?

Andrew Zigler:

Yeah.

Sagar Batchu:

Conway's Law being that kind of states we end up shipping product that looks like our business, uh, than what the customer wants. If you have five teams, your a p is gonna look like it was designed by five different people. I think what you wanna do to avoid, in my opinion, is, enable your teams to a enable. To production. I think it's important to have a single API owner sometimes. This is called an API platform team at a company. Larger ones who ensure kind of a governance of standards. They, they play the role of governance, of standards across all the APIs, and so internally it's five teams developing a P. But externally from the customer's point of view, it looks like this one person organizational. If you're a small company, it's a simple problem. Don't try to distribute it, distribute the problem. If you're a big company, just make sure there's a kind of last mile gate in place to ensure a, a consistent design experience.

Andrew Zigler:

Just like how you'd have like a product manager that's in charge at the very end, you know, someone, a sole owner of what is gonna be used By the end user or whoever's gonna be consuming your application. Right? And that person, their job is to liaison between all the different teams and all the different assets and all the different needs to make sure it is a cohesive experience. You know, what you're calling out with. APIs is really top of mind for me too. I think of all the best APIs I've used and even if like they had a huge varieties of stuff that they could do, or like a lot of different endpoints that maybe are very different from each other. At the end of the day, they all kind of still have the same shape. Them smell at least the successful ones that, that I use and that get sticky. so it makes sense that you'd have one person or one team kind of owning it before it goes out the door. And that's like for, that's like how an API first company would like adopt that would, would think and would organize themselves with that mentality. but does any, any of this matter, if you're not an API first company, if you're maybe building internal or self-serve APIs, does, does this become less important?

Sagar Batchu:

Yeah, that's a, that's a. APIs a, little bit like a, like the iceberg effect where you have the majority of APIs actually internal. And so like below the, the waterline is actually all those millions of internal APIs we don't see. And then the ones above the waterline are like the few first businesses that also have external facing APIs. most of it is actually an internal problem with the internal case. Like sure, there isn't as much of a. I think you're somewhat more inoculated from inconsistencies because the, the user is fundamentally more tolerant being an internal user. however, I think designing with the same principles in place will lead to a good outcome. but internally the problems we see are less about. Consistency, quality and governance and more around discoverability access and development speed or, you know, ease of development. so I think for companies focus on this as an internal problem. I would actually start by saying the first step really comes down to like discovery and cataloging and making sure you have the tools in place to know all the APIs that you have. I'm talking really big companies with, you know, hundreds of product teams, the few that we work with where yeah, they have incredible number of internal APIs and they've done such a good job enabling their teams to build new ones that, like they spawn left and right. And so they need kind of a structure or methodology around keeping track of them. It can be done through tooling and automation of course, but, it's a slightly different flavor of the.

Andrew Zigler:

when you are a large company or a small company and then suddenly you need something like, that's easy to scale or serve to your developer teams, then that's kind of where an API might come into the mix. So in, in your experience in the teams that you've worked with, are there scenarios where maybe. One day a company wakes up and they're like, oh, we really need to organize around an internal API. We need to provide something in an API like way for our developers to be using. or is that a problem that's kind of native to the company? Like when you founded that company, you already knew that that was the problem you were gonna solve. versus it's something that just pops up one day.

Sagar Batchu:

a large number of companies we see, like, they don't realize that this is coming. Like they don't realize this is an issue. I think what happens is they hit PMF and they start scaling. And when you talk to founders who have hit PMF, they come under such pressure to start scaling the business and there's like incredible demands. so I don't think they necessarily always foresee the road how the API could become messy or difficult to work with. Right.

Andrew Zigler:

Yeah.

Sagar Batchu:

it's, you can't blame anyone, right? Because they're kind of focused on growth and everything else kind of comes second. but there are steps you can take upfront to actually ensure that long term. As you grow the API design and API usage doesn't suffer. and it comes down to simple things like adopting standards of development. if you're a REST developer, open API is a great standard and kind of gives you this escape patch into the rest of the ecosystem, however big or small you are. So things like that you can adopt from early on.

Andrew Zigler:

Something that keeps sticking out to me and, and what you've described is just how important that ownership must be for the API within a company or the API strategy, and how important it is that if it's something that, is going to be saving your developers' time or you're gonna be serving as a product, how you have to structure around it and how you have to strive for a level of excellence. Because when I think of internal APIs in my experiences, I often think of like, you know, internal developer portal or, or something where a bunch of teams would have self-serve versions of something they're building for each other. it always ends up in this weird no man's land where it's kind of like part of the infrastructure or infrastructure team as part of the product team. In some regards. Some of the engineering team owns it. So exactly what you've described kind of happens. You get like this, uh. Sprawl, API sprawl of a bunch of different approaches of a bunch of different solutions. one really great takeaway so far is about unifying the ownership of the API into one place. that way it can be leveraged effectively. And even if your company is not like, an API first, you're serving an API as its first bread and butter, you have to be able to organize yourself around solving those problems, for when they do come up. And I'm wondering what are the. successful, habits or practices that you see engineering teams that do manage to achieve that excellence and strive for that excellence? Is there like a common theme that you see between them besides just caring a lot about their APIs?

Sagar Batchu:

Caring about your APIs? The way that it manifests is understanding customer usage. if you were a designer and you were designing a ui, you probably look at things like session recordings and there's suite of tools on like tracking how customers are moving on your screen, doing user interviews. I think API is no different. the way it manifests slightly, the metrics you look for different, you, you probably wanna track. Which parts of the a p are getting used the most versus the least, like error rates. there's a great metric I like to call time to 200, which is the time to your first successful call as a user. you probably want to track that over time as well. Like always should be trending down. really caring about it comes down to the design, but also comes down to like monitoring in real time and

Andrew Zigler:

Right.

Sagar Batchu:

based, based on that. Yeah.

Andrew Zigler:

There's a lot of importance in measuring to understanding the, the vernacular, the language of the goals that you're striving for times. Time to first 200 is a great example because you can look at someone's journey along the way. It takes them longer. Over time, you, your users, get to their first successful call faster and faster. You can look at the, the factors that play into that. Then you can iterate over time because API is, you know, they're just like any other type of software development. You can measure it, you can put, actions in place to improve it. and then you can track it over time. APIs, you know, the ones that we've discussed so far, that's a very traditional format of how APIs have been built. And consumed. But you know, there's definitely a little bit of an elephant in the room around APIs right now with LLMs and especially Ag Agentic AI coming onto the scene. because we're living in a world where these tools, what makes these, uh, LLMs so powerful to work with is their ability to do. Tool usage and to call out to things like these APIs. So suddenly, now you have like a split user base, you know? Yeah. Time the 200 that you've been measuring might have always represented a human, but now that there's a, there's maybe even a machine in the mix that is using your API like how a developer once would, uh, so that kind of rewrite. I think the playbook for everything about like, you know, beautiful documentation, interactive sandboxes, the developer experience. what has been your perspective, as like an API expert, someone building an API company, that you've been seeing as LLMs come on the scene of these as these API callers.

Sagar Batchu:

What's really interesting, and I think you alluded to is like as, as these new interfaces come online, there's an even more of a demand to actually do the traditional things well. Right. Even more because one way to like if look at it from outside in is there's just more API consumers now and there's more API calls and there's gonna be more usage. And so you want to prioritize. the things People have always said you should prioritize their own design. Like have an API spec, make sure it's maintained, make sure it's accurate. Those things only further become more important when the integrators are not just humans, but also agentic workflows probably doing 10 times as many API calls as, the standard static integration would do. So

Andrew Zigler:

Wow. 10 times as many. You think that would be the scale you see?

Sagar Batchu:

Right. But you know, I

Andrew Zigler:

Yeah.

Sagar Batchu:

it is order of magnitude change.

Andrew Zigler:

Okay. I like the idea of, of just zooming out and just being like, there's more demand. You have more users, but you have to stick with the traditional core basics of what makes your API successful. All of those original things stay true. I think that's been a universal takeaway in software engineering that a lot of, leaders have been learning along the way is that all of those things that did matter, they still matter. And in fact, in some cases they matter even more. because when you scale those fundamentals. They become even more impactful. so, you, you throw the number just like 10 x obviously that's just an idea of their API usage. I guess also looking at how I. APIs are used and adopted. Like I think of my own perspective, as like a developer who's used a lot of APIs, and has also created a lot of resources for folks to use APIs. is that a lot of that boils down to having that really delightful developer experience that self-starting as that really easy to use documentation. Maybe it has the spec that you can play with right on the website, right. We're all familiar with. These ways of reducing friction to that first successful API call. but when you are now maybe building at scale for LLMs that are gonna call your APIs 10 times, maybe they don't care about that developer experience. Is that what you've seen or is it a different kind of developer experience?

Sagar Batchu:

the industry's already kind of gravitating to terms like agent experience ax instead of dx and um,

Andrew Zigler:

interesting.

Sagar Batchu:

Yeah, it's funny, you know, there's lot people love these buzzwords and kind of marketing stuff that comes from it. What I would say is when I double click on it, it does come down to actually a lot of the same things. Not, not all, but. Down to how good of a grasp you have a, I recommend. More isn't better actually. I think companies that have APIs, the smaller and simpler and clearer your API is the better. Like the truth is that people probably don't want to do everything with your product programmatically. know, most of the usage is probably still gonna be through like the UI or like whatever else you expose. the API often serves one or two use cases really well, like something that should be programmatic. so I always like start by. Asking customers they bring us an API spec and we make these SDKs and other tools from them, do you wanna expose everything in the spec? Right? Do you just wanna start with one or two or three operations in the spec? Like if you're a payments company, do you just wanna start with create payment, like create payment, get payment, delete payment, update payment, like that? That's it. And then do you want to expand outwards from there instead of like dumping, you know, operations customer? and what happens? I think there is like, you, you do that and suddenly you may have a hundred operations, you're exposed to get 90% of the usage and then, 90 get like 10% of the usage. But you can't get rid of those 90 now, right?'cause there's usage, but it's not really a game changer for anyone. And so you've put

Andrew Zigler:

Right.

Sagar Batchu:

spot. I always tell 'em to start small and with agents, I think it's even more true. Like context is really important. The context you can provide these models and, and agentic workflows. So the simpler API is the better documented described examples, like it's all compounding in value. I've done experiments now with a lot of APIs where like just. To an a p spec into, Claude or some other, and using it is okay, uh, or into even my IDE, is okay, but if I, instead of that actually give it, a documentation site. Good examples, maybe an SDK with like prebuilt, valid examples. It flies all of a sudden, like it goes from being a fun. little Tool fun little like demo to actually, oh my God, this could 10x my day-to-day productivity. So, in this new world context matters, a lot more. and so yeah, I, I would start, yeah, start with small, simple APIs. Don't try to like expose your whole product to the world through an API, and then the stuff that is exposed, make sure it's thoroughly documented, the examples, all of that good stuff.

Andrew Zigler:

There's also a, a new idea on the scene, that I know you've been thinking a lot about with, MCP or model context protocol. And this is what allows an LLLM to work directly with tools and with APIs. I'd love to hear from your perspective what you think about this, how you're seeing it impact, workflows, and kind of what a. You know, you, you think people in, in software leadership should be paying attention to right now with MCP.

Sagar Batchu:

I think the really interesting thing with MCP, and you're right, it's kind of become really hot and just come to the forefront is since we started working with these LLMs, like the thing that everyone has been excited about is how I. How easy it's to use them and get this magical experience. But the big gap has been determinism. Like how do you ensure that the stuff that it gives you is always accurate? It's relevant, it's consistent. And I think agentic tools like MCP are really the gateway into this. I think it makes, it takes LLMS and, agents more broadly from being, discovery and search tools to actually being operational tools. With MCP in particular, for those of you who are not familiar with it, it basically is a protocol, a schema that defines the resources of an API an agent has access to, or an LLM has access to and calling that API. it's like a level of indirection above an API spec with a little bit of extra, concepts that allow for access control, and. With this what we're seeing is people are creating MCP servers for different APIs and then they add it to their clients. A client in this case is actually like your cloud, desktop or cursor, IDE, and suddenly they have access to that API the cool thing is they're not even prompt. They're not even saying, please use this tool. you just continue with what you wanted to do. there's enough context in these tools that the LLMS agents actually decide when to use the tools. actually, like automatic decisioning that's happening. I was able to, create an MCP server for our GitHub and Slack, and then suddenly I'm able to ask questions like how many GitHub issues have. Customers opened. What's the latest issue? What's the highest priority one? Like it cloud goes from being my, you know, of l that I use for search and, and knowledge and all of that to actually doing operational work. which is like a huge leap in how useful AI could be for us. So, yeah, I think, I think as a leader I would actually start by, even before investing in the stuff for your product, investing, for your productivity of your team, I think people should be playing with these things and kind of the use case are gonna evolve as, as people get creative. But I think identifying an internal workflow, something that you probably tool up yourself or use another SaaS product to kind of orchestrate for you. I think you could actually just do a lot of that through having the right MCP servers for the right APIs. and that's something we're really excited as well to kind of get into in, see we can help enable.

Andrew Zigler:

Yeah, and that's a really great call out too, that, you know, paying attention to your internal developers, your developer productivity, measuring and understanding how people are working and, and consuming these tools. It kind of makes me think of that. MCP is kind of like the developer experience for the LLLM, for these agents to use. is providing that last mile that is helpful for it to be able to make the context to decide when to use it, when you're already just natively using the tool. So does that mean that all APIs. That are going to be popularly consumed by developers should be going the direction of being available that way? Or is that something that, like how, how do you decide as a company or someone with an API that it's like, we should be implementing MCP? we should follow this track.

Sagar Batchu:

Yeah, luckily implementing MCP is reasonably easy, and I think products like ours, our own actually make it a lot easier to get into this ecosystem. I think if your API or product has, any value in terms of, day-to-day operational use, right? Things that you want. Like, let's even take a simple example, right? Like, I think it's pretty intuitive for most users today. they will probably have this idea of like, I wish I could kind of dump all my personal notes into this LLLM and all my Apple Notes and to do and tasks and have it become kind of a store and memory of this stuff. Like I think that that is one of the more early intuitive use cases people have. that's actually possible now because of MCP. a lot of task note taking products have APIs and so you can actually create a tool that allows your LLM to interface with that. And so now the idea of task note taking. Memory is no longer like an operational task. You just have to, know, talk in natural language to the LLM and it will automatically update all of these tasks and notes for you. I think there's like anything in your API that's stateful, it's a really exciting thing to explore. and also I would say, lighthouse companies should just try this out, right? See, it's much like an SDK or putting an a p out there in the first place. You have a hunch of what it's gonna be used for. But sure the best API ecosystems didn't start knowing that the API was gonna get used in all these different ways. I would put it out then kind of trust users to see what are the interesting workflows that.

Andrew Zigler:

we started by talking about API first. Is there gonna be an MCP first company one day? how does that modify, the future you think, from the teams that you're seeing that are combining these technologies?

Sagar Batchu:

most of the disruption, I think is actually on the consumer side,

Andrew Zigler:

Hmm.

Sagar Batchu:

of the problem and on the producer side. Producers have to keep building APIs, making them better, making them accessible. I think consumers suddenly have at their fingertips a very powerful set of tools for integration and even before integration, I would say for like discovery and testing and understanding how to work with APIs. I think as it becomes more deterministic over time, see actual live integrations run off of these tools. so yeah, I think, um. APIs? I don't, I don't know. I think it really depends on how usage evolves. but I think, yeah, there's more disruption to be on the consumer side of l.

Andrew Zigler:

what about like with what y'all are building at speakeasy? is there something kind of like top of mind that you think that the future's really moving towards?

Sagar Batchu:

what I will say is that we are in day zero, like innings minus one of this process.

Andrew Zigler:

Yeah,

Sagar Batchu:

I think people sometimes under appreciate how. Important APIs are to our, like daily life, right? And so, you know, if APIs start functioning incorrectly, your banking system doesn't work,

Andrew Zigler:

I.

Sagar Batchu:

systems don't work. Like everything we do is an API call, like your DoorDash order, whatever it is. and so I think the changes are gonna start more to be honest on the like. what I would call, exploratory side, right? It's gonna be experimental. It's gonna start with like, people trying stuff out. The really big breakthroughs, I think is gonna come when there are actual operational changes, right? So when like real systems, real teams actually start doing things differently because of the evolution of. How a, so I think we're very, very early. and I'm to see it evolve. In terms of what we are doing, like Speakeasy's mission has always been to provide really the modern tool chain for API development, all the way from kind of design to distribution of the NAPI. and so we work a lot with API producers, however. There's been such an explosion in this world. We've kind of quickly added agentic tooling support. We generate MCP servers off the, just off of your API spec for you now, so we're getting involved in that way. And then also probably take us towards really more work around agentic tooling, hosting the tools, running them, providing evaluation, toolkits on top. So yeah, we, we wanna help people have the best APIs, which. You know, as you lightly pointed out, is also gonna include having the now, so expansion of our mandate and our mission.

Andrew Zigler:

Yeah. And it's about bringing the tools to the end users. That's a really good call out that you made. Is that like a lot of the work to be done, a lot of the change that will happen is gonna happen on that exploratory side, on the user adoption side and the ways that they can interact with these types of tools. I. Well, you know, Sagar this has been a really fascinating to kind of get in your head and learn a little bit of how you think about APIs and with the MCP coming on the scene as well. And it's been really interesting to get a glimpse at the challenges and opportunities, that face these kind of companies that are building these internally or serving them to customers, how they're prioritizing things like developer productivity and excellence and how that impacts, their end result. And really, like you said in the beginning. it boils down to Conway's Law and that you need to structure how your company is around what it's producing, that your company's structure reflects what you ultimately put out into the market. so in order to get that product market fit, in order to create that really delightful experience for your users, you gotta match where your users are and what they're looking for. and Sagar. I'm also curious where can people learn a little bit about speakeasy and what y'all are building? If, you know, after this conversation, folks wanted to go learn more?

Sagar Batchu:

Yeah, absolutely. I love ending it on Conway's Law. It, determines so much of what I think businesses do. to learn a little bit more about speakeasy, you can find us@speakeasy.com. we also very active, on LinkedIn accounts, so on x at speakeasy Dev and on, uh, LinkedIn speak a. we're also very reachable team. We have, you know, slack spaces linked on our website. Come and chat with us anytime. We have a kind of change log that tracks our progress. Um, doing a lot of work, agentic tools, and if you're looking to adopt in your own business or just looking to try it out, let us know. We can.

Andrew Zigler:

Absolutely. So we'll get all of that included in our show notes. So if you've been listening and this has caught your interest, definitely be sure to check that out. thank you so much for joining us this far. Please check us out on Substack, and also reach out to us. Sagar and myself. Were both on LinkedIn. We'd love to hear from you. so definitely please give us a ping on socials. that's it for this week's Dev Interrupted, and we'll see you next time.

People on this episode

Head Shot

Dan Lines

Host
Head Shot

Conor Bronsdon

Co-host