A CTO's Honest Read on the Year AI Surpasses Human Intelligence | Gil Feig, CTO @ Merge

How much time do we software engineers have?

It's a better coder than most engineers I know. It does make some mistakes here and there. It's not perfect at everything, but at this point I've seen such an inflection point in the growth of sort of intelligence of these agents that I'm not here to say it's not gonna happen anymore. So I think the answer is like the gap is closing because you won't need software engineers.

Is that your doomsday prediction for software engineers?

Yes, absolutely. So I think though another way to say this is imagine you had the smartest possible person on the planet, right? And you go up to them and you say, which of my customers were upset last year, right? The question is, does it matter how smart they are? It's also a sense of knowledge. It's also, do they have the data to go through to actually decide? Once you have too many of those and you're passing in too much text, the agent's performance starts degrading massively. The equivalent would be you go, you open your laptop, you put in your password, you go up to someone random on the street and you're like, here you go, take this and feel free to do what you want. They can always go rogue. And going rogue when someone has unlocked access to your computer, that could mean going to a browser, going to a website that you have your password saved on, logging in. So permissions are really difficult. When you sync the full dataset from a third party, you need to make sure that employee A, who just joined the company as a new grad, is not able to see the board deck from your last board meeting, right? So what we do is we rebuild the permission sync twice. So we sync all of it in one engine. We have another engine that was built by someone who did not see the original codebase and also syncs those permissions. I always think of, not to bring this up, but I always think of that ship that hit that bridge in Baltimore and how for 10 minutes you could see it was going to hit the bridge. Everyone knows like this is going to hit, but there is nothing you can do. This thing is just going, going, going.

Today I have Gil Feig, co-founder and CTO of Merge.dev, and they're the company that helps you integrate with everything you need to build reliable AI agents.

Thanks so much for having me. Looking forward to it.

For people who don't know about what Merge does, can you explain what it does? Let's say at 3 levels. Let's go with an elementary schooler, a developer who's building AI agents. And the last one, a C-suite at a company.

Yes, absolutely. What Merge does, I guess for the elementary schooler, what Merge does is it helps businesses exchange data. So basically whenever you're using a piece of software on the internet and you see you can go in there and you can see data from other platforms you use, or you can take a certain action and you see that same action happen in other platforms you use, Merge helps make that possible because it's It's not trivial to set that all up.

I think the elementary schoolers are getting smarter and smarter. They'll be able to understand that.

Okay. And then I guess for your more sophisticated audience here, because I'm assuming not a lot of, not a ton of elementary schoolers are listening to this. We maybe, we make it incredibly easy for companies to add hundreds of integrations to their products. So we have 2 different products here. One is our unified APIs. So those are meant for synced data. If you want to sync across a copy of your customer's data and build something like an enterprise search experience where AI can search across all that data, provide really valuable insights on it, you integrate once with our unified API where we normalize to a single format, and then you can integrate with all of your customers' third-party systems. And then we offer the same thing for live connections. So that would be MCP style or live lookups where you want your agent to talk to a bunch of platforms. Not from a synced dataset, but actually make those live API calls. We power both of those experiences. Generally, our customers use one or both of those to build really valuable AI flows that are context-rich and can actually take actions versus just being a standalone tool.

What about C-suite? Would you add something else?

Like, yeah, I think the big thing there is when your customers now are coming in to use your products, they expect it to integrate with all the other tools they use. And especially for agentic products, they expect it to be context-rich. They expect it to give good, reliable answers that are rooted in knowledge of the person speaking with that agent. And to build those best products, to be able to close deals with customers who insist that you have the integrations with the platforms that they use, you need something like Merge to have those integrations be incredibly reliable, secure, and performant from day one.

So it sounds like it's something that you can tailor to Yeah, that's exactly right.

And how Merge works is we do have some customers who use us for internal, for their own integrations, but that's much less common than the vast majority of our customers who use Merge to offer integrations to their customers. We're an embeddable product. So essentially, yeah, we get built into a product to let that product integrate with customers.

Their customers. I learned that you started a company in 2020, so it's been 5 years and this is the 6 years.

Yeah.

At that time, it was mostly COVID. What did you see then that made you feel like you had to do something?

Yeah. So my co-founder and I were both seeing this problem at our previous startups. So Shensi, my co-founder, was working in cybersecurity and they had to integrate with a lot of different ticketing systems. So things like Jira, Asana, Trello, but then they also got asked for QRadar and Splunk and all these other ITSMs and just so many platforms. And at my company, we were recruiting tech and we had to integrate with applicant tracking systems. So Greenhouse, Lever, Workday. And from both of our ends, we were realizing we are building integrations with very different platforms and we are very different verticalized solutions, but we have the same problem, which is that B2B companies need to integrate with all the competitive products in a vertical because you don't know which one your customers might be using. And obviously back then, this was created in the sense of providing rich experiences in SaaS products, which is still a heavy use case for Merge. Don't get me wrong. It's still one of the widest, but since then, the The idea of context really got popular. AI became much more broadly used, GenAI. And so now we are the context layer. We are the context provider for dozens of Fortune 500s out there. It's not a problem that we thought we would be solving, but one that we very fortunately landed on as the world changed.

I really like your new framing. So instead of saying you're a connector, you're actually the context provider. Yeah.

Right.

