AnnaSetu

Backend deployed on render
Frontend deployed on vercel
Decision Ledger and Guided demos
Frontend Basic (Annasetu)
Architecture Diagram

Inspiration

Every day, perfectly good surplus food from restaurants, banquets, and events goes to waste. The root of the problem isn't a lack of willingness to donate, but a lack of logistical bandwidth. Coordinating immediate pickup and delivery to local NGOs before the food spoils is often too complex and time-consuming for humans to manage in real-time.

We envisioned a system where a simple message could trigger an autonomous swarm of AI agents to instantly handle the logistics, safety checks, and dispatching required to rescue food, eliminating the logistical friction of charity.

What it does

AnnaSetu is a fully autonomous food-rescue coordination network. When a donor reports a surplus, AnnaSetu delegates the task to a team of specialized AI sub-agents:

Signal Agent: Extracts intent and structured data (food type, quantity, expiration). Demand Agent: Matches the surplus against the live capacity of local NGOs. Logistics Agent: Calculates ETAs and assigns the nearest available volunteer rider. Safety Agent (AnnaGuard): Deterministically verifies that the travel time leaves a strict safety margin before the food expires, ensuring (Expiry Time minus Travel Time is greater than the Safety Margin). Supervisor Agent: Orchestrates the workflow and commits an auditable log to the live Decision Ledger.

How we built it

We architected AnnaSetu with a clear separation of concerns, heavily leveraging modern cloud-native and AI tools:

Generative AI Engine: Powered by Amazon Bedrock (Claude Haiku), enabling incredibly fast, cost-effective, and highly accurate multi-agent inference. Agent Orchestration: We utilized the Strands Agents SDK in Python to define strict, system-prompted agents capable of deterministic tool use. Backend Framework: Built with FastAPI to serve high-performance, asynchronous REST endpoints, deployed on Render. Database & Persistence: We implemented the state layer using Amazon DynamoDB, storing the live state of the network (riders, NGOs) and the immutable Decision Ledger. Frontend Dashboard: A highly responsive, glassmorphic React (Vite) application hosted on Vercel, allowing operators to monitor the "Live Network" in real-time and intervene if the AI flags an edge-case..

Challenges we ran into

Building a deterministic multi-agent system is inherently difficult because LLMs are probabilistic. Early on, agents would occasionally hallucinate rider assignments or approve unsafe delivery routes. We solved this by implementing AnnaGuard—a deterministic validation tool injected directly into the Safety Agent's context. By forcing the LLM to call a Python function to validate the math, we achieved 100% adherence to safety bounds.

Additionally, navigating AWS Bedrock's cross-region inference profiles for the newest Claude models presented deployment hurdles. We had to dynamically decouple our Bedrock client (routing to Oregon) from our DynamoDB client (routing to Virginia) within the backend architecture to ensure low-latency model access without migrating our existing data tables.

Accomplishments that we're proud of

We are incredibly proud of moving beyond a simple "chatbot" to build a true, autonomous, multi-agent orchestration layer. Integrating the Strands SDK with Amazon Bedrock allowed us to create specialized agents that actually talk to each other to solve complex logistics in seconds.

We are especially proud of engineering AnnaGuard. Generative AI is notoriously probabilistic, which is dangerous when dealing with perishable food. By injecting deterministic Python-based safety bounds directly into our Safety Agent's toolset, we successfully forced the LLM to strictly adhere to health codes, proving that AI can be both autonomous and 100% safe. Finally, we are proud of our Live Decision Ledger, which brings complete transparency and explainability to every single AI decision.

What we learned

We learned that the true power of Agentic AI isn't in creating one massive, omniscient prompt—it's in specialized multi-agent delegation. By breaking down the complex food-rescue pipeline into specialized agents (Logistics, Safety, Demand), the AI became significantly faster and less prone to errors. We also gained deep experience in integrating AWS Bedrock and managing serverless persistence with DynamoDB in a fast-paced environment.

What's next for AnnaSetu

We plan to expand the Demand Agent's capabilities to include predictive modeling, anticipating food shortages in specific geographic sectors based on historical data. We also aim to fully integrate the WhatsApp Business API webhook, so local restaurants can simply text "45 vegetarian meals ready" and watch a volunteer rider arrive 10 minutes later.

Built With

amazon-bedrock
amazon-dynamodb
amazon-web-services
anthropic-claude
fastapi
python
react
render
typescript
vercel
vite

Submitted to

Agents for Humans Hackathon

Created by

I worked on backend and finetuning specialized agents to improve respective functionings and built the project decision tree and designing the whole workflow including frontend. I got exposures to aws frameworks and its tools, along with it i also learned multi agent network deployment and my main challenge was to keep every agent's operation accountabe along with it being connected wo the workchain.

Aadi Srivastava
I worked primarily on the backend architecture and cloud infrastructure. I built the FastAPI server, deployed it to Render, and integrated the Strands Agents SDK with Amazon Bedrock. My biggest challenge was debugging AWS IAM permissions and cross-region inference profiles for the new Claude Haiku models, which taught me a massive amount about cloud-native AI deployment!

Vansh Singh