Going Beyond Chat with Alex From Arcade

It's it's this part of the journey of a tech wave where the winners and the losers are going to materialize in whatever category you want. This is like the internet in the late '90s. And so the earlier you and your organization start to play, start to tinker, start to try and get it to do anything or something useful, the earlier you're going to get on that learning curve. Because if you wait until it's all mature and stable, you're going to wake up and you're going to have any number of competitors that got ahead of you and you run the risk of becoming blockbuster. >> Hi, my name is Demetri Bonichi and I'm a content creator, agency owner, and AI enthusiast. You're listening to the AI agents podcast brought to you by Jot Form and featuring our very own CEO and founder Idkin Tank. This is

the show where artificial intelligence meets innovation, productivity, and the tools shaping the future of work. Enjoy the show. Hello and welcome back to another episode of the AI Asians podcast. Today I have with me founder and CEO of arcade.dev, Alex Cazar. How you doing? >> I'm doing great, man. Thanks for having me. >> I appreciate having you on. And uh just to kind of kick things off, I uh congrats on I see on your website you're a new your new Forbes rising star. Um which is pretty great. You know, I saw that pretty relevant. It's come out a couple weeks ago, but I feel like still relevant. You know, you're uh you're on the up and up. And with that being said, tell everyone kind of how you yourself uh got into the world of AI and and tell us a little bit about arcade.dev.

>> Yeah, so you know, maybe I'll work backwards. So arcade.dev dev makes it really easy for a developer to build an agent that securely talks to other things and it can take actions against other things. >> So if you go into chatbt for example, you can draft an email but you can't send it. Uh the reason why even something as advanced as chatbt can't send an email or take an action in other service is largely um because it can't authorize on behalf of the user. It's a bit of a security problem. And so we clear that blocker so that developers can go build the kind of agents that they have in mind. >> Yeah. >> That workflow automation and other services. >> And so we have a bunch of out of the box integrations like Salesforce and and Gmail and Twitter and GitHub. And we

have an whole SDK to custom build your own integrations. And and we have a lot of really nice features to make all of that really easy to to build and manage for developers. But to answer your question on how we got into it, this is my second company. Uh, a while back I had started a company in the authentication space called Storm Path. Um, we were making it very easy for developers to have login screens and manage O and their web apps. If you're familiar with Ozero, we were a direct competitor sort of around the same time. And then Octa acquired us first and then acquired OC zero second. And when I was wrapping up my time at the at Octo uh you know when you get acquired there's a window you have to stay you stick around. As I was wrapping that up I

wanted to start another company and but AI hadn't happened yet and so you know I I thought cloud was kind of over already and so I I didn't really have a great idea so I went into venture capital and venture capital was awesome. I joined a great firm with a great team and I focused on AI infrastructure investing and while I was while I was you know in that front row seat that VCs get seeing all this early innovation >> GPT3.5 came out >> and that for me was moment where I realized oh wait a second this is the new platform this is the this is like the the the similar moment to when EC2 and S3 came out from AWS that's what I felt when I saw 3.5 and then eventually 3.5 came out 3.5 Turbo which supported what people call tool use. This

was the first time that a large language model could select tools instead of doing everything itself. And that really reinforced my opinion that this was going to be the way new applications were going to be built. And so, uh, the builder in me, you know, couldn't keep my hand out of the cookie jar. And so I left to go start a company. Um, and my my co-founder, so I was the former head of product at Octa for developer products and my co-founder was the former head of AI for Reddus, >> the database company. >> And together we started jamming and then we ultimately left. And our original intent was to go start an agent. Um, we decided that we were going to build an agent for site reliability engineering. At the time, we thought it was a very novel idea. It's now a very crowded

market, but >> you know, we prototyped. >> What time would this have been? Sorry. What time would have this been? Oh, this would have been uh fall of 23 is when we had started jamming on that idea. >> It's an early jam session. >> It was an early jam session. We didn't go fulltime on it till February of 24. And so from February of 24 up until about let's call it April of 24, we were building this agent. And we very quickly ran into a problem where if you think of how a site reliability and agent would work is it's going to get an alert from something like a data dog. It's going to tell you that there's a problem on service A and then the agent would then go through a workflow to diagnose that problem and figure out why you're seeing a latency