And you have 2 products, the Merge Unified and the Agent Handler. And both essentially are calling APIs to the same third-party systems, right? Why would I want to use Merge, like this intermediary API?

Yeah. So I think, so one of the main reasons that people want to use Merge, we have our 2 products, but starting with Unified, why do people want to use a synced data layer? So in general, why do you want to sync? It's because you get much better results from your enterprise search. There's a reason that companies like like Glean and OpenAI's Enterprise Search are so good. And it's because they're syncing across a copy of that data. And to give you an example of why that's important, let's say that you ask the LLM, which of my customers were upset last year? Okay. The only way to really know that answer is to go, assuming you're using ticketing data to back it up.

Right.

The only way to really know that answer is to go through every ticket, right? You can't avoid, if you avoid going through even one ticket, then you end up in a situation where That could have been one complaint from a customer and you now miss them as one of your customers. So you have to go through all of them. But there's no way that you can fetch all of that in real time using MCP, right? Even if your agent had unlimited context and you could pass in every piece of data ever entered in your ticketing system, it still wouldn't work because the API itself doesn't make it easy to get all that data out as needed. So you would be sitting there waiting for your agent to get all the data out of the ticketing system. Instead, people use Agent Handler to pre— or sorry, use Merge Unified to pre-retrieve all that data and pre-structure it so they can actually query it semantically. They can actually ask a database which customers were upset last year, and there's a way to actually look that up in real time. So synced integrations are essential. And the reason people don't want to build them is because they're incredibly difficult to build. It's not about that, that setting up the initial code to fetch from an API. That's never been a struggle. That's always been relatively easy if you've done it. The real challenge lies in building reliable, robust syncs that work across hundreds or thousands of customers that all have different complex setups in these enterprise systems. You go, you fetch data for one customer, and then you go and you fetch it for a different customer. And that data, it's not just different data. The actual structure of that data is completely different. They have custom fields set up. They have a lot of custom data set up. They have scopes and certain things don't come back from the API. There's just a lot of complexity that's not documented anywhere. And so even AI agents are not great at building these. And we as humans sit there and debate what the best way to build something in the room. When we as humans are debating it, AI's not great at it yet.

Let's say I'm building an AI agent for my sales team. This is common. Let's say I need access to Salesforce and Jira tickets, Google Drive, and maybe my HR system. So I have a naive approach. Let's say like I just give the agent API keys to each one of the systems, and then when it gets a question from the user, the sales team, it calls the relevant APIs. Pulls back the data and stuff all those data into the context window and then let LLM to answer that question. So this is the natural thought that this, at least at a high level, this has to be the case, right? But something is gonna break based on what you just told me.

So this is a great use case. And like I, this is a, it's a common use case, but yeah, where something breaks is we all know and we've all seen, like it's a common trend in the industry. Context is the data that you're passing into the agent. So that could be that your prompts, what you're actually asking of it, and it could be any of the tools you're saying you're making available. You're saying, which candidates have applied to my job? And then by connecting Greenhouse MCP, you're actually then also saying, here are the different tools that you have in Greenhouse to communicate with. Once you have too many of those and you're passing in too much text, the agent's performance starts degrading massively. If you look this up, you can see charts about agent performance and accuracy just plummeting. And so the problem is when you have too many tools and too many things connected to an agent, and then too much data that comes back from those tools, you start confusing the agent. It gets to a point where performance plummets and it becomes unusable. So it's definitely a great use case for a lot of very simple things. But that's why I would guess a lot of people who are using like a basic, I'm not going to name names, but there's certain platforms that are purely MCP. That's why they're not thought of as like the best tool use type of platforms. They're not thought of as the ones that really solve your major problem for your organization. And go and repeatedly take action in third parties. You just don't see it yet, but I think we're getting there. And that's what we've worked really hard on with our agent handler product is how can we provide thousands of live tools to an agent without overloading the context? So maybe we slow drip. We say, "Hey agent, you want to you want to know what tools or what actions you can take in third parties?" First, tell me what you're trying to do, and then I'm going to return to you a scoped down or filtered list of actions I think are relevant to that. So there are ways to build around this. It doesn't solve all of the problems, but.

It definitely helps when every user are asking different questions. And then the most efficient way is to scope the context down towards that user's question. And that's the hard part when you scale with, I don't know, 20 or more systems that you're hooking up and large amounts of data across a long period of time and thousands of tools that you're using, then that's going to crash the context window and it's going to be a needle in a haystack.

Yeah.

Right.

Yeah, that's exactly right. That's why, like, one of the biggest challenges right now is everyone's agreeing that the models are approaching— they're all pretty, pretty similar now. They're all trained on the same datasets. But you see those models actually have very different performance depending on what sort of engine you have backing the contact. And in simpler terms, depending on the software that actually decides what should be sent alongside your messages to the agent, that's where now there's a lot of room for improvement.

What if we achieve AGI? Let's say if the models become extremely good, would this naive approach work?

So I think though, another way to say this is imagine you had the smartest possible person on the planet, right? And you have this, this truly true genius and you go up to them and you say, which of my customers were upset last year? The question is, does it matter how smart they are? It's also a sense of knowledge. It's also, do they have the data to go through to actually decide? So I think AGI helps, but AGI does not solve this problem. AGI, it also like, there's AGI, there's also like context window sizes. So like we might have a really smart agent that still can't take a lot of context, but if we have AGI and unlimited context, you get better and better. You still though run into the problem of how do I extract all of this data from a third-party system to actually then send into the context of the agent?

