Everyone Has AI. Applying It In The Enterprise Is The Hard Part.

Introducing Applied Intelligence, one of Data Domain's three practice pillars.

Two years ago, the hard part was getting access to a good LLM model. That problem is gone. Most organisations we work with have a frontier model, an enterprise agreement, a handful of people building things, and a growing library of prototypes that impressed everyone in the demo and then quietly stopped.

The gap is no longer capability. It is application. McKinsey put the number at 6% of businesses actually realising value from AI. Deloitte found only around one in five have a governance model mature enough to monitor autonomous agents. Both numbers describe the same thing: the distance between something that works in a notebook and something a business can depend on.

Applied Intelligence is the practice we built to close that distance: the process mapping, architecture, evals and staged rollout that take an agent from a demo to something a business can depend on.

The prototypes are real. So are the problems.

We build AI solutions across a deliberately wide range of use cases, because the pattern of what breaks is consistent:

• Conversational discovery over a large media catalogue. A user asks for "street dancing shots from 2025" in plain language and gets the twelve right assets instead of 114,000 search results.
• Automated CRM intelligence. A scheduled model executes a daily news aggregation, checks relevance against our CRM, and sends updates and alerts out to the sales team.
• Churn prediction with an agent that acts on it. A model scores a quarter of a million customers nightly. An agent then picks up the highest-risk accounts, checks the commercial rules, and drafts a retention offer for a human to approve and send.
• AML and financial crime detection. A model ranks transaction monitoring alerts by genuine risk rather than rule-hit count, cutting the false positive load.

Every one of these works in a controlled environment. Three things stop them reaching production.

Accuracy falls over. Model accuracy that sits at 85% in testing routinely lands nearer 60% on real traffic, because production is where the edge cases live. In our own image-scoring work the first versions hallucinated confidently about images the model had barely processed. That is a system design failure, not a model failure.

Costs run away. Few teams budget for an agent that loops fourteen times, burns thousands of tokens and returns a confidently wrong answer. Token spend stays invisible until it is material, and by then the CFO is asking questions the team cannot answer.

Write-back is not trusted. This is the real ceiling. Reading is easy. Writing back to the CRM, the ERP or the core banking system is where the value sits, and it is where most organisations stop. Native agent write-access is now generally available inside Salesforce, HubSpot and ServiceNow, which makes it easy to grant and easy to regret. The moment an agent advances an opportunity stage incorrectly, eleven downstream processes read that mistake.

The honest position: agentic write-back to systems of record is happening, but it is happening carefully, in stages, with a human on the approval.

Start with the process, not the model

The single biggest predictor of whether an AI project reaches production is whether anyone documented the process it was meant to improve.

We start with workshops. Not model selection, process mapping. Where does the work actually go? Where are the handoffs, the queues, the rework loops, the manual reconciliations, the four-day wait for an approval that takes ninety seconds to give? We document the current state with error rates and cycle times attached, because that baseline is what benefit realisation is measured against later. Without it you cannot prove anything.

Only then do we design the target state: which steps become deterministic automation, which need reasoning, which agents hand off to which, where the integrations sit, and which model is right-sized for each step. A cheap, fast model does the high-volume fact gathering. A reasoning model does the policy and compliance check. A cheap model drafts the output. That single decision routinely halves token cost.

A note on tooling

There are a number of different tools on the market that can help with process and model orchestration. Here are some of the ones we like:

• n8n is a workflow automation tool: a visual canvas where you wire triggers to actions across systems, with an LLM available as one node among many. It suits fast internal automation built by people who are not full-time engineers.
• LangChain is a developer framework: a Python or TypeScript library for building agents in code, with abstractions for tool calling, memory and retrieval. It suits bespoke agent logic that needs version control and tests.
• Workato sits further up the enterprise stack, adding governed connectors, role-based access and human approval routing into Slack or Teams, with every action logged and traceable. It suits regulated environments where each write must be attributable to a named identity.

Most production systems we build use more than one of these.

The staged rollout we recommend is straightforward:

