A Process Change Isn't Deployed When the Document Changes
It's deployed when the work changes.
That sentence became the thesis behind DRIFTZERO.
Enterprises are very good at changing documents.
A policy gets approved.
A standard operating procedure gets updated.
A workflow changes.
A training email goes out.
A new version becomes the official version.
And yet, the person doing the work tomorrow may still execute yesterday's procedure.
That gap is what I call:
The last mile of operational change
And it's the problem I wanted DRIFTZERO to solve.
This article was created for the purpose of entering the All Things Agentic Hackathon.
🌐 Live application:
https://driftzero-web-eepb64ze2q-uc.a.run.app
🎬 Live demo:
https://youtu.be/d10dqIPcFHE
💻 Source code:
https://github.com/jpablortiz96/driftzero
The problem
Most enterprise change systems can answer questions like:
- Was the new procedure approved?
- Was the SOP published?
- Was training assigned?
- Was the workflow updated?
- Was the communication sent?
Those are important questions.
But none of them answer the one I care about most:
Did the real work actually change?
Imagine a packing procedure where the required label position changes from:
LEFT
to:
TOP_RIGHT
Updating the document is easy.
Sending the worker the new instruction is easy.
But what if tomorrow's package still has the label on the left?
The change exists in the system.
It does not yet exist in the real world.
That distinction became the foundation of DRIFTZERO.
Meet DRIFTZERO
DRIFTZERO is the autonomous last-mile for operational change.
Its core workflow is:
SOURCE CHANGE
↓
IMPACT
↓
ACTION
↓
FRONTLINE VERIFICATION
↓
CHANGE PROOF
Instead of stopping when a document changes, DRIFTZERO follows that change until there is evidence that the work itself changed.
A real end-to-end example
The public pilot uses a simple but deliberately physical scenario.
A packing SOP changes:
label_position
LEFT → TOP_RIGHT
A new live DRIFTZERO execution then begins.
1. Gemini understands the change
Gemini 3.5 Flash interprets the semantic difference between the previous and new procedure.
Change Intelligence proposes which operational artifacts may be affected.
But there's an important architectural rule here.
Agents propose. The Truth Engine decides.
The language model does not own operational truth.
It proposes.
A deterministic Truth Engine qualifies whether the proposed impact is allowed to proceed.
In the pilot, exactly one authorized target is selected.
2. DRIFTZERO takes scoped action
Once the impact has been qualified, DRIFTZERO applies the authorized remediation.
The worker does not receive the entire procedure again.
Instead, the frontline experience communicates only the delta:
YOUR WORK HAS CHANGED
Label position
Was:
LEFT
Now:
TOP RIGHT
That leads to another important idea behind the product:
Teach the delta, not the entire process.
For organizations managing frequent operational change, repeatedly retraining people on an entire process can create unnecessary cognitive load and operational overhead.
DRIFTZERO focuses on what actually changed.
3. Then we test reality
This is where DRIFTZERO becomes very different from a standard workflow automation or AI chatbot.
The worker submits physical evidence.
In the public pilot, I manually select a real photograph from my computer.
That image is sent through the live public application to the private backend.
Gemma, running through Vertex AI MaaS, performs a new inference.
The first photo shows the package label still on the:
LEFT
Gemma reports:
Observation: LEFT
But Gemma still does not decide whether the change passed.
The deterministic Truth Engine compares the observation against the required operational state.
Result:
FAIL
The worker sees:
Not done yet
And critically:
No Change Proof is generated.
The system refuses to call the change deployed.
4. The failed evidence is not erased
Now the worker corrects the physical work.
A second, different image is manually selected and uploaded.
This isn't a replay.
It isn't a cached PASS.
It isn't a special success endpoint.
It triggers another real Gemma inference against different image bytes.
Gemma observes:
TOP_RIGHT
The Truth Engine evaluates it.
Result:
PASS
The workflow now contains the complete chronology:
FAIL → PASS
The failed attempt remains part of the history.
DRIFTZERO doesn't rewrite reality just because the final state succeeded.
5. Only now is the change deployed
Once the corrected physical state passes verification, the Truth Engine evaluates the full completion contract.
In the current pilot:
7 / 7 conditions satisfied
Only then does DRIFTZERO transition to:
PROOF_COMPLETE
and generate a new Change Proof.
What is a Change Proof?
The Change Proof links the operational deployment together.
It includes information such as:
Source change
Affected artifact
Previous state → Current state
Frontline delivery
Verification chronology
FAIL → PASS
Completion timestamp
Proof ID
Content hash
This means the final result is not simply:
"The AI says this was successful."
Instead, there is a deterministic record tying together what changed, what action occurred, what was delivered, what was observed and why the system considers the deployment complete.
The proof includes a SHA-256 content hash calculated over canonical proof JSON.
The browser independently recomputes that hash and can display:
Content hash matches
A precision point matters here.
This provides content identity and integrity.
It is not:
- a digital signature
- an attestation
- a trusted timestamp
- non-repudiation
- a blockchain or ledger entry
Being precise about what technology does not prove is just as important as describing what it does.
The architecture
DRIFTZERO deliberately separates semantic intelligence from authority.
The system contains four specialized agent responsibilities:
Change Intelligence
│
▼
Remediation
│
▼
Frontline Enablement
│
▼
Field Verification
But authoritative decisions cross a deterministic boundary.
Conceptually:
┌─────────────────────┐
│ SOURCE CHANGE │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Change Intelligence │
│ Gemini │
└──────────┬──────────┘
│ proposal
▼
┌─────────────────────┐
│ TRUTH ENGINE │
│ deterministic │
└──────────┬──────────┘
│
┌─────────────┴─────────────┐
▼ ▼
Remediation Frontline Delta
│ │
└─────────────┬─────────────┘
▼
Physical Evidence
│
▼
┌─────────────────────┐
│ Gemma │
│ physical observation│
└──────────┬──────────┘
│ observation
▼
┌─────────────────────┐
│ TRUTH ENGINE │
│ FAIL / PASS │
└──────────┬──────────┘
│
▼
CHANGE PROOF
The architectural principle is:
Use models where ambiguity exists.
Use deterministic code where authority exists.
Why not let the model decide PASS or FAIL?
Because a language model is extremely useful for interpreting ambiguous information.
It is not where I want irreversible operational authority to live.
In DRIFTZERO, models cannot directly decide:
PASS
FAIL
PROOF_COMPLETE
authorization
workflow state
idempotency
supersession
proof generation
Instead, agents return constrained observations and proposals.
The Truth Engine owns authoritative transitions.
This dramatically reduces the blast radius of hallucinations.
Google Cloud architecture
DRIFTZERO runs as two Cloud Run services.
PUBLIC INTERNET
│
▼
┌─────────────────────┐
│ driftzero-web │
│ Cloud Run PUBLIC │
└──────────┬──────────┘
│
│ Google-signed identity token
│
▼
┌─────────────────────┐
│ driftzero-api │
│ Cloud Run PRIVATE │
└──────────┬──────────┘
│
┌─────┼──────────────┐
▼ ▼ ▼
Firestore Pub/Sub Gemini / Gemma
The public browser never receives backend credentials.
driftzero-web authenticates to driftzero-api using Google service identity.
The operational API remains protected by Cloud Run IAM.
The Google stack
Google ADK
Used for agent orchestration and the agent execution model.
Gemini 3.5 Flash
Used by Change Intelligence to understand semantic process changes.
Gemma on Vertex AI MaaS
Used for multimodal physical-world observation.
Gemma reports what it sees.
It does not own the verdict.
Cloud Run
Two-service deployment:
driftzero-web → public experience
driftzero-api → private operational API
Firestore
Stores durable workflow and session state.
Pub/Sub
Supports authenticated event ingestion and bounded dead-letter handling.
Google Cloud IAM
Keeps the operational backend private and provides server-to-server identity.
The public pilot is actually live
The hosted application isn't a gallery of screenshots.
From an unauthenticated browser, a visitor can:
RUN LIVE PILOT
↓
real Gemini inference
↓
receive the real delta
↓
upload a physical image
↓
real Gemma inference
↓
FAIL
↓
upload a second image
↓
new Gemma inference
↓
PASS
↓
7 / 7
↓
new Change Proof
The two uploaded pilot images contain different bytes, produce different verification events and generate two independent model calls.
The final workflow preserves:
verification #1 → FAIL
verification #2 → PASS
inside the same durable workflow.
Try it here:
👉 https://driftzero-web-eepb64ze2q-uc.a.run.app
Security still matters in a public pilot
Making the pilot publicly accessible did not mean making the backend public.
The browser cannot supply:
arbitrary prompts
model parameters
expected observations
PASS / FAIL
workflow IDs as mutation authority
proof results
The source change is server-controlled.
Uploads are bounded.
Image MIME type is detected from the actual bytes.
A short-lived capability is bound to one workflow.
The backend remains private.
This creates a narrow public action surface instead of exposing a generic AI API.
Durable execution matters more than LLM memory
One of the more interesting lessons from building DRIFTZERO was that durable agentic systems need much more than “memory.”
For a real operational workflow, persistence has to include concepts such as:
business state
agent session state
invocation identity
action execution identity
idempotency
verification chronology
proof conditions
Otherwise, restarting a process can result in duplicated work or inconsistent truth.
DRIFTZERO treats failure and recovery as part of the architecture rather than exceptions added later.
Business value
The product thesis is not that AI magically eliminates change-management cost.
The opportunity is more specific.
DRIFTZERO targets areas like:
unnecessary full-process retraining
manual change follow-up
stale-procedure rework
slow operational adoption
field drift
audit evidence collection
operational risk exposure
An illustrative operating model might look like:
10,000 workers
× 8 operational changes per year
× 20 minutes of unnecessary full retraining
= 26,667 workforce hours exposed to retraining
That is an illustrative modelling exercise, not a measured customer result.
The broader value equation is:
Annual Value Opportunity
=
Avoided Retraining
+ Avoided Rework
+ Reduced Follow-up
+ Avoided Change Incidents
+ Audit Efficiency
The core thesis remains simpler:
Teach the delta. Verify the reality. Prove the deployment.
What I learned building it
Three lessons stood out.
1. Agentic doesn't mean giving the model unlimited authority
Agents become more useful when their authority boundaries are explicit.
The goal is not autonomy at any cost.
The goal is safe, useful autonomy.
2. Observing reality and deciding truth are different responsibilities
Gemma can interpret a physical image.
The Truth Engine can decide whether that observation satisfies an operational requirement.
Keeping those responsibilities separate makes the system easier to reason about and audit.
3. A workflow isn't durable just because the database is durable
Execution identity, idempotency, action state and verification chronology matter too.
Agent architectures need to survive process replacement without blindly repeating side effects.
Current status
DRIFTZERO is a working cloud pilot.
The current public release includes:
real Gemini inference
real Gemma multimodal inference
Google ADK
Cloud Run deployment
private operational backend
durable Firestore state
authenticated Pub/Sub
manual physical evidence upload
FAIL → PASS retry chronology
Change Proof
public source code
reproducible setup
1,999 passing automated tests
The project deliberately does not claim full enterprise production readiness.
Some enterprise platform capabilities require organization-level prerequisites that were unavailable in the hackathon environment.
Rather than simulate them, those limitations are documented publicly.
Try DRIFTZERO
🌐 Live application
https://driftzero-web-eepb64ze2q-uc.a.run.app
🎬 Live demo
💻 GitHub
https://github.com/jpablortiz96/driftzero
Closing thought
Most enterprise systems can tell you:
“The procedure changed.”
I wanted to build something that could answer a harder question:
“Did the work change?”
That's DRIFTZERO.
The autonomous last-mile for operational change.
This article was created for the purpose of entering the All Things Agentic Hackathon.
