FairReach

The problem

During large floods in Sri Lanka, aid isn't short; coordination is. Government agencies, NGOs and private donor groups all distribute relief at once, with no shared record of who has already been served. Roadside villages get several deliveries in a week while cut-off interior divisions get nothing.

What it does

FairReach keeps a live Coverage Ledger for every Grama Niladhari division: estimated need, what has been delivered, the resulting coverage deficit, which roads are passable, and which hospitals and shelters are open. Five agents read and write it. They take in reports in Sinhala, Tamil and English, rank divisions by unmet need, forecast which ones will be cut off, track road access, and dispatch teams.

The output isn't a map for someone to interpret. It's a dispatch instruction: this team, to this division, by this route, because these households are unserved, waiting for a coordinator's approval.

How it works

I owned the core that everyone else's agents write into:

• The Coverage Ledger: PostgreSQL with PostGIS, one row per division, with its boundary, household baseline, deliveries, deficit, access status and when it was last heard from. Every write goes through one repository layer and appends to an audit log recording who changed what, on what evidence.
• The orchestration graph in LangGraph. Agents don't message each other: the ledger is the shared state, and conditional edges decide at runtime which agent wakes next.
• Agent A2, the Coverage Analyst. It recomputes each division's deficit on every verified incident and delivery, and ranks divisions by unmet need, each with a confidence and a plain-language justification.

Decisions

Silence is evidence. A division that reports nothing may be fine, or may be cut off with no signal, which is where need is highest. The Coverage Analyst classifies quiet divisions as quiet because unaffected or quiet because unreachable, using connectivity, the division's normal reporting rhythm, river levels and road status.

Optimise for equity, not speed. The goal is to reduce the gap in coverage between divisions. Optimising for tonnage or delivery speed makes inequity worse, because the fastest deliveries always go to the easiest places.

The ledger is the blackboard. Because agents only communicate through the ledger, every decision leaves a trace in the audit log. That made the system explainable in the demo and let four people build agents in parallel against one published schema.