1. Read-only. The agent retrieves context and recommends. Humans execute. Low value and low risk, but it proves the integration, the authentication and the audit trail.
2. Propose and approve. The agent drafts the write and a human approves it. The permission model and validation logic get exercised in real conditions.
3. Shadow mode. The agent proposes every write to a diff log while humans do the real work. Two weeks of this tells you the agent's actual precision on your data, not a vendor's benchmark on theirs.
4. Bounded autonomy. Low-risk fields write automatically. Anything touching revenue, forecast or a regulated record still needs a human.

Most organisations should be at stage two or three today. That is not a failure of ambition. It is how trust gets built.

Architecture and model governance: MCP as a translation layer

Here is the technical decision that made the biggest difference to our own accuracy numbers.

Early agent designs let the model reason directly against raw tables and API schemas. It half-worked. The model had to infer what orders.total_amount meant, which of four customer tables was authoritative, and whether "active" meant logged in this month or holding a live contract. Every one of those inferences was a chance to be wrong.

We moved that knowledge into a semantic layer and exposed it through MCP, the Model Context Protocol, as a governed set of described tools. Entities, relationships, metric definitions, business rules and access permissions are defined once, in one place, and the agent calls a tool rather than writing its own SQL. In our eval monitoring, accuracy on business questions moved from around 70% to around 95%. Nothing about the model changed. What changed was that we stopped asking it to guess.

MCP is also the right place to put the write-back controls. A write tool is a single stored procedure with least-privilege grants attached, not open table access. The tool description is effectively the agent's entire API surface, so it gets written and reviewed like an interface contract.

We deploy this two ways depending on where the data lives.

Snowflake-native. Snowflake's managed MCP server exposes semantic views, Cortex Search services and stored procedures as MCP tools directly, and Cortex Agents and MCP servers in Native Apps went generally available in August 2026. The advantage for regulated clients is clear: no data leaves the Snowflake boundary and the existing role model does the access control. Where we need arbitrary compute or a custom dependency, we host the server in Snowpark Container Services instead.

AWS. For clients whose systems of record sit outside the warehouse, we build a custom MCP server and deploy it on ECS Fargate behind API Gateway, with mTLS for service-to-service authentication, IAM roles rather than shared keys, and VPC egress rules that only permit traffic to approved model endpoints. Every tool call is logged. Write actions carry action-level authorisation separate from read access.

Neither of these is exotic. That is the point: boring, auditable infrastructure, which is exactly what a risk committee needs.

Evals: the discipline nobody wants to fund

If you cannot point to the eval set that caught your last regression, you do not have evals.

Our approach is consistent regardless of use case:

• Define what good looks like before building. Success criteria come from the business, not the data science team. In the image-scoring work that meant ten binary attributes across technical quality, composition, emotional impact, peak action and brand fit, each worth a point, ten points maximum.
• Build a golden dataset. A hundred real examples with human labels beats a thousand synthetic ones. This is where subject-matter experts earn their place in the project.
• Run multiple graders. We typically use three types. A deterministic grader checks structural rules: valid JSON, correct schema, internally consistent scores. A model-based grader checks reasoning quality. Our visual grounding grader re-examined the source image and compared it against the justification the model gave, passing 97% of the time and catching the cases where the model was confabulating. A human-agreement grader measures how often the model's decision matches the expert's.
• Calculate the final answer deterministically. Models violate their own scoring rules. We let the model produce the evidence and the weights, then compute the score in code. Hallucination risk drops immediately.
• Calibrate the distribution. Our first version marked far too many images as keepers. Forcing an explicit target distribution, roughly 5% scoring 9 to 10, 15% scoring 8 and most in the middle, produced output that matched editorial judgement.
• Version, gate, repeat. Prompt versions are tracked. The suite runs on every change. Failures in production become new test cases. Monitored KPIs include score distribution, grader pass rates and human-agreement rate over time.