It's not efficient anyway. Even if this works, right? You're not going to be answering every single question with the whole universe of knowledge out there. It just doesn't make any sense.

It's slow, it's expensive. There's a lot of problems associated with that.

So the bottleneck is really not intelligence, it's actually the data.

It's the data for sure.

How do we let these agents take actions but still keep good control? Yeah.

So what I like about MCP, and I'm assuming most people listening have at least heard of MCP, what I like about it is it's actually a relatively simple concept, right? The idea is You want your agent to be able to take actions in third parties, but you don't want to give an API key to an agent. Giving an API key to an agent is like giving a username password to an agent. Like they could send it anywhere. They can do a lot. They can go rogue and just take actions in the third party that you don't want. So MCP gives agents the ability to have like scoped access. It basically exposes a tool to the agent and says, you can call, let's use Jira as an example. The Jira MCP server might have create ticket and list tickets and search ticket, something like that. And. When you actually get your agent to call those tools, you want to make sure that it's not making a direct API call because then it has an API key and it can take, it can call different APIs. It can send it to other places. Instead, you expose this as via MCP, discrete callable sort of tools that they can call. So basically you tell the agent, you can call these 3 tools. The agent then is passed those tools as an option and the agent decides, I want to call X tool. It out of context, it jumps out and it tells your static code base. Hey, me as an agent, I wanna call X tool, and then that tool gets called outside. So the nice part there is you don't really have to worry about like the agent going rogue and calling things it shouldn't or exposing keys that it shouldn't. It has a very tightly defined interface for what it's able to do.

Speaking of like agents going rogue, one of the latest news is OpenCLAW, right? It went, exploded like 250K GitHub stars, employees installing it on work machines. And connecting to corporate systems. I heard that a security researcher was taking full control of one instance, like under one hour.

Yeah.

As someone building enterprise agent infrastructure, what do you think when you see that?

So I, we had to immediately talk to our whole company about why you can't be using things like, like OpenCLAW. And there, there's a lot of reasons, but notably it's a computer use agent. So this is different from a lot of like enterprise agents that run in the cloud. You're basically, you're basically. The equivalent would be you go, you open your laptop, you put in your password, you go up to someone random on the street and you're like, here you go, take this and feel free to do what you want, right? It's not quite as bad. Maybe you're passing it to someone who's semi-trusted on the street.

Right.

Because there are some controls in place, but it can always go rogue. And going rogue when someone has unlocked access to your computer, that could mean going to a browser, going to a website that you have your password saved on, logging in. What if you have iMessage on your computer and you have 2-factor auth with your bank? Like. Boom, it goes, it just logs right into your bank. So the risks are so immensely high right now of what you're inherently just giving this thing access to. Even if you try to lock it down, a lot of people just don't know enough to be able to do this right. So our advice to our team has been, unless you are sure of what you're doing, just don't bother with OpenCLAW right now. Everyone, if you are going to use it, you should be using it on like a sandbox. So that would be either like, I'm guessing most people here don't have this, like a virtual machine setup, something of that sort.

Yeah.

Something containerized or privatized. Or the other option is on some brand new side computer that you just wanna mess around with. But you should assume that any services or anything you log into on that machine, you're giving an agent full access to do whatever it wants with.

I heard that computer, new computer prices has gone up.

Yeah.

Oh yeah.

And that all of the, what is it? The, the, the— Some ultimate Mac minis are selling.

Yeah. Mac minis. Yeah.

We, what's funny too is at Merge, we have, we have the old company devices that we recycle, but we give our employees a chance to buy them at a very low cost if they want them before we send them to get recycled. And it used to be like, not a lot of takers. A lot of them did end up getting recycled, but now like they're all getting purchased. As soon as we get one decommissioned, people buy it.

Okay. Now it's going to good use.

Yeah.

Speaking of MCP, a lot of people have been talking about MCP since last year, this year. And I remember you said something like most public MCP servers aren't enterprise grade. And why is that?

I think there's a mix of things. So I think it started with marketing. Everyone just wanted to have something out there to, to yeah, be, be first to market and say we support MCP and all of that. And I think the problem was they didn't expose a lot of tools. They didn't make things super reliable. They didn't test really deeply. And so ultimately you end up with all these tools out there that people tested once and were like, this doesn't work super well. I'm not going to use this. Also, auth is not super easy with MCP. And so actually getting connected and making it all work is just difficult. And so yeah, that's why at Merge we decided like one of the most important things here is tool reliability. And how we've done that is we build out all of the integrations from scratch. We don't use any official MCP servers. We rebuild all of them. We cover all tools. So we basically cover anything that's needed for common use cases, because again, we've become experts in this space over 6 years. And then lastly, we train over all of the ticketing data that we have from customers who have ever reported bugs or edge cases. And so just off the bat, these integrations are just built to be extremely robust and handle broad use cases. I think unfortunately a lot of the APIs at these big companies haven't been touched in years. And so you have people trying to tack on MCP servers with no real connection to the problem. And that's why you've seen that. And actually you have seen some platforms release much better MCP servers. They've gotten better over time. But it's still a huge problem. The vast majority are unusable.

Can you explain in a very simple language for just in case people don't know what it is?