on a service or something. We ended up getting that working on a prototype and when we tried to make it production grade, we ran into some really formidable brick walls. The first one was we had given ourselves super user access to everything. Uh but that's not going to work in production. No one no customer is going to give a super user access to all the services. And so when we tried to give ourselves scoped access privileged access to systems that could follow some semblance of a policy that an organization might already have. >> We discovered the hard way that there was no way to do that in agents. No one had invented that yet. and and so that wasn't going to work. The second problem we ran into is that if you think through an agent flow there's you know you're going to for a

diagnostic you're going to ask a bunch of questions. A large language model is going to be invoked many times. You're going to be like oh is it the memory? Is it this server? Is it the database? Was there a pull request? Is it the code? And so you're going to run through this chain of questions. But the problem is a large language model hallucinates. And so the more the more times you call the large language model on the chain, the higher the probability something in that chain is going to fail. Like you're rolling a dice every single time. And if the dice rolls a one any anywhere in the chain, the whole chain fails. And so we call that compounding error rates. And so for something as complex as diagnosing a production server issue, we were starting to get near 100% failure rates. >> Wow.

those two problems uh invalidated the the idea and so we kind of kept banging our heads on how to fix it. Then we ultimately had an epiphany one day that what if we called the large language model less? What if we relied far less on the large language model and we relied a lot more on deterministic software? And it sounds like a very basic concept but it drove a major architectural change in how everybody was building agents. We realized that we're going to put a lot more logic into the tool layer of an agent. And so at the time there was no tool layer. Tools are just baked into the agents themselves. And so step one was we had to externalize the tool layer as its own service and then start putting the tools in there. The tools became a lot beefier than they were

at the time. They become very heavy because they were taking on a lot more logic. And when we did that, it then gave us a second epiphany on how to solve the authentication and authorization problem for an agent. And so we ended up inventing a solution to this. We ended up being the first people ever uh to solve this problem. We ended up filing a bunch of patents around it. Um and then and then and when we went to go show people this really cool agent that we had built that now worked, people were kind of lukewarm on the side reliability agent. But anyone who knew AI fell out of their seat when they saw how we did it. And people thought we were lying. They thought we were faking the demo. And when we would show people that no, it was real. The question

quickly changed to, hey, when can I see that? Show me how that worked. I need that for my project. So thankfully, we're not stupid. We pivoted. And so we, you know, we tore off the domain layer and started showing people just that tool layer. And the demand was exceptionally different than what we'd been pitching before. And so we made that transition to being uh this, you know, this tool execution company and tool authorization company uh formally July 1st of 24. And then since then, we've been on on a mad sprint to, you know, release product. Uh we released private beta in October. Uh Lang Chain was our our first our first real user. Harrison put a video out using us in one of his samples. I think uh late October, early November. Uh we went into public GA uh January, February. Uh the product has

done exceptionally well in that period. And then we started to spend money on marketing um late April and and so it's been it's it's been a wild ride. >> You know, how many people are you or not people? How many companies are you kind of up to when it comes to customers, >> you know? It's it's it's it's we we don't publicly disclose it, but I'll stick around. >> Yeah. Yeah. Like how Yeah. What's the growth been like as the the main reason? Yeah. >> Yeah. We see, you know, we see we see a few hundred a week. >> Oh wow. >> Signing up for the service. >> Um and it's interesting. It's actually quite biodal. Uh we see that there is by volume the large percentage of them are earlier stage companies or small projects. So you know the SNSB uh agent first AI

first projects and startups. But then we're we've also been very fortunate that we're seeing a tremendous amount of interest from the Fortune 500. And so our pipeline has has been interestingly biodal uh and and we're really excited about that. But uh we're seeing we're seeing a lot of demand, >> you know, and and seems like what's interesting is obviously SMB I see value in it, large enterprise I see value in it. But like what are what are kind of the different um reasons the different size of companies would be um wanting to use arcade.dev, right? >> Yeah. Um you know, I've been racking my brain on on why we're seeing so much like Fortune 500 because that's actually not the playbook for early stage adoption of technology. Normally, you would expect the midmarket >> to be driving the adoption early on. Absolutely. Fortune 500 would

come in late. >> Um that's not been what's happening. I think what's happening is it's very difficult and expensive to build agents and so you are seeing a lot >> because the kinds of people that it takes to build an agent properly tend to be machine learning engineers or people with some amount of machine learning background. And those people are expensive and you need multiple and and you need them available to go work on projects that may or may not work out because building an agent is still early and most agent projects fail. And so if you think of like a 70% failure rate on an agent project, you need to be running at least like four projects for one to be successful roughly, right? Uh and so you've got startups that are built for that kind of risk and so they're gladly take the

