In one sentence

Drift is the gradual decline in a workflow's quality as the world around it changes, even though nothing in the workflow itself was altered.

The simple model

You build a workflow, test it, and it works. Then, slowly, things change: the documents it reads, the process it supports, the format of its inputs, the behavior of the model or a connected system. Each change is small. None of them touch your workflow directly. But together they erode its accuracy.

The danger of drift is that it is quiet. There is no error message. The workflow keeps running and keeps looking fine, while being slowly, increasingly wrong.

Why you care

An agent that worked in March can be meaningfully wrong by September because:

  • source documents changed
  • the underlying process changed
  • input formats changed
  • a connected system or its integration changed
  • the model or vendor changed behavior
  • people started using the workflow in an unexpected way

None of these announce themselves. If nobody is watching, drift is discovered only when it causes a visible problem, by which point it may have been wrong for a long time.

How to guard against drift

You cannot stop the world from changing, so you detect drift rather than prevent it:

A small example

A classification workflow slowly got worse over months. Nothing had been changed. The cause was drift: customers had gradually started describing a new product in new terms the workflow had never seen. A scheduled test-set rerun caught the decline, and adding recent cases restored accuracy.

What this does not solve

Understanding drift tells you to watch for decline; it does not prevent the changes that cause it. Drift is a permanent condition of operation, not a bug to fix once. The response is ongoing monitoring and maintenance, owned by someone.