Yeah, I think the easiest way to think about MCP is it's like an API built for agents. It's not, that's not 100% exactly how someone like deeply technical would describe it. But if you wanna think of it that way, it's basically just a way to expose access to a third party directly to an agent.

A lot of these things that we were talking about is plumbing and getting the right data at the right time. It is RAG, right? But last year, or maybe even 2 years ago, people are already saying that RAG is dead. Yeah. Like, really? What's your opinion on this one?

Yeah, so actually I used a different term earlier, but that's what I was referring to by synced connectors is RAG. It's this notion of you pull in the full dataset, you put that in a vector database or some type of specialized data storage that is optimized for you being able to retrieve that data really quickly locally in a sort of semantic format, semantic being something with meaning. So you're not saying, if SQL, you're not saying select from tickets or give me all tickets from the database. Instead, you're saying which customers were upset last year, and that can be actually looked up in this optimized store. So what's interesting is people say RAG is dead. RAG is not dead. It's far from dead. It's just not the only option anymore. It's definitely the best option for a lot of use cases. But if you're saying like, get me ticket number 347, RAG is not optimal for that. There's no reason to preload all tickets from Jira if you can also just quickly go fetch one ticket. But if you need broad data analysis, if you need broad scope, like for example, how Glean or again, OpenAI's Enterprise Search enable you to search broad swaths of company data with a single query, that's where RAG is still really important.

RAG is still different from things like text-to-SQL. Some of the hybrid use cases really RAG understanding the unstructured data and turning into a SQL language for querying. Structured database.

Yeah. Yeah. I think there's a lot of different use cases. RAG is ultimately though, like you've created a copy of the data somewhere and you've optimized it for fetching by AI, right? That's why like an API is like not quite RAG because it hasn't been optimized or standardized for retrieval in the right ways.

When does someone need this RAG more synced version versus live agent lookups or both?

Yeah. So I think where MCP or live integrations are nice is for a couple of use cases, but notably it's things that are simple. So simple transactional lookups. I want one record from a database, or I want a list of 5 records. I want the most recent. I want those sorts of really simple things. And it's especially good for taking actions. I want to go update a ticket. I want to do X, Y, and Z in the third party. It's very effective at that. But where it's not good is again, these the broad swaths of data. And so when you're building something that needs to provide insights or analyze more data or potentially bring together a lot of different data sources and do so quickly, that's where synced or RAG connectors are a better approach.

Do you test that your agents' connectors are working correctly?

Oh yeah, massively. So we use evals, which essentially is, it's sort of the, you know, everyone's heard of testing in software. You write tests. Evals are the way of testing for AI. And the reason it's different is in the past you would write a test and you would say, let's say you, this is just really simple, but let's say you have code that adds 2 numbers, right? You would have a test that basically calls that code and passes it 1 1 and just checks that 2 is returned. That way, if anyone in the future went and changed that function and it broke the functionality, that would be surfaced, right? It makes it so that software is maintainable. It makes it so you're not scared of breaking things every time you make a change. And with evals, a little bit different, right? Because you can't say every time I ask what is the weather, it should say it is 70 degrees because one, that's going to maybe change, but also it might say it is 70 degrees one day and then a millisecond later it might say the weather is 70 out. So it's a really, it's inconsistent. So what you need to do with an eval is actually have an agent that evaluates that the answer that was given out was correct. So you would say. Does this— does the answer given by the agent in some way, shape, or form say that the weather is currently 70 degrees out, right? And it doesn't matter what the wording of it is, it judges that the answer is correct based on the semantics or the meaning of what it says. So we use heavy evals to make sure that we are getting performant tool calls, that they work across a broad set of potential inputs and across a broad set of customer credentials, because every instance Is hallucination still a problem along the pipeline?

You have agents pretty much everywhere and the core of the agents are still LLMs, right? Yeah.

So hallucination is still a problem. I think it's getting better though. The models have really improved now. You, it used to be that you, and by used to, like 4 months ago, you would use a framework like LangChain or CrewAI or one of these others that helps you basically chain together a bunch of agents. And the whole reason people did that was they're seeking deterministic results. Every time I run this agent, does the same thing happen or does it, is it non-deterministic? Does it go off on different paths, different times, which makes it really hard to then deploy that to, to an enterprise. And so people were building these guardrails of first, here's a simple query to run, then always do the following, then always do the following. It's like, how close can we make it to traditional deterministic software while also mixing in AI was how the approach was. Now you don't even need to do that anymore because the agents are actually really good and really consistent at following. You can just give it a workflow in text and it just does it. It just does what you say. And that's getting better and better by the day. So I think we're, yeah, we're moving to a really good place where the models are handling a lot on their own.

So basically it's less about prompt engineering or even this context engineering thing. And the model is getting better is actually solving this problem by itself a little bit.

It really is. Yeah.

I'm curious, for your 2 products, which one is selling better?

Honestly, both. It's, it's there. I, I wouldn't say one is selling better than the other. It's different use cases. So yeah, I would say both are selling faster than ever.

In our prep call, you mentioned about context graph.

Yeah. Yeah. What is it? Yeah. So the context graph is this notion of, it, it's what I described, right? You have so much context you potentially wanna pass to your agent.

Right.

