BatchGuard AI
Google Cloud AI Builder Cup 2026 · Manufacturing

Yourfactory,watchedby anagentthatexplainsandcalls.

BatchGuard AI turns a PDF manual into a verified monitoring spec in two minutes. From then on, a Gemini agent on Google Cloud watches the machine 24/7, explains every abnormal reading with evidence, and calls you when it is serious.

Walk through an incidentHow the agent reasons
live · line A · conv-01
vibration_rms3.1 mm/s
motor_temp74 °C
motor_current8.4 A
belt_speed1.2 m/s
telemetry · 4 devices online

Line A is running

Four machines post telemetry every second through their own device keys. Dashboard shows everything inside its verified limits.

Loading 3D factory…
  • < 3 min

    PDF manual → verified machine

  • < 10 s

    fault start → incident open

  • < 60 s

    critical → phone ringing

Google CloudGemini on Vertex AIAgent Development KitCloud RunPub/SubBigQueryFirestoreCloud StorageCloud Text-to-SpeechSecret ManagerFirebase AuthCloud LoggingTwilio VoiceNext.jsReactThree.jsFastAPIBlenderGoogle CloudGemini on Vertex AIAgent Development KitCloud RunPub/SubBigQueryFirestoreCloud StorageCloud Text-to-SpeechSecret ManagerFirebase AuthCloud LoggingTwilio VoiceNext.jsReactThree.jsFastAPIBlender

One incident, start to finish

Scroll to break a bearing. Watch the agent catch it.

This is the exact round trip: machine → telemetry API → detection → agent → phone call → engineer. The 3D line reacts to each step as you scroll.

live · line A · conv-01
telemetry · 4 devices online
Loading 3D factory…

vibration_rms

3.1 mm/s

motor_temp

74 °C

motor_current

8.4 A

belt_speed

1.2 m/s

  1. 1telemetry · 4 devices online

    Line A is running

    Four machines post telemetry every second through their own device keys. Dashboard shows everything inside its verified limits.

  2. 2anomaly layer · z-score 2.8

    A bearing starts to wear

    Vibration on the conveyor motor creeps up: 3.1 → 4.4 mm/s. Still inside limits — a threshold alarm would stay silent.

  3. 3time-to-limit · 4 min

    Trend detection predicts the breach

    A linear fit over the last 60 s projects the critical limit in ~4 minutes. A Warning opens before anything breaks. Email sent.

  4. 4INC-0419 · critical

    Motor temperature crosses 90 °C

    The limit layer fires. The symptoms attach to the same incident — one fault, one incident, not 200 alerts.

  5. 5ADK agent · 7 tool calls · 6 s

    The agent investigates

    Gemini pulls 5 minutes of readings, neighbours, events and the manual's bearing section. It ranks causes with evidence for and against.

    #1 Bearing wear · STRONG · vibration leads temperature by 9 min (r = 0.91)

    #2 Cooling fan failure · WEAK · contradicted: vibration moved first

    #3 Overload · WEAK · load flat at 38 kg, no jam event

    Check first → IR-gun drive-end bearing · manual p.42 §7.3

  6. 6Twilio voice · Cloud TTS

    The phone rings

    “Conveyor conv-01 critical. Bearing wear likely — vibration led temperature by nine minutes. Check the drive-end bearing. Press 1 to acknowledge.”

  7. 7ack · 00:41 after call

    Engineer acknowledges

    Escalation stops. The engineer IR-guns the bearing — 118 °C. Diagnosis confirmed and recorded against the machine's history.

  8. 8resolved · feedback: correct

    Bearing replaced. Back to green.

    Vibration returns to baseline. The incident, the evidence and the fix become training data for next time.

The gap

A threshold alarm at 2 a.m. says “temperature high”. Nobody knows why.

Small and mid-sized factories produce data but have no affordable way to watch it, understand it, or act on it in time. Enterprise condition monitoring is expensive, needs integrators, and still stops at a threshold.

Onboarding is slow

Monitoring means hand-typing every limit from a machine manual into a SCADA tool. Hours per machine.

Alarms don't explain

"Motor temperature high" says nothing about why, which readings moved first, or what to check.

Alarm fatigue

Repeated, duplicate, low-value alerts train operators to ignore them. The serious one gets missed.

