AWS Builder Center
Agents for Humans: Meet thunAI_UGMDU - A Neighborhood Agent Built to Know When to Act

Agents for Humans: Meet thunAI_UGMDU - A Neighborhood Agent Built to Know When to Act

thunAI_UGMDU is a neighborhood AI agent that notices local situations, understands context, and helps people take the right action - when action is needed.

Series: Agents for Humans: Building thunAI_UGMDU - A Neighborhood AI Agent (3 articles)

  1. 1
    Agents for Humans: Meet thunAI_UGMDU - A Neighborhood Agent Built to Know When to Act This article
Community Builder and Browserstack Champion

🌊 The Incident That Started the Idea

On 26 August 2026, devastating flash floods swept through communities in northern Nepal. Homes, roads and bridges were destroyed, entire communities were cut off, and rescue teams faced significant challenges reaching people who needed help. UNICEF reported that more than 84,000 people were affected, including around 32,000 children.Β 
What stayed with us was not only the scale of the disaster, but the coordination challenge underneath it. Information about what was happening existed across different sources and communities, yet turning that information into timely, contextual help became much harder as roads disappeared, communications were disrupted, and needs changed rapidly.
That became the starting point for thunAI_UGMDU.
We started asking a simple question:
What if a neighborhood had an AI agent that could understand what was happening around it, recognize who might need help, coordinate the right response, and know when a human should make the final decision?
We did not start with an AI technology looking for a problem. We started with a real-world event that exposed a coordination gap - and then asked whether an agent could help close it.

πŸ’§ The Problem: Coordination, Not Information

Every flood-prone neighborhood already produces the signals that matter. River gauges rise, upstream rainfall intensifies, dams release water, residents report water entering their streets, and shelters approach capacity. The underlying data frequently exists. What is missing is not information, but timely and contextual coordination of it.
In current practice, situational awareness during an emergency is assembled manually. A ward coordinator must simultaneously monitor sensor readings, field incoming reports across disconnected channels, assess who is at risk, determine which responder to deploy, and compose public guidance - all under time pressure, as conditions continue to deteriorate. This approach is adequate for isolated, low-volume incidents. It degrades precisely when it is needed most: as the number of concurrent events, affected residents, and data sources increases, the signals of greatest consequence become the most likely to be overlooked.
Moreover, each observation raises the same recurring set of judgments:
  • Does this reading represent a material change, or ordinary fluctuation?
  • Which areas, and how many residents, are affected?
  • Is immediate action warranted?
  • Who must be informed - the coordinator, a specific responder, or the wider community?
  • Should the system act autonomously, or is this a determination that requires human authority
  • thunAI_UGMDU was designed to address this coordination gap directly.
Rather than presenting another dashboard that depends on continuous human attention, thunAI operates as an autonomous agent that monitors the neighborhood on its own initiative. It converts raw hazard signals into a deterministic severity assessment, performs routine coordination independently, and maintains a complete, auditable record of every action. Critically, it defers to a human only where a decision carries genuine stakes - approving a mass evacuation advisory, or committing a limited rescue asset to a specific location.
The governing principle is deliberate: autonomous by default, with human oversight reserved for the decisions that warrant it.
β€œWhat does this thing actually look like?”

πŸ’¬ Why Existing Approaches Fall Short

The difficulty is not that neighborhoods lack communication channels - it is that they have too many. During a flood, relevant information may be distributed across river and rainfall sensors, resident messages, WhatsApp groups, social media, phone calls, and local announcements. Each channel serves a purpose, but all of them ultimately rely on a person to notice the information, interpret its significance, and decide what to do next.
This produces three recurring failures.
First, information is fragmented. A consequential signal - a gauge crossing a threshold, a resident reporting rising water - may exist in one place while the people responsible for acting on it are attending to another.
Second, context is absent. A raw observation that "something happened" does not by itself convey how serious the situation is, which areas or how many residents are affected, or whether any action is warranted. That interpretation is left entirely to human judgment, applied under pressure and without a consistent standard.
Third, people become the coordination layer. A coordinator must continuously monitor sources, correlate them, contact responders, and judge whether an alert is justified. This is sustainable for isolated incidents, but it does not scale: as concurrent events multiply, the manual effort required to keep pace grows faster than any individual can absorb - and the most critical signals are the first to be missed.
Adding another notification system does not resolve this. In most cases it worsens the problem, introducing additional streams for an already-overloaded coordinator to monitor.
thunAI was built to address a different need: the work that sits between "something happened" and "here is what we should do about it." That intermediate layer - assessing severity against fixed rules, determining who is affected, performing routine coordination autonomously, and escalating to a human only when a decision genuinely requires one - is precisely where existing tools leave a gap, and precisely what thunAI is designed to fill.

🏑 The Idea Behind thunAI_UGMDU

