Michel Tricot, CEO and co-founder of Airbyte, has spent years solving some of the hardest problems in data ingestion, the unglamorous plumbing that decides whether an AI application works in production or falls apart under load. Most of what he sees now is the same plumbing failing in a new way, breaking reliably once real agent workloads arrive.
On a recent episode of the Dev Interrupted podcast, Tricot walked through where agentic systems succeed or collapse, and the answer is almost always the data underneath them. You are what you eat, and an agent is what it reads. What follows is a tour of the data reality teams now live in, from ingestion to permissions to context.
The data ingestion crisis breaks AI agents in production
"There is a crisis on data access," Tricot says. Data access has been a hard problem for as long as computers have existed. What changes in an agentic world is scale and speed, the ability to automate a task and run it faster than any human could.
The standard model still holds, and ETL into a warehouse with analytics on top remains valid. But agents introduce a wave of new use cases where one application talks to another and the agent starts behaving as an entity that becomes self-sufficient. At that point the real issue is control. Teams have to understand who is accessing the data, at what pace, and what operations they can perform. That governance problem is settled for people and unsolved for autonomous software.
The deeper shift is one of trust. "Normally you expect some human judgment, but now suddenly you have to trust agent judgment," in Tricot's words. The companion question is when the agent should hand a decision back to a human. Alongside that sits a live-access requirement that historical tables never covered. Agents need databases, and they need SaaS services, internal APIs, and internal services in real time. Without a solid semantic layer and clean data models underneath, agents inherit the messy, unreconciled data that has always plagued analytics teams, and they act on it at machine speed.
AI agent data infrastructure demands entity resolution
The more systems an agent connects to, the more intelligence the infrastructure needs to map the same entity across them. A support ticket, a payment record, and a row in a product database can all describe one customer, and nothing in the raw data says so. A human exercises judgment to make that link. Autonomous software cannot, so the logic that governs those links between systems has to be discoverable rather than hand-carried.
Ideally, entity resolution is self-learning. The agent discovers weak connections across silos, decides that two records are likely the same, and logs the match over time. That linkage is the load-bearing layer that lets an agent trace a customer or a feature across Jira, Zendesk, and a product database as one coherent story.
Every agent data problem is a search problem
Every data problem an agent has reduces to the same shape, a search problem. RAG is one instance, unstructured text that has to be indexed before it can be retrieved. Structured records are another. A payment ledger becomes one the moment an agent needs every transaction of a specific amount.
The obstacle is that many systems offer no search primitive at all. A call-recording platform with no search forces an agent to page through transcript after transcript before the relevant one turns up, and a payment provider with no amount filter cannot answer the question at all. That gap sets up a commercial question the vendor world has not resolved. Providers can open their data, charge for access, or keep it inside a walled garden and sell their own retrieval agents. Salesforce, HubSpot, and Gong each face the choice between shipping real search and telling customers to run their agents on the vendor's platform.
ETL is the hedge against whichever way that goes. Loading data into a place where processes can be built on top of it, for search or for analytics, keeps the answer in the company's hands. The same logic explains why warehouses outlast opinionated platforms, which fall through the moment a company's attribution or tracking deviates from the vendor's model of the world. Tricot is direct about it. "You will need an escape hatch, and your escape hatch is the raw data."
Agent permissions and access control require built-in escape hatches
Building an agent is a learning process. A team lets it roam relatively free at first, watches what it reaches for, then narrows the perimeter to the golden path the work needs. A tight perimeter without a feedback loop is dangerous, because the agent has no way to signal that it has hit a wall. Tricot's design gives the agent a way to work out that a system sits outside its boundary and to say so in plain terms, naming the system it cannot reach and why it believes that system is relevant to the task.
Without that mechanism, a blocked agent goes looking for a way around the block. Reported incidents of agents breaking out of a sandbox to reach outside services are a symptom of exactly this. Wall off the internet and every adjacent system without the right boundaries in place, and the model finds an exit and causes damage. The healthier design stops blocking on the first iteration and starts listening, so the team gets feedback from the agent about what is missing.
Metadata about what systems exist should stay visible even when the underlying data does not. An agent that can see a registry of available systems can make its case. Blocked from Salesforce but asked about sales results, it can reason that it probably needs Salesforce and request a grant, perhaps a temporary one. The parallel to a human employee is exact. "I don't have access to a specific report, but I need it to do my work," as Tricot puts it, and the next move is to ask the platform's admin for access rather than to improvise around the gap.
An agent that cannot see the boundary deviates into extremes trying to solve the problem blind. What the ingestion crisis demands is a specific investment, "this documentation and registry of what is available, what it can be used for, what type of data is available inside." The ultimate goal is an entity that performs a task with as little limitation as possible, and no team knows on day one what its agent will need. The registry is what lets the next iteration be better than the last.
Context sprawl in AI agents demands precise, on-demand retrieval
Every new system an agent connects to adds another layer of context on top of an operator's workflow, a higher order of information about all the tools a team already uses. That richness carries its own risk. The more context available, the stronger the pull to load all of it, bloating the window with records the task never needed.
Avoiding that comes down to how accurate the data is for the task at hand. The same problem surfaced with MCP, where early clients pulled every available tool into the context and bloated it before the work began. The fix was to stop loading everything and start searching for the tools that mattered to the task.
Precision means discovering data step by step rather than in bulk. A request for the lifecycle of a customer on a specific feature sends the agent through a discovery phase, first identifying the feature, then the Jira item it maps to, the Zendesk ticket that mentions it, and the customer that filters it. That path keeps the context lean, relevant, and accurate. A strong semantic layer does the same work upstream, encoding company definitions and business rules once so agents do not re-derive them on every query. Skills can carry specific rules and tables too, though they remain unpredictable enough to leave an open question about whether to review a generated query before it runs or let the skill execute directly.
Data becomes a productivity tool once the wall comes down
The through-line across all of this is that data has always been bottlenecked on teams treated as cost centers, slow to grow and running their own roadmaps. When a question takes a query, a queue, and a specialist, most questions never get asked, and the follow-up questions that carry the real insight never get asked either. When the wall between the raw data and the person asking comes down, the perception flips. "I think data is going to become more accessible as a productivity tool," Tricot says. A leader can then justify a decision by having gone deep into the analysis rather than delegating it and waiting.
ROI on the agent shift does not arrive in a six-month window, any more than the move to cloud paid off through a lift and shift. Tricot points to that earlier migration, where nothing was really lift and shift because the whole cost model moved from CapEx to OpEx, and the move to agents asks for the same rethink of how a company builds and operates. Airbyte's own Hydra project, which automates connector maintenance, measures value in connectors per engineer, a ratio that climbed from one-to-one toward broad automation as the team built abstractions around it. Each step makes the next one easier, and the gains land only as fast as a team can tame the technology underneath them.
Michel Tricot goes deeper on the data ingestion crisis, agent permissions and access control, and context sprawl in AI agents on the full episode of the Dev Interrupted podcast.
