I-der

Closed-loop consignment launch for Indonesian neighbourhood shops: eight ADK agents turn a product drop into a measured experiment.

Comment

Inspiration

I-der (Javanese: ngider, to sell door to door) comes from a real consignment friction, not a corporate dashboard. A warung lontong is a neighbourhood stall that sells rice cakes with side dishes — a tiny shop, not a supermarket. Indonesia has on the order of millions of neighbourhood shops; this project is not a national census — it is that guessing, on this kind of stall. A supplier of entry-level goods to those stalls still decides where to leave stock by instinct. The result is wasted courier visits, the wrong product on a tiny shelf, returns, and stagnant inventory. The "Bring Your Own Friction" here is that guessing. The people on the loop are the operator running the launch and the shop owner who still has to say yes, no, or counter.

This project was created for the All Things Agentic Hackathon, track The Taskmaster.

What it does

I-der is a closed-loop product-launch system. Eight specialised agents predict which shops fit a SKU, negotiate a consignment, schedule delivery and collection, measure sell-through against a holdout group, and propose new scoring weights.

Field staff file shops on a Google Form (nothing to install). Cloud Scheduler pulls new rows. Humans still approve the ProductFit candidate list, record the owner's answer, and gate model updates. Google Calendar and Google Sheets are what the courier and operator actually read — the sheet brief is in Indonesian.

The eight agents: SurveyIntelligence, StoreSegmentation, ProductFit, ExperimentDesigner, ConsentNegotiation, AllocationRoute, SellThroughMonitor (including a nightly stagnant-stock scan), and LearningEvaluation.

How we built it

Agents are Google ADK Agent classes. All reasoning uses Gemini 3.5 Flash (gemini-3.5-flash) through Vertex AI with Application Default Credentials — no AI Studio API key. They run in one Cloud Run service (ider); the operator console is a second Cloud Run service (ider-web). There is no central orchestrator object: Cloud Pub/Sub push subscriptions wake the next agent. State lives in Firestore. Stock reservation is a Firestore transaction so two agents cannot promise the same units. After five failed deliveries an event lands in a dead-letter queue; Replay clears the idempotency marker first so the agent genuinely re-runs. Correlation IDs group the whole chain on the Operations tab. Three steps stay human on purpose: approve candidates, record the shop owner's counter, apply new model weights.

We used Google Agent Development Kit (ADK), Vertex AI (Gemini 3.5 Flash), Cloud Run, Cloud Pub/Sub, Cloud Firestore, Cloud Scheduler, Secret Manager, Google Forms, Google Sheets, Google Calendar, FastAPI, Python, React, and TypeScript.

Live field intake is Google Form to Google Sheet. Cloud Scheduler job ider-sheet-intake (and the demo Force Run) reads new rows with enrich=False; that path does not analyse shelf photos. Pilot seed uses survey CSV plus on-disk shelf photos via scripts/ingest_survey.py (enrich=True), off camera; a Drive link from Forms is not a usable photo. Visit 1 and visit 2 counts come from field CSVs and the console Record visit form. There is no national retail dataset; numbers on screen are this pilot, not Indonesia-wide results.

Challenges we ran into

Keeping the demo honest under a hard 4:00 cap: live Scheduler and Pub/Sub, not mock Console; no claim that Force Run analyses photos; holdout offers left pending; dead-letter Replay without relying on a toast that unmounts. Cloud Run that we are not promising 24/7 for judges — the public repo, video, and README are the reproducible proof.

Accomplishments that we're proud of

The four-minute video is a live Google Cloud run: Cloud Scheduler Force Run, Pub/Sub waking StoreSegmentation, Cloud Run and Firestore in the last beat — not slideware. Stock cannot double-book because reservation is transactional. Failed deliveries replay from a dead-letter queue after the idempotency marker is cleared. A holdout group gets no agent help, so treatment sell-through has a control. make test goes green without a GCP project. The operator console is English; the field route brief is Indonesian, because that is who reads it.

What we learned

A warung lontong is almost always "small" display capacity. An absolute scoring scale that assumes small/medium/large outlets silently caps every shop in this population, and a 60-point fit threshold was filtering on segment coincidence rather than on whether the shop was actually worth stocking. We moved the threshold onto the product's model_params (45 for this SKU) so it is a documented parameter, not a magic CLI flag. The more honest fix — normalising capacity against a micro-outlet population — is not built yet.

The catalogue in the field is many entry-level SKUs; the four-minute video shows one snack SKU because that is what ProductFit's daily-score dimension is honest about. A learning --dry-run writes nothing; the Calibration snapshot on screen came from a prior approved-path run and stays pending_approval until a named human signs.

What's next for I-der

Next, if I keep building after the hackathon: scoring dimensions that depend on product category, negative segment signals (shops that should not get a SKU), and per-SKU unit proposals instead of one snack-shaped daily score. Capacity would be normalised against a micro-outlet population rather than small/medium/large.

None of that is in this submission. What is submitted is the eight-agent loop on Google Cloud with the three human gates.

Built With

Share this project:

Updates