HerdRelay

Every livestock alert ends the same way: everyone assumes someone else is going. HerdRelay makes one approved phone call, asks the caretaker, and writes down the answer — "I can't tell yet" included.

Comment

Inspiration

Automated livestock monitoring is good at noticing and bad at concluding. A camera can tell you that cow C-17 has been breathing at 46 breaths a minute against a 25–35 baseline for eleven minutes. It cannot tell you whether she is ill, whether someone is already standing next to her, or whether the reading is an artifact of a feed push.

The gap between "a sensor is worried" and "a person has looked" is where herd health is actually lost. Alerts pile into a dashboard nobody is watching at 05:40, or into a group chat where three people each assume one of the others is going. Meanwhile the only fact that matters — is somebody walking to that pen, and when — is unknown to everyone.

What it does

HerdRelay turns one monitoring alert into one phone call to one authorized caretaker, and returns what they said as a validated structured result.

A person reviews the alert, then sees the complete call before it happens: the masked recipient, the purpose, the AI disclosure that will be spoken word for word, the five questions, the data expected back, the safety limits, and the entire brief. They approve that exact call. CALL-E dials, says it is an AI-assisted monitoring demonstration working from synthetic data, and asks:

  1. Can you inspect the animal?
  2. How soon can you reach it?
  3. Are visible signs of distress present?
  4. Is veterinary or supervisor follow-up requested?
  5. Is there any additional observation?

The console follows the call live and returns a summary, the timestamped transcript, a strict seven-field structured result, a recommended coordination status, and whether human review is required.

It refuses to do the interesting-sounding parts. It does not diagnose the animal, gives no veterinary advice, never contacts a vet or an emergency service on its own, never redials, and never schedules. The call collects observations; a human decides.

How I built it

TypeScript and Next.js, with the official CALL-E SDK server-side only. The API key is read inside a route handler, pinned to https://api.heycall-e.com with redirects refused, and never reaches the browser or a stored record.

The design decision the whole thing rests on is the result schema. Every field a person could leave unstated is an enum with an explicit unclear/unknown member, and the arrival estimate is a string rather than a number. A boolean has no way to say "they did not answer", so a boolean forces the model to invent one. Give it somewhere to put the uncertainty and it stops inventing.

A validator then checks the result against its own fields and against the transcript. An outcome claiming the inspection was confirmed with no acceptance recorded, an arrival time for somebody who said they are not going, or "nobody answered" when the transcript shows the caretaker speaking — each is downgraded to uncertain with human review required, and every correction is printed on screen rather than applied silently.

Dry run is the default and is the value of anything that is not exactly HERDRELAY_MODE=live. Seven scripted CALL-E responses replay through normalizeCall() — the same boundary a live call crosses — so a rehearsal and a real call share one render path.

Challenges I ran into

Not calling carelessly is most of the code. The approval is bound to a SHA-256 fingerprint of the exact preview, mode included, so an approval cannot be spent on a call that changed and a dry-run approval cannot redeem for a real one. The browser never supplies a phone number. One in-flight call per caretaker is enforced with an on-disk reservation that stays held while an outcome is unknown.

The hardest case is not knowing. If the create request times out, HerdRelay does not know whether a phone rang — so it does not retry, idempotency key or not. It halts the incident, keeps the caretaker reserved, and asks a human to reconcile it against the CALL-E dashboard.

Two bugs found by running it against a real configuration. A misconfigured phone number threw a plain error that got flattened into "the action failed" — useless, and only after the operator had clicked. And approvals recorded a hash of a shared token rather than a person, which undercuts the entire claim the app makes. Both are fixed: one validator now feeds both the readiness banner and the preview, and operators sign in against named accounts so the record reads "Marta Nowak approved one real call to +1 ••••••••53."

What I learned

Getting honest uncertainty out of a model is a schema problem before it is a prompt problem.

And the cost of honesty is visible: six of the seven shipped scenarios end with human review required, and only one produces the tidy green result. That ratio is the correct one — a two-minute call to somebody who has not walked to the pen yet mostly establishes that somebody is going to walk to the pen. Claiming more would be the actual failure.

What's next

SSO against the farm's existing identity provider, so access follows employment. A caretaker rota with an escalation ladder gated behind a per-rung approval rather than a timer. CALL-E terminal webhooks replacing the poll. Callback-window awareness, so a moderate alert at 02:00 waits and a high-severity one does not.

Built With

Share this project:

Updates

Submission history