So that could be, let's just use an example here. Let's say that we have built some sort of enterprise knowledge search for our company, because I've used that example a couple of times here. So we want to go and we want to ask, who is Gil's manager? There's a lot of ways to get this information, but what we also know is that in the context we pass to the agent to answer this question, we don't want to answer when was Gil's last vacation, right? But that is data that's valuable. To have and potentially pass to an agent. So a context graph is essentially a sort of structured. It's a data structure we call it. It's a graph, and what that means is you have pieces of information. Gil, I am likely connected on this graph to another person who is my manager and maybe my reports. So you can think of that almost as like a tree, which is like a graph. And so then when I when a certain question is asked, you can go into this graph and you can follow between all the links. You just go to all the nearby data that seems similar, and that helps you gather the. Relevant information so that you don't pass too much context to your agent, but you pass just the right amount to answer the questions that are being passed in. So context graphs are an underlying infrastructure feature that most people probably use in their day-to-day when using AI and don't even realize it. And it's used for local context. So what are things that I've asked before? What are corrections I've given the agent in the past so that it knows not to? There's a lot of that, but then it's also third-party data about my company. It's all of my knowledge base information. It's all of my HR information, my ticketing information. All the tools that my company's using, accounting, ERP, stuff.

That sounds very similar to a knowledge graph. So the GraphRAG approach for like getting the right context.

Yes, it is very similar to a knowledge graph. I think that there's, there are some key differences. There is more living, the data is changing constantly. It's optimized for, for different relationships and all of that. But yeah, in a lot of ways it's very similar to a knowledge graph.

Are you building it from ground up within your company?

Yeah, so that, that is going to be coming. So right now we offer live context and we offer stored context, but what we don't do is actually pre-optimize that and put it into a knowledge or context graph for our customers. So that's something that we are working on and will be coming over the next year or so.

Is it going to be very expensive to build these features for any of your clients? They might have large amounts of data, right?

Yeah, it's expensive to operate. There's no denying that, but I think when you see the value, when you actually like come into one of these tools, connect everything, and start asking questions, you realize that the cost of indexing that data is very much outweighed by, you know, that it very much outweighs what the cost of an employee would be when it can answer deep questions for everyone in your organization.

Do you have a demo you want to share right now?

So I don't have a demo of that stuff. I could demo the Agent Handler product.

Oh yeah, why not?

What you're seeing on the screen here is the Agent Handler dashboard. So this is meant for the admins at a company, assuming you're using this internally for your employees. This is meant for the admins at the company to come in and manage It's not meant for every employee at the company to have access to. The first thing that we do, like I mentioned, is we build, manage, and maintain all the connectors. We have hundreds of connectors with all the popular platforms out there. We manage all the authentication. We manage building the actual connectors. Now, if you go into any one of them, for example, you can then see all of the underlying tools that exist. So for something like Airtable, that might be creating a new table, that might be updating tables, commenting, all of that. So once you have all these, you set them up in a tool pack, which is just a bundling of tools. So these are the tools you want to expose to your agent. And then lastly, you have an agent and you connect it. So I'll just show you an example of what this looks like. So this is our playground. You can connect Agent Handler to any of the AI tooling that you use. It follows a standard MCP or a standard integration protocol. So that's supported by the vast majority of platforms out there. Copilot, OpenAI, like all of them support integrating with this. What I'm going to show you now is how we actually connect a lot of this. So let's say that you are someone at a financial services firm, for example, and you want to talk to a lot of your tool suite. So that might include things like Teams, SharePoint for all of your file storage, Asana for your ticketing, and then also let's say Google Drive, for example. So I'm going to paste in a prompt here and just to quickly show you what it does, it's saying first. Find my client financial folders in G Drive, grab the newest 8K document, download it, and then let's do the following. Determine what the primary event is, a positive or negative, what's likely for the stock price in the future, and then send your findings to Matt on Teams. Cool. That's pretty complicated flow. This would previously have required quite a bit of work and using a framework to make sure that it operates every time.

But we're going to see how good tools and better agents have actually transformed I think as a consumer user of Claude, this is a very similar interface as well. So I can hook up my Claude with different MCPs and different tools and basically do something similar.

Yep, exactly right. So, okay. So it turns out we're not logged in here. And so it's saying to go get it otherwise. Sorry, I might need to redo this demo.

Okay.

Sorry. Do you wanna repeat that so it doesn't—

For all these things you're building, what's the hardest to build? What's the tricky part?

I think it's the sheer volume and breadth of data. It's incredibly tough. It's these systems that we're pulling data from were not optimized. They weren't built for mass data movement. And just the sheer amount of data that exists in them is greater than ever. So I think that, I think partnerships, I think navigating a complex landscape. Integrations are a very tough problem because they constantly break. There's a lot of edge cases. And so I think figuring out how to properly be a reactive company and handle changes and all that, it's just a tough problem that we've grappled with. For our whole existence. And I think it's something that AI has helped us get better at, but it just continues to be a really tough problem, which I think is what also makes it a good business, right? That's what makes it one of the businesses that survives the AI revolution and actually thrives in it, is the idea that it's plumbing data in a really complex problem.

Do you think Anthropic or OpenAI would build some native tool calling infrastructure that handles these authorization permissions? Would they do that?

Yeah, I think absolutely. I think that they are, Anthropic invented MCP, right? They're the ones who released the standard there. But it just doesn't solve all of the problems, right? This is a full company problem. It involves building out integrations, getting partnerships, onboarding and authentication and key management permissions. There's a lot that you need to handle here. And so I think one, a lot of the large LLMs are our customers and do use us for this. I don't have local rights, so I can't actively share a bunch of names here, but A lot of them do use us and we do have them on our website. And yeah, I think that they've seen how big of a problem this is and they would rather just have someone else handle it for them than have to have a whole team of people working on this.