thunAI_UGMDU was conceived as a neighborhood agent that operates in the space between local information and meaningful action.
Rather than requiring people to continuously monitor disparate sources, interpret every update, and coordinate a response themselves, thunAI is designed to make sense of what is happening on their behalf. The premise is deliberately simple: give the neighborhood an autonomous agent that can notice, interpret, and assist - without generating unnecessary noise.
thunAI is not intended to replace residents, community groups, or local authorities. It is intended to augment them, by connecting information, the context that gives it meaning, and the people positioned to respond.
At its core, the agent reasons through three questions on every signal it receives:
  1. What is happening? It establishes the situation and its context - interpreting sensor readings and resident reports against a fixed, auditable set of rules to determine severity.
  2. Who might be affected? It identifies the areas and the community that require attention, expressed as aggregate impact rather than raw data.
  3. What should happen next? It determines whether to act autonomously, to defer to a human, or to remain silent.
The third question is the one we consider most important. A well-designed agent is not one that acts on every input; it is one that recognizes when action is genuinely useful - and, equally, when the correct response is to do nothing and avoid adding to the noise. Restraint is treated as a first-class behavior, not an afterthought.
This principle - autonomous where warranted, deferential where stakes are high, and silent where intervention would only add noise - became the foundation of thunAI_UGMDU, and the standard we carried through every stage of turning the idea into a working system.

πŸ’‘ The Principle: Knowing When to Act, Ask, or Stay Quiet

For us, designing an agent for a neighborhood was never a question of maximizing autonomy. It was a question of making the agent responsible.
A neighborhood agent operates within a human environment in which not every signal warrants a response. Acting prematurely can create confusion, generate unnecessary alerts, or actively worsen a situation. Conversely, remaining silent when meaningful assistance is required defeats the very purpose of the system. The design challenge, therefore, is not capability - it is judgment.
thunAI_UGMDU is built around a single governing principle, expressed as three modes of behavior:
Act when the situation is clear. When the information is reliable, the context is understood, and an appropriate action is well defined, the agent proceeds and moves the response forward on its own.
Ask when the situation is uncertain or consequential. When context is incomplete, or when a decision carries material stakes - a mass advisory, an irreversible commitment of resources - the agent defers to a human rather than acting on a confident guess.
Stay quiet when no action is warranted. Not every event merits an alert. In many cases, the most valuable behavior an agent can exhibit is to correctly recognize that nothing needs to happen, and to refrain from adding to the noise.
This reframes how we approach agentic AI. The objective is not maximum autonomy, but appropriate autonomy - granting the agent enough responsibility to be genuinely useful, while keeping humans in the loop wherever judgment, context, or accountability is decisive.
In thunAI, this principle is not merely a design intention; it is enforced structurally. The decision to act, ask, or stay quiet is governed by a single, deterministic escalation policy rather than by model discretion, so the boundary between autonomous action and human authority is explicit, consistent, and auditable. That principle became one of the foundations of thunAI_UGMDU as we moved from concept to a working application.

🌳 From Idea to Implementation

To translate the concept behind ThunAI_UGMDU into a working agent, we built on AWS and the Strands Agents SDK.
Strands allowed us to move beyond the model of a conventional chatbot and instead construct a genuine agent - one organized around goals, context, decisions, and actions rather than turn-by-turn conversation. AWS provided the foundation on which those capabilities were assembled into a deployable system: Amazon Bedrock AgentCore as the agent runtime, Amazon Nova as the reasoning models, and a set of managed services for state, identity, notification, and observability.
Our objective was not simply to add an AI feature to a neighborhood application. It was to use these technologies to examine a more substantive question:
Can an AI agent understand a local situation well enough to distinguish what deserves attention from what does not?
That question shaped every design decision. It is the reason severity is computed by deterministic rules rather than model judgment; the reason the agent's authority to act is bounded by a single, explicit escalation policy; and the reason restraint - the choice not to act - is treated as a valid and important outcome.
In the sections that follow, we go behind the scenes: the architecture, the multi-agent workflow, the tools each agent is given, and the specific engineering decisions that turned this principle into a working, deployed system.

πŸš€ What Comes Next

thunAI_UGMDU began with a simple question: what if a neighborhood had an AI agent that could understand local situations and offer help at the right moment?
The harder part was never making the agent capable of acting. It was designing it to recognize when action is genuinely useful, when a human should be brought into the decision, and when the better choice is to do nothing at all. With that principle established, we turned the idea into a working application built on Strands Agents and AWS.
The more interesting story, however, is what happens beneath the surface. How does the agent receive information about the neighborhood? How does it reason about a developing situation? How does it decide between acting, asking, and staying silent? And how do Strands and AWS come together to make that workflow reliable, auditable, and safe?
In Part 2, we open up thunAI_UGMDU and walk through the architecture and implementation behind the agent - from the Strands agent workflow and the tools each agent is given, to the AWS services that hold the system together, to the deterministic policy that governs when the agent may act on its own and when it must defer to a human.
From the idea of a neighborhood agent, to the engineering that makes it real.

πŸ§‘πŸ»β€πŸ’» Working Apps
GitHub - https://github.com/Ajaykumarkv17/ThunAI
YouTube - https://youtu.be/qSHEpTGEAH0
Working App - https://main.d2jea0lxqs5c0.amplifyapp.com/

Series: Agents for Humans: Building thunAI_UGMDU - A Neighborhood AI Agent (3 articles)

  1. 1
    Agents for Humans: Meet thunAI_UGMDU - A Neighborhood Agent Built to Know When to Act This article
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article