risk. Mid-market doesn't have that kind of bench laying around and available. U but the large enterprise does. They've been investing in data science and machine learning talent for well over a decade. And you know, if they can get a one or 2% improvement on some major workflow or major process, because of the scale they're operating at, the benefits far outweigh the cost. And so they're able to justify that scale of investment in part because the the the absolute value is so high for them. >> And so why do people come to us? The biggest reason they come to us is the moment you try and build an agent, you run into a brick wall, you try and get it to access something that needs any kind of authentication and authorization and then they quickly realize that there is no easy way to do it. And

so we've seen a number of projects get shot uh in in development. We're talking to a large bank, like a Fortune50 bank, and when we showed up, they'd already killed two agent projects because they couldn't get uh agent authorization working uh with MCP. And so when we showed up, we ended up helping them bring those two projects back to life, and now they're on track for production. And so very specifically the question that everybody's struggling with is how do I check that this agent on behalf of this user can perform this action on this resource and today that is almost an impossible thing for a team to implement and we unblock that for people. >> Yeah. So it seems like I mean you're solving a lot of issues right the there's the complexity obviously but the the cost is exceptionally high too you know for

anyone who's trying to do this. So, it's it's very interesting to me where where do you where did you guys um manage to overcome those hurdles, right? Because obviously I'm sure it's not it wasn't cheap for you and you know there's there's a lot of hurdles that if you're going to then become the one that builds the agents, right? There there's hurdles there. So, how did you end up overcoming those those hurdles? >> Yeah, you know, there's a lot to that answer. I mean, the first one is being very surgical. Um we we picked a very narrow part of the stack that was that was that no one was serving, no one even really understood um where there wasn't a lot of action but everybody was blocked. Now we we we we discovered that by accident but once we discovered it we were very surgical

to stay there and not start to expand into other things. We went to go solve one set of problems only. And so that reduces our costs because we're not trying to build everything for agents. We're just trying to build the the tool execution and authorization layer for agents. Um, you know, people sometimes call it like an MCP gateway. We call it a service bus or an engine, but same concept. And so we stay there. We're we're ruthlessly depri, you know, descoping and we're ruthlessly prioritizing feature sets because like everybody else, we have limited capacity and limited resources. The second thing we did was when we did spend our capital and we and and we made sure that we hired the best. It's easy when you're early to justify um lower quality talent because you need to move fast and you need to be conservative with

cash. We did not do that. Um, we hired the best people we knew, the highest caliber people because they just deliver better product faster with less maintenance burden. And so even though it feels more expensive and slower, it ends up being faster and cheaper in my opinion. And then the third thing is we raised a lot of venture capital. Um, this stuff is expensive to build and so we raised according. And so our seed round was $12 million. That's a very large seed. >> You said 12. >> Sorry, Mr. Okay. Sorry, I kind of cut off for a second. 12. Okay, that's not Yeah, that's a pretty solid seed round. And you know, um, with this investment, you know, I think it always gives people opportunity to to get off the ground started, but you know, what are kind of as somebody who's in your

position, right? Like >> um, if I recall, you also raised series A. Is that correct? >> Not yet. >> Afterwards. No, not yet. Okay. So, you haven't. Yeah. So as somebody who's kind of in this position of uh you know getting customers growing um what's your experience been with you know uh you know you said you're getting all these new customers and things are going going amazing. Um do you feel like you would have in a competitive marketplace like this been able to even start without some sort of funding because you know of the the different hurdles that you have to you know like I mean that I I'd imagine it'd be pretty difficult like how does how how did you approach that whole situation? Yeah, it's a great question. Um, look, I I it depends on what you're trying to achieve. I I personally

believe that if you're trying to build a large successful software company, especially in a hot category like AI >> and especially infrastructure software like what we're trying to build, >> it's a winner take all market. most software categories are winner take all and so you have to swing for the fences and so that's what we did now we're not reckless and so we modulated our risk and so in the early days of the company before we even raised Sam and I did a ton of upfront what's called product market fit work we were basically trying to test if people would buy the product that we were proposing even though we didn't have it yet. We We pretended like we did to see if anybody would pay us and we did that a ton and that helped us really get tight on what it is we