Nobody watches at night

On a night shift or weekend a critical fault can run for hours before anyone sees the dashboard.

Expertise is scarce

Junior operators can't reproduce the diagnosis a senior maintenance engineer would make.

Problem statement

Factory owners need a low-setup way to connect machines, detect abnormal behaviour early, understand the likely cause with evidence, and make sure the right person is reached in time — without replacing human judgement on the shop floor.

Theme alignment · Intelligent Operations & Industrial Efficiency

Reliability

Detects abnormal behaviour early and predicts time-to-breach before a limit is crossed

Quality

Flags process drift (speed, load, temperature) that causes defective output

Efficiency

Cuts time-to-diagnosis: the agent gathers evidence and ranks causes

Predictive maintenance

Trend-based early warnings plus checks drawn from the machine's own manual

Sustainability

Less scrap, less energy on faulty runs, less unplanned downtime

End-to-end journey

Three stations. One loop. From PDF manual to a ringing phone.

Every incident on BatchGuard travels the same line: a machine is onboarded, it is watched, and when something drifts the right person is reached with evidence in hand.

01

Station 1

Onboard

Manual in, verified spec and device key out. Under three minutes.

  1. 01Setup

    Create a factory

    Owner creates Factory A, adds a line, and sets escalation contacts with order and quiet hours.

  2. 02Gemini multimodal

    Upload the manual

    Drop the conveyor's PDF datasheet. Gemini reads it and pre-fills parameters, units, normal ranges, warning and critical limits.

  3. 03Human-in-the-loop

    Verify, side by side

    Every extracted value is shown next to its source page with a confidence score. Nothing goes live unverified.

  4. 04POST /v1/telemetry

    Get a device key

    Platform issues a device ID, API key and endpoint URL with a copy-paste code sample.

I read the PDF. You verify every number before it goes live.

02

Station 2

Watch

Telemetry streams in every second. I watch the trend, not just the limit.

  1. 05Pub/Sub + Firestore

    Stream telemetry

    The machine posts readings every 1–2 s. Dashboard shows live charts against its own limits.

  2. 06Predictive

    Something drifts

    Vibration starts rising. Trend detection projects time-to-limit: ~4 minutes. A warning opens before anything breaks.

Vibration creeping up? I'll tell you four minutes before it matters.

03

Station 3

Respond

Evidence-backed diagnosis, a phone call, and a human closing the loop.

  1. 07ADK + Gemini

    Agent investigates

    Pulls readings, neighbours, events and the manual's troubleshooting pages. Ranks causes with evidence for and against.

  2. 08Twilio + Cloud TTS

    Phone rings

    Critical and unacknowledged? An automated voice call reads out the machine, the problem and the first check. Press 1 to acknowledge.

  3. 09Feedback

    Human closes the loop

    Engineer marks the diagnosis correct or wrong and records the fix. Feedback becomes the machine's history.

I rank causes with evidence for and against, then I call you.

01

Human-in-the-loop

The agent recommends; people decide. It never changes machine settings.

02

Evidence or silence

Every claim links to a reading, timestamp or manual page. Missing data is said out loud.

03

Fewer, better alerts

Deduplicate, group symptoms into one incident, escalate only when it matters.

Builder canvas

How a machine gets connected — and how an incident becomes a phone call.

Read it like a workflow: readings enter on the left, deterministic detection opens an incident, and only then does the Gemini agent wake up, pull evidence from four sources, and fan out to email, voice and the dashboard.

① Connect② Detect③ Evidence④ Investigate⑤ RespondBQ SUBSCRIPTIONWAKES AGENTREPORTNO ACK 2 MIN → NEXT

Machine / PLC

OPC UA · Modbus · HTTPS

Device key

X-Device-Key header

Telemetry API

Cloud Run · FastAPI

Pub/Sub

topic: telemetry

Detection worker

limits · trend · anomaly

Incident

INC-0419 · critical

BigQuery

history · baselines

Machine manual

Cloud Storage · §7.3

Line neighbours

feeder · inspection

ADK agent · Gemini

causes · evidence · checks

get_readingsget_manual_sectionsget_line_neighbourscompute_correlation

Email

warning + critical

Voice call

Twilio · Cloud TTS

