By APIs were designed for human-scale UI consumption. They carry rate limits, pagination constraints, and access management models that assume a person or a narrow automation script is calling them. AI agents do not operate that way. They need to discover what data exists across dozens of systems, cross-reference it, and write back reliably, all at speeds and volumes no existing API infrastructure was built to support.
In this interview on TFiR, Michel Tricot, Founder and CEO at Airbyte, breaks down why thin MCP wrappers fail in production agentic systems, how Airbyte’s Context Store is architected to solve the discovery and write problem, and what governance frameworks enterprises need to audit agent actions at scale.
Guest: Michel Tricot, Founder and CEO at Airbyte
Show: TFiR
Here is what every data engineer and AI platform team needs to know.
Technical Deep Dive
Q: Why are existing APIs and data pipelines insufficient for AI agent workloads?
Michel Tricot, Founder and CEO at Airbyte, explains that the systems where enterprise data lives today, including databases, Google Drive, Salesforce, and Stripe, were built for UI consumption by human users. Their APIs exist for specific narrow automations and operate at low scale. Agents operate at high speed, need dynamic discovery across multiple systems simultaneously, and require infrastructure that was never part of the original API design contract.
“These APIs have not really been designed and built for agency consumption, where suddenly you have something that operates really fast, that needs to discover the world around them.” — Michel Tricot, Founder and CEO, Airbyte
Q: What is the Airbyte Context Store and how does it differ from a standard API or data pipeline?
Tricot describes the Context Store as a layer that lets agents discover available information across systems of record without requiring hardcoded if-then-else decision logic. Instead of the agent being told explicitly where to look, it can identify that data exists in Salesforce, recognize a related system like Zendesk is also available, and pull context from both organically. This discovery-first model is the core architectural difference from a traditional pipeline or direct API call.
“It’s giving you a way to discover this information without you doing a sequence of if then else. It’s just going to discover what’s available.” — Michel Tricot, Founder and CEO, Airbyte
Q: Why do MCPs fail when used as a thin layer in front of an API?
Tricot is direct on this point: placing an MCP as a thin wrapper over an existing API does not solve the underlying infrastructure gap. The agent is still subject to rate limits, pagination, access management constraints, and the absence of real search capability. That configuration returns the agent to the same operational environment as any traditional API consumer, negating the purpose of an agentic architecture.
“MCPs don’t work when they are just a very thin layer in front of an API because then you’re just back in the old world of you have rate limits, you have pagination, you have access management, you don’t have search.” — Michel Tricot, Founder and CEO, Airbyte
Q: How does the agentic data loop work in practice?
Tricot frames the agentic data loop as a continuous cycle with three phases: discover and search, read, and write. The agent first identifies what data is available across connected systems, reads and cross-references that information, then writes back to upstream or downstream systems with richer context than any single system could provide alone. This loop repeats continuously rather than executing as a one-time pipeline run.
“First you need to discover and search, then you’re able to write to read this information and then you’re able to write and then you continue that loop and you go over and over and over again.” — Michel Tricot, Founder and CEO, Airbyte
Q: Why does cross-referencing data across silos improve the quality of agent write operations?
Tricot argues that the logic determining what data gets written to a system almost never originates from a single source. An agent writing to a downstream system without cross-referencing related data is missing context that a human operator would naturally have. The more data the agent can pull from multiple silos before executing a write, the lower the probability of writing incorrect or incomplete information.
“The logic of what data you put into this write is never coming from just one singular system. It’s coming from a multitude of places where data and context is actually stored.” — Michel Tricot, Founder and CEO, Airbyte
Q: How should enterprises approach governance and auditing for AI agents acting on enterprise data?
Tricot frames agent governance as an extension of existing human governance frameworks, not a replacement for them. Enterprises need to expand their governance model to account for synthetic roles making actions, then audit what information was accessed and what was written using the same log-and-monitor approach applied to human actors. Specific rules can be encoded into agents either as prompts or as deterministic workflow constraints defining what the agent is and is not permitted to do.
“We need to expand governance to not just humans making action, but having actually synthetic roles that are making these different actions.” — Michel Tricot, Founder and CEO, Airbyte
Q: How do you handle the reality that AI agents will make mistakes in production?
Tricot takes a pragmatic position: agent mistakes are not a failure condition to be eliminated but an operational reality to be managed. He draws a direct parallel to how enterprises already accept that human operators make mistakes and build detection and correction processes around that. The net advantage of agents is not zero-error execution but the speed at which errors can be identified and corrected once a detection system is in place. He also suggests using an agent to audit the audit logs themselves.
“The thing that you gain by having agents running on top of that is that the speed at which you can solve these problems is much higher.” — Michel Tricot, Founder and CEO, Airbyte
Q: Will better future models eliminate the need for this kind of data infrastructure?
Tricot is explicit that model improvement does not resolve the underlying data access and governance problem. Whether the current generation of LLMs or a future generation is running the agent, mistakes will still occur and the same operational risk management applies. The infrastructure layer for discovery, context, and auditing is model-agnostic and remains necessary regardless of model capability improvements.
“It doesn’t matter if today we’re using LLM or tomorrow we’re using another generation of models, it is going to make model mistakes.” — Michel Tricot, Founder and CEO, Airbyte
Resources and Documentation
- Airbyte, open-source data integration platform with Context Store for agentic AI workloads
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: Now when it comes to AI, as I said, I am also a heavy user. Context matter, you know, if you don’t explain to or if the AI doesn’t have the context, it can cook things up. And you folks are also introducing the concept of context store. Talk a bit about what it is and how is it different from traditional API or data pipelines and why does it matter for production AI systems when
Michel Tricot: we think about where is the data living today? So it is living in a database, it is living in a Google Drive, it is living on Stripe, on Salesforce, on any kind of systems that act as a system of record. Now these systems have been built for UI consumption. So a human going on a ui, manipulating the system, changing it, et cetera, et cetera. And yes, you also have API in case you have like specific automation that you want, but they operate at a very low scale in terms of how much is being used, et cetera, et cetera. So these APIs have not really been designed and built for agency consumption, where suddenly you have something that operates really fast, that needs to discover the world around them. And this is what the context source is all about. It’s giving you a way to discover this information without you doing like a sequence of if then else, if then else. It’s just going to discover what’s available and it’s going to be able to just, oh, there is this piece of information on Salesforce. You know what, let me, I see that there is this other system available, Zendesk and let me see what’s happening on the Zendesk side. And all this interaction, if they are gated by API or if you just put, you know, you mentioned MCPs that are not working like MCPs don’t work when they are just a very thin layer in front of an API because then you’re just back in the old world of you have rate limits, you have pagination, you have access management, you don’t have search, you don’t have the ability to do that discovery. And this is where the Context store actually enables this agent is just, it allows the agents to behave with this organic knowledge that it might have by just pulling different string, discovering what’s available and then making the best decision based on how it was prompted or the different type of workloads that were defined around them. The other piece is on everything that is what we call write. So the ability to interact with this upstream or downstream system, if you just let the agent interact directly with the API, it might not have all the information necessary to make the right API call, or it might mess up, it might write the wrong information, but the more it’s able to cross reference data across silos and the better the write is going to be. And yes, there is always the technical piece of it, which is making sure that you’re making the right API call. But the logic of what data you put into this write is never coming from just one singular system. It’s coming from a multitude of places where data and context is actually stored. So that is why when we’re thinking about the context, all we always approach it from this, what we call the agentic data loop, which is first you need to discover and search, then you’re able to write to read this information and then you’re able to write and then you continue that loop and you go over and over and over again.
Swapnil Bhartiya: Let’s talk about trust a bit. If an AI agent is making decisions or taking action based on the data from your system, how do you ensure data quality, lineage auditability, in a way that enterprises can actually rely on?
Michel Tricot: I think we go back to, we go back to this idea around governance. It’s just that we need to expand it to not just humans making action, but having actually synthetic roles that are making these different actions. And after that the same thing is going to come into play is like how do you audit what information was accessed, how do you audit what information was written? And having all these logs and monitoring of all of that. And you can also encode specific rules that your agent is going to be relying on, whether they are prompt or whether they are just deterministic workflows on what the agent can and cannot do. But, but at the end of the day, it’s going to come down to auditing every single action that is being taken by your agent and potentially having an agent auditing that audit logs to make sure that nothing wrong is happening. So in terms of permissioning and auditing and governance, we come down to the very similar type of processes. Just it’s going to be higher scale. So you will probably need to overlay additional information on top of that and potentially connect that to evaluation systems defining new rules, defining new constraints that are then being encoded into the agent. But the thing that is very important when we’re thinking about agents is they’re going to make mistake. And that’s the reality of things. It doesn’t matter if today we’re using LLM or tomorrow we’re using another generation of models, it is going to make model mistakes. But the same way humans make mistakes, we should just accept that there is an operational risk whenever these decisions are made. The thing that you gain by having agents running on top of that is that the speed at which you can solve these problems is much higher. And as long as you have a system that detects that there are mistakes the same way you detect them when a human is making a mistake, it’s a net positive because you will be able to fix them at an unprecedented speed.