had to build. And the moment we had strong conviction on what that was based on customer demand and willingness to pay, then we raised a bunch of money and then and then focused all of that capital on developing and going to market. Uh building software is very expensive. Engineers are very expensive. You know, I I don't know how you do it without a few million dollars in the bank. And then people underestimate how hard it is to learn how to go to market. You know, once a product's ready, you have to go build a marketing team and a sales team and fund it with program dollars and and this stuff isn't cheap. And in the world of AI, but in the world of software in general, this all moves so fast that you can't wait for that to be profitable and and selfuating on its

own revenue. you you have to lean heavily on the milestone signals you're getting and and invest ahead of any kind of profitability. And if you're right, you're going to keep doing that for as long as your growth dollars are effective. But this is why you see so many high growth tech companies constantly running in a negative. It's not that they're being reckless. In fact, they're I would argue they're doing the right thing. they continue to find opportunities to spend money for growth and they just keep it in as fast as they can and so we took a similar approach. >> Interesting. No. Yeah, that that that's some good insight because I' I'd say probably some who are unaware of how that works would just say they're being reckless and wasting the not wasting the money, but maybe maybe some think that um that they're not

making the most of their dollars. And uh yeah, no, that that that's interesting. I hadn't considered it like that, but >> yeah, to to put to put a to put a like a really fine point on it, I would say that taking our category as an example in the AI world, category winners are probably going to get crowned inside of the first 24 months of the category. >> And so, and so if you think of that perspective, we've been in market for a little bit over a year, >> okay? And I predict that the winner of our category is either already been crowned uh whe and whether or not we know it or not or is going to get crowned by the by the end of by the end of 20 by the end of 26. And so if you if you look at it

from that lens, you have to move incredibly fast. And how long would you say that your market just to put a full bun on it has existed or like the the clock started so to speak, right? >> Yeah. Depends how you argue depends how you look at it, but I would argue our category became real uh January or February of 25 when MCP came out. >> Yeah. Yeah. Yeah. I was Yeah, that Okay. Yeah. Interesting. So, >> yeah. So you're basically saying that the timelines at longest to like a like a year and 11 months. >> Yeah. Yeah. Pretty much. And so in a year and 11 months if you're in this category, you you have to be the clear winner. >> And and so far that seems to be us, >> but the game isn't over, right? You know, we're probably at the sixth

inning. And so, uh, we have to move incredibly fast to make sure that we're still the winner at the end of the game and but that game is incredibly short and so you have to you have to move fast. Part of it is having the capital to do it. >> That's actually that's actually the easiest part. >> The hardest part is knowing how to deploy the capital. >> And that's where things like product market fit are everything in this game. And so you can you can hand a competitor $40 million and doesn't mean they're going to win because do they know how to allocate the capital properly? And if they don't, they're just going to burn a hole, you know, in in in the ground versus a team that already has product market fit, already knows the the right message, the right buyer, the the

the right channels for marketing, the right feature sets, the right deployment strategy, the right documentation. that team can be incredibly efficient with whatever capital they have and they can move so much faster because they know exactly where to go. >> Okay. So, just to clarify this a little bit more, like obviously feels like you're the leader, right? That's what you're you're you're seeing from a growth perspective, from a product perspective, and just to let the people know a little bit more, why would you say that's the case? What are some of the key components of arcade.dev that makes that the case versus your competitors? >> Yeah, it's Oh, man. It's a great question. Uh actually I I was I wa I listened to a talk yesterday uh where somebody actually broke this down in their own talk. And so I'm going to totally plagiarize uh

the talk. I think it was given by company called Reforge. So >> if you're not plagiarizing, you're not doing good content. That's >> I'm quot I'm quoting Reforge. So uh we can even do an MLA type citation somewhere in here. But um if I remember correctly, it's about it's about um retention and engagement and scale. >> And so um when we look at our retention and engagement metrics, they're top tier. Um our activation rates on people showing up to our service and signing up is it just I I've never quite seen numbers like it, which is fantastic. And then when I look at my one day, 7-day, and 30-day retention numbers, they're all tier one. It's fantastic. We're very privileged. Now, a lot of engineering went into doing that. Uh these things don't happen overnight. Um and then there's a scale issue, right? Who is

who is using it? How many people are using it? What are they doing with it? And most importantly, in this space of AI agents, how many are going to production? And when we look at when we look at it through that lens, we have the highest quality of users that are building the most things that are going to be in production. And so we have the highest scale of quality users. Highest scale of quality users. Okay. Um what would Yeah. Like what would what would clarify like what is a a quality versus a non-quality user? I feel like that's a >> fair. So I think in in the world of AI agents is are you going to production? Like are you just like like we have a lot of people that are playing with our product and tinkering and and we do a lot to