Engineer ack

press 1 · feedback

Firestore

report → dashboard

No LLM on the hot path

Detection is deterministic and runs on every reading. Gemini is invoked only when an incident opens.

One fault, one incident

Cooldown and grouping attach new symptoms to the open incident instead of spawning alerts.

Evidence from four sources

History, the machine's own manual, its neighbours, and signal correlations — all cited in the report.

Escalation that climbs

Unacknowledged critical → next contact in order, until a human presses 1.

Detection + diagnosis

Detection is deterministic code. Diagnosis is a Gemini agent.

Detection must be fast, cheap and testable, so it never waits on an LLM. The agent is only woken once an incident opens — which keeps cost low and reasoning focused.

Layer 1 · Limits

Value vs verified warning / critical limits from onboarding

Catches: Clear breaches

Motor temp 92 °C > critical 90 °C

Layer 2 · Trend

Linear fit over the last 60 s → projected time to limit

Catches: Slow drift before a breach

Vibration rising; limit reached in ~4 min

Layer 3 · Anomaly

Rolling z-score vs the machine's own baseline; cross-signal checks

Catches: Odd patterns still inside limits

Current +30 % at the same speed and load

Layer 4 · Staleness

No telemetry for 10 s

Catches: Offline machine or sensor failure

conv-01 silent since 10:42:05

Agent pipeline · ADK + Gemini

  1. 1

    Context builder

    Incident window (5 min before → now), all parameters, upstream/downstream machines, events, verified spec.

  2. 2

    Retriever

    Pulls troubleshooting and maintenance passages from the machine's own manual, with page refs.

  3. 3

    Hypothesis generator

    Proposes 3–5 candidate causes, each tied to specific observations.

  4. 4

    Hypothesis evaluator

    Supporting evidence, contradicting evidence, missing data. Support level: strong / plausible / weak / inconclusive.

  5. 5

    Recommender

    Ordered checks, most discriminating first: "IR-gun the bearing; if normal, inspect belt tension."

  6. 6

    Reporter

    Schema-validated incident report plus a 20-second phone script.

Function tools the agent can call

get_readings(machine, params, window)get_baseline(machine, param)get_events(machine, window)get_line_neighbours(machine)get_manual_sections(machine, query)get_past_incidents(machine)compute_correlation(machine, a, b, window)
agent · incident report · schema-validated
incidentINC-0419 · conv-01 · Critical
signalsvibration_rms 3.1→6.8 mm/s (14 min) · motor_temp 74→91 °C
cause #1Bearing wear · STRONG · vib leads temp by 9 min (r=0.91)
cause #2Cooling fan failure · WEAK · contradicted: vibration moved first
cause #3Overload · WEAK · load flat at 38 kg, no jam event
check firstIR-gun drive-end bearing; manual p.42 §7.3 (Bearing inspection)
call script“Conveyor conv-01 critical. Bearing wear likely. Check bearing temp. Press 1 to acknowledge.”

Guardrails

  • Every number in the report is checked against stored readings; unsupported numbers are removed.
  • Output must pass a JSON schema; retry once, then fall back to a rule-based summary.
  • The agent has no tool that changes a machine. Recommendations are text only.
  • In blind test mode the fault label is stored where the agent's tools cannot read it.

Severity & escalation ladder

Info

Trigger

Single anomaly, inside limits

Action

Dashboard only

Warning

Trigger

Warning limit crossed, or time-to-limit < 10 min

Action

Dashboard + email

Critical

Trigger

Critical limit crossed, or several parameters in warning

Action

Dashboard + email + voice call

Emergency

Trigger

Critical not acknowledged in 2 min, or a safety event

Action

Call next contact; repeat until acknowledged

Cooldown: the same parameter on the same machine cannot open a new incident for 5 minutes — new symptoms attach to the open one. One fault = one incident, not 200 alerts.

Architecture

Everything on Google Cloud. The LLM only wakes when an incident opens.

Readings flow into Pub/Sub; a BigQuery subscription keeps history with no code; Firestore drives the live dashboard. Only an opened incident wakes the agent, which reads history from BigQuery and the manual from Cloud Storage, then writes its report back to Firestore.

Machine / PLC gateway

device key

Ingestion API

Cloud Run · FastAPI

