Your Data Isn’t Ready. Start Agentic Transformation Anyway.

I keep hearing the same thing from executives: “We want to build AI agents, but our data isn’t ready.”

I understand why. The data lives in dozens of systems. Nobody has catalogued it properly. Different teams use the same word to mean different things. There’s no consistent taxonomy, much less an enterprise ontology.

But when they ask their teams what “ready” would look like, the answer sounds like a multiyear transformation program.

As a CEO, should you wait for that program to finish before pursuing agentic AI?

No. Get started.

Your IT team is right when they tell you agents need reliable data and clear definitions. But you can establish those for a useful piece of work without first putting your entire data estate in order. Also, and this is exciting for me as a technologist, there’s an emerging architectural approach worth piloting that could reduce how much infrastructure your team must build along the way.

The conventional wisdom: do it usecase-by-usecase

The familiar advice still makes sense: pick a use case, clean up the data it needs, build an agent, demonstrate value, and repeat.

An investment team could start with an agent that compares a company’s latest earnings release with the assumptions in its investment thesis.

A commercial property insurer could start with an agent that assembles a renewal submission, property schedule, and loss history, then flags missing information for the underwriter.

Both are useful. Neither requires fixing every system in the company.

A warehouse such as Snowflake or a lakehouse such as Databricks may be the right foundation. Choose around the people who will use and maintain it, and the work they need to do. An organization full of SQL analysts has different needs from one with a large engineering team building models and processing data in code. That remains the useful principle from my earlier article on choosing data platforms.

Those people also have more help now. AI assistants can generate code and queries. Natural-language analytics tools can answer questions using business definitions and verified logic. Capabilities in Cortex and Genie illustrate the direction: users write less of the machinery themselves, while the organization still supplies the meaning.

Managed connectors like Fivetran can take care of much of the routine data movement, including synchronization and schema changes, reducing the integration work your team owns..

So yes, the conventional route remains viable. It is also getting easier.

But with easier creation, the bottleneck becomes judgment. Someone still needs to ask: Do we need another pipeline? Why do we have three definitions of exposure? Who owns this application after its creator moves on?

That is what I mean by taste: knowing what to build, what to reuse, and what to retire. Goldman Sachs is restricting the use of AI coding tools by non-coders after reviewing productivity and risk concerns. This illustrates the tension executives face as powerful development tools reach more employees. 

To reduce sprawl, I’d ask this question after the first successful project is: What have we made easier for the second one?

If the answer is “very little,” you have a looming problem, and will find yourself in the position that Goldman Sachs found themselves in.

Increase your ambition beyond isolated, useful agents

Think about why people connect an AI assistant to their email, calendar, messages, and documents. Each connection gives the assistant more context. Some of the most useful answers require several of those connections together.

Now apply that idea to your company.

The term in vogue is enterprise brain: shared enterprise context and capabilities that agents can use to find information, understand its business meaning, and take authorized actions.

You do not need one giant model or one central database. You need applications that can draw on shared knowledge and useful tools. You need an agentic mesh.

Take the investment example. Comparing earnings with a thesis is a good start. But the analyst’s actual question is bigger:

“Given today’s earnings release, market price, and news, does our investment thesis still hold?”

To help, the agent needs the original thesis, its assumptions, current evidence, and access to an approved valuation model. It could run scenarios and propose an update, showing the analyst which assumptions changed and why.

The property underwriter has a similar question:

“Should we renew these properties, and on what terms?”

The submission and loss history provide only part of the answer. The underwriter may also need updated valuations, inspection findings, catastrophe-model results, policy terms, and the insurer’s existing exposure in the region.

A property can look attractive in isolation and still add too much concentration to the portfolio. An agent that only sees the submission will miss that.

This is where connected context compounds in value. Portfolio exposure makes the property assessment more useful. The property’s updated valuation makes the portfolio assessment more accurate.

That benefit does not appear just because you connect more systems. You have to connect the meaning (which property, which valuation, which policy period, which definition of exposure?) and the tools (how to rerun the valuation analysis or update the property details with all the access control and security that this entails).

Still, the implication is clear. If every agent gets its own isolated data preparation project, you keep paying to solve the same problems—and you limit what those agents can do.

Pilot a Managed MCP Gateway

Alongside the conventional approach, I would test a managed data-access layer that exposes governed, task-specific capabilities through MCP, the Model Context Protocol.

The proposition, now being offered by several startups (including Obin), is worth investigating: connect to the systems you already have, let a managed service handle more of the integration and processing, and give agents useful tools without first undertaking a large platform-building program.

MCP standardizes how an AI application accesses tools and context. However, the service behind that interface must provide the data processing, access enforcement, and operational controls. The interesting development is that managed MCP gateways can take on more of this work. Published implementations describe discovering source structures, generating initial data products with metadata and lineage, and exposing them through governed interfaces. Users still configure requirements such as refresh schedules and quality rules.

At this point, I would expect every infrastructure team to object: “We built analytical platforms for a reason. We can’t have agents running expensive queries against production systems. Especially if the way that the caching and transformation work is opaque to us.”

Exactly. This is why I’m suggesting a pilot. We have successfully built managed MCP gateways over several systems of record, but it may not work for yours in the way that you use it. The pilot will establish where the processing happens, how the service protects source systems, what it caches or replicates, and how it handles freshness and failures. Some workloads might, as a result, still belong in a warehouse or lakehouse.

That creates a concrete hypothesis to test: Can we deliver this agent faster, with less integration code and less ongoing maintenance, while meeting our requirements for correctness, access, and performance?

Test the business task, not just the connection

For the investment pilot, connecting the research repository is easy to demonstrate. The meaningful test is whether the agent can retrieve the right thesis, identify changed assumptions, run a specified scenario, and produce a reviewable update.

For property underwriting, retrieving a policy record proves little. Ask the system to assemble a renewal exposure view across the relevant systems, identify unresolved discrepancies, and invoke an approved scenario model.

This is why task-specific tools are interesting.

A generic collection of source connectors can leave the agent doing a great deal of work: discovering schemas, finding records, matching identifiers, and combining results in its conversation.

A task-specific tool can perform that repeatable work server-side and return a defined result with sources, timestamps, and exceptions. The next agent can use the same capability. Task-specific MCP gateways have fewer tool calls and lower token consumption. In the pilot, measure your own tasks, including the total processing cost and the effort required to build and maintain the tools. 

I would not declare this the architecture of the future but I would give it a real workflow and find out. Wherever this architecture works, you will have dramatically sped up your agentic roadmap.

You still need domain expertise

When the investment team says “earnings,” does it mean reported, adjusted, trailing, or forecast earnings? When the insurer says “value,” does it mean replacement cost, insured value, or something else? A coverage limit is another concept again. Subject Matter Experts need to settle those definitions for the work at hand. They also need to decide what happens when information conflicts or is missing.

A managed service may operate the pipelines. Your organization still owns the judgment about whether the information supports the decision.

The same applies to actions. Drafting a thesis update is different from publishing it. Proposing renewal terms is different from binding coverage. Give the agent the authority the workflow requires, and make the review points explicit.

You can do all of this one use case at a time. You do not need to settle every definition across the enterprise first. Choose a real task. Establish the meaning and controls it needs. Build something useful. Evaluate the practical route to delivery, including a managed gateway pilot where it fits. Measure time to value, answer quality, source-system impact, operating cost, and maintenance effort. Ask what the next application will inherit.

Don’t postpone agentic transformation until your data estate is ready.