DEV Community

Juan Pablo Enriquez Ortiz
Juan Pablo Enriquez Ortiz

Posted on

A Process Change Isn't Deployed When the Document Changes — Building DRIFTZERO with Gemini, Google ADK, Gemma & Google Cloud

#allthingsagentichackathon #gemini #gemma

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
Enter fullscreen mode Exit fullscreen mode

to:

TOP_RIGHT
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Gemma reports:

Observation: LEFT
Enter fullscreen mode Exit fullscreen mode

But Gemma still does not decide whether the change passed.

The deterministic Truth Engine compares the observation against the required operational state.

Result:

FAIL
Enter fullscreen mode Exit fullscreen mode

The worker sees:

Not done yet
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The Truth Engine evaluates it.

Result:

PASS
Enter fullscreen mode Exit fullscreen mode

The workflow now contains the complete chronology:

FAIL → PASS
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Only then does DRIFTZERO transition to:

PROOF_COMPLETE
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

https://youtu.be/d10dqIPcFHE

💻 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.

AllThingsAgenticHackathon

Top comments (0)