It's not a simple integration once and then you can just leave it there. So I guess the big labs don't want to deal with it.

Yeah.

And you mentioned about, there's some issue with using building agents with admin API keys, right? What's wrong with the API keys that agents are using?

Yeah. So you just don't want to give an agent an API key. That's the biggest problem because the agent, like if you think about it, in the past, whenever you wanted to send data anywhere via API, you had to have an engineer hardcode what data was being sent where, and then a second set of eyes approve it. But now you're telling this agent, hey, you have the ability to talk to any API anywhere on the internet. And also here's an API key. It could take your API key and then just send it anywhere. It could post it to some hacker's URL, it could post it On, on your Facebook, like it could post it anywhere. And so that's the risk there. You just, the, the assumption should be that any data or context you pass to your agent, there is a chance that it does leak that and send it somewhere it shouldn't. And so that's why you have to be incredibly careful about not just giving an API key to an agent, but instead letting the agent tell you, I want you to talk to this API. And then you're able to go and handle that sort of outside the scope of the agent and then pass the results back to the agent when you want it to continue.

And there's a permission and authorization in the steps, right?

That's exactly, yeah, that's exactly right. The permission and authorization is what backs up the API key, right? The API key is backed by what it's actually capable of and able to do. And so yeah, essentially the agent asks you to do something, you then go try to do it with the API key. If it gets blocked, then it's blocked. But also that does give you the ability to add additional controls because some platforms just make you, they, they only let you generate a sort of master API key that can do everything. So by lying in the middle of the agent. and the third party, you also can control what can actually be done, which is something that we offer heavily in Agent Handler.

And you also mentioned before that you rebuild every integration twice.

Yeah.

And that was like the secret sauce. Tell me.

Oh, so for permissions specifically. So permissions are really difficult and this is for synced connectors. When you sync the full dataset from a third party, you need to make sure that employee A who just joined the company as a new grad is not able to see the board deck from your last board meeting, right? And so in order to do that, these third-party APIs also return the permissions. Who has the ability to view each specific file? If that's wrong, the consequences are grave, right? That could be— that is almost surefire churn. We know about it happening to a lot of players in the space who have built enterprise search solutions. You have to be super careful. And so what we do is we rebuild the permission sync twice. So we sync all of it in one engine. We have another engine that was built by someone who did not see the original codebase. And also syncs those permissions. Those 2 then have a task that runs between them and runs a statistically significant number of comparisons between them to make sure that the permissions are actually up to date. It's that important. And so while you're seeing this really beautiful interface, you're like, hey, what happened last week and while I was out? And you're getting all these answers back and whatever. Behind the scenes, there's a lot going on to make sure that you can only see the documents that you should be seeing so that the agent is being passed Again, not just permissions that it's allowed to be seeing, but also it's not passed too many documents that aren't relevant to what you're asking. So you can see how that all comes together.

Who are your customers right now?

They're all over the place. So we have a bunch of logos on our website, but we sell to everywhere from early, early startups up to Fortune 500s. A lot of the large LLMs, AI labs are using our product. So yeah, I don't know if you want to, maybe at this point you can show like a scrolling of our logos. But yeah, we serve quite a bunch. I just wanna make sure I don't say any that we don't have logo rights for here.

Did it evolve? Like, what did you do to be able to earn the trust of those big labs and the Fortune 500 companies?

Yeah, we, we sell to, like I mentioned, a lot of the big banks like JP Morgan. We sell to a lot of the big AI labs. We sell to just a lot across the board. And the way I describe this is we had to climb a logo ladder, right? We are an infrastructure provider.

Right.

And infrastructure providers do not close enterprise It's quite rare. And so, it was a sort of climbing the ladder, serving a company, proving that we could serve a downmarket customer well, improving our security posture, signing a better customer, or sorry, a larger company that was even stricter on security, having them then audit and critique us, and moving up slowly but surely until we finally hit the sort of mass enterprise.

Congratulations. Yeah. Appreciate it.

Yeah, it's not easy.

Yeah, for 5 years. If there's one thing you can teach me to be a better founder or entrepreneur, what would it be?

I think it's who you hire is everything. You have to hire people who really care and who are really passionate about the space. We always optimize for learners and growers over people who have done it 10 times before, but seem like they just don't really care much anymore.

Speaking of hiring and people's career, right? AI is changing the gap between senior and junior engineers, right? Some people might say that it's widening and some people might say it's shrinking. What are you seeing emerge?

I look, my argument from 2 months ago to now is it's just going to keep shifting. And I think the answer is like, soon the agents will be smarter and better than all of us. And it just won't really matter. Like, I've just seen it move too fast now. At this point, I'm convinced, like, it's a better coder than most people I know, right? It's a better coder than most engineers I know. It does make some mistakes here and there. It's not perfect at everything. But at this point, I've seen such an inflection point in the growth of sort of intelligence of these agents that I'm not here to say it's not going to happen anymore. So I think the answer is like the gap is closing because you won't need software engineers.

Man, is that your doomsday prediction for software engineers? Yeah.

