ML engineering project

Neighborly

Neighborly reimagines mutual aid by using AI to coordinate local community support. We realized that the biggest barrier to helping isn't a lack of will, but a lack of coordination. Neighborly solves this by using autonomous agents to connect supply with demand. **The AI Agents:** • **Urgency Agent** - Uses **RAG** to analyze request context and prioritize critical needs like food or medicine over standard requests • **Balance Agent** - Monitors real-time supply and demand across neighborhoods to optimize resource allocation • **Trust Agent** - Leverages **Google ADK** for automated moderation and safety verification **Tech Stack & Architecture:** Built with **React** and **TailwindCSS** for a mobile-first experience, backed by **Supabase** for real-time data syncing. The system integrates **Google's Agent Development Kit** with **Python**-based agents. We utilized **RAG** (Retrieval-Augmented Generation) to ground the AI's decision-making in local community data, ensuring recommendations are relevant and resources are routed effectively.

ReactTailwindCSSSupabaseGoogle-ADKPythonRAGPostgreSQLReal-time SyncGeospatial DataAgentic AI
Neighborly machine learning project by Michael Rusu

Problem

People and local organizations want to exchange help, but offers, requests, urgency, and trust are difficult to coordinate.

My role

Helped build the agent-supported community workflow and connect the React/Tailwind product, Supabase data layer, and Google ADK services.

Approach

Build a React and Tailwind interface on Supabase, then use Google ADK agents for urgency ranking, supply-demand matching, and trust checks.

Outcome

Delivered a working mutual-aid prototype with real-time posts, nearby priority needs, matching, and automated moderation; no adoption metric is claimed.

Implementation

  • Built the mobile-first experience with React and Tailwind CSS.
  • Used Supabase for PostgreSQL-backed real-time data synchronization.
  • Implemented Google ADK agents for urgency, balance, and trust workflows.

Evaluation

  • Exercised the offer, request, shortage, ranking, and matching paths in the prototype.
  • Kept outcomes framed as product behavior because no deployment study is documented.

Results

  • Produced a functioning prototype that surfaces three urgent nearby needs and coordinates offers with requests.
  • No user-adoption or community-impact metric is claimed.

Constraints

  • Urgency and trust decisions needed grounding in local post context.
  • Offers and requests changed in real time and depended on location.
  • Automated moderation needed to support rather than replace community judgment.

Tradeoffs

  • Automated ranking can improve responsiveness but must remain transparent and contestable.
  • Real-time geospatial features introduce privacy and moderation considerations.

Next improvements

  • Test ranking quality with community organizations and publish moderation criteria.
  • Add privacy-preserving location controls and operational escalation paths.