make their experience fantastic, but do do any of them transition over and build something that's going to go to production that's going to be used by the rest of the world? Because those projects, one, not only are they the ones you're going to monetize, you're never going to monetize a tinkerer. We don't. We make our product as cheap and as free as possible for the tinkerers. You're going to make all your money on people actually going to production. That's where they see value. So, you can't capture value if your customers don't don't get value. >> Yeah. Absolutely. >> If they get value, we get to capture value. >> But more importantly, those become the reference implementations, >> right? They become the examples of the art of the possible. they become the taste makers of how these types of things should be built. And if you

don't have a population of that in your user base, then you you're not building the right product. >> Yeah. You know, it's interesting because I I do feel like there was that study recently that came out. Um everyone's talking about it. You familiar with the the 95% five >> study? Favor. Yes. >> Yeah. What were your thoughts on What were your thoughts on that? cuz I feel like you just spoke on the whole getting value out of the I mean in general that was about getting value out of like AI and AI agentic implementation. So like it's interesting you you bring up how you are in a position where you're finding the right customers to in fact get the value out of your product right whereas that doesn't seem to be the case. You know they're claiming it's like 5%. Um which I don't know

if it was a flawed study that sounds that sounds like it's too good to be true. I might be in a bubble. I don't or no too negative to be true. I might be in a bubble. I don't know. What were your thoughts on that? And and then how maybe you are getting these quality customers if that's the case. >> I think look I think I think the paper we can we can debate if it's 95 or 85 or 70 but directionally it's >> it's less it's correct, right? Like okay like the the the conclusion is correct. the the the the numbers and the details can be debatable, but you're seeing similar reports coming out from all kinds of other sources. I think Gartner puts it at 70. Um so somewhere in that range. So let's say the majority of agent projects fail or don't

go to production and we see that uh we see it anecdotally when we talk to customers. There's a bunch of reasons why that happens. Um they can't get the token costs to work out. The biggest one is they can't get accuracy and consistency to work out. uh they can't get the author work out. There's all kinds of things that just kill projects. >> Sure. >> But so like how do we how do we focus on the ones that are going to go to production? There's a lot to it, but part of it is making sure that the people that are going to go to production find us. And so that is really about us understanding what it takes to go to production and build a real agent. and then making sure that our product is designed to help people solve those problems. It's it's very

and this is actually a very big challenge in the world of agents because there's so much buzz and so much of the buzz is around people playing around like one of my favorite companies is NAM. >> I'm fascinated by everybody's >> a lot of people's favorites. Yeah. Now, if you I don't know exactly what's happening at Nan, so this is me from the outside guessing, but if if you were to look at where they're monetizing and where they're making money, I suspect the bulk of it is not exact on Reddit, right? But the buzz on Reddit is critically important because it's bringing people to come in to then go build the things that they're probably monetizing. And so if you're just looking at Reddit, it's very easy to believe that this particular workflow, this particular use case, this particular kind of hype thing is what

my product needs to be. But then you're probably missing what like the real high value customer that's probably a large enterprise deploying this for multiple workflows across multiple teams like their problem statements which are probably different. And so a lot of it is being deep in the problem statements >> on both sides >> and making sure that we're nailing both. We are building for the citizen developer who comes in and wants to play and tinker and is learning and we're making sure that there's a clear on-ramp and understanding of what a team's going to need at a real organization when they go to production. >> H yeah, you know, it's it is interesting. I think a couple things you pointed out there like the the token costs as well as the um stability, right, and the consistency of response and stuff like that. You know,

I think in general agentic AI LLMs for a while have had this this concern for companies. How how do you at Arcade kind of adapt to basically help make it easier and mitigate those those concerns? Because as a business owner myself, I know that if I'm implementing an agent in email inboxes or anything to that effect, like it can get pretty even for this podcast, right? I got an agent obviously to try to see whether the company is relevant to the show, but somehow even the agents mess up without extensive kind of work. How how do you make it that easy on companies to to implement those guard rails? >> Yeah, it's it's hard. Um I would say that the core insight of the company is grounded in that. >> So again came from an agent company. We were trying to build an agent. We