My prediction is you don't need anything. Like you won't need anyone. Like I think it's going to take, I don't think it's tomorrow. I don't think it's tomorrow. Don't get me wrong. Like I think it's going to take a long time. We sell to enterprises. We see what it's like to get an institution to change anything. Like the way I picture this is I always think of, not to bring this up, but I always think of that ship that hit that bridge in Baltimore and how for 10 minutes you could see it was going to hit the bridge. Everyone knows like this is gonna hit, but there is nothing you can do. This thing is just going and it's like a large heap of metal with so much momentum in a specific direction. That's how enterprise is right now. And so they will change, but they might have to hit the bridge first. They might have to, some other things might have to happen before they get there, but it's gonna happen.

How much time do we, do software engineers have?

Do we all? I think there's still several years, right? There's still many years because like even if AI can write all the code, you, if you can choose between having software engineers backing that and supporting the AI and doing it. And not having software engineers, why would you not opt for software engineers doing that right now? But I think over time, like that argument gets weaker. Software engineers just become really expensive. And at some point it's, yeah, you just have this sort of, I think what's really going to emerge is a new type of role here that a lot of different professions are going to move into, which is some form of operator of the AI.

How does that change how you think about your team size and the career growth on your team?

I think right now it means we want to hire more. Reason being, we see that we get more output per person, right? So there's, like, for us, it's always been that when we build more, we have good ROI, but it's not, it's not insanely positive ROI infinitely, and it takes time to adapt. Whereas now with AI, we see positive ROI much more quickly on employees and on headcount, and that means we want more.

The gaps between people Who's figured out how to use AI versus people who haven't are just widening. And this is scary. How do you think an average person can get themselves prepared to learn, to figure it out?

Yeah, I think first of all, if you're using ChatGPT every day, some form of LLM every day, you're already probably in the top and you're doing great. Like, I, I don't think people should be, feel shamed about that, but I do think it's time to get to the place where you have things running automatically, you have things taking actions for you. You've at least thought about connecting to third-party systems, so going into these platforms, going in and connecting your Google Drive or your SharePoint and your Slack and your Teams. And don't go rogue and do that without your security and your team's approval. But I think that's where you start getting real value is when AI is actually taking actions for you. And we're finally at the point where it doesn't take an expert agent builder to go and do that. Again, you can just send one prompt that has a list of things to do, and the agent tends to execute pretty perfectly on all of those these days, especially if you have the right tools Which is something, you know, Agent Handler provides. Or you can use some of the native connectors as well that are built into some of these platforms.

Let's say for a non-technical person, what's your suggestion of trying to get where what you just said that they could get to having AI automated making decisions for them? Where should they start on building something like that?

Yeah, I think I would use any of the major platforms out there. There's sign up for one of the monthly plans on one of the major LLMs. They all have agent building capabilities and they all have the ability to run tasks repeatedly in the background. Get deeper into it. I think one ecosystem I love a lot, like I, I'm a heavy OpenAI user. I also love Claude. And there's a lot of different things you can do, but Claude, I would start learning the basics. The cool thing is learning about these platforms and how they work. You're no longer learning things that are inherently like really complex, right? People talk about Claude and skills and like, what are skills? It's actually a text file that that gives that has customized instructions for the agent, right? You might have a skill that is the security analyzer, or let me pick a simpler one. You might have a skill that is like the contract evaluator, and you say merge never agrees to auto renewal clauses. Make sure it doesn't have that merge never, and then anyone in your company can rerun that skill. That's something that sounds so complex, but actually it's simple. A lot of these things now are relatively simple. They're just like. Constructs or concepts to understand, and under the hood, it's all just English English language that's been put in different places because that's all the the LLM is literally a large language model. You communicate it; you communicate with it in English, which is really cool for the masses. It's a great opportunity. So I would say go in, learn those things. Just go deep on one of the frameworks and just read their documentation. Also talk to the agent itself. Tell it what you want to do. I would love to use go to Claude and say, "I would love to use Claude to automatically wake up my kids in the morning and do blah blah blah." And it'll tell you what to do. So that, that's how I would go about it.

What are you using? What are you automating in your life or work?

Yeah, so I've automated a lot of different things. So like lights on, things like a lot of my smart home are now automated, but in slightly smarter ways than they were in the past. I've automated flagging important emails to myself because I get a lot of emails throughout the day and I want, when I get one that's actually really urgent and critical, I want that to be flagged to me on Slack immediately. So I have that set up. I've set up a lot of really cool automations that just make my quality of life higher. Even things like I found myself asking recruiting, how's pipe looking for this role? Or in, in, I could have always gone in and looked too, but now I have it looking for anomalies and notifying me if pipe has dropped for a certain role. Things that just weren't really possible before.

What are you using? Are you using Claude or are you using Merge?

I use Merge Agent Handler to power a lot of that combined with some stuff I've built on my own.

You are using your own product, which is a great sign.

Yeah, definitely. I think one of the big problems we see is like most platforms don't have a lot of live connectors yet. And so with Agent Handler, I, we have so many, we have hundreds. And so I just connect the, the whatever platform you're using. I've connected all, all of them basically to Agent Handler. So now Claude, for example, or my, my ChatGPT can talk to literally all of the platforms I use for work, including, including our recruiting software Greenhouse and, and our file storage, just like tons of different systems I can talk to now.

The email flagging important email one, are you using Merge as well?

