DRIFTZERO
The autonomous last-mile for operational change.
A process change isn't deployed when the document changes.
It's deployed when the work changes.
🌐 Run the live pilot
🎬 Watch the live demo
💻 Explore the source code
Inspiration
Enterprises are extremely good at changing documents.
A policy gets approved.
A standard operating procedure gets updated.
A workflow changes.
Training is assigned.
A communication is sent.
And yet, the person doing the work tomorrow may still execute yesterday's procedure.
That gap became the inspiration for DRIFTZERO.
I kept coming back to one question:
How do you know an operational change actually reached reality?
Most enterprise systems can prove that a document was changed, approved, distributed, or acknowledged.
But those signals do not prove that the work itself changed.
I wanted to build an agentic system that would not stop at:
"The procedure changed."
It would continue until it could answer:
"The work changed — and here is the evidence."
That is the last mile of operational change.
And that is what DRIFTZERO is designed to close.
What DRIFTZERO does
DRIFTZERO turns an operational change into a verified deployment:
SOURCE CHANGE
↓
IMPACT
↓
ACTION
↓
FRONTLINE VERIFICATION
↓
CHANGE PROOF
The system combines autonomous agents for semantic work with deterministic software for authoritative decisions.
The core architectural principle is:
Agents propose. The Truth Engine decides.
Models are used where ambiguity exists.
Deterministic code is used where authority exists.
The live scenario
The public pilot uses a deliberately simple physical example.
A packing procedure changes:
label_position
LEFT → TOP_RIGHT
The important question is not whether the new SOP contains TOP_RIGHT.
The important question is whether the next physical package actually follows it.
1. Gemini understands the change
A fresh public pilot creates a new workflow.
Gemini 3.5 Flash analyzes the semantic change and Change Intelligence proposes which operational artifacts may be affected.
The model does not directly authorize a modification.
The deterministic Truth Engine evaluates the proposal and qualifies exactly one authorized target.
This is the first important authority boundary in DRIFTZERO.
2. DRIFTZERO takes scoped action
Once the target has been qualified, DRIFTZERO performs the authorized remediation.
The frontline worker then receives only the operational delta:
YOUR WORK HAS CHANGED
Label position
Was:
LEFT
Now:
TOP RIGHT
Instead of forcing someone to relearn an entire procedure, DRIFTZERO focuses on what actually changed.
Teach the delta, not the entire process.
But even at this point, DRIFTZERO does not consider the change deployed.
The instruction changed.
Reality still has to be verified.
3. The worker submits physical evidence
From the public application, a physical photograph is manually selected and uploaded.
The actual image bytes travel through the public Cloud Run application to the private operational backend.
Gemma, running through Vertex AI MaaS, performs a new multimodal inference.
For the first photograph, Gemma observes:
LEFT
But Gemma does not decide whether the operation passes.
It only reports what it observes.
The deterministic Truth Engine compares that observation against the required operational state.
Result:
FAIL
The frontline worker sees:
Not done yet.
No Change Proof is generated.
The system refuses to pretend the change has been deployed.
4. The worker corrects reality
The worker then submits a second, different physical image.
This is not a replay.
It is not a cached result.
It is not a special success endpoint.
The second file contains different bytes and triggers a new Gemma inference.
Gemma now observes:
TOP_RIGHT
The deterministic comparator evaluates that observation.
Result:
PASS
Both attempts remain attached to the same durable workflow.
The history becomes:
FAIL → PASS
The failed evidence is not erased simply because the final attempt succeeded.
5. Only now is the change deployed
After the successful field verification, DRIFTZERO evaluates its full completion contract.
In the current pilot:
7 / 7 conditions satisfied
Only then does the workflow reach:
PROOF_COMPLETE
and generate a new Change Proof.
Change Proof
A Change Proof ties together the operational deployment.
It contains information including:
source change
affected artifact
previous state → current state
frontline delivery
verification chronology
completion timestamp
proof ID
content hash
The important part is that the final result is not:
"The AI says it succeeded."
The proof connects what changed, what action occurred, what was delivered, what was physically observed, and why the system considers the deployment complete.
The public proof surface independently recomputes a SHA-256 hash over canonical proof JSON and verifies:
Content hash matches
That hash 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 a system does not prove is part of building trustworthy infrastructure.
How I built it
DRIFTZERO is intentionally split between semantic intelligence and deterministic authority.
Four specialized agent responsibilities
Change Intelligence
Understands unstructured operational changes and proposes what may be affected.
Remediation
Operates only inside a scoped, authorized mutation boundary.
Frontline Enablement
Turns the approved change into a concise worker-facing delta.
Field Verification
Interprets physical-world evidence and returns a normalized observation.
None of these agents owns the final operational truth.
The Truth Engine
The Truth Engine is deterministic software, not an LLM.
It owns:
- impact qualification
- authorization semantics
- workflow transitions
- idempotency
- reconciliation
- verification verdicts
- completion conditions
- Change Proof generation
Models can propose.
Models can observe.
Models can reason.
But models cannot independently declare:
PASS
FAIL
PROOF_COMPLETE
authorization
workflow state
proof validity
This is how DRIFTZERO limits the blast radius of hallucinations while still allowing agents to take useful action.
Google Cloud architecture
The deployed system uses a public/private Cloud Run boundary:
PUBLIC INTERNET
│
▼
┌─────────────────────┐
│ driftzero-web │
│ Cloud Run · PUBLIC │
└──────────┬──────────┘
│
│ Google-signed identity token
▼
┌─────────────────────┐
│ driftzero-api │
│ Cloud Run · PRIVATE │
└──────────┬──────────┘
│
┌─────┼───────────────┐
▼ ▼ ▼
Firestore Pub/Sub Gemini / Gemma
The browser never receives backend credentials.
The public frontend authenticates to the operational API server-to-server using Google identity.
The backend remains protected by Cloud Run IAM.
Google technologies used
Google ADK
Used for agent orchestration and agent execution.
Gemini 3.5 Flash
Used by Change Intelligence to interpret semantic process changes.
Gemma on Vertex AI MaaS
Used for real multimodal field observation.
Gemma determines what is visible in the physical evidence.
The Truth Engine determines what that observation means operationally.
Cloud Run
Two independently deployed services:
driftzero-web
→ public product experience
driftzero-api
→ private operational backend
Firestore
Provides durable workflow and agent-session state.
Pub/Sub
Provides authenticated event ingestion with a bounded dead-letter path.
Google Cloud IAM
Maintains the public/private service boundary and least-privilege service-to-service access.
Cloud Logging and tracing
Provide correlation and operational observability across workflows.
Why this is agentic
DRIFTZERO is not a chatbot.
It does not simply explain what someone should do.
A live workflow:
- interprets a change,
- identifies affected work,
- qualifies an authorized action,
- performs scoped remediation,
- delivers the operational delta,
- evaluates physical-world evidence,
- preserves retries and failure history,
- and creates proof only after completion.
The system acts.
And it carries state across a multi-step operational workflow.
Building for failure
One of the biggest design goals was making failure a first-class state rather than an exception.
A workflow may encounter:
REVIEW_REQUIRED
VERIFICATION_INCONCLUSIVE
VERIFICATION_FAILED
FAILED
SUPERSEDED
A failed field verification does not corrupt or reset the workflow.
A corrected attempt can later succeed while preserving the previous failure.
The system also uses durable action identities and idempotency to avoid blindly repeating side effects after uncertain execution.
The hardest challenges
Challenge 1: separating reasoning from authority
The simplest architecture would have been to ask an LLM:
"Did this change succeed?"
I deliberately rejected that design.
Models are extremely useful at semantic interpretation, but letting the same probabilistic component own operational truth creates an unacceptable authority boundary.
The solution became the core of the project:
Agents propose. The Truth Engine decides.
Challenge 2: durable agent execution
Persisting business state is not enough.
A durable agentic system also needs to reason about:
- agent-session state
- invocation identity
- action execution identity
- retries
- idempotency
- reconciliation
- verification chronology
Otherwise, process replacement or retry can duplicate actions or lose the meaning of previous attempts.
DRIFTZERO therefore treats persistent execution state as part of the product architecture, not just storage.
Challenge 3: making a real public pilot safe
I wanted judges to run the real system from the Internet.
That meant the easy solution — making the operational API public — was unacceptable.
Instead, I deployed a separate public Cloud Run service while keeping the operational API private.
The browser talks to driftzero-web.
driftzero-web authenticates server-to-server to driftzero-api.
The public mutation surface is deliberately narrow.
Visitors cannot provide arbitrary:
- prompts
- model names
- workflow IDs as mutation authority
- expected observations
- PASS/FAIL values
- proof results
Physical uploads are bounded and validated from their actual bytes.
A short-lived capability is tied to one workflow.
Challenge 4: proving the multimodal retry was actually real
During final testing, I found an important UX defect.
The first manually uploaded photograph worked correctly and produced a real FAIL.
But after that failure, the page only offered a server-owned corrected pilot photograph.
That meant a user who uploaded their own first photo could not visibly submit their own corrected second photo.
Worse, pressing the existing retry button would silently change the evidence source.
I fixed the public state machine so a failed manual upload now presents:
Upload corrected photo
The second image goes through the exact same real verification pipeline.
The final public acceptance test produced:
Image #1
different bytes
→ Gemma: LEFT
→ Truth Engine: FAIL
Image #2
different bytes
→ new Gemma inference
→ TOP_RIGHT
→ Truth Engine: PASS
Both attempts remained in the same workflow.
That bug became a useful reminder:
A technically correct backend is not enough.
The user-visible evidence path also has to preserve truth.
What I learned
1. Agentic does not mean unlimited authority
Autonomy becomes more valuable when authority boundaries are explicit.
The goal is not maximum autonomy.
The goal is safe, useful autonomy.
2. Observation and judgment are different responsibilities
Gemma can determine what appears in an image.
The Truth Engine can determine whether that observation satisfies an operational requirement.
Separating those responsibilities makes the system easier to audit and reason about.
3. Durable execution is more than memory
Agent systems need more than conversation history.
Operational durability requires the system to preserve enough execution context to know:
- what has already happened,
- what was attempted,
- which side effects are authoritative,
- whether something is safe to retry,
- and how later evidence relates to earlier evidence.
4. The best AI architecture sometimes contains less AI
One of the most important decisions in DRIFTZERO was deciding where not to use a model.
Deterministic components are not a limitation of an agentic architecture.
In the right places, they are what make the agents trustworthy enough to act.
Business opportunity
DRIFTZERO targets the gap between change management and change deployment.
Potential value categories include:
- reduced unnecessary full-process retraining
- reduced manual follow-up
- faster operational adoption
- lower rework from stale procedures
- earlier field-drift detection
- stronger audit evidence
- lower operational-risk exposure
An illustrative model:
10,000 workers
× 8 operational changes per year
× 20 minutes of unnecessary full retraining
= 26,667 workforce hours exposed to retraining per year
This is an illustrative scenario, not a measured customer result.
A broader value model:
Annual Value Opportunity =
Avoided Retraining + Avoided Rework + Reduced Follow-up + Avoided Change Incidents + Audit Efficiency
The thesis is simpler:
Teach the delta. Verify reality. Prove deployment.
Current status
DRIFTZERO is a working cloud pilot.
The current release includes:
- real Gemini inference
- real Gemma multimodal inference
- Google ADK orchestration
- public Cloud Run application
- private Cloud Run backend
- durable Firestore state
- authenticated Pub/Sub
- physical image upload
- same-workflow FAIL → PASS retry history
- deterministic Change Proof
- public source code
- reproducible setup
- 1,999 passing automated tests
The project deliberately does not claim full enterprise production readiness.
Where enterprise platform capabilities required organization-level prerequisites unavailable in the hackathon environment, I documented those limitations rather than simulating capabilities that were not running.
Try it
🌐 Live product
https://driftzero-web-eepb64ze2q-uc.a.run.app
🎬 Live demo
💻 Source code
https://github.com/jpablortiz96/driftzero
📝 Technical deep dive
𝕏 Project launch
Closing
Most enterprise systems can tell us:
The procedure changed.
DRIFTZERO is designed to answer the harder question:
Did the work change?
And if the answer is yes:
prove it.
Built for the All Things Agentic Hackathon — Fortified Enterprise Fleet.
DRIFTZERO — the autonomous last-mile for operational change.
Log in or sign up for Devpost to join the conversation.