I've lost count of how many times I've sat in a room — virtual or otherwise — with a leadership team who say, almost word for word: "We need to move fast on AI agents this year. Our competitors are already doing it."
The ambition is genuine. The budget is usually there. What's almost always missing is the foundation underneath.
I see the same story across fintechs, manufacturers, SaaS companies, and consumer brands. Teams burn months and serious money on agent frameworks, vector stores, and prompt libraries — and then hit a wall the moment they try to push anything to production. The agents look brilliant in the demo. In production they hallucinate on stale data, quietly violate compliance rules, or degrade until someone notices the outputs are no longer trustworthy.
At Mohadata we don't build AI agents. We build the data foundations that make agents — and every other AI use case — actually reliable. After 30+ engagements and watching too many promising AI projects die in the gap between demo and production, we've developed a very specific way of thinking about this.
This is the blueprint we use.
Why "just add AI" keeps failing
Most organisations are trying to run AI agents on data infrastructure that was designed for 2018-era reporting. The patterns repeat:
- Data lives in silos with inconsistent definitions. One team's "customer" is another team's "client" and a third team's "user".
- Freshness is assumed rather than guaranteed. Agents pull data that's days old and nobody notices until a customer complains.
- Governance is theatre. Policies exist on paper; enforcement doesn't exist in the pipelines.
- Lineage is missing. When an agent gives a wrong answer, nobody can trace where the bad data came from.
- The platform was chosen for cost, fashion, or vendor relationship rather than fitness for purpose. Six months in, it becomes a maintenance tax.
The result is the AI projects everybody recognises — impressive in month three, expensive liabilities by month nine.
The companies actually succeeding with AI agents in 2026 aren't the ones with the cleverest prompts. They're the ones that did the unsexy work of building proper foundations first.
Our 5-phase methodology
We don't follow vendor roadmaps. We follow a process we've stress-tested and refined over five years of engagements because it works.
Phase 1 — Discovery & current-state audit
This is never as quick as clients hope. We map actual data flows (not the ones on the architecture diagram), test data quality on the most critical domains, and look for the places where governance claims don't match reality.
In a recent engagement with a regulated European fintech, we found that three different systems each held a different definition of "transaction status" — and the AI compliance agent they were planning to build would have been making decisions on conflicting data. That single finding changed the entire project scope.
Phase 2 — Strategy & target architecture
This is where we make the hard, custom decisions. What does "good enough" actually look like for this organisation? Do you need real-time streaming everywhere, or just for two or three high-value domains? Should the semantic layer be lightweight or heavy? Which governance controls are genuinely non-negotiable, and which are aspirational?
We are deliberately biased toward fit-for-purpose over fashionable. Sometimes that means a managed service. More often it means a custom orchestration layer or a purpose-built data contract system because the off-the-shelf option would create more problems than it solves.
Phase 3 — Foundation build
The heavy engineering phase. Ingestion, storage, transformation, and — most importantly — the governance layer that most teams leave until last and almost always regret.
We treat governance as infrastructure, not documentation. Data contracts live in version control. Quality rules run in CI. Lineage is captured automatically. Access policies are enforced at query time, not just at the warehouse boundary.
Phase 4 — Activation & AI enablement
Only once the foundations are solid do we open the platform for AI consumption. That means clean semantic interfaces that agents can discover, feature stores for consistent ML inputs, RAG-ready views with proper sourcing, and full audit logging so every agent decision can be explained and defended.
Phase 5 — Optimisation & continuous governance
The work that never really ends. We build feedback loops so the platform improves over time rather than slowly rotting. Governance isn't a project — it's an operating model.
The reference architecture we start from
Every client is different, but we almost always begin with a layered model that looks like this:
The governance layer is the one we refuse to compromise on. Everything else gets tuned to the client's actual constraints, risk tolerance, and team capabilities.
What this looks like in a real engagement
One of the more memorable projects in the last twelve months was a fast-growing AI SaaS company. They had raised a meaningful round on the promise of agents that could analyse customer behaviour in real time. Six months in, the agents were producing beautiful but unreliable outputs. The root cause was straightforward: their event data had no contracts, freshness SLAs were aspirational, and there was zero lineage.
We ran the five phases. By the end of week seven we had implemented version-controlled data contracts, automated freshness monitoring, and a lightweight semantic layer. Their first production-grade agent went live in week ten.
This pattern repeats across industries. The model is rarely the bottleneck. The data underneath it is.
Practical implementation details
Here's the kind of data contract we put into version control on almost every project:
contracts/dim_customer.yml
version: 2
models:
- name: dim_customer
description: "Single source of truth for customer entities"
config:
contract:
enforced: true
columns:
- name: customer_id
data_type: string
constraints:
- type: not_null
- type: unique
- name: email
data_type: string
constraints:
- type: not_null
tests:
- dbt_utils.not_empty_string
- name: created_at
data_type: timestamp
constraints:
- type: not_null
sources:
- name: customer_events
loaded_at_field: ingested_at
freshness:
warn_after: { count: 24, period: hour }
error_after: { count: 48, period: hour }Two things matter here. First, contract.enforced: true makes the schema part of the build — a column rename in upstream code now fails CI rather than silently breaking a downstream agent. Second, freshness is declared, not assumed. The same file that defines the table also defines what "fresh" means for it.
Alongside the contracts we deploy small, focused observability sensors. Nothing exotic — the point is that they exist, run on a schedule, and fail loudly:
sensors/freshness.py
from datetime import datetime, timedelta, timezone
from typing import Callable
class StaleDataError(RuntimeError):
"""Raised when a table has not been updated within its SLA."""
def check_table_freshness(
table_name: str,
get_last_update: Callable[[str], datetime],
max_age_hours: int = 24,
) -> bool:
last_update = get_last_update(table_name)
age = datetime.now(timezone.utc) - last_update
if age > timedelta(hours=max_age_hours):
raise StaleDataError(
f"{table_name} is stale: last updated {age} ago "
f"(SLA: {max_age_hours}h)"
)
return TrueSmall enforceable pieces compound. A platform with twenty contracts and ten freshness sensors is qualitatively different from one with none — even if every individual piece is unremarkable.
Where to start in the next sixty days
If you're not ready for a full engagement, you can still make real progress on your own. The shape of the work is roughly:
Weeks 1–2. Pick the single most important data domain and run a brutal honesty audit. Where are the definition conflicts? Where is freshness unknown? Where would governance fail an audit?
Weeks 3–4. Define and version-control data contracts for that domain. Start with the five to seven most critical fields. Enforce them in your pipelines.
Weeks 5–6. Add basic observability — freshness, volume, schema drift — and make the results visible to the teams that own the data.
Weeks 7–8. Build a minimal semantic layer on top. Expose it safely to your AI teams. Measure what changes.
Most organisations discover they're further behind than they thought. That isn't failure. That's the starting point.
A closing thought
The companies that will win with AI agents in 2026 aren't the ones chasing the latest model release. They're the ones doing the disciplined, custom foundation work that makes those agents reliable, auditable, and worth deploying.
Models keep getting better. The data underneath them is everyone's own responsibility.
Share this article
