Digital Foundations
Digital Transformation Services — Systems Your Agents Can Safely Act On
A dashboard with a wrong number in it produces a bad slide. An agent with a wrong number in it produces a bad action, at speed, and then several more consistent with it. That is the whole change, and it is why data and integration work stopped being back-office hygiene the moment businesses started letting software act. A person reading a report discounts what looks off. An agent does not discount; it proceeds. Our digital transformation services exist to make the difference between those two situations measurable and monitored — and we run these checks on our own systems first, because our own delivery depends on them being right this week.
We run these checks on ourselves, because our loops act on the answers
Facet's engineering, content, reporting and quality reviews run through agent loops under human command. Those loops read our own data: our pipeline records, our project history, our analytics — and all three are documented down to which source each loop queries. When that data is wrong, the loops do not stop — they produce confident, fluent, wrong output, and they produce it faster than a person would have produced the right thing. So the checking is not something we sell and do not practise. It is an operating requirement we carry, and the monitoring described below is the monitoring that keeps our own delivery honest.
We have been at this longer than the agents have. In 2017 we built our own marketing intelligence pipeline on Singer and wrote up what it took, including contributing one of the first integration taps back to the ecosystem — because even then, getting one trustworthy view of our own numbers meant engineering rather than buying. What changed since is the consequence of getting it wrong.
- The checking is agent-carried, which is the only reason it can be continuous. Freshness, completeness, reconciliation between systems, schema drift and integration health are high-volume, mechanically checkable and almost always fine. That combination is what makes a person stop doing them properly by week three, and what makes them ideal for a loop.
- We name the failure modes. An agent asked to "fix the data" will helpfully deduplicate two records that were genuinely different customers, infer a missing field from a pattern that does not hold, and report success either way. Destructive operations go through a person with a rollback, always.
- Humans stay in command. Loops detect, reconcile and propose. A named person decides what counts as correct, which system wins a conflict, and what an agent is permitted to act on without asking.
- It is not a prerequisite phase, and we will not sell it as one. Nobody needs every system clean before anything can start. You need one domain trustworthy enough to act on, and the fastest route to knowing which domain that is takes weeks rather than quarters.
What actually goes wrong, in the order it goes wrong
The pattern is consistent and it is rarely dramatic. A company gets serious about automation, connects an agent to the CRM, and the agent queries records that are three months stale. It triggers a workflow that was never documented, only remembered. It reports on an outcome using a metric two systems define differently. None of that is a failure of the software. It is the environment being reported on accurately for the first time.
Bad data plus agents equals fast wrong decisions. That is the entire argument of this page, and the corollary is more useful than the warning: the bar moved. "Clean enough to report on" and "clean enough to act on" are different standards, and almost every business is sitting somewhere between them without knowing which side of the line each system falls on.
Four things determine which side you are on, and none of them is a framework:
- Whether the record is current, and whether anything tells you when it stops being current.
- Whether two systems that describe the same thing agree, and which one wins when they do not.
- Whether the process an agent would execute is written down anywhere other than in the head of the person who usually does it.
- Whether anyone would notice if an integration silently stopped passing records — which is the most common failure of all, because nothing errors.
What the loop actually does
These passes run continuously against your real systems. Each one is high-volume and pass-fail, which is exactly why they are worth automating and exactly why they get skipped when a person owns them.
- Check freshness and completeness where it matters. Not every field in every system — the specific fields an agent or a report actually reads, watched for staleness and for gaps, so "this record has not updated since June" is a flag rather than a discovery.
- Reconcile the systems that describe the same thing. Customer counts, deal values, hours, inventory — compared across CRM, finance, operations and analytics on a schedule. Every business has at least one pair of systems that quietly disagree, and the disagreement is usually a definition rather than a bug.
- Detect schema and integration drift. A field renamed upstream, an API version deprecated, a sync that returns success and passes nothing. This is the category with the worst signal-to-noise for humans — invisible until something downstream is obviously wrong — and the easiest for a machine to catch the same day.
- Watch the processes for divergence. Where a documented workflow and the actual event sequence stop matching, surfaced from the records themselves rather than from an interview. A process everybody routes around is data about the process.
- Track access and permission drift. Who and what can read or write each system, checked against what was agreed. Before you let software act on your behalf, the blast radius has to be a known number rather than an assumption.
What a person still decides
- What "correct" means for each metric. Two defensible definitions of "active customer" produce two defensible and contradictory numbers. Settling that is a business decision, and every downstream automation inherits it.
- Which system is the source of truth. When the CRM and the finance system disagree, one of them has to win by rule. That rule is a commercial judgment about which team's workflow bends.
- What an agent may act on unsupervised. The whole risk model lives in this line. Reading, drafting and flagging are cheap to get wrong; sending, deleting, charging and committing are not. Drawing it is your decision and we will argue for a conservative version of it.
- Which broken thing to fix first. A readiness assessment always returns more than anyone can address. Ranking it against commercial priority and engineering capacity is a leadership call, not a sort order.
- What is worth documenting at all. Some processes should be redesigned rather than recorded. Deciding which is which is the most valuable hour in this engagement and it requires the people who do the work.
What weak foundations cost — computed on your own numbers
We are not going to tell you what percentage of transformations fail or how many hours the average operations manager loses, because we would be making both numbers up. Here is the arithmetic that actually applies to you.
Action item, and it takes an afternoon: pick the single workflow you would most like an agent to run. Then answer four questions about it. Where does its data come from, and when did that source last update? Which two systems have to agree for it to be right, and do they? Is the process written down anywhere outside somebody's head? Would anything alert you if its inputs stopped arriving? Count how many of the four you cannot answer today.
That count is the real assessment, and it is more useful than a maturity score, because it is specific to the thing you actually want to automate. Zero unanswered means you can start on that workflow now. Three or four means starting there would produce confident wrong output — and tells you precisely what to fix, in a scope measured in weeks.
How could AI agents run this part of your business safely? Book the 45-minute agent-readiness review. Bring the one workflow you most want automated. We trace its data lineage with you, name where two systems disagree, identify what would fail silently, and you leave with a ranked remediation list with effort attached, a defensible answer on what an agent could safely act on today, and a written recommendation — including "this workflow is already clean enough, start it next month and do not buy a readiness programme" when that is what the trace shows.
What an engagement covers
Data trustworthiness
A measurement architecture your decisions — human or agentic — can stand on. That means a modern stack appropriate to your scale rather than to a reference diagram: analytics instrumented correctly, a transformation layer that defines your business logic once (we use dbt) so the same metric means the same thing everywhere, and the continuous checks above running against it. The goal is not more dashboards. It is that a number, wherever it appears, has one definition and a known freshness.
Integration and connectivity
Most companies do not have a tooling shortage; they have an integration shortage, and the cost of it is paid by people acting as middleware between systems that should be talking. We select, configure and connect so data flows without a human in the middle — and, because this is the layer that fails silently, we instrument the connections themselves. Our default is integration-first rather than replacement-first, and when a tool genuinely cannot connect or scale we will say so and explain why. We hold no vendor relationships that would bias that.
Process definition
Mapping how work actually moves through your business — the handoffs, decision points and exception paths — in a format people can refine and agents can eventually execute. Automating a broken process just produces broken outcomes faster, so this phase frequently ends in a redesign rather than a diagram. Documented processes are also auditable ones, which for clients in healthcare, legal and financial services is not optional.
The first supervised loop
The point of all of it. We take one workflow in the domain that is cleanest, put a loop on it under human approval, and let it run where a mistake is visible and cheap. That is worth more than a maturity rating, because it converts readiness from an opinion into an observation.
How engagements are scoped
From $6,000 for a readiness review and a targeted remediation sprint, through phased programmes for companies addressing several domains. Facet has done this work since 2014, was named a CIOReview Top 10 Digital Transformation Services Company in 2021, and fields a team of 40 across 9 timezones and 6 continents with a 500+ specialist network — so a dbt engineer, a CRM migration specialist or an integration developer joins the engagement for the weeks they are needed rather than being carried as overhead.
Where this work goes next
This is readiness work, and it is deliberately not a rung on the ladder — you do not have to finish it to start climbing.
- Agentic Engineering — the build layer. Agents that plan, build, check and improve under human command, once there is something trustworthy for them to read.
- AI Managed Services — the run layer. A named Facet team keeps the loops and the checks beneath them working as your data and goals move.
- Agentic Operating System — the whole operation run this way rather than one domain. Readiness work is what makes the second and third domains faster than the first, because the definitions are already settled.
- CRM and marketing automation — where the specific system in question is the commercial stack, the work has its own page and its own arithmetic.
The standard changed, and that is the opportunity
For thirty years the cost of imperfect data was a slide somebody argued with. Everybody knew which numbers to distrust, the distrust was institutional, and the business ran on human discounting of its own reports. It was expensive, and it was survivable, which is why nobody fixed it.
Agents remove the discounting. They act on what they read, exactly as read, at volume — which means the same imperfection that used to produce an awkward quarterly review now produces a hundred consistent decisions nobody sanity-checked. That is the bad news, and it is the reason this work became urgent rather than worthy.
The good news is in the same fact. The bar is not "clean everything" — it is "trustworthy enough to act on, in this one domain." That is a scoped, testable, weeks-long question with a definite answer, and answering it for one workflow tells you most of what you need to know about the rest. You do not need a transformation programme to find out. You need somebody to trace one workflow's data lineage with you and tell you honestly whether an agent could act on it — and if the answer is yes, to stop selling you readiness and start building the loop.
How could AI agents run this part of your business safely? Book the 45-minute agent-readiness review — no deck, no maturity scorecard. Bring the workflow you most want automated. You leave with its data lineage traced, the disagreements between your systems named, a ranked remediation list with effort attached, and a written recommendation you keep and can act on with anyone. If the honest answer is that the workflow is already clean enough and you should skip straight to building the loop, that is what the document will say.
FAQ
What does a digital transformation engagement cost, and what does it include?
The readiness review is a working session on one real workflow followed by a written trace, a ranked remediation list and a recommendation. Remediation is scoped from what the review finds — from a targeted sprint at the lower end of our $6,000+ range to a phased programme across several domains. We scope after the review rather than before it, because the honest number depends entirely on what the trace turns up.
Do we need to clean up everything before we can use AI agents?
No, and the framing is the problem. You need one domain trustworthy enough that an agent acting in it produces reliable output — in practice, current data in that domain, agreement between the systems it reads, one documented process, and monitoring that would notice if its inputs stopped arriving. That is a weeks-long scope, not a twelve-month programme, and it is why we start by tracing the workflow you care about rather than auditing everything you own.
Can you work with our existing tools, or will you push us to replace everything?
Integration-first by default. We evaluate what you have, how well it connects, and whether the gaps are addressable through configuration and integration or genuinely require a platform change. Most clients need integration work rather than replacement. When something truly cannot connect or scale, we say so and explain why — we hold no preferred-vendor relationships that create a bias toward replacement.
How is this different from a data warehouse project?
A warehouse project ends when the data is centralized. This work is about whether the data is trustworthy enough to act on, which is a continuous property rather than a delivered artifact — and it includes the process definitions and integration monitoring a warehouse project would consider out of scope. Warehousing is often part of the answer; it is rarely the whole of it.
What happens when the checks find something broken after we go live?
The loop flags it and the agent that depends on it stops rather than proceeding on bad input — that is the design decision that matters most in this whole service. A named person triages, and the remediation follows your priority order. Systems that fail loudly are the entire point; the failures that cost real money are the silent ones.