Pub/Sub

telemetry topic

Detection worker

limits · trend · anomaly

Incident

Firestore

ADK agent

Gemini on Vertex AI

Escalation

Twilio · TTS · email

BigQuery ← Pub/Sub subscription (history)Cloud Storage ← manuals, photos, call audioFirestore → real-time listeners → live dashboard

AI

  • Vertex AI (Gemini Flash + Pro)
  • Agent Development Kit
  • Cloud Text-to-Speech
  • Vertex AI Agent Engine
  • RAG Engine / Vector Search
  • Gen AI evaluation service

Data

  • BigQuery
  • BigQuery ML forecasting
  • ML.DETECT_ANOMALIES
  • Firestore
  • Cloud Storage
  • Looker Studio

Streaming

  • Pub/Sub
  • BigQuery subscription
  • Dataflow

App & ops

  • Cloud Run
  • Firebase Auth
  • Cloud Tasks
  • Cloud Scheduler
  • Secret Manager
  • Cloud Logging & Trace

built for the demo (P0) · if time allows / roadmap

Gemini is used at 10 points, not one chat call

01P0

Read machine manual / datasheet

Multimodal PDF + image → structured JSON

02P0

Link each value to its source page

Citation of page and snippet

03P0

Incident investigation

Multi-step agent, function calling over 7 tools

04P0

Incident report

Schema-validated JSON

05P0

Phone call script

Gemini + Cloud Text-to-Speech

06P1

Ask the agent

Grounded chat over the same evidence

07P1

Photo as evidence

Vision: worn belt, burnt cable

08P1

Alerts in operator's language

Translation + plain-language rewrite

09P1

Similar past incidents

Embeddings + BigQuery vector search

10P1

Weekly health digest

AI.GENERATE in BigQuery

Built with

Google CloudGeminiAgent Development KitFirebase AuthBigQueryPub/SubCloud StorageTwilio VoiceNext.jsReactThree.jsTypeScriptTailwindFastAPIPythonBlender

Proof, not promises

Blind runs. The diagnosis is locked before the label is revealed.

A hidden fault is injected into the line; the agent's answer is saved before the ground truth is shown; the scoreboard shows real accuracy. Targets below are goals to measure against — the submission reports whatever the runs produce, with the number of runs.

Blind test protocol

  1. 1. Inject hidden fault

    Random fault + random start time. Label written to a restricted eval_runs store the agent's tools cannot read.

  2. 2. Lock the diagnosis

    Agent investigates and its ranked causes are saved with a timestamp.

  3. 3. Reveal and score

    Top-1 / Top-3 accuracy, detection delay and false alarms go to the scoreboard shown in the demo.

Minimum test set: 7 fault types × 3 runs = 21 blind runs + 1 hour of normal running for false alarms.

AreaMetricTarget
DetectionFault runs detected≥ 90%
DetectionFalse incidents / hour of normal running≤ 1
DetectionFault start → incident (sudden)< 10 s
PredictionTrend warning before critical limit≥ 80%
DiagnosisTop-1 accuracy≥ 60%
DiagnosisTop-3 accuracy≥ 85%
EvidenceReport numbers matching stored readings100%
OnboardingPDF upload → verified machine< 3 min
EscalationCritical incident → phone ringing< 60 s

Path to production

Real hardware uses the same endpoint.

The telemetry API is device-agnostic. Cost stays low because detection is plain code and the LLM runs only when an incident opens — not on every reading.

stage 1

Prototype now

Machines post over HTTPS with per-device keys; one factory; Cloud Run autoscaling.

stage 2

Pilot · 1–3 factories

Edge gateway reads PLCs over OPC UA / Modbus and posts to the same API; per-device certificates.

stage 3

Scale · hundreds

Multi-tenant Firestore; Pub/Sub + BigQuery at millions of readings/hour; Dataflow for windowed detection; Vertex AI models per machine type.

stage 4

Product

Shared, anonymised incident knowledge base per machine model; CMMS work orders; mobile app.

Demo · Oct 18, 2026

Upload a manual. Break a machine. Answer the phone.

Three minutes from onboarding to an evidence-backed diagnosis and a voice call. Every step is a real round trip through Google Cloud.

Replay the incident Watch the demo GitHub