Agentic Data Integration: What It Is, Examples, and How It Differs From ETL
The short answer. Agentic data integration is an approach where an AI agent plans, builds,…
Foundation models know a great deal. What they do not know is your business: what you mean by a qualified opportunity, which metric finance treats as authoritative, how you handle a pricing exception, which system wins when two disagree. Context is the knowledge that closes that gap. This post is about the most common way enterprises are getting it wrong, and it is a mistake we have made before.
Around 2013 the instinct in enterprise data was to collect everything. Storage was cheap, Hadoop could land any file, and the logic seemed sound: we do not know which data will matter later, so keep all of it. The data lake came from that reasoning. So did the data swamp. Petabytes of data, duplicate tables with different transformations, feeds nobody could trace to an owner, and a business that had quietly stopped trusting the numbers. Governance and lineage arrived years later, at considerable expense.
The lesson was not “collect less.” Collection was never the expensive part. The lesson was that the value of information comes from knowing what it means, who owns it, whether it is current, and whether it can be trusted for the decision in front of you. We are about to run the same experiment one level up.
Look at the pressure on a CIO right now. The board wants an AI strategy. Every vendor sells “connect everything.” The demos that impress are the ones where an agent seems to know the whole company. The safe-feeling move is to index every document, capture every conversation, connect every source, and let the model sort it out.
Here is how that plays out. I will use one scenario through all three posts in this series, because the same task exposes the quality problem, the architecture problem, and the security problem.
Consider a B2B software company. A sales rep asks an AI agent whether she can approve a 12 percent discount for a strategic account that is up for renewal. The company built a knowledge hub for the agent: forty thousand documents, the full wiki, three years of Slack, several shared drives. The pilot demoed beautifully.
The agent answers with confidence. It cites a discount policy from a sales enablement deck, which is version 3. Version 4 replaced it in March and lives in the RevOps folder. It treats a 15 percent threshold someone floated in a Slack thread as policy. It applies an exception rule written for the EMEA segment to a North American account. Every sentence is fluent. The rep cannot tell which parts to trust, so she checks all of them with her manager, which takes longer than not asking. Multiply that by every rep and every question, and the pilot stalls within a quarter.
The model was fine. Nobody had decided what the model should know.
Right answer
Within threshold, routed for VP sign-off. Fine for this question. The next question needs the exception history, which is not here.
Confident, wrong
The model reconciles v3 and v4 without saying so, adopts the Slack threshold, and applies the EMEA rule. Fluent. Unverifiable.
Confident, wrong, and different each time
A paragraph from the board memo shows up because it was the closest match. The rep stops trusting any answer and checks everything with her manager.
Right answer, inspectable
Within threshold, routed for VP sign-off. Every input carries an owner, a version and a date. The rep can see what was used and why.
Illustrative scenario. The counts are indicative, not measured.
More context is not better context. The value of context comes from relevance, not volume.
This is the point where the swamp lesson gets misread, so let me be precise. The answer is not to stop capturing. Context accumulates every day in every team: in systems, in processes, in documents, in telemetry, and in people’s heads. It never stops. Capturing it continuously is cheap, and it is necessary, because the thing you did not capture is the thing an agent needs next week.
The swamp comes from two things that have nothing to do with volume. The first is context captured without provenance: no owner, no version, no validity date, no record of what it conflicts with. The second is context retrieved by similarity. The agent pulled the version 3 deck because it was the closest match to the question, not because anyone had decided it was authoritative.
So the hard question is not how much context to gather. It is this: given a task, what is the smallest useful set of knowledge to bring into it?
Every additional piece of context is another judgment call the system has to make. Is it relevant? Current? Authoritative? Does it contradict something else in the pile? Was it written for this geography, this customer, this point in time? As the pile grows, the model is not becoming better informed. It is receiving more signals it has to reconcile, and models are very good at reconciling. That is the danger. The agent never reported that the version 3 deck conflicted with version 4. It picked one and answered smoothly.
Context is task-specific in a way data is not. Take the same account and two people who need something from it.
The same rows serve both tasks.
What the analyst needs to interpret the rows.
What the rep needs to act on the rows.
Same company. Same account. Much of the same data. Different context. This is why one universal context, collected once and handed to every AI system, does not hold up. Plenty of knowledge can contribute: metadata, lineage, documentation, policies, conversations, prior decisions, human expertise. Its value depends entirely on the task.
Semantic similarity does not get you there either. A document can be closely related and still be the wrong one. A policy can be relevant and outdated. A prior decision can look identical and have been made under different circumstances. A context system has to understand the task, who is performing it, which systems and data are involved, what is authoritative, what has changed, and what should be left out. That list is a task model, and it is the subject of the next post. It is also, not by coincidence, exactly what you describe when you build a task-specific MCP server instead of one server per application.
Nobody comes to AI because they want context. They want to do something: approve the discount, understand why revenue changed, resolve a customer issue, have an agent complete a workflow across systems. Those tasks run on data. Context tells the system how to interpret it. Current ARR, the renewal date and the projected margin are data. The discount policy, the strategic account list and the exception history are the context that tells you what to do with them. A margin number without context is ambiguous. Context without the number cannot answer the question.
This has a consequence for where context should live. It cannot sit in a document index that never meets the data. It has to attach to the data objects and the tasks the enterprise already runs: the account record, the discount field, the approval workflow. Two companies running the same CRM, ERP and warehouse have entirely different context around how they operate them, and most of that context is already encoded in how those systems are configured, what their schemas mean, and what their workflows do. Documents are the supplement. The systems are the base. That is why we think the context layer belongs on the data layer, and the next post makes that case in detail.
Much of the most valuable context is not generic knowledge. It is accumulated know-how: why sales handles this account type differently, why operations distrusts one signal, why an exception is allowed for one customer and not another. As models commoditize, that context will not. It may become one of the most differentiated forms of IP a company has, and one of the most sensitive. That is the third post.
The big data era taught us that collecting information is not the same as making it useful. AI is a chance to apply that lesson early.
The goal is not the largest context repository. It is a system that delivers sufficient, reliable, task-specific context at the moment a task runs, alongside the data the task needs. That means being deliberate about three problems. Gathering: where knowledge lives, and how to capture it with an owner and a date attached. Organizing: authority, conflicts, freshness, provenance. Retrieving: exactly what a task needs, and nothing more.
If you are being asked to fund a context initiative, four questions are worth asking first. Those questions lead somewhere more interesting than “where should we store context?” The real question is how to build a context layer that understands enough about the task to know what knowledge matters.
Because if we get this wrong, the next great enterprise data swamp will not be made of data at all. It will be made of context.
This series. Part 1: Don’t Turn Context Into the Next Data Swamp (this post). Part 2: Building the Context Layer. Part 3: Context Is Enterprise IP.
Related. The Context Layer for AI Agents: Definition, Five Capabilities, and How It Works, The Future Is Not One MCP Server Per Application, and the Helix Context Layer.
What a context layer for AI agents is, the five capabilities that separate one from relabeled ETL, how it works at runtime, and a test for each capability you can run against any vendor.
Connectors are necessary and insufficient. A provider-blind buyer’s framework for building a context layer from multiple data sources: five capabilities beyond ingestion, a scoring rubric, TCO per source, where CDC fits, and a reference architecture.