were running into all these problems ourselves. >> Okay. >> So the big insight that we've ultimately productized >> is >> let's let's take some of the work off the large language model. I give a very simple example. If I ask you to multiply 3,272 * 15,893 and I tell you not to use a calculator, you're probably going to get the question wrong. If I ask a large language model the same question, they're probably also going to get it wrong. But if I ask you to multiply four time four, you're going to get it right. And if I ask a large language multiply four by four, they're probably also going to get it right. And so you as a human, you use tools, use a calculator. >> Our big insight when we're building an agent, which is now kind of an obvious insight, but at the

time it was not, was let's not ask the large language model to multiply the huge numbers. Let's not ask it to figure out all this complex work. Let's give it a calculator with really big buttons. And by doing that, we reduced our error rates. We reduced our token costs because we were having to call the large language model a lot less with a lot less context too. We reduced our latency because again we were calling the large language models less with a lot less context >> and we were getting better results. Everything started to work. And now we weren't alone in this insight. Anthropic clearly came to a similar insight and released MCP. And so you know we're very fortunate to have it caught it at the right time. Um, but that's a big part of how you resolve this. Give it a calculator. You

want to send an email, don't have it infer how email works. Give it an agentic tool. Give it an MCP server with a tool that is send an email. >> Right? You want to do a reply, don't leave it to the large language model to figure out how to string together the Gmail APIs and unpack mime to go handle a proper reply to that maintains threading. do all that work in a function, in a tool, and just have the large language model pick the tool. Far easier. Or even more interesting, you're building a sales agent. You want to get a brief on the customer you're going to meet with right before the meeting. You're going to have your agent go reach into Drive to get the right brochure. It's going to reach into your email and your CRM to figure out like the latest history

on that account. So, you walk in brief. We can already use tools to go talk to drive, but why let the large language model navigate drive and then also navigate the different brochures to figure out which one the right which the right brochure is? That doesn't make any sense. Why not create a brochure tool that just does all of that navigation for you and makes the makes the the work and the decision for the agent that much smaller. that that insight of offloading to code is I think one of the biggest innovations in agents that is what's unlocking so many of the really cool projects coming down this year and next >> you know just to speak to that a little bit more you said that it I mean January February is when like MCP started becoming a thing I mean obviously cloud released that

like November of last year November 5th I remember is the date um we just did an episode on that and you know I think it'd be good to just kind of explain from your perspective how much of an unlock uh the MCP uh the modal context protocol really was because uh to me it's been one of the most eye opening experiences as I've delved into it uh over the last month or two. >> Yeah, it's fascinating. Um man, there's going to be case studies on MCP because it it just like it just hits it hits on so much academic work done on disruptive innovation. Um >> but okay so so here's what it is u it's just a protocol it is you know enthropic put out a paper that said hey this is how a large language model is going to communicate with another system

full stop and the original intent of it was for claw desktop so that you working on your local machine um could you know access things you could access your file system you could uh access git and a few other things and that was very it was a very breakthrough idea and it was very innovative u there were a number of other people working on some problem statements uh but uh and and then cursor adopted it and the moment cursor adopted it because >> you know if you think of cursor They're ultimately writing a bunch of code and there's a bunch of things that it needs to do in order to do it right. It needs to talk to your files. It needs to talk to Git. It needs to go check for documentation. It needs to go run playright. All those things are natural MCP

servers. And the moment cursor adopted it, man, it went bananas, right? All of a sudden MCP was everywhere. But initially it was just for the desktop. But if you look at what most agent builders, not developers using agents, but people building agents, what they need, they don't need a desktop agent. They need something that can run over the internet. >> This is so something for for broader use, something like chatbt or cloud online. >> So the desktop MCP won't work. And so there's tremendous growing pressure for MCP to support internetbased tools. And then they I forget the exact date uh but then they released HTTP streaming as an option and that unlock that's when MCP became in my opinion that's when it became a real option and so you've seen an explosion in MCP. Today it's largely still developers using it for their own software

development, but you're seeing a lot of people getting very excited and trying to use it to to build their own agents to to give their agents more and more tools. We firmly believe that is the future and I think I think there's broad consensus that that is the way it's all going to play out. It's still early though. aren't a lot of high quality HTTP MCP tools yet and almost none of them support proper O and so the the ecosystem is still constrained by capacity but it's coming uh people you know people lose sight the fact that HTTP streaming is only a few months old like the whole industry is already like fully standardized in MCP despite the fact that it's it's still nent um I would you know I would argue that the biggest challenge to MCP is that people are are are have

