AI services, shipped to production and measured.
Five AI practices under one engineering standard: agentic commerce readiness, operations automation, agent development, systems integration and consulting. Every build ships with an evaluation harness, guardrails and a known cost per interaction — because an AI feature nobody can measure is a liability rather than an asset.
Most AI programmes fail in the same place. The demo works, everyone is impressed, and then nobody can say whether the thing is getting better or worse, what it costs per use, or what happens when it is confidently wrong in front of a customer. The gap between a convincing prototype and a system you can leave running is engineering discipline, and that is the whole of what we sell.
DTN has built and operated commerce systems since 2005 — 200+ projects across four continents, with SAP-backed pricing and fulfilment logic across MASCOT Workwear's 20+ markets and TTI's 18 regional sites. That matters for AI work more than it sounds: almost every useful AI feature is an integration problem wearing a model as a hat. The hard part is the messy data and the system boundary, not the prompt.
This section covers the general-purpose AI work. If your question is specifically about commerce — a shopping assistant, semantic search, on-site personalisation — start at AI for e-commerce instead, or e-commerce automation for operational work inside the store. If you want to build the capability in your own team rather than buy an outcome, hire AI engineers.
Pick the one that matches the question you actually have.
Agentic commerce readiness
AI agents are starting to buy on customers' behalf. Making a store legible and transactable for them is new work: agent-readable product data, checkout that survives a non-human buyer, and a bot policy you chose on purpose.
Agentic commerce readiness →Automation of operational work
The recurring manual work that eats a team's week — triage, reconciliation, data entry between systems that will never be replaced. Deterministic where it can be, model-driven only where it must be.
AI automation agency →Agents that act, not chat
Agents with tools, permissions and an audit trail, scoped to a job with a definition of done. Including multi-agent designs where a single agent genuinely cannot hold the task.
AI agent development →Integration into what you already run
Models wired into your ERP, PIM, helpdesk and storefront through real API surfaces, auth, webhooks and fallback behaviour. Two decades of doing exactly this without the model.
AI integration services →Consulting that ends in a build plan
A short engagement that ranks your candidate use cases by value and feasibility, kills the ones that will not pay, and hands over a costed plan you could give to another supplier.
AI consulting services →Evaluation harness before feature
A golden set built from your own queries and records, scored automatically on every change and wired into CI as a release gate. It is what makes every later claim checkable — including ours.
How an engagement usually starts.
One call about the problem
Not a capability tour. What the work is, who does it now, what it costs, and what "better" would look like as a number.
An honest feasibility answer
Including "this does not need AI" — often the answer is better search, a fixed workflow, or fixing the data. We would rather say it in week one than bill for six.
Measurement first, then build
The first deliverable is the evaluation set and the cost model. Everything after that is checkable against it.
Ship, then hand over
Runbooks and architecture decisions in your repository as we go. The test of a supplier is whether your team can operate the thing without us on the call.
Our own standards, not client results we cannot show you.
Deliberately absent: percentage uplifts. We have not published an AI case study with a named client yet, so we do not quote AI performance numbers as if we had. Ask us what we have running and we will describe it precisely.
The stack.
Common questions.
Where should we start if we do not know which use case to pick?
With an assessment. It is a short, fixed-scope engagement that ends in a ranked shortlist and a costed build plan — deliberately structured so the output is useful even if you then hire someone else to build it.
How is this different from your e-commerce AI pages?
Scope. AI for e-commerce and e-commerce automation cover AI inside a store — assistants, discovery, merchandising, store operations. This section covers AI work that is not specific to commerce: back-office automation, agents, integration and strategy. Plenty of clients buy from both.
Do you have AI case studies?
Not published ones, and we would rather say that than imply otherwise. We have twenty years of published commerce case studies, including integration work — SAP-backed logic across MASCOT's 20+ markets, 13 country sites for Goodiebox, an automated customer-service workflow behind Endota Spa's booking platform. On AI specifically, ask on the call and we will walk you through what is running, with the client's permission where a name is involved.
Which models do you use?
Whichever fits the job, behind an interface. Claude and GPT for reasoning-heavy work, small or local models via Ollama and Qwen where cost, latency or data residency rules out an API. Committing a client to one vendor at the architecture level is a decision that gets expensive later, so we do not make it.
What does it cost?
We quote a target cost per interaction and a target volume of work removed before the build, then report against it. We do not publish percentage uplifts from other clients as a forecast for yours — the ones you see on agency sites are rarely comparable and never checkable. Model and infrastructure spend sits in your own accounts, so you see it directly rather than through our margin.
Commerce-scoped AI lives elsewhere on the site.
Bring the problem, not the technology.
Tell us what work you want removed or what decision you want made better. We will tell you whether AI is the right tool, and what measuring it would take.