Speaker 1: Warren.
Speaker 2: I'm pretty excited for today's episode. Know why is that
Speaker 2: because I have a lot of questions about this topic,
Speaker 2: Like I've heard that I've heard the phrase MCP so much,
Speaker 2: and I just have many questions.
Speaker 3: I mean, at some point you're going to have heard
Speaker 3: it too much. And with that, maybe I'll drop a
Speaker 3: little fact for the episode. There was a little research
Speaker 3: done not too long ago about the adverse impacts of
Speaker 3: mentioning artificial intelligence in product and service names, and they
Speaker 3: found that it actually significantly decreases consumer trust. Really, I
Speaker 3: think that tracks.
Speaker 2: Yeah, it seems reasonable.
Speaker 3: Like you go to Starbucks and you get some coffee
Speaker 3: and they're like, now with AI included, are you like,
Speaker 3: are you gonna be happy for that?
Speaker 2: Absolutely? Can I get my double vine latte with AI
Speaker 2: on a blockchain?
Speaker 3: We'll come with MCP on the side.
Speaker 2: Okay.
Speaker 1: Cool.
Speaker 2: So speaking of which, Gil, you're here to talk to
Speaker 2: us about MCP.
Speaker 4: Yeah, I'm very excited too, and I am one of
Speaker 4: those people who's actually heard MCP way too many times,
Speaker 4: so happy to do that.
Speaker 2: All right, Before we jump into that, give me a
Speaker 2: little bit about your background.
Speaker 4: Absolutely, So, as you mentioned, I'm Gil, I am the
Speaker 4: co founder and CTO of Merge and Merge is a
Speaker 4: platform that offers unified epis to help companies offer integrations
Speaker 4: with a ton of different products in any specific vertical
Speaker 4: from ticketing, CRM, file storage, and so on, and a
Speaker 4: lot more coming in the AI space MCP all of
Speaker 4: that as we'll talk about today.
Speaker 1: But before that, I.
Speaker 4: Went to college in New York and then ended up
Speaker 4: going straight into tech. So I worked at LinkedIn out
Speaker 4: in San Francisco, and then worked at a couple smaller startups,
Speaker 4: which ultimately led me to this problem of integration, seeing
Speaker 4: how it's just bogging down space, so I decided to.
Speaker 1: Star Merge to tackle that problem. And it's been great.
Speaker 4: It's been about five years now, four years since coming
Speaker 4: out of Stealth. We've gone from zero to one hundred and
Speaker 4: ten employees. We have almost fifteen thousand free and paying
Speaker 4: customers all around the world. We have our three offices
Speaker 4: in San Francisco, New York, and Berlin.
Speaker 2: Right on right on. So with four years like that's
Speaker 2: a pretty solid record for a startup, you're feeling pretty
Speaker 2: confident about this.
Speaker 1: Yeah.
Speaker 4: Absolutely, I think that we're seeing that this is a
Speaker 4: bigger problem than we have ever even envisioned. Everyone needs integrations.
Speaker 4: The problems only getting worse now with AI. You have
Speaker 4: these models that have essentially ingested the full public corpus
Speaker 4: of Internet data, and all that's left is private data.
Speaker 1: And that's what Merge does.
Speaker 4: We specifically help companies get access to their customers data.
Speaker 4: So we're excited about the problem now, but also where
Speaker 4: it's going, both in the traditional API and integration building
Speaker 4: space as well as all of the upcoming AI and
Speaker 4: MCP driven integrations right on.
Speaker 2: So like is the concept there? Instead of having to
Speaker 2: go and figure out the API docs for the fifteen
Speaker 2: different services I need to integrate with, I just connect
Speaker 2: with Merge and you're like the relay to those services
Speaker 2: for me, and I just have to talk to one service.
Speaker 1: That's exactly right.
Speaker 4: So an example here brax Ramp, which are corporate cards.
Speaker 4: Their customers have merged and they use us to power
Speaker 4: a few use cases. But notably they want to automatically
Speaker 4: onboard employees of companies that use their credit cards, automatically
Speaker 4: mail them a credit cards to their home address based
Speaker 4: on their title. Maybe give them twenty dollars a day
Speaker 4: for lunch if they're an engineer, for example, and then
Speaker 4: they want to terminate those cards when person leaves the company,
Speaker 4: and manually managing all of that is impossible, and so
Speaker 4: instead they want to integrate with the HR systems to
Speaker 4: be able to pull in all this data. But some
Speaker 4: of their customers use Bamboo HR. Gusto namely worked a
Speaker 4: SAP and they have to build all of those integrations.
Speaker 4: So instead they integrate once with us, and we integrate
Speaker 4: and sort of normalize all that data to one format that.
Speaker 1: They integrate with.
Speaker 4: And then again we do that for HR, but we
Speaker 4: also do that for a lot of other platforms like ticketings, RM,
Speaker 4: file storage and so on.
Speaker 2: Right on, that's cool, that's cool. So let's jump into MCP.
Speaker 2: Give me the give me like the layman's version of
Speaker 2: what MCP is.
Speaker 4: Yeah, so there's a lot of ways to think about MCP,
Speaker 4: but I think the important node here is it's actually
Speaker 4: a really simple concept. It was a standard that was
Speaker 4: reached similar to other protocols and standards of the Internet
Speaker 4: that ultimately aren't so complicated, but solved the need, which
Speaker 4: was that there was a major lack of standardization. And
Speaker 4: so when we think about the history of APIs building
Speaker 4: an integration required you to go to API documentation and
Speaker 4: explicitly say I'm going to take data from this point
Speaker 4: and I'm going to move it to this point. A
Speaker 4: lot of complications there, but overall you're doing that. Now
Speaker 4: in the agentic era, you want to expose those API
Speaker 4: calls essentially to an agent so that you can actually
Speaker 4: give it arms as a to them being these sort
Speaker 4: of you know, things to say, Hey, here's how you
Speaker 4: solve this. Go log into your Salesforce account, click this button,
Speaker 4: click that instead letting the agents actually take those actions
Speaker 4: for you. And so MCP is essentially a way to
Speaker 4: make it so that those API calls or actions or
Speaker 4: tool calls is as you would say, are available and
Speaker 4: exposed to the agents in a way that it can
Speaker 4: easily understand, and so then it can formulate a workflow
Speaker 4: knowing what tools via MCP are available to it and
Speaker 4: then make those calls.
Speaker 3: What would stop an agent from being able to integrate
Speaker 3: with the existing API docs or one of the standards
Speaker 3: like open API Specification or whatever Ataboose is using with
Speaker 3: Smithy just consume that and be able to generate the
Speaker 3: appropriate calls into the APIs.
Speaker 1: So there's a.
Speaker 4: Few things that are that are differentiators, but overall, I
Speaker 4: will say, at a high level, I'm with you. I
Speaker 4: think it's it's not even a hot take anymore to
Speaker 4: say that MCP doesn't actually do all that much. You
Speaker 4: have API documentation that's built for humans to build integrations.
Speaker 1: You have open API specs, which.
Speaker 4: Were kind of the next evolution of hey, some static
Speaker 4: script can understand my API and build docs or SDKs
Speaker 4: out of it. And then finally you have MCP, which
Speaker 4: is just another type of rapper that allows agents to interact.
Speaker 4: I think the difference is MCP is not stateless like
Speaker 4: documentation or like you know, like an open API spect
Speaker 4: but instead it's an actual running server that stores credentials,
Speaker 4: that manages sessions and can be stateful. So it's it's
Speaker 4: not ultimately adding a ton more, but it does unlock
Speaker 4: a few additional abilities that are necessary for an agent
Speaker 4: to take actions.
Speaker 3: That's I feel like a little scary, like I've I've
Speaker 3: designed the perfect service that is stateless in every way
Speaker 3: with you know, I've thought a lot about what the
Speaker 3: endpoint should be, and in order for an agent to
Speaker 3: work with it, we're saying you need to actually forget
Speaker 3: everything that you've built so far, make a different doc
Speaker 3: that is readable, and also start storing state and do
Speaker 3: a lot of extra stuff that you specifically didn't want
Speaker 3: in your service to begin with.
Speaker 4: Yeah, it's true, I think that, you know, when you
Speaker 4: think about like a statically coded app, though you would
Speaker 4: pull from you know, let's say that you want to
Speaker 4: update all records, all ticketing system tickets that have Gill
Speaker 4: in the title. You have to pull in all those tickets,
Speaker 4: then you have to iterate through them and modify them,
Speaker 4: and then you need to write them back. So there's
Speaker 4: this notion of like state needs to be maintained between calls.
Speaker 1: And an agent. An agent can do that.
Speaker 4: But you can also write tools on the server that actually,
Speaker 4: you know, manage a lot of that. So what you're
Speaker 4: doing is you're deciding how much complexity you want to
Speaker 4: expose to the agent and how much you want to
Speaker 4: wrap behind a statically coded tool that the agent can
Speaker 4: then call.
Speaker 3: So normally you would push the if your API was
Speaker 3: fetch ticket and then update ticket as two independent API calls,
Speaker 3: and that's all you offered. You were like, we don't
Speaker 3: offer bulk support, and the client would be responsible for
Speaker 3: actually pulling each one of those and then updating them individually.
Speaker 3: And if we're saying that you're building a proxy in
Speaker 3: between there, it's because the API that you're offering to
Speaker 3: end users wasn't valuable enough that it wasn't actually solving
Speaker 3: the needs that they would frequently have. I don't think
Speaker 3: bulk actions are very common, so I think in that
Speaker 3: way this is a little interesting to saying, like, well,
Speaker 3: now you need to actually start thinking about what the
Speaker 3: value of your service is actually offering, because if people
Speaker 3: want to do these bulk actions, you may think about
Speaker 3: wanting to provide that, and this is where you would
Speaker 3: prevent actually provide this logic in a agent based system.
Speaker 4: I mean absolutely, and I even say this about MCP service.
Speaker 4: They're not unlocking anything that new. They are fully limited
Speaker 4: by the capabilities of the underlying API. Notably this is
Speaker 4: MCP for API interactions. You can use MCP to wrap
Speaker 4: SEQL calls to a local database, that sort of thing.
Speaker 4: But yeah, and one of the big problems you see
Speaker 4: in the integration space and have seen for years, is
Speaker 4: that you often have to pull full data sets. And
Speaker 4: the reason you have to pull full data sets is
Speaker 4: that you don't have good search endpoints in these APIs,
Speaker 4: So I would say, I would say most inefficient integrations
Speaker 4: are built by bad APIs, not necessarily bad consumption patterns
Speaker 4: or anything else.
Speaker 3: Oh they're going to say bad engineers, and that I would.
Speaker 4: I mean, yeah, hopefully that one's not going to be
Speaker 4: The engineering skill level won't matter as much anymore. We're
Speaker 4: working on a new product right now, and I can
Speaker 4: tell you from using AI to build it, the skill
Speaker 4: gap is closing really really fast.
Speaker 1: It is so good now interesting.
Speaker 2: So so you think the vibe coding is leveling up?
Speaker 1: Oh yeah, Oh yeah, it's scary to say.
Speaker 4: Look, I'm an engineer who's I've been coding for for
Speaker 4: almost actually over twenty years now.
Speaker 1: I love it.
Speaker 4: I'm so passionate about building, and it's scary to see
Speaker 4: it just writing code that you would have written. But
Speaker 4: I also think it's really leveling me up too. We
Speaker 4: vibe coded, so me, a product manager, and a software
Speaker 4: engineer are building this new product. Our product manager, who
Speaker 4: has never written a line of code in his life,
Speaker 4: built our entire front end for it. We imported that
Speaker 4: into GitHub. Then we took over with Windsurf and started
Speaker 4: started you know, actually doing some a little bit more
Speaker 4: guided AI coding on top of it.
Speaker 1: But it worked and it was great, and then we
Speaker 1: just connected that straight to the back end right on.
Speaker 2: Yeah, I think that's been my experience. Like it's really
Speaker 2: easy to get started with AI, but then I think
Speaker 2: after like those initial few steps, I think it's still
Speaker 2: important to have the technical skills. And I treat AI,
Speaker 2: and the way I try to get people to treat
Speaker 2: AI is think of it as if you had your
Speaker 2: own intern or your own junior engineer, you know, like,
Speaker 2: don't treat the AI as a principal architect. Treat it
Speaker 2: as an intern, and give it very small scoped tasks
Speaker 2: that you can check up on, because it's it does
Speaker 2: sometimes get things wrong and just like your intern would,
Speaker 2: so you've got to give it a task that you
Speaker 2: can follow up and make sure that it's continuing to
Speaker 2: build towards the same end goal that you are. And
Speaker 2: I think that's where a lot of projects get off
Speaker 2: the rails, as they just give AI like this vague
Speaker 2: task without the guardrails to keep it from wandering off
Speaker 2: and hallucinating.
Speaker 3: I want to probe you on that well, definitely, because
Speaker 3: I see a lot of companies are not hiring interns
Speaker 3: and have no idea what to do with some interns,
Speaker 3: And yet they're coming up and hiring llms out there
Speaker 3: in the world to interact with, and I don't have
Speaker 3: the faith that they are capable of understanding how to
Speaker 3: provide that additional contact. So are you optimistic about where
Speaker 3: the quality of software in the world is going?
Speaker 2: I think so, yeah, because like on a large enough
Speaker 2: time frame, like this is going to work.
Speaker 1: Itself out, you know.
Speaker 3: Yeah, the death of the universe right around the corner.
Speaker 2: Yeah, absolutely, Like in the big scale of things, it
Speaker 2: doesn't really matter. But no, like specifically to your question,
Speaker 2: in people like engineers not having the skills to guide
Speaker 2: an intern, I would agree with that. I would include
Speaker 2: myself in that bucket as well as something I've had
Speaker 2: to learn and improve on. And I think that's where
Speaker 2: I think that's the skill gap that AI doesn't cover.
Speaker 2: So AI can write the technical code, but as an engineer,
Speaker 2: your value add into that equation is maintaining the big
Speaker 2: picture and breaking that down into concrete, isolated tasks. It
Speaker 2: can be distributed to junior engineers, interns, AIS, senior engineers,
Speaker 2: whatever is on your team.
Speaker 1: I totally agree with that.
Speaker 4: And I think we see this a lot. We see
Speaker 4: a fear of adopting AI from a lot of engineers
Speaker 4: or and it's not necessarily a fear of you know, oh,
Speaker 4: it's going to take my job, But I think it's
Speaker 4: a fear of it building bad software, or it just
Speaker 4: changing the way that someone is used to building in general.
Speaker 4: And I think the way that I explain this to
Speaker 4: my team is, you know, yeah, you're frustrated because it
Speaker 4: generated bad code number one, that's time for introspection.
Speaker 1: What did I do wrong? How do I prompt better? Yeah?
Speaker 4: But also, you know, I think that a lot of
Speaker 4: people see this as like, Okay, it's spent out really
Speaker 4: terrible code, I'm going to waste so much time cleaning
Speaker 4: it up. But what I'm not thinking about it's like, Okay,
Speaker 4: what if that eight hours buildings by hand? Or I
Speaker 4: can spend thirty minutes prompting it to create something, and
Speaker 4: then thirty minutes to an hour cleaning up the code,
Speaker 4: and then I've spent you know, a fourth of the
Speaker 4: time just maybe not how I'm used to building.
Speaker 3: Yeah.
Speaker 2: One of the big takeaways I've had from working with
Speaker 2: AI has been applying that to the rest of my life.
Speaker 2: Like I give AI a bad prompt, it writes bad code,
Speaker 2: and I spend a bunch of time cleaning it up
Speaker 2: and then thinking about what should I have said differently?
Speaker 2: And then I started looking at like other conversations in
Speaker 2: my life, and when I'm talking to humans now, I
Speaker 2: use that same process, and I realize, like, a lot
Speaker 2: of the pain and suffering I've had in my life
Speaker 2: is because I gave another human a bad prompt.
Speaker 3: Yeah, wow, you have relationships built on lies. Right, It's
Speaker 3: like I need to go back to this first conversation
Speaker 3: I ever had with this person and maybe change what
Speaker 3: I said to them, because that that's that set me
Speaker 3: up for a success or failure.
Speaker 1: Right.
Speaker 2: Yeah, It's like this whole chain of events that happened
Speaker 2: in my life could have been corrected had I given
Speaker 2: that person the right prompt to begin with.
Speaker 4: You very well may have just changed my dating life forever.
Speaker 4: It wasn't expected outcome of this call, but it really hasn't.
Speaker 3: It just become like you just sick one agentic agent
Speaker 3: at some dating service, and it will talk to another
Speaker 3: LM out there and then they'll decide collectively whether or
Speaker 3: not to start your relationship.
Speaker 4: Yeah, I mean it's once once Tender release is their
Speaker 4: official MCP server.
Speaker 1: We're going. I'm in.
Speaker 3: I mean, I assume people are doing this. They're just
Speaker 3: scraping the app and you know, uploading data anyway. I mean,
Speaker 3: or it's a human in the loop still, like it's
Speaker 3: still telling you what to type. Uh, you're just you're
Speaker 3: just doing Yeah, Like I don't. I don't think automating
Speaker 3: it is going to mean maybe that's what we're missing.
Speaker 3: We're missing the automation so people can get on more
Speaker 3: dates faster.
Speaker 1: I've been I've been seeing the tiktoks because I guess
Speaker 1: the dating apps are going after people who are automating.
Speaker 4: Of some people who set up an actual phone in
Speaker 4: a room with a little rubber hand on.
Speaker 1: A screwdriver or on a on a drill that's just swiping.
Speaker 3: I mean, it's a it's a miss market for them.
Speaker 3: Like if all of your users are doing something we
Speaker 3: know from there's like some great books out there like
Speaker 3: Platform Revolution that you should actually, other than trying to
Speaker 3: prevent that behavior and punish people for it, realize that
Speaker 3: is where the value is being added. And like I
Speaker 3: think the swiping left or right is the action which
Speaker 3: makes people feel invested in the action they're taking so
Speaker 3: that they're more likely to continue. So, you know, give
Speaker 3: them that capability, but give them what they want, which
Speaker 3: is like maybe a multi select option or or you know,
Speaker 3: something like that, and to take it to the next level.
Speaker 3: Rather than banning those people, let them have that functionality
Speaker 3: like once a day and then you know, up charge
Speaker 3: for it for the you know, next one hundred matches.
Speaker 1: Yeah, the AI matchmaker, Yeah right.
Speaker 2: Exactly, well, yeah right, just be open with it, like say, okay,
Speaker 2: I see, I see what you're up for here, and
Speaker 2: I'm gonna make it easy for you. You just gotta
Speaker 2: upgrade your service level here, sign up for the next
Speaker 2: plan and I got you dude.
Speaker 1: Mm hm cool.
Speaker 2: So so back to MCP, it's it sounds like it's
Speaker 2: very agent focused. Is that an accurate statement?
Speaker 1: Yeah?
Speaker 4: So, so people still ask us this a lot, you know,
Speaker 4: when when do we want to use a traditional API
Speaker 4: versus MCP? And I think that the way to think
Speaker 4: about it is a lot of what we've built is
Speaker 4: still the best possible.
Speaker 1: UI or something.
Speaker 4: So if I want to cancel an order is it
Speaker 4: easier for me to go to Amazon, go to my
Speaker 4: orders and click cancel, or to open up a chat
Speaker 4: butt and say hi, the order for this, and it's like, okay,
Speaker 4: are you Are you referring to disorder and I'm like yes,
Speaker 4: And it's it's just not the best the interface to cancel,
Speaker 4: and so for that there's a button, and to have
Speaker 4: a button then prompt an agent and say hey, the
Speaker 4: customer would like to cancel disorder, and it then has
Speaker 4: to decide on a tool, and then it has to
Speaker 4: make sure it's calling the right tool and make that call.
Speaker 4: One it's just inefficient and really slow. But two, you're
Speaker 4: going from a world of a very deterministic action I
Speaker 4: click a button that runs this code that cancels this
Speaker 4: order to we think that the agent should be able
Speaker 4: to figure out the right tool to call, but it
Speaker 4: might not get it right every time.
Speaker 1: And again we're spending a lot of money on having
Speaker 1: the agent decide what to actually do.
Speaker 4: And so I think in a lot of cases, classic
Speaker 4: APIs are still going to be the really valuable one.
Speaker 4: MCP is for agentic interfaces, it's for bots, it's for communications.
Speaker 4: It could be a customer facing bot it could be
Speaker 4: an internal sorry by bottom referring to it could be
Speaker 4: a customer facing agent, it could be an internal agent,
Speaker 4: or it could be some form of non exposed agent
Speaker 4: that's actually just taking actions.
Speaker 3: I really like this take. I think it's really interesting
Speaker 3: and I want to repeat this. Basically, if the thing
Speaker 3: that could bring you value in your business or your
Speaker 3: API is allowing increased volume or speed for execution, this
Speaker 3: could be the right thing to do. But if you
Speaker 3: don't want people to cancel your orders, don't make it
Speaker 3: easier for them to do that.
Speaker 4: So that's not where it was going.
Speaker 3: But that's why that's what I no, but.
Speaker 1: I think I will.
Speaker 3: It's interesting that you chose Amazon though, Like you know,
Speaker 3: if you pick something and it has a really great
Speaker 3: user experience, then it doesn't necessarily make sense to automate that.
Speaker 3: But as we know out there, there's like every company
Speaker 3: sucks at UX. So you know, you think about that,
Speaker 3: do you want to invest in you you actually do
Speaker 3: want to just throw money at the problem and run
Speaker 3: a really expensive service somewhere to manage state for letting
Speaker 3: agents manage the user experience.
Speaker 1: Yeah, yeah, I.
Speaker 4: Mean ultimately they're going to that specific example they're going
Speaker 4: to do both anyway, But in general, the idea is
Speaker 4: like a static action that's button driven, classic API integration
Speaker 4: AGENTIC MCP.
Speaker 2: Whenever you're building out an MCP, how do you debug that?
Speaker 2: Like in this example, you know where you're talking about.
Speaker 2: It's trying to figure out the best course of action
Speaker 2: to do what it thinks the user wanted to do.
Speaker 2: And then sometimes it's wrong, like what kind of feedback
Speaker 2: do you get or what kind of metrics are you
Speaker 2: collecting to track that and improve on that?
Speaker 3: It's just a proxy, right or is there something else
Speaker 3: magical happening in there?
Speaker 4: Yeah, So how MCP works is effectively you create an
Speaker 4: MCP server and that has a function on it called
Speaker 4: get tools, and it returns back to the agent that's
Speaker 4: calling it, or the MCP client. But effectively the agent
Speaker 4: it says, hey, here are the tools available to you.
Speaker 4: Create a ticket in asana, modify a ticket, change the
Speaker 4: status of a ticket, and effectively, on the MCP server,
Speaker 4: you're right, those are just wrapping API calls, and so
Speaker 4: when the agent calls get tools, it then actually uses
Speaker 4: its LM abilities to decide which tools should be called
Speaker 4: based on the human The English description in that MCP
Speaker 4: server of what each tool does. So yes, it is
Speaker 4: statically coded. The place where there is sort of that
Speaker 4: that decision making is on the agent itself about how
Speaker 4: it's going to chain all those tool calls together.
Speaker 2: Gotcha, and are you bringing your own LLLM into the
Speaker 2: agent or using like publicly available ones.
Speaker 4: So this is totally up to whoever you know. It's
Speaker 4: compatible with all agents. The idea is is you know
Speaker 4: your agent can make a tool call its most agents,
Speaker 4: your agent can make a tool get tools call, and
Speaker 4: then it doesn't matter what model it is. It then
Speaker 4: determines what tools to call.
Speaker 1: And you see this.
Speaker 4: Also with things like even even windsurf and cursor for coding.
Speaker 4: You can see that when you ask it to do something,
Speaker 4: it kind of formulates a workflow using the tools available
Speaker 4: to it, like edit file, read contents of file, that.
Speaker 1: Sort of thing.
Speaker 3: I think, I think I finally figured it out. It's
Speaker 3: that there is just too much functionality in some of
Speaker 3: these products and services. And someone thinks that their opinion
Speaker 3: opinion version of the world is the most optimal and
Speaker 3: effective one, and they've coded that in an MTP server.
Speaker 3: So they look at GitHub, they look at GitHub and say,
Speaker 3: you know, I only do five actions. I only like
Speaker 3: copy code, make commits, push up pull requests. You know,
Speaker 3: then you know, once pull requests there as I approve
Speaker 3: it and maybe deploy it. And if that's my whole
Speaker 3: version of the world, then having the whole access to
Speaker 3: all of githubs or git labs or whatever's API is
Speaker 3: totally unnecessary. You don't need all those things. So let
Speaker 3: me make a personalized MTP server that just understands how
Speaker 3: to integrate in this one way, and then I'll expose
Speaker 3: that for interacting with the other tools.
Speaker 1: That I have. Oh yeah, yeah, I think that's right.
Speaker 4: And you can also you can extend it, and so
Speaker 4: a lot of times people will you know, notice, hey,
Speaker 4: whenever it's really important to me to build an agent
Speaker 4: where someone can ask it, you know what, what is
Speaker 4: what pull requests had the most reviews on it? And
Speaker 4: GitHub doesn't necessarily have a way to do that via
Speaker 4: their API. And so you could write a tool that's
Speaker 4: called you know, get repo with most stars, and that
Speaker 4: might make many API requests and do all that and
Speaker 4: then just return the repo at the end. So it's
Speaker 4: while it is stringing together the API calls. You're effectively
Speaker 4: building a tool chain within each tool as well.
Speaker 3: Micro services.
Speaker 2: Yeah, yeah, you can say that I don't know, but
Speaker 2: it's micros macro services because we've gotta put AI in
Speaker 2: the middle of the word now that it's a new
Speaker 2: tool Yeah. So you mentioned that these are not stateless,
Speaker 2: So what does the what's the infrastructures look like?
Speaker 1: So it depends on how you end up building it.
Speaker 4: I mean, I mean some people will back it with
Speaker 4: just you know, cash, you'll use in memory, you can,
Speaker 4: you can connect it to a database. You run into
Speaker 4: some risks though, right of of you know, sort of cross.
Speaker 1: Cross user data sharing.
Speaker 4: There's a whole new a whole new suite of potential
Speaker 4: security issues with MCP now that that come up, and
Speaker 4: it's something that we are we're hard at work at,
Speaker 4: not just you know, for us, but for customers as well.
Speaker 4: As we built that our new product, but we do
Speaker 4: have to also think about it for ourselves in everything
Speaker 4: we build.
Speaker 1: Now.
Speaker 3: The thing that really comes to mind a lot here
Speaker 3: is think about what, given the state of the world,
Speaker 3: what is the optimal way to allow agents to interact
Speaker 3: with things? And if you think about where the costs
Speaker 3: are it's having the agent do anything, So minimize the
Speaker 3: agent workload as much as possible, So limiting the input tokens.
Speaker 3: That means that don't force it to read the whole
Speaker 3: knowledge base and the whole API spec. You want to
Speaker 3: have it collapse into something very opinionated, very specific, with
Speaker 3: only the keywords that are necessary, like don't even use
Speaker 3: human readable descriptions there, right, like you know, focus just
Speaker 3: on those most important keywords. And same goes with the
Speaker 3: output stuff. So every single additional output token is also
Speaker 3: going to charge you. So you want to capture as
Speaker 3: much of the value of the action that you want
Speaker 3: to take in this intermediary MCP server.
Speaker 1: Yeah, yeah, I think that's right.
Speaker 4: It's both a security thing as well as it adds
Speaker 4: capabilities and makes things more efficient.
Speaker 1: Yeah.
Speaker 3: So yeah, the security thing, I think that's going to
Speaker 3: keep coming up for the till the dawn of time.
Speaker 3: I mean, because especially with the automation, right, we're using
Speaker 3: these LM tools to assist us in making additional services,
Speaker 3: additional value provided for our products and businesses and skipping
Speaker 3: the part where we're heavily interrogating what comes out of it.
Speaker 3: And this is an area where we're going to have
Speaker 3: a lot of extra usages going through here. Whereas the
Speaker 3: underlying API store is has you know, years maybe decades
Speaker 3: built up into how to make this API secure. Now
Speaker 3: we're cash data effectively not allowed cross contamination, et cetera.
Speaker 3: And now we're adding a layer on top that someone
Speaker 3: just throwing things as fast as possible to expose the
Speaker 3: data in a way that allows other agents to interact
Speaker 3: with it in the way they see as most optimal.
Speaker 1: Yeah, and there's there's a lot of new risks with it.
Speaker 4: And you know, one good example here is is API
Speaker 4: token passing in this idea of like, okay, well if
Speaker 4: the key lives on the MCP server, maybe that can
Speaker 4: never be exposed.
Speaker 1: So you go, you ask the agent like what is
Speaker 1: the API token?
Speaker 4: It's going to say, I don't have access to that,
Speaker 4: or I've been I've been programmed not to tell you.
Speaker 4: But let's say that this is an integration where it's
Speaker 4: connecting to say Salesforce, where everyone has a different sub domain,
Speaker 4: and part of your setup is what is your sub domain?
Speaker 4: And you find a way to just pass in an
Speaker 4: entirely different URL and basically overad what it's doing and
Speaker 4: have it make an API call and that URL as
Speaker 4: a private server that you're hosting, and you're getting that
Speaker 4: apike sent right to you.
Speaker 1: So we're seeing a big new class.
Speaker 4: That's just one example, and there's going to be a
Speaker 4: whole new set of rules, a whole new set of
Speaker 4: like linting that's going to have to catch this, but
Speaker 4: also intermediate security services for MCP specifically, and yeah, again,
Speaker 4: that's that's somewhere we're going.
Speaker 2: Yeah, so there's a whole layer of impersonation in here
Speaker 2: because you've got the MCP service that responds to requests
Speaker 2: from multiple people, but each one of those individuals probably
Speaker 2: has different permissions, and so the MCP service has to
Speaker 2: impersonate the request based on what credentials that person has,
Speaker 2: like to use your example earlier of canceling ramp cards
Speaker 2: for employees. It has to determine, you know, does this
Speaker 2: person have the ability to cancel cards at all, and
Speaker 2: if so, which cards.
Speaker 3: Yeah, I mean, I think realistically you're talking a little
Speaker 3: bit about the confused deputy problem here, where you're passing
Speaker 3: off the request to a privileged agent which is going
Speaker 3: to have requests from multiple different users and customers and
Speaker 3: it needs to do effective authentication and authorization. You can't
Speaker 3: just pass all the data along and expect the underlying
Speaker 3: API to do the right thing, and the individual agent
Speaker 3: might have its own identity or the actions that it's taking,
Speaker 3: And like, we've already solved these problems in the world.
Speaker 3: It's just that I think fundamentally, the people that are
Speaker 3: most closely working on the software and the control inside
Speaker 3: MCP services haven't thought about these things as deeply as
Speaker 3: they are. Like, my whole domain is just app seck,
Speaker 3: Like I only think about authentication and authorization all day long.
Speaker 3: That's pretty much my only job. And there's still way
Speaker 3: more in security than that, and I can get And
Speaker 3: I'm giving a talk literally in a couple of weeks
Speaker 3: like what the heck is off, like just explaining to
Speaker 3: people what these concepts are, and I'm getting a lot
Speaker 3: of feedback like, oh, mcps a thing, like how do
Speaker 3: we do this? It's even more important now, And I'm
Speaker 3: like that's really surprising.
Speaker 4: Yeah, it begs the question it does does OFF even
Speaker 4: belong in the MCP s back itself or is everyone
Speaker 4: going to keep just building it on their own because
Speaker 4: right now there's not much in there about it, how
Speaker 4: to actually implement it, how to actually handle it other
Speaker 4: than saying, you know, you probably should should keep off
Speaker 4: on the MCP server itself.
Speaker 3: I think, yeah, I mean it's a really good point.
Speaker 3: I think the biggest problem is that you're not just
Speaker 3: building this proxy layer that statelessly passes along request. And
Speaker 3: this has been a huge problem with proxies to begin with,
Speaker 3: and now people are taking it further and saying, oh,
Speaker 3: we know what we want to do, We've already figured
Speaker 3: it out. We don't want to explode the number of
Speaker 3: input tokens or pass the context back to the caller,
Speaker 3: so they have to iteraly call the endpoints. We want
Speaker 3: to handle all that in scope here, which means, as
Speaker 3: you pointed out, managing state, and that becomes the risk
Speaker 3: really doing that effect actively and correctly so you don't
Speaker 3: end up with this crossing. And there are tons of
Speaker 3: security vulnerabilities cvees that get published every single month about
Speaker 3: how one customer was able to access a different customer's
Speaker 3: data publicly on the Internet, and like, those things all
Speaker 3: happen without MVP servers, and now people aren't even thinking about, oh,
Speaker 3: how do we actually even handle off here? So yeah,
Speaker 3: We're definitely going to get into a problem very quickly.
Speaker 4: Yeah, and the problem, you know, one of the things
Speaker 4: we're seeing as we build out this new product is
Speaker 4: specific requirements from people around credential sharing among people who
Speaker 4: talk to the agents, but varying who shares which credentials
Speaker 4: for different services.
Speaker 1: So, you know, you have an.
Speaker 4: Agent that has access to both a ticketing system and salesforce,
Speaker 4: and everyone who talks to it should be able to
Speaker 4: use the shared ticketing credentials, but only the sales team
Speaker 4: should be able to actually communicate with salesforce, and then
Speaker 4: only super admins should be able to use the HR
Speaker 4: you know, credentials. So we're seeing this a lot, and
Speaker 4: it's going to be interesting to see how people approach it.
Speaker 3: That's like our whole product right there, Like that little
Speaker 3: aspect you described is like the whole thing that we do,
Speaker 3: uh for internal resources because I mean, it's really unfortunate
Speaker 3: that we live in the world of credential sharing, but yeah,
Speaker 3: it still happens because companies charge for uh, you know,
Speaker 3: SSO and first class options.
Speaker 1: Yeah.
Speaker 2: So, Warren, are are you at offerers creating an off
Speaker 2: front end for MCP services.
Speaker 3: I don't even know how to answer that question. You know,
Speaker 3: it's like, what's the difference between off for MCP and not?
Speaker 3: I mean, there's literally no difference. Like whatever we offer
Speaker 3: is like it's the same. There really is no difference
Speaker 3: between what we offer. Like I was joking to my
Speaker 3: CEO who almost said that she was going to have
Speaker 3: a mental breakdown when I told her that we could
Speaker 3: start offering off for AI because realistically, there is no difference,
Speaker 3: like we offer other off like the it doesn't matter
Speaker 3: difference marketing marketing.
Speaker 4: Your one little rapper file that makes it interact nicely
Speaker 4: with a lot of the AI library.
Speaker 1: Maybe that it's.
Speaker 3: Actually not even that, it's literally just what shows up
Speaker 3: on the marketing page like that. That's really what's important,
Speaker 3: because you know, you can put whatever you want on
Speaker 3: the in the knowledge based on the documentation, and people
Speaker 3: will pick up and run with it, you know, focusing
Speaker 3: on the problem and the vocabulary that they're using to
Speaker 3: solve it, right, you know, if it's not your company,
Speaker 3: but like I say, one of your customers are like, oh,
Speaker 3: how do we keep the credential ownership separate? Or while
Speaker 3: using some sort of agent. You know, now we have
Speaker 3: to match on all those terms to hit SEO so
Speaker 3: that shows up in search results in one of the
Speaker 3: search providers or through one of the lamps six months
Speaker 3: from now. So it has to match on that and
Speaker 3: then also produce you know, relevant code with variable names
Speaker 3: that look like it's appropriate. So yeah, I mean, we
Speaker 3: don't have any any plans to throw up an MCB server,
Speaker 3: but if one of our customers was like, you know,
Speaker 3: we have this use case and we're willing to pay
Speaker 3: you some money for it, yeah, I mean done.
Speaker 2: Sort of the scaling issues you see with MCP services.
Speaker 1: Yeah, so we've seen a few. I think I think.
Speaker 4: One is is like managing I hate to say this again,
Speaker 4: but managing off and I think I think it's because
Speaker 4: companies just aren't really thinking about that at scale, how
Speaker 4: like groups in differentiation of who has access.
Speaker 1: So that's one of them.
Speaker 4: I think another one is that people are using AI
Speaker 4: to generate a lot of MCP servers right now, and
Speaker 4: I think that at scale it brings on again more
Speaker 4: security risks, but also scaling risks, right you're not necessarily
Speaker 4: hitting the end points very efficiently. We actually we see
Speaker 4: another big problem which is MCP servers and MCP in
Speaker 4: general love to do linear scans of APIs.
Speaker 1: So if you have an MCP server that.
Speaker 4: Lets you, you know, fetch tickets and then you can
Speaker 4: pass a page number and you say to your LLM like,
Speaker 4: get me all tickets that have Gill in the title,
Speaker 4: it is going to do a linear scan of that API,
Speaker 4: and that will will crash your MCP server. It's going
Speaker 4: to kill the agent. It's going to cost you a ton.
Speaker 4: So that's another one we've seen.
Speaker 3: I mean, because like, as an experienced engineer, it's like, oh,
Speaker 3: this is I'm actually paging through this for like ten minutes.
Speaker 3: What is going on is it's stuck, you know, something
Speaker 3: else going on. And you may look at your code
Speaker 3: and be like, oh, there's actually a lot of items here,
Speaker 3: or each one of these calls is like really expensive,
Speaker 3: or I'm getting throttled, and you'd go and investigate that.
Speaker 3: But if you're not paying attention and you don't even
Speaker 3: really understand what's going on with that MTP server or
Speaker 3: any product, and you get something automatically generated, it's not
Speaker 3: paying attention to that. It doesn't care. It doesn't care
Speaker 3: along it runs right.
Speaker 4: That's a good point, and it knows how to exponentially
Speaker 4: back off, so it will take its time and really
Speaker 4: pull everything.
Speaker 2: Yeah, I can see a scenario where this is like
Speaker 2: after rollout and people get used to it and it's
Speaker 2: fully adopted. There's like a layer of knowledge abstraction where
Speaker 2: someone troubleshooting it or interacting with it doesn't even know
Speaker 2: to go look at the API end points that it's
Speaker 2: calling to find out that you've been getting hit with
Speaker 2: overage charges for the last twelve hours because the service
Speaker 2: is just banging away on it.
Speaker 3: I think there's another another huge complexity there, like some
Speaker 3: of those routes may be paid and other ones may
Speaker 3: be free, or like instead of using the search endpoint,
Speaker 3: it's using some sort of native pat genation or you know,
Speaker 3: if you if you if the MCP server isn't built
Speaker 3: by the company who's running the API, they know what
Speaker 3: their internal complexity is and should be focusing on that,
Speaker 3: whereas someone else may not understand or really don't even care.
Speaker 3: You know where the limitations are for using that server,
Speaker 3: and like, if you come and talk to us, we'll say, oh, yeah,
Speaker 3: you know what the thing you're doing. You want to
Speaker 3: use endpoints A and B. This will be the fastest,
Speaker 3: the cheapest option for you, most cash option, et cetera.
Speaker 3: And if you're just dynamically generating something, it may look
Speaker 3: like different endpoints could be appropriate. And if you're not
Speaker 3: paying attention, that's what'll get used and that could be
Speaker 3: the worst scenario for both the caller and also uh
Speaker 3: the service provider in the end.
Speaker 4: Yeah, and ultimately that's why we pretty firmly believe that
Speaker 4: that you still need to think full sets of data
Speaker 4: for a lot of types of integration too. You know,
Speaker 4: if there's it's the lack of a search endpoint that
Speaker 4: causes that. And if you have no search endpoint and
Speaker 4: you you're building your business right, your product team doesn't
Speaker 4: want to hear no, we can't sink the full data
Speaker 4: is that they want to hear, like, here's how we're
Speaker 4: going to solve this problem. I mean, you have to
Speaker 4: do that, And so MCP becomes a little useless there.
Speaker 2: So with with this being a stateful service, is that
Speaker 2: a concept that exists of saying, hey, go grab this
Speaker 2: API data and if you need it again for anything else,
Speaker 2: this this payload is valid for the next six hours
Speaker 2: or for the next two days or whatever, and then
Speaker 2: it just cashes that and reuses that.
Speaker 4: Yeah, I mean, ultimately, your your tool implementation can do anything.
Speaker 4: And so you know, if you have a tool that's
Speaker 4: like you know, synk this data and then it cashes
Speaker 4: for six hours, it can under the hood be hitting
Speaker 4: some internal cash, whether that's like a memcash, REDDI or
Speaker 4: a database, and then it knows who it's who's talking
Speaker 4: to the server, so it knows who to look it
Speaker 4: up for.
Speaker 1: Yeah.
Speaker 3: I mean there's like a lot of different ways to
Speaker 3: handle cases, right. I think there's like two hard problems
Speaker 3: and computer science. So I mean you can, right, you
Speaker 3: can do read through cases, write through cashes. You know
Speaker 3: how you're managing it Basically, you're basically saying that the
Speaker 3: API as it's written isn't effective for the actions you
Speaker 3: want to take, and if one of those is like
Speaker 3: very bulk data related, you have no choice but to
Speaker 3: handle all of the interactions and then also get sinks
Speaker 3: back from the source, like constantly pulling it to get
Speaker 3: any updates there are. I imagine over time we're going
Speaker 3: to see primary providers of that data offer better strategies
Speaker 3: for interacting with them because third parties that spin up
Speaker 3: these MTP servers they're not benefiting anyone directly. I mean,
Speaker 3: it's the value is there clearly if the customers say, hey,
Speaker 3: you know, your API end points aren't giving us what
Speaker 3: we want and we need something better. So there's a
Speaker 3: drive for it. But I think over time, realizing what
Speaker 3: those traders are will have to be changed into whoever
Speaker 3: owns the data fundamentally.
Speaker 4: Yeah, the question is whether you know, especially among the enterprise,
Speaker 4: you're going to see companies wanting to release the MCP servers.
Speaker 4: I think that you know, there's the world's always gone
Speaker 4: back and forth on whether API should be fully public,
Speaker 4: what data should.
Speaker 1: Be exposed, and whatnot.
Speaker 4: And you know, one of the things we're seeing among
Speaker 4: enterprise is fhear around MCP the idea both of unintended
Speaker 4: actions being taken, but also of data extraction.
Speaker 3: Yeah. Well, I mean that's an interesting point because there's
Speaker 3: a I live in La la land, and here's my
Speaker 3: perspective of how the reality works, and this is how
Speaker 3: we make money and the mature, grown up approach of
Speaker 3: our users are actually doing this thing, and we should
Speaker 3: figure out how to encourage them to do the right
Speaker 3: thing so they don't accidentally do the wrong thing and
Speaker 3: the companies that realize that will be the ones that
Speaker 3: capture the value in the long term, and the ones
Speaker 3: that don't we'll just end up failing because people will
Speaker 3: stop using their services because they will no longer want
Speaker 3: to use the interface that's being provided to them.
Speaker 1: Yeah, I think.
Speaker 4: I think a notable example of that is Salesforce having
Speaker 4: a very open ecosystem and because of that, other platforms
Speaker 4: built on top of them. And now when you use
Speaker 4: Salesforce and you haven't integrated everywhere, you can't chur and
Speaker 4: that data is the core system of record for all
Speaker 4: the services your good market stack uses. But I'm not
Speaker 4: going to name names here, but there are a lot
Speaker 4: of enterprise players that are very locked down about their data,
Speaker 4: and actually mid market players as well, and somehow they've
Speaker 4: maintained a solid user base. I wouldn't say they are
Speaker 4: the fastest growing companies anymore, though.
Speaker 3: I hope this causes a turnaround here because historically the
Speaker 3: products that have the most data, which end up being
Speaker 3: things like CRMs and data platforms, have had the worst
Speaker 3: APIs and the ones with the most Yeah, I'm sorry
Speaker 3: I had to come out and say that, but we're all.
Speaker 2: Thinking it so yeah.
Speaker 3: Yeah, sorry to all our previous guests from like the
Speaker 3: last four or five weeks to all of it on
Speaker 3: the data side, just from experience here. But if they're
Speaker 3: all the ones with the worst APIs and now we
Speaker 3: all care about that data as fundamentally as we can
Speaker 3: to get at it, and those APIs don't exist, the
Speaker 3: ones that survive will be the companies that actually invest
Speaker 3: in better APIs for accessing their data.
Speaker 1: I agree, I completely agree.
Speaker 3: So I just put it on the blockchain, I think
Speaker 3: is what wells thinking.
Speaker 1: Absolutely very efficient.
Speaker 3: Yep, well it's public, you know, problem solved.
Speaker 2: Yeah, to share database, We're just sharing, just share damn it.
Speaker 2: So now this is scaled in complexity quite a bit.
Speaker 2: Just in the last thirty ish minutes we've been talking
Speaker 2: about it because we started saying, okay, you have this
Speaker 2: agent and it just makes it easier to talk to
Speaker 2: APIs for you. But now we're talking about you know,
Speaker 2: off issues and scaling and like security of the data.
Speaker 2: Like so for someone who's thinking, man, I saw this
Speaker 2: MCP term, I should go build one of these things,
Speaker 2: Like what's your recommendation for the top things they need
Speaker 2: to be thinking about.
Speaker 4: I mean, I think number one right now. It's really
Speaker 4: good marketing. It's the topic and so and so releasing one.
Speaker 1: It's out there.
Speaker 4: I think, I think there are things to consider, like
Speaker 4: your MCP servers only as good as the underlying tools
Speaker 4: or you know, in other terms, the underlying API that
Speaker 4: it's talking to. I think you need to think through
Speaker 4: real world use cases and you need to test it.
Speaker 1: And actually one of the things.
Speaker 4: We talked about earlier was how to evaluate this, and
Speaker 4: I think it's you know, it's similar to other AI
Speaker 4: evaluation methods where where you're feeding it sort of like
Speaker 4: mock prompts and data and you're using evaluators to decide like,
Speaker 4: is the output eighty percent of the time close enough
Speaker 4: to what I needed to be that sort of thing,
Speaker 4: is the right tool getting called based on certain prompts?
Speaker 4: So I think I think making sure that you build
Speaker 4: good tools, making sure they're well documented, and making sure
Speaker 4: that you actually test them is important.
Speaker 3: Yeah, it sounds like, you know, if I rephrase that,
Speaker 3: you've got to make sure that you understand what your
Speaker 3: users are actually asking for, you know, because there's like
Speaker 3: an infinite number of things that can be done with
Speaker 3: an API. So if you don't know what that is.
Speaker 3: You don't know what functionality to actually throw in your
Speaker 3: MCP server to begin with. You can't just like have
Speaker 3: it spun up and have just have it work. It
Speaker 3: needs to actually do something right.
Speaker 1: That's exactly right.
Speaker 4: And if you know your your customers are very likely
Speaker 4: to come in and say create an invoice. But whenever
Speaker 4: they do that, the way they word it is like
Speaker 4: create a I don't know, create a spend report. So whatever,
Speaker 4: you you know that you want to put that in
Speaker 4: the documentation for the MCP server when someone asks for
Speaker 4: creating a spend report, this is the tool to call.
Speaker 3: I think you want to like add a line item
Speaker 3: to the accounts payable list.
Speaker 1: You know, Yeah, there you go.
Speaker 3: That's that's what's important. Getting that language right, okay, and
Speaker 3: words are hard.
Speaker 1: Words are hard.
Speaker 3: I mean you could you can in your MCP server,
Speaker 3: receive the request, pass it to another l M to
Speaker 3: get it translated into you know what makes sense, and
Speaker 3: then actually execute. But I highly don't recommend that.
Speaker 1: Yeah, yeah, you know.
Speaker 3: It's going to multiply your your security issues by quite
Speaker 3: a large amount.
Speaker 1: That is so true.
Speaker 4: Yeah, we we definitely believe in that separate we give
Speaker 4: you the tools.
Speaker 1: You do what you want to do with it.
Speaker 2: Here's the knife, cut off whatever you'd like. We're not
Speaker 2: responsible for the medical bill.
Speaker 1: Yeah.
Speaker 2: Have you seen scenarios of MCP services instead of talking
Speaker 2: to APIs or talking to other MCP services.
Speaker 1: Oh that's interesting.
Speaker 4: So I mean I guess realistically you could have an
Speaker 4: MCP service ask another service for tools, or call other
Speaker 4: call other tools. I'm not sure there's a great use case.
Speaker 4: Maybe I would have to think three use cases there.
Speaker 4: So I haven't seen any specific instances.
Speaker 1: You know.
Speaker 4: What I've really seen is is MCP servers. You know,
Speaker 4: they can return static data, they can query databases and
Speaker 4: like query databases directly or call APIs. So I definitely
Speaker 4: have seen where you have tools that are formulating SQL
Speaker 4: queries and so you could you know, like have an
Speaker 4: agent that you know, equeries a database using English language
Speaker 4: and that English language causes another you know tool, call
Speaker 4: to another MCP server that can translate to SQL for example.
Speaker 4: And I guess that's one one example, but I think
Speaker 4: you'll probably see more like a to a level communications
Speaker 4: as opposed to like agent to MCP to MCP.
Speaker 3: Yeah, I mean, I guess there would have to be fundamentally.
Speaker 3: There could be a case, right, you call an API
Speaker 3: today and it does something with an l M, and
Speaker 3: in the future you call an API and that can
Speaker 3: call a different API and instead of doing that, it
Speaker 3: could use natural language there, although natural language is terrible.
Speaker 3: Like if you know how to if one one software
Speaker 3: developer rites in a code to call a different API,
Speaker 3: like use the first class API notions that are available there,
Speaker 3: you know you always want that code and that that
Speaker 3: would be software development there. And the other thing is
Speaker 3: that like the cost, like you want to pass that
Speaker 3: back to the caller as fast as possible and push
Speaker 3: them with the costs there. Otherwise you're running two agents
Speaker 3: at the same time, so you know whatever determinations need
Speaker 3: to be made. Plus there's also this like i'm gonna
Speaker 3: say security again, like delegation, like who owns that recquid.
Speaker 3: You probably don't want to build your service in a
Speaker 3: way which allows users to interact with a third party
Speaker 3: solution because that means they have to give you the
Speaker 3: credentials to do that, and then you're managing your customer's
Speaker 3: credentials to other third party systems. And if you're doing that,
Speaker 3: maybe you should like, talk to Gil and see if
Speaker 3: this is the use case that there, you know, because
Speaker 3: that really sounds like merge. Yeah, so you know, pass
Speaker 3: the data back to the caller and let them deal
Speaker 3: with the complexity and the cost of calling out to
Speaker 3: that second system.
Speaker 4: I thought you were about to say, if you're doing that,
Speaker 4: you're wrong, and I was like, well, that's our whole business.
Speaker 1: So I.
Speaker 3: Try very hard not to say things in episode that
Speaker 3: contradict what the guest is saying.
Speaker 1: So I'll keep an eye on your Twitter later.
Speaker 3: Oh well, I deleted that a long time ago.
Speaker 1: All right, I'm safe then.
Speaker 2: Yeah. Yeah, we have an unwritten rule not to insult
Speaker 2: our guests till after the recording's over.
Speaker 1: Man, all right, mutual to two Way Street them, I.
Speaker 3: Like, I like you brought up Yeah. I mean, you
Speaker 3: have plenty of opportunities here, and I'm sure most of
Speaker 3: the audience are just waiting for those punches. Gil. So
Speaker 3: you know, if if myself or Will is there for you, you know,
Speaker 3: feel free to you know, come at us with with
Speaker 3: full force. No no, uh, no worries. You did mention
Speaker 3: a to Ah, and I do want to ask about
Speaker 3: this because you meant agent to agent, I think, and
Speaker 3: not A to A as the protocol that GDP released
Speaker 3: to do MCP right.
Speaker 4: So well, so the the the g CP A to
Speaker 4: A is a true agent to agent that is sort
Speaker 4: of compatible with MCP.
Speaker 1: It works well, and it's it's a good concept.
Speaker 4: It's just one one of the many protocols that are
Speaker 4: coming out for agent agent communications right now.
Speaker 1: It's just newer.
Speaker 4: It's a it's a newer concept entirely, but I think
Speaker 4: it's similar to MCP and that it's solving a problem
Speaker 4: that everyone was just solving in a million different ways.
Speaker 1: Right with MCP, people new agents.
Speaker 4: Wanted to have remote tool calling as as an option
Speaker 4: and CP was a protocol that form to solve that,
Speaker 4: and a day is similar. It's you know, agents need
Speaker 4: to talk to each other. How do we have just
Speaker 4: like what's the most simple way to make that happen?
Speaker 3: Well, if you're if you're talking about that, I have
Speaker 3: to ask, have you seen the one where someone devised
Speaker 3: the idea of oh it's so expensive to send request
Speaker 3: using Bluetooth or USB or Wi Fi. Let's just send
Speaker 3: an audio signal over the air from one device to
Speaker 3: another one and have like, you know, your phone will
Speaker 3: make a sound and your computer will pick it up
Speaker 3: on its you know, speaker or microphone and listen to it.
Speaker 1: Yeah.
Speaker 4: I think that's how like people in the old days
Speaker 4: you do things on iPhone when when Apple hadn't exposed
Speaker 4: all of the SDKs or the APIs yet.
Speaker 3: I like how you put that, because yes, I mean,
Speaker 3: this was how you did it in the old days
Speaker 3: before we invented technology that did it correctly, and now'll
Speaker 3: people like, well, I have an agent over here and
Speaker 3: an agent over here, how do I get them to communicate?
Speaker 2: There are a lot like a fax.
Speaker 1: I was just like.
Speaker 3: Dial up go. Well, I like, there it goes, you know,
Speaker 3: it just DSL you know, making those things over broadband Yep.
Speaker 4: The stripe reader that was plugged into the headphone slot,
Speaker 4: it did the same thing, converted to a microphone signal
Speaker 4: from your credit card number.
Speaker 1: Yeah, I think so.
Speaker 4: Yeah, don't quote me on that, but I'm like nearly
Speaker 4: positive that that's how it worked.
Speaker 3: I have this seeking suspicion that most of the audience
Speaker 3: will have no idea what you're talking about anyway, So
Speaker 3: don't worry about it.
Speaker 1: I mean, w am I old now? Is that the Yeah?
Speaker 3: I think we're all technically old, so yeah, yeah, it's fair.
Speaker 2: That is true. Though, Like I've been doing this for
Speaker 2: three decades, and I had to go around and ask
Speaker 2: if I was the oldest person at the company, because
Speaker 2: I was like pretty confident that I was, and it
Speaker 2: turns out I wasn't. There's one guy who's a couple
Speaker 2: of years older than me, but it's close enough in
Speaker 2: terms of the ages of the rest of the people
Speaker 2: in the company where we're practically the same age.
Speaker 4: Yeah, yeah, we have a we have a pretty young
Speaker 4: company too, but we've as we've grown, we've gotten some
Speaker 4: more maturity, and honestly, it's it's much better. It's much
Speaker 4: better to have just a more mature company.
Speaker 2: I think that's an interesting dynamic to balance, you know,
Speaker 2: because you have like the a lot of the enthusiasm
Speaker 2: and the excitement that comes from people who are earlier
Speaker 2: in their career, but there's also like a really nice
Speaker 2: balance when you have people who are who are senior
Speaker 2: in their career to provide like perspective on those ideas,
Speaker 2: you know, and sometimes you get that dynamic where it
Speaker 2: feels like the young people are just trying to do
Speaker 2: something and the old people are just trying to say no.
Speaker 2: But if you get that really great combination there, you
Speaker 2: can get this dynamic where the young people are coming
Speaker 2: up with new ideas and the older people can say like, yeah,
Speaker 2: we used to do that in the nineties and here's
Speaker 2: why we changed, and then you kind of iterate on
Speaker 2: that and evolve into something completely different.
Speaker 3: I think you should hire him because of all his
Speaker 3: great ideas.
Speaker 4: I mean, I completely agree, though it's you know, they've
Speaker 4: really it's sort of a balance that's important.
Speaker 1: But also bringing just years of.
Speaker 4: Expertise on you know, I'm thinking go to market in
Speaker 4: this case, but you know you have something, you can
Speaker 4: sell it at the beginning by years of experience, just
Speaker 4: help you sell something, like, really bring it to market,
Speaker 4: really scale it. So I think about like kind of
Speaker 4: you know, earlier talent is helping you get something off
Speaker 4: the ground, and then late later career talent is really
Speaker 4: helping you push it and scale it.
Speaker 3: I feel like we're losing I mean, even with years
Speaker 3: of experience, I feel like we're losing actually the original
Speaker 3: concept of later year talent because I think it came
Speaker 3: from having managed systems that were alive for a very
Speaker 3: long time and understanding the nuances. They're like, oh, yeah,
Speaker 3: we've had a you know, in our data center, we've
Speaker 3: had a mainframe there for fifty years that's been running
Speaker 3: you know, whatever it was running from. I assume IBM
Speaker 3: and you know, going and going, and these are the
Speaker 3: weird things that we saw. And now it's fifty years. Like, no,
Speaker 3: that's like twenty five different people were integrating with that, right, Like,
Speaker 3: it's not one person who had seen everything there was
Speaker 3: to see with that one piece of technology, that one
Speaker 3: service or one product, And I don't know if that's
Speaker 3: ever coming back, which means I feel like we're losing
Speaker 3: as a society.
Speaker 1: This.
Speaker 3: It's a critically useful piece of information as far as
Speaker 3: how we actually deal with these systems or those experiences
Speaker 3: to be able to guide us in the right direction
Speaker 3: going forward.
Speaker 4: Yeah, but I guess the question is is that important too,
Speaker 4: because you now have this sort of abstraction of knowledge
Speaker 4: where you have an AWS or a GCP managed service
Speaker 4: that you know.
Speaker 1: I mean, I think it depends on the example.
Speaker 4: But you keep getting, you keep abstracting above and then
Speaker 4: people can focus on like a different level of skill.
Speaker 3: I think it's something different like if we see that
Speaker 3: the majority of people in the world are spending their
Speaker 3: effort and how they're focusing on problems that become more
Speaker 3: and more short term than we are losing those situations
Speaker 3: where people have experience working with long term functionality. And
Speaker 3: I think this is coming to the cloud providers and
Speaker 3: hyperscalers out there unfortunately, and we'll see that if everyone
Speaker 3: outside of them doesn't have long term experience and the
Speaker 3: only people that for those companies to hire are people
Speaker 3: without long term experience, and what the market cares about.
Speaker 3: If I see lots of little data centers and cloud
Speaker 3: providers pop up to say, oh, we're better than AWS
Speaker 3: and GCP and whomever because we do this thing, and
Speaker 3: it's like, well, you're better because you wrote a hack
Speaker 3: that got it done in six months compared to a
Speaker 3: company that's been around and has that particular service for
Speaker 3: twenty years. And it's not as good, but it still
Speaker 3: maybe solves your particular use case. And I think this
Speaker 3: is similar to hard hardened API versus MTP server written
Speaker 3: on top of it. You know, we wrote something quick
Speaker 3: and dirty to get it done. It's a hack and
Speaker 3: it now it becomes ingrained in what we're utilizing and
Speaker 3: so there's a lot of risk associated with it. And
Speaker 3: I think this is a this is a failure of
Speaker 3: the human race to you know, be so short and
Speaker 3: narrow like narrow sighted there, like you really focus on
Speaker 3: the short term. Having a long term focus is very
Speaker 3: difficult for people.
Speaker 2: I think true story.
Speaker 3: I like this will be my I think this will
Speaker 3: be one of my future picks. But there's a great
Speaker 3: science fiction television show called Well, actually written after a
Speaker 3: book called The Expanse, and the one of the characters Abursala,
Speaker 3: who's I don't need to go into it, she has
Speaker 3: this really great quote that the failure of humanity is
Speaker 3: too little, too late, And I think it really does
Speaker 3: go to the fact that humans do really wait too
Speaker 3: long to see a problem and attempt to fix it,
Speaker 3: even even if without even putting in enough effort to
Speaker 3: actually solve it. So you know, I'm with her. I'm
Speaker 3: very pessimistic on the on the topic. But yeah, I just.
Speaker 4: Think of the word AI and I'm like, the world
Speaker 4: as we know it is over and I just can't
Speaker 4: think about the problems.
Speaker 1: But I know I'm with you.
Speaker 3: It's well, I think you know there's something there and
Speaker 3: I am always the first to bash anything related to
Speaker 3: AI because it's not AI as I understand it. It's
Speaker 3: these probabilistic engines that are just returning a statistical result
Speaker 3: that has no intelligence behind it whatsoever. I mean, there
Speaker 3: was intelligence to build the system, but actually contained in
Speaker 3: the computational matrix of the anyway. Yeah, so lack of
Speaker 3: lack of intelligence.
Speaker 1: That's fine. I think most human brains are similar.
Speaker 3: So yeah, well there's a there's a huge debate there.
Speaker 3: I mean, if LM is what we created in humanity
Speaker 3: after downloading all of the information and compiling it, then
Speaker 3: it should be an average. So I'd say that it
Speaker 3: must be that lms are better than fifty percent of
Speaker 3: humanity of the people who contributed to them, and worse
Speaker 3: than the other fifty percent. And if you're okay with
Speaker 3: the average of an output, the average code that's being
Speaker 3: generated or workflow is being executed, then an LM may
Speaker 3: be an improvement there an average amount of knowledge.
Speaker 4: Yeah, but it is also it is also all the
Speaker 4: knowledge that everyone knew throughout their entire lifetimes versus not
Speaker 4: all useful moment in time.
Speaker 3: Yeah, there's things there, right, I'm pretty sure it was like,
Speaker 3: and I'm going to get this wrong, like Aristotle believed.
Speaker 3: I mean, people recognize the name Aristotle believe that the
Speaker 3: Sun went around the Earth, So you know, that's sort
Speaker 3: of an interesting thing. So, yes, there's a lot of
Speaker 3: history of information, and uh, there's a lot that's wrong.
Speaker 2: Yes, sure, yes, we need to feed LLM with the
Speaker 2: the redlined version of our human collective consciousness.
Speaker 3: Well that's that, you know. And the problem is that
Speaker 3: the information that's being fed in to train lms today
Speaker 3: isn't being sanitized as much as data engineering was doing
Speaker 3: in the past. They're, you know, they're realizing that there's
Speaker 3: too much information to do this, so they're coming up
Speaker 3: with tricks and strategies to try to filter stuff out.
Speaker 3: But often you're picking you're filtering the sources and the
Speaker 3: attributes and the functionality rather than the accuracy, which is very,
Speaker 3: very difficult. And now, for sure, if you find something wrong,
Speaker 3: you can go back to the training data and start
Speaker 3: eliminating things, get it to solve certain problems. But I mean,
Speaker 3: mathematics or equation solving today is something because of how
Speaker 3: the lms are designed, just is almost never getting better.
Speaker 4: For instance, yeah, the cool thing there is is you know,
Speaker 4: if it can successfully call a calculator tool via MCP,
Speaker 4: then there you go, or even a local tool, then
Speaker 4: at least they can formulate that and let let a
Speaker 4: calculator statically.
Speaker 3: Do it MCP for Wolfram Alpha, that's what I'm hearing.
Speaker 4: I'm sure someone oh man, that was the most advanced
Speaker 4: a they had when I was in college.
Speaker 2: So yeah, right on, this feels like a good point
Speaker 2: to move into picks. What do you think?
Speaker 3: I think we should definitely do it, all right, Yeah,
Speaker 3: so I have something non technical this week. I'm just
Speaker 3: going to jump in and save mine because I know,
Speaker 3: you know, if I don't will it's just gonna be
Speaker 3: like Warren, you know what time it is time for
Speaker 3: my pick, because I always go first. So my pick
Speaker 3: is the book A Slash television show The Magicians by
Speaker 3: Lev Grossman. I'm I don't know something something science fiction, fantasy.
Speaker 3: There is a question is fantasy different from science fiction?
Speaker 3: And I think that The Magicians gets into that quite
Speaker 3: a little bit that it's hard to distinguish, which is
Speaker 3: which I really like the book and the show. They're
Speaker 3: they're good in different ways. Unfortunately, Like it's not like
Speaker 3: they well recreated. It's sort of like a different storyline
Speaker 3: and different stuff happen. Characters that are good in the
Speaker 3: in the book are bad in the show, and vice versa.
Speaker 3: So if you've only read or watched one, I highly
Speaker 3: recommend the other.
Speaker 2: Right on, Gil, you gave us a sneak preview of
Speaker 2: your pick before we started recording, so I'm excited what
Speaker 2: you got.
Speaker 1: Yeah.
Speaker 4: So I'm a big watch fan, and a topic that
Speaker 4: I've been rereading about recently that I'm really into is
Speaker 4: the historical notion it's called of constant escapement. It's a
Speaker 4: problem in watchmaking where and clockmaking and all formsquare and sorry,
Speaker 4: And the reason I bring this up is because with
Speaker 4: AI technology just changing so fast, what I love about
Speaker 4: watches is it's technology. There's no electronics and nothing really
Speaker 4: changes except maybe material science gets better. And so with
Speaker 4: the constant escaements this idea of you know, in watches
Speaker 4: or in clocks, you wind something up. When you have
Speaker 4: a wound up spring, as it unwinds, the power that
Speaker 4: it gives off decreases. Right, It's more powerful when it's
Speaker 4: really tightly wound. And so if you picture what that
Speaker 4: does on a clock, you're gonna have really fast movement
Speaker 4: of the hands and then it'll start to slow down
Speaker 4: and that doesn't work. And so the huge problem always
Speaker 4: has been constant escapement. How do you get constant forced
Speaker 4: to be emitted from that that spring? And that's why
Speaker 4: you see this idea of something you know balance wee
Speaker 4: all going back and forth. It helps slowly release tension
Speaker 4: from that spring. Or on a clock you have a
Speaker 4: pendulum that swings back and forth. You need to have
Speaker 4: ways to very like let gravity help you release that.
Speaker 4: So I think it's a super interesting topic if you're
Speaker 4: into attack and you want to read about something that's
Speaker 4: just not changing so fast. But it's just a cool
Speaker 4: historical thing. Look up constant escapement and read about all
Speaker 4: the different ways it's been solved over time.
Speaker 3: It sounds like a conservation of angular momentum problem.
Speaker 1: Yes, it's a similar idea.
Speaker 3: I don't if you tell I I took a math
Speaker 3: in physics as my U that was who I was
Speaker 3: before I went into the philosophy of software engineering.
Speaker 1: It's it's such an interesting problem. I really love that.
Speaker 4: Again, like it's it's it's not to say that AI
Speaker 4: and technology isn't great but it's just a fun different
Speaker 4: way of thinking about things.
Speaker 3: Is there like a particular watch or a clock type
Speaker 3: or something that you much prefer over others? Like do
Speaker 3: you have like a giant grandfather clock sitting in your home?
Speaker 4: I so, I actually really like this clock called it's
Speaker 4: JLC or La Colts. It's a it's called the atmost clock,
Speaker 4: and you've probably seen them around, but it's sits in
Speaker 4: your room, and it also can run forever no electricity,
Speaker 4: and it's not on your wrist, so it's not.
Speaker 1: Wound or anything.
Speaker 4: It has a big bulb in it that's filled with
Speaker 4: a gas, and even one degree of temperature variation in
Speaker 4: the room makes it expand and then that is is
Speaker 4: somehow winding up a mechanism when it expands and contracts.
Speaker 1: So I think that was really cool.
Speaker 2: Oh wow, that's pretty wild. That's super cool.
Speaker 3: I always get concerned when there's no like battery electricity,
Speaker 3: that if it's not if it's not taking energy, it's
Speaker 3: you know, giving off radiation, And.
Speaker 4: A lot of watches do give off radiation from the
Speaker 4: the tritium tubes in the you know, in the the loom.
Speaker 3: So interesting besides being like low in the dark or
Speaker 3: is it different purpose?
Speaker 1: Yeah, no, just for going the dark.
Speaker 4: You don't you know a lot of these days you
Speaker 4: don't see a lot of tridium tubes, but you still
Speaker 4: see them. They're not I think it's not to a
Speaker 4: level that's considered dangerous, like a lot of this lead
Speaker 4: paint that you see on like old plates and stuff,
Speaker 4: but it's still you know, I I personally wouldn't wear one.
Speaker 2: Yeah, it's the It's an alpha wave emitter, and alpha
Speaker 2: wave radiation can be stopped by the outer dead layers
Speaker 2: of skin, so its ability to impact you or do
Speaker 2: anything is super super low risk.
Speaker 3: Yeah, let's talk about radiation. Yeah, I mean alpha beta
Speaker 3: is fine, but you know usually when we talk about
Speaker 3: bad radiation, it's it's gamma or something stronger, which is
Speaker 3: you know, multiple particle size, not just a single hydrogen
Speaker 3: atom or electron.
Speaker 1: Yeah, so no nuclear reactor is on your risk.
Speaker 3: Well, I'm worried about wearing a piece of technology that
Speaker 3: has five g antenna in it. So you know, that's
Speaker 3: that's my own I would have to say conspiracy theory,
Speaker 3: but that that is my own personal fear.
Speaker 4: I mean, I I get that, like we don't know,
Speaker 4: so why take the risk. I mean, I know a
Speaker 4: lot of people like my sister and her husband, they
Speaker 4: put their phones on or on on airplane mode next
Speaker 4: to their beds every night, or they keep their phone
Speaker 4: across the room.
Speaker 3: I think outside like I think it's actually the heat
Speaker 3: is worse than the radio. Yeah, or in your pocket.
Speaker 3: I think there's a bunch of research done so like
Speaker 3: keeping it outside your b it is for sure better there. Well,
Speaker 3: you seem like you know about radiation and watch as.
Speaker 1: A little bit.
Speaker 2: You know, I was a former nuclear engineer in the Navy,
Speaker 2: so I studied a bit about radiation.
Speaker 3: What's his what's his favorite kind of reactor? He's like
Speaker 3: the authorium you yellow cake, uranium two fifty eight like water, right,
Speaker 3: it's it's got to be like that was one of
Speaker 3: the interesting things because when I went through nuclear power school,
Speaker 3: it was just after the Chernobyl incident and and so
Speaker 3: like the US was parading around the fact that we
Speaker 3: use all water based coolant or water cooled reactors. And
Speaker 3: the interesting thing about that is as as the water
Speaker 3: gets heated up, the density and this is we're going
Speaker 3: back like over, We're going back to the late eighties.
Speaker 3: For me, to remember this sum likely going to botch
Speaker 3: most of these facts. But as the water heated up,
Speaker 3: the atoms got closer together, so even though the radioactivity
Speaker 3: of the nuclear reactor was increasing, the increased density of
Speaker 3: the molecules of water effectively shunted that increase in radiation.
Speaker 3: So it was almost impossible for a water cooled reactor
Speaker 3: to overheat the way that Chernobyl did because Chernobyl used
Speaker 3: liquid sodium as they're coolant. And then Three Mile Island
Speaker 3: and Fukushima.
Speaker 2: Yeah, and Three Mile Island was great because they got
Speaker 2: the first alert telling that there was a problem, assumed
Speaker 2: that it was a faulty sensor, and then they got
Speaker 2: the second alert, which was downstream from that one, and
Speaker 2: they were like, damn, we got two sensors that failed today.
Speaker 2: And then it finally started spewing out into the river
Speaker 2: and they're.
Speaker 3: Like, oh, oh, oh.
Speaker 2: Shit, we're going to fill out some sleeper work on
Speaker 2: this one.
Speaker 4: Oh man, much worse than software, you know, ignoring an
Speaker 4: alert that pops up, right.
Speaker 3: You just got to put the MCP server in front
Speaker 3: of the nuclear reactor and problem right, you.
Speaker 1: Know, solves everything.
Speaker 3: I'm surprised. I also I also did Uh, I didn't
Speaker 3: go as far as you did, well, but I definitely
Speaker 3: got the book, and I'm pretty sure that in my
Speaker 3: nuclear physics book there was no mention of MCP servers
Speaker 3: anywhere in there, and it's clearly an oversight, clearly an oversite.
Speaker 3: So uh, what's your pick?
Speaker 2: So my pick this is a repeat pick for me,
Speaker 2: because I'm still pissed at you over this warn. I'm
Speaker 2: working my way through the Dungeon Crawler Carl series because
Speaker 2: every book is so great, and I've pieced together at
Speaker 2: this point that there's I think there's seven books in
Speaker 2: this series right.
Speaker 1: Starting.
Speaker 3: I don't know why you're mad at me because it
Speaker 3: was Matt Lee that brought up a dungeon collar pull
Speaker 3: and I haven't read it yet, so you can be
Speaker 3: mad at me all you want, but I don't know
Speaker 3: what I don't know.
Speaker 2: Then I flipped that conversation in my head because I
Speaker 2: remember it as you bringing it up. But okay, I
Speaker 2: haven't read it.
Speaker 3: It's now on my list, and I you know, it's
Speaker 3: always great when there's like multiple books in that series,
Speaker 3: so you know, every single time you bring this up,
Speaker 3: I'm like, okay, a good reminder that this is going
Speaker 3: to have to be the next thing that I read.
Speaker 2: The disappointing thing is I'm five books into it now,
Speaker 2: and there's seven books in a series. But I'm starting
Speaker 2: to piece together the picture that the story's not going
Speaker 2: to be complete by the time I finished book seven,
Speaker 2: and then I'm going to be stuck waiting for him
Speaker 2: to write the rest of the damn books so that
Speaker 2: I get closure on this whole story.
Speaker 3: Aren't you taking salts in the fact the you'll propaly
Speaker 3: You know, given given your years of experience, you may
Speaker 3: forget what happened and then go back and reread the
Speaker 3: book and you know, relived that greatness all the verga
Speaker 3: when the next one comes out.
Speaker 2: Late career talent, yeah yeah, or just be dead by
Speaker 2: the time it happens and it's not my problem anymore
Speaker 2: either way. W's aw cool, all right, Gil, Thank you
Speaker 2: so much, man. This has been super insightful. I appreciate
Speaker 2: your insights, and you're taking the time to join us today.
Speaker 1: Awesome. Thank you so much for having me really enjoyed
Speaker 1: the conversation. This is great.
Speaker 2: Yeah, Warren, thank you as always for joining me here
Speaker 2: and carrying the conversation whenever I space Out and all
Speaker 2: our listeners. Thank you guys for listening. Be sure and
Speaker 2: hit us up if there's anything you want to see.
Speaker 2: Elaborate on comments, thoughts, feedbacks, smart ass jabs.
Speaker 1: It's all good.
Speaker 2: Bring it on and we'll see everyone next week.