already skated ahead so far in their expectations that they're they're expecting SCP to be something that it's not yet but will be. And I think that's creating a lot of the problems. People like, "Oh, why can't it do this and why can't it do that?" It's like, "Yeah, bro. It's only a few months old. Like, give it time." Um, but it's going to get there and and we're super bullish and and we like many other companies are actively contributing to MCP to accelerate its path there. But to to really bring it back down to a very basic mental model, the large language models the brain. The tool layer like arcade are the hands. MCP is the protocol by which the brains talk to the hands and that protocol existing has created a tremendous amount of innovation around the hands. And so while chat tpt and

claude can't yet send an email on your behalf, the capability to do it in your own agent is already possible because of services like us. >> You know, I I find that interesting. You are right. It's nent. You know, I I I'll be honest. It took me a moment. I was like, I think that means early on. Let me Google that. Um some words you forget what they mean even though you know what they mean. But um yeah, so it is really early on still. And you you know, you're talking about the future of where it can go, right? and how you're attempting to accelerate it to that point. Where do you think the ultimate level is for MCP then? Obviously, it's not there now. It's new. You know, it's we're trying to get there. So, where is it going? Yeah. What is the goal?

>> I think, you know, it's funny. I would say that uh MCP's future is today's current expectations. And so, what people think MCP can do today, which it can't, is its future. I think you know people have already set a level of expectation uh that I think is largely complete uh and so which is which is both like I mentioned earlier it's a bit of a curse because you have to live up to an expectation that's not yet realistic but I think it's also a blessing because everybody needs to know where it needs to build towards there'll be you know there'll be modulations there'll be changes you know there'll be hurdles we'll run into all kinds of things but I think I think there's a lot of clarity, let's call it 80% clarity on where it needs to be in a year. Um, and then

the remaining 20% we'll bump into as we get there. Um, now I think the part that's fascinating where the jury is still out is I think we're starting to see a blurring of lines between what is an MTP server, what is an agent, and what is an application. And I think that those three things are starting to blur. An application at its most fundamental level in my opinion is a workflow automation system. An agent is a large language modelbased workflow system. Uh and an MCP server is how a large language model based application speaks to another system. And so the moment you put a large language model inside of a tool, which is just now starting to happen, the MCP servers and the agent start to look very similar. They start to blur. And the moment you start to build more intelligence into a traditional

application or you start to build more traditional software around an agent, the blurring lines of an app and an agent start to get, you know, pretty heavy. And you're already seeing this. The number of application vendors that are releasing their own MCP servers to wrap their app is getting very very high. And you're seeing a lot of MCP servers that themselves are agentic. And so what what I find interesting and and and and I think I'm bullish enough to predict is that MCP is the new HTTP. It is the new protocol by which anything in the AI space talks to anything else in the AI space. >> Yeah. Okay. Yeah, that that's a good answer to my question because you know I I I do think the expectation when I even started using MCP is that it's like this magical communication language, right? You've seen

the videos on the internet of uh Claude talking to or Chat GPT talking to Chat GPT with the ones and zeros language, right? and you're just assuming that's the the weird tech stuff happening in the background. But yeah, I guess it's not the case. But um you know, when this when this first came to be, right, January, February, you said is the timeline. Uh but if I'm not incorrect, last year, right, was the uh uh summer was like about when you >> Yeah. Actually, not last year. This year, like January, February of 24 is when >> Yeah. But for your company yourself, right? Uh right. It was uh last summer. Correct. Correct. >> Yeah. So, that is interesting to me, right? You've almost been in the marketplace with it about as long as you've been without it, if I can math, right? So, how um

how did your company kind of like shift when that whole situation occurred, right? Like maybe it was a whole hands- on deck situation. Like what was that like when you go, "Oh, this is like we got to do this." you know, like when you saw the >> capabilities. >> Yeah. You know, it's been interesting because um there's been a number of these events that have happened since we since we kind of focused in this category. I remember uh I remember when uh you know, when JSON mode came out >> for for for GPT, I think it was GPT40. Forget exactly which version it was. When JSON mode came out, there was this big question of wait, what does that mean for us? Is this is this good? Is this bad? We ultimately came to the correct conclusion. this was actually very good for us. Um,

similarly, when MCP came out at first, we looked at it and we didn't think much of it because it was it was a desktop protocol. So, it wasn't obvious to us at the time that it was going to evolve into what it is now. So, we had our eyes on it. We thought it was novel. They clearly had a similar insight to us. And so, we were all seeing the same thing. We found it very validating, but we didn't think it was yet relevant. And then as the as the demand and excitement for something like that really started to grow, we found ourselves considering with with one of our partners, hey, do do we release our own protocol? You know, there isn't there wasn't yet HTTP streaming for MCP. So, we knew the demand was there. Demand was getting louder. So, we're like, well, no

