Foreman+: An AI Agent Fleet That Writes Field Service Job Records
Retailbox R&D: All Things Agentic Hackathon entry (Gemini and Google Cloud)
By Michael Oskola, Founder & AI Automation Architect · Project completed 2026
Our entry for the All Things Agentic hackathon, built on Gemini and Google Cloud. A technician photographs an equipment nameplate and talks, and three AI agents turn that into a job record with an estimate. A fact gets into the fleet's memory only after it passes a write-gate. The repo is public and the demo runs without a login.
What was the problem?
A service call produces facts nobody checks. The technician reads a nameplate, quotes a price and drives off, and the quote lives in their head or a text thread. The next technician on a callback starts from scratch. An AI agent in that loop doesn't help on its own, because it files whatever it's told: a homeowner's guess about the unit's age goes into the record with the same weight as the nameplate. We wanted capture that costs the technician nothing, and a record the next person can trust without diagnosing the job again.
How did Retailbox solve it?
We built Foreman+: three agents on Google's Agent Development Kit sharing one memory in Cloud SQL Postgres. The foreman records what the technician reported and hands off. The estimator looks for similar past jobs across the fleet's memory before it writes an estimate. The closer only reads: it builds the closeout document with no LLM call, briefs whoever arrives next, and is the one agent outside systems can reach, over the A2A protocol. Intake takes a photo and spoken notes as plain files, so the phone is the main path and Mentra Live camera glasses are an optional hands-free one. The model reads the equipment model and serial number from the photo rather than from what was said, and a field it can't read stays UNKNOWN. Every write passes a gate. Cheap checks run first (the agent must be a registered fleet member, a value can't exceed 4,096 bytes, a subject can't exceed 64 predicates), then a Gemini verifier judges the proposal against what's already known. If the verifier errors or returns nothing, the write is refused. Refused proposals stay in a journal with their reason, and the closeout document lists them.
Facing the same problem? These are the services that cover this kind of work: AI agent development services.
What does it look like?
(opens the full-size image in a new tab)
(opens the full-size image in a new tab)
(opens the full-size image in a new tab)
(opens the full-size image in a new tab)What were the results?
- ✓Submitted to the All Things Agentic hackathon on Devpost, together with the public repo, the live demo and the demo video on this page.
- ✓In the demo run captured for the submission gallery, the fleet made 14 proposals in 83 seconds. The gate approved 13 and refused 1: a manufacture date of 2022 that contradicted the nameplate's 05/2004. The record kept 05/2004 and filed the homeowner's statement separately, as a claim.
- ✓The public demo opens on a sample workspace seeded through the real fleet rather than by SQL, so every value in it went through the gate. Each value carries a chip naming its source (nameplate photo or voice line), the agent that proposed it and its gate entry.
- ✓Check it yourself: the Run the demo button on the office seat drives the real fleet through the same two turns. The technician seat opens on a phone at /tech, and the closer's A2A agent card is public.
- ✓Measured on the glasses: switching photo compression to medium cut capture time from 34 s to 6.3 s, and the Gemini Live guidance session answered in 0.24 to 0.67 s per turn with a camera frame attached.
- ✓Open-sourced under MIT: the three agents, the write-gate, the dashboard and the glasses bridge.
- ✓Limits, as the repo states them: every service runs at a single instance, there's no CI pipeline yet, and the glasses run on an SDK the vendor is retiring, so moving off it means rewriting a bridge of about 300 lines. Nothing depends on the glasses; the phone path works without them.