Translation means adapting AI to the operation a company already runs. Transformation means redesigning the operation around the software. A translation engagement takes one existing workflow, learns how it is actually performed, and builds an AI coworker that performs part of it inside the tools already in use. A transformation engagement asks the company to change how it works first, and treats the software as the reason to do so.
Why the distinction matters
A transformation engagement asks a company to absorb two risks at the same time: whether the AI works, and whether the new way of working is better than the old one. If the outcome disappoints, nobody can separate the two. A translation engagement isolates the first risk, which is the only one the AI is actually responsible for.
It also changes who has to change their behaviour. In a translation engagement, the coworker appears inside the CRM, inbox, or queue the team already works in, so the benefit arrives without anyone learning a new habit. That is not a nicety. Adoption is the most common point of failure in production AI, and the surest way to avoid it is to require nothing of the people the coworker is meant to help.
Signs an engagement has become a transformation project
The scope is a function, not a workflow
When the stated scope is a department, a quarter, or an operating model rather than one workflow with a defined output, there is no way to tell whether the AI worked. Nothing has a measurable before and after.
Someone has to change how they work first
If the workflow has to be redesigned before the coworker can perform it, the redesign is now the project. Sometimes that is genuinely necessary, and it should be named as its own piece of work with its own justification.
The deliverable is a new interface
A new dashboard or console means the team must go somewhere else to get the benefit. Work should surface where the work already happens: the record updated in the system they already open, the draft waiting in the inbox they already read.
When transformation is the honest answer
Sometimes a workflow is genuinely broken, and automating it produces a faster broken workflow. Three questions usually settle it: does the workflow have a defined output, could a capable new hire perform it from written rules, and is it repeated often enough to justify building and operating a coworker. If the answer to any of those is no, the problem is a process problem and should be solved with people before it is solved with software.
Read more in our blog: Translation, Not Transformation and How to Choose the First Workflow.