one's filling that gap. Do we fill that gap? And interestingly, we actually got very close to releasing it uh until MCPHP streaming came out. And then when we saw it hit the market, we were like, well, they're filling that gap. Why don't we just jump on that bandwagon? And then we tried to jump on the bandwagon. And honestly, the limitations of at the time made it so that it wasn't really production grade. And so we we we knew it was the future, but it wasn't yet ready for what our customers want to build. It didn't very specifically, it didn't support tool-based authorization. And so we knew this isn't project grade yet. And so we didn't touch it, but we watched it. And then as it kept growing and as it coming up more and more in our customer conversations, we realized, okay, we can't wait

for it to magically evolve. And so we leaned in in collaboration with Anthropic. And we started to contribute our intellectual property back to the spec to help unlock this tool authorization issue. And so there's a spec coming out uh it was actually recently accepted uh by MCP. you know, we're just as of as of the taping of this of this of this uh recording, it has not yet been released, but it will be hopefully by the time we by the time this thing gets published, it'll already released. And that'll that'll unblock MCP uh for the use cases that we focus on. But leading up to that, we made the decision a few months ago to just go all in on MCP and and uh and and we hope we're right. But ultimately, the decision came to what is our value that we bring to the

market? What what are the things that we need to own and what are the things that we can we can collaborate on? And when you're an early stage company, it's you get this feeling that you need to own everything. And that's a trap. And so, as I mentioned at the beginning of the call, part of part of the job is ruthless prioritization. And so, when we look at this, you know, it's incredibly strategic for a protocol to exist, but it's not critical for us to own it. We need it to exist. We need to be adopting it to be good. And so, if there's already momentum, all the better. let's jump in and accelerate it because it actually accelerates us in the process and the community. >> You know, obviously we're getting up to where we're at uh timewise on the show. It's kind of

went by really fast. I'm kind of shocked. Um that was uh it's been it's been great kind of hearing and learning about what you all are doing over there at Arcade and and your thoughts on on the progress of things. And I guess just just to kind of close it out, what would you say is the the number one thing you would recommend to business owners and those trying to get into the world of implementing AI agents into their their company in general, right? Because there's a lot of noise out there. There's a lot of advice. What What would be your one piece of advice? Yeah. Yeah. I've got a lot, but I'll give you I'll give you the most important one in my opinion is to get started. Like the technology is nent. Uh regardless of what path you take on what on what

tech, but all of it is relatively new. It's it's not perfect yet. It's incomplete. But that's kind of the point, right? This is it's it's this part of the journey of a tech wave where the winners and the losers are going to materialize in whatever category you want. This is like the internet in the late 90s. And so the earlier you and your organization start to play, start to tinker, start to try and get it to do anything or something useful, the earlier you're going to get on that learning curve. Because if you wait until it's all mature and stable, you're going to wake up and you're going to have any number of competitors that got ahead of you and you run the risk of becoming blockbuster. And so my number one piece of advice is start playing with it now. And I think the

large enterprise companies have gotten the memo because their boards and and investors have all kind of made them see the light. I think the place where people really need to start accelerating their experimentation is SMB because I don't know that they're feeling the pressure just yet, but by the time they feel it, it's going to be too late. H no, that's a very that's a very good point. I I think um getting started for me is really important not only in in general with agents, but I think anytime there's a new uh feature, right, like I just mentioned, I run a podcast about the AI about AI agents, right? And we've had conversations about other things and I'm I'm I'm very with it when it comes to automation and AI and whatnot. I wasn't really diving into MCP until about a month and a half

ago and I'm pretty upset at myself for that, right? Because when you learn about something new and maybe a little bit of a delay is fine when it gets the kinks out like you're saying production wise, but you know getting into it in general in this space is the best thing you can do because if you find that it provides value to your company uh and it's it's something you can have someone on the team improve a workflow for. It's it's one step in the right direction and I think the outstanding amount of value that's there is um is untapped probably by most companies. So >> yeah. >> Yeah. All right. Well, Alex, thank you so much for being on the show and uh please make sure to check out arcade arcade.dev. We appreciate Alex Salazar for being on the show and make sure all

of you to leave a like, comment, and a review on the podcast itself. Thanks so much for watching and we'll see you in the next one. Thanks.