Yeah, so Merge has a Gmail connector. So basically it can get, it gets notified of a new email coming in and then it can, I basically have a prompt that's, that judges the importance of that email. And it says, if it's, if you deem this to fall under the highest of priorities, message me on Slack to tell me.

How are you different from Glean? Because you mentioned Glean. I feel like these enterprise search functions are very similar to Glean.

Yeah, so people can, so people can build Glean using Merge. So Glean essentially is, it's actually in some ways a productized context graph, right? You base it, it loads in. Data from all your different company sources, structures them in a way for optimal lookups and retrieval. And then when you're talking to the agent, it's talking to that. At a simple level, that's kind of how that all works. And so with Merge, we're providing all of that data too. And so that's how a lot of these large LLMs and a lot of these AI companies have built Glean-like or enterprise search functionality is by using Merge as the base layer for all of the synced data that gets loaded up. As well as the third-party or live connectors.

I think I just need Mergent to just hook up my database and all the systems and then that's it.

Yeah. So it's interesting because we don't power that directly for companies. We power it for companies that want to offer it to their customers for the actual Glean-like use case, which is the actual index, pull in all the data, index it, store it, run over it. But, but yes, absolutely. For live lookups. And for connecting all of your company data sources and bringing that with you to any platform, that's absolutely a fantastic use case. So we find a lot of our customers will come in, they will connect their, their Greenhouse and their SharePoint and their Outlook and all their sources, Teams, everything. And then they now have this sort of portable layer to talk to all of their apps that they can bring to any third-party API or to any AI solution that they're using.

Users can use Merge for both the internal use cases and using it to build whatever they're building for their customer as well. So you're covering 2 use cases, whereas Glean is only the first use case.

Yeah, that's exactly it. So yes, we help companies launch and offer products, but also like, for example, Netflix uses us to power their internal agent. So their internal agent can talk to all the third-party systems that they use. And then any employee at Netflix can just ask. So they have effectively built an internal Glean competitor, and that's built entirely on Merge.

I have a traditional closing question now. If you could recommend a book To, let's say, a 20-year-old you?

I think everyone needs to get smart on AI. Like, it's, it, like, it's the second industrial revolution, or it's the, this, the largest probably industrial revolution. And that means reading about AI. And there's a book that I read a long time ago that has held up to be like kind of true, which is why I'm about to read the next one called The Singularity Is Near. And it's basically about how we are approaching the moment. And I think that like it was written in early 2000s or something, and they quote 2029 as the year that like the singularity being the year that, so I think 2029 was like what they predicted. I could be wrong about this, but what they predicted is like when AI reaches or surpasses human intelligence. And then 2045 or something is the year of the singularity, which is when humans and machine technology merge. And it's so weird because you're seeing things popping up that are like this. Like you have Neuralink, which is the chip in your brain that can help. And AI is getting good enough and Neuralink can run AI. And so we're getting to this point where it's like, Things are starting to come true from there. There are some wild, outlandish claims in there, and it's a cool book for that reason. I like that it's like a thought experiment, and a lot of it is not true, and a lot of it is true. But I think this claim around the singularity is really interesting. And I love reading about these things because it helps you realize what the art of the possible is with AI and where things are going to go, whether or not you believe every single claim or guess in that book.

It seems like you are seeing firsthand it's happening now, right? And do you think that the time is about right? 2029, 2025?

It's weird. Yeah.

It could be very close. Are you prepared for this?

What can one do to be prepared? I, the things I've read are like, make all your money now because you'll never have a chance to make money again. Oh, which is so scary. I don't, I think a lot of this is a little bit crazy. I think wherever you are on the political spectrum, you're gonna see that like there's jobs are gonna be hit. And so there, there's gonna need to be government intervention in some way here. I, I, no one knows exactly, but I think everyone is pretty fearful of a post-AGI world.

Yes. And I don't know the answer, just like you.

No one does. And if we did, we would probably be regulating.

When we have 50% unemployment rate and all the software engineers cannot even find a job, I don't know what people will do. But as you said, on a positive note, maybe just, it's just gonna be a new role. Maybe we'll have to be more creative. Yep. Start writing books, getting on podcasts.

Writing books. Yeah. 'Cause I don't know, the thing is like, what is AI not gonna be better than us at? And the answer's probably not Nothing. So I don't know, bring back the, the idea of human creativity. Who knows? Who knows how good AI will get?

What was that? Not even creativity. You don't think we can beat AI with creativity?

Who knows? Really? Who knows? Like AI might get very creative too. It's gotten better at that stuff.

But what about consumers? Like nobody talks about consumers. We still need consumers to buy all these fancy things that people are building, right?

Yeah, but how many, there's so few jobs to actually create those things.

So we are all gonna run outta money to buy and then whatever fancy things the founders are building. I don't wanna go dark, but I know. Yeah.

Whether or not, like the point is you're gonna have all this intelligence. It's not like productivity on Earth is gonna go down, right? So there's gonna be enough outputs to like fuel and feed everyone and all of that. The question is how it gets redistributed from the few people who are gonna be really running a lot.

We should stay in touch and I'm gonna chat with you like in next year and in 2029 as well. How do you feel?

We'll have a fun employment vacation together.

Let's do that. If you have new announcements, always come back on my podcast and we can always chat about it.

Awesome. Yeah.

Sounds great. Thank you so much.

Thanks so much for having me on. Really appreciate it.