The tooling landscape here is unsettled and clients should know it. OpenAI announced in June 2026 that it is deprecating both its hosted Evals platform and Agent Builder, with read-only from 31 October 2026 and shutdown on 30 November, pointing users toward Promptfoo, which OpenAI acquired in March. Anthropic went the other way, hiring the Humanloop founding team after that platform sunset and folding evaluation into its Console alongside some of the better public writing on agent evaluation. Braintrust, LangSmith, Langfuse, Arize Phoenix, DeepEval and Ragas each serve overlapping slices of the problem.

Keep your eval cases, rubrics and thresholds portable, in your own repository, in files you control. Treat the runner as replaceable.

The durable asset is the golden dataset and the grader definitions, not whichever vendor is hosting them this quarter. Most serious teams run an open framework in CI plus one observability platform, and that is a reasonable default.

Decision science: dashboards still matter

There is a fashionable argument that agents make dashboards obsolete. We disagree.

Executives need a single source of truth they can point at in a board pack. Auditors need a number that reconciles. Regulators need a definition of "compliance rate" that has not quietly changed between reporting periods. Management reporting is not a legacy artefact. It is the mechanism by which an organisation agrees on what is true.

The interesting shift is that the semantic layer now serves both audiences. The same metric definitions that power the dashboard are the ones the agent calls through MCP. Define churn once and the number in the board pack matches the number the agent reasons about. That alignment is worth more than any individual dashboard.

We are pleased to be partnering with Sigma here. Sigma's native connection to Snowflake means analysis happens where the governance already sits, with a spreadsheet-style interface that finance and operations teams adopt without a training programme.

Data science: the biggest opportunity, and the cheapest

If we could move client budget from one place to another, it would be from generic AI experimentation into applied machine learning.

Prediction is where the compounding value sits. Knowing which customers will churn next quarter, which invoices will go bad, which assets will fail, which alerts are genuine, and then acting on it automatically. Our recent churn work reached an AUC around 0.88 on a customer base of roughly a quarter of a million, enough signal to make a retention programme economically rational.

There is a cost argument here that gets overlooked. Scoring 250,000 customers with a gradient-boosted model costs a few cents of warehouse compute. Doing the same reasoning with an LLM, per customer, costs orders of magnitude more and is less accurate at exactly this kind of structured prediction. Use ML for the prediction. Use the language model for what it is uniquely good at: reading unstructured context, drafting the outreach, and explaining the recommendation to the person who has to act on it.

That combination is the architecture we keep returning to.

The model predicts. The agent proposes. The human approves. The evals watch. The KPI moves.

Where to start

Most organisations we speak to have already spent heavily on data foundations: a warehouse migration, a governance programme, a platform rebuild. That investment is necessary, but it does not pay for itself. Applied Intelligence is where the return on it shows up.

If your foundations are in place, we recommend starting with two proofs of value run together: one machine learning model and one AI workflow. The model proves you can predict something the business cares about. The workflow proves you can act on that prediction without breaking a system of record. Run separately they are experiments. Run together they are an operating pattern you can repeat.

Starting points by sector:

• Financial services. Churn or attrition scoring feeding a next-best-action workflow. Or AML alert triage: a model that ranks alerts by genuine risk, with an agent assembling the case pack for the analyst.
• Logistics. Delay and ETA prediction feeding an exception-handling workflow that reschedules, updates the booking and notifies the customer before they call.
• Utilities and telco. Asset failure prediction feeding a fault triage and dispatch workflow, in the same spirit as the operational work we've done with One NZ. Or usage-based contract optimisation, where an agent identifies under-optimised accounts and drafts a better plan before the customer shops around.
• Retail. Demand forecasting feeding automated replenishment and markdown decisions. Or returns fraud scoring with an agent-assembled case for the investigations team.

The engagement pattern is deliberately short: a two-week discovery to capture the process, the semantic layer and the value case, then four to six weeks to deliver both proofs of value against explicit targets. Cost per task, cycle time and error rate, all measured against the baseline established in week one.

If your organisation has more prototypes than production systems, that is the normal state of the market right now. It is also a solvable problem.‍

Talk to us today or discover more about our Applied Intelligence service.