Agents for Humans: Building thunAI_UGMDU with Strands Agents and AWS
A behind-the-scenes look at how we turned the thunAI_UGMDU concept into a working neighborhood AI agent using Strands Agents and AWS - from architecture and agent workflow to the tools and cloud services that bring local signals to meaningful action.
Series: Agents for Humans: Building thunAI_UGMDU - A Neighborhood AI Agent (3 articles)
- 2Agents for Humans: Building thunAI_UGMDU with Strands Agents and AWS This article
🧠 From Idea to Architecture
In Part 1 , we introduced thunAI_UGMDU and the principle behind it: a neighborhood agent that can notice what is happening, understand the surrounding context, and assist only when action is genuinely useful.
Translating that principle into a working system required us to answer a distinct set of engineering questions. How does the agent receive information about its environment? How does it interpret that information into an understanding of the situation? How does it decide what to do next? And how does it use tools to move beyond generating text toward taking meaningful action?
To address these questions, we needed an architecture capable of connecting each of these stages into a coherent, practical workflow - while keeping the governing principle from Part 1 at the center of the design:
The agent should know when to act, when to ask, and when to stay quiet.
This is where the Strands Agents SDK and AWS became the foundation for turning the concept of thunAI_UGMDU into a working application. Strands provided the structure for organizing the agent's reasoning and tool use, while AWS supplied the runtime, state, and delivery infrastructure needed to operate the system reliably. Together, they allowed us to express not only what the agent can do, but the conditions under which it should do it.
The idea was simple: move from detecting a neighborhood signal to understanding it, deciding what to do, coordinating the response, and verifying the outcome. To make that possible, we designed thunAI_UGMDU as a multi-agent system built with Strands Agents and Amazon Bedrock AgentCore.
In the next section, we examine the architecture that brings these pieces together - how information flows through the system, how the agent reasons over it, and how the boundary between autonomous action and human judgment is enforced in practice.
📌 Architecture of thunAI_UGMDU
- thunAI_UGMDU - Agent Architecture on AWS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
Users (Residents · Coordinator · Responder — browser)
│ HTTPS
▼
AWS Amplify + CloudFront ← React + Vite SPA (3 surfaces: resident · coordinator · responder)
│ auth (SRP) → Amazon Cognito (coordinators / responders groups)
│ fetch /api/*
▼
Amazon API Gateway (REST, prod)
├── thunai-resident GET /public/status
├── thunai-escalation /escalations · /resolve · /respond
├── thunai-responder /responders · /assignments
└── thunai-ingestion POST /intake
│
▼
AWS Lambda (Python 3.13)
├── resident_api → reads live state
├── escalation_service → resolve / respond (invoke runtime: mode=resume)
├── responder_api → assignment read / respond
├── ingestion_lambda → invoke runtime: mode=intake
├── sweep_lambda ← EventBridge Scheduler rate(10 min) → mode=sweep
├── timeout_sweeper ← EventBridge Rule rate(1 min) → mode=resume
└── stream_publisher ← DynamoDB Streams → AppSync EventPublish
│
▼
Amazon Bedrock AgentCore Runtime (arm64, mode-dispatched)
│ Runtime · Memory · Gateway · Observability
│
└── Strands incident graph (fixed six-node topology)
1. Rule Engine (deterministic severity banding — no model call)
2. Monitor → raises / updates an incident above NORMAL
3. Intake → resident message → structured request
4. Dispatch → matches responder / shelter ┐
5. Alert → drafts warning (Tamil / English) ┘ (branch: alert vs dispatch)
6. Safety / QA → reviews high-risk actions
│
▼
Escalation Policy (single autonomy authority)
ACT when clear · ASK a human when uncertain / irreversible · STAY QUIET when nothing to do
│
├── Amazon Bedrock — Nova (agent reasoning: nova-lite / nova-pro)
├── Bedrock Knowledge Base → Amazon S3 Vectors (official FAQs / guidelines — RAG Retrieve)
├── AgentCore Memory (run + incident state, coordinator prefs)
│
▼
Data tier
├── DynamoDB thunai-state (live incidents / requests / assignments — Streams on)
├── DynamoDB thunai-audit (append-only audit ledger)
├── DynamoDB thunai-memory (30-day hazard baselines + prefs)
└── Amazon S3 (working context + hazard images)
│
▼
Realtime & Notifications
├── AppSync Events (WebSocket) → pushes state changes back to all surfaces
├── Amazon SNS → escalation SMS
└── Amazon SES → escalation email
Inputs (external) Human-in-the-loop
├── Weather / rainfall feed Coordinator approves every
├── River / dam sensors irreversible action before
└── Resident messages (SMS / web) it is dispatched
Flow: signal → Amplify/CloudFront → API Gateway → Lambda → AgentCore Runtime
→ Strands graph (rule → monitor → intake → dispatch / alert → safety-QA)
→ Nova / KB · escalate to human when irreversible · AppSync pushes outcomes back in real time.
2. Technical architecture diagram
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
Residents · Coordinator · Responder (browser) + Sensors / gov feeds
| HTTPS
v
Amplify + CloudFront (the website — resident / coordinator / responder)
| auth (sign-in) -> Cognito (security desk: who are you, which role)
| fetch /api
v
API Gateway (reception desk) -> AWS Lambda (one small worker per job)
|-- resident_api -> public status page
|-- ingestion_lambda -> takes in messages / sensor readings (mode=intake)
|-- escalation_service -> coordinator's decisions (mode=resume)
|-- responder_api -> responder assignments
|-- sweep_lambda <- EventBridge every 10 min -> checks conditions (mode=sweep)
|-- timeout_sweeper <- EventBridge every 1 min -> checks timed-out decisions
|
v
AgentCore Runtime — the brain (the AI team, an assembly line)
|
| 1. Rule Engine (strict calculator: Normal->Watch->Warning->Evacuate)
| v
| 2. Monitor (notices something abnormal, opens an incident)
| / \
| 5. Alert 3. Intake (reads Tamil/English message -> clear request)
| (warning | \
| in local | -> Knowledge Agent
| language) v (answers from official
| 4. Dispatch docs only, with citations;
| (right responder / shelter) refuses if unsure)
| \ /
| 6. Safety / QA (double-checks risky actions)
| v
| +-------------------------------------------------------------+
| | Escalation Policy — the ONE rulebook for every action: |
| | ACT (safe, do it) · ASK (serious -> human approves) |
| | · STAY QUIET (nothing needed) |
| +-------------------------------------------------------------+
|
| thinks with -> Amazon Nova (AI models)
| looks up -> Bedrock Knowledge Base (searchable official
| guidance = RAG / vector store)
| remembers -> AgentCore Memory (coordinator preferences)
|
v
State, Notifications & Realtime (memory + messengers)
|-- DynamoDB thunai-state (the live situation)
|-- DynamoDB thunai-audit (permanent, tamper-proof log of every action)
|-- DynamoDB thunai-memory (baselines + preferences)
|-- S3 (images / working files)
|-- SNS -> SMS to coordinator \ "we need your decision"
|-- SES -> email to coordinator /
|-- AppSync (realtime) ---------------> pushes live updates back to
every screen, no refresh needed
^ |
|_________________________ realtime push back to the surfaces ____|
Colour key on the diagram:
green = strict rule (no AI guessing) blue = an AI agent
yellow = human-approval gatekeeper dashed = automatic / real-time updates
One-line story:
a signal comes in at the top -> the AI team figures out how serious it is
and what to do -> it ACTS on safe things, ASKS a human for serious things,
STAYS QUIET when nothing's needed -> then it stores everything, notifies
people, and updates all the screens in real time.
🚩 Building the Agent with Strands
The core of thunAI_UGMDU follows a single arc:
Signal → Understand → Decide → Act → Verify
We structured the system so that it does more than generate a response to a prompt. The agent receives signals from the neighbourhood - river and rainfall readings on a scheduled sweep, or an inbound resident message - builds an understanding of what is happening, evaluates that situation against the available context and a fixed set of rules, and then determines the appropriate next step rather than replying with text alone.
To do this reliably, we deliberately avoided putting every responsibility into one large agent. Instead, thunAI_UGMDU is built as a fixed graph of specialised nodes, each with a focused role:
- Rule Engine - a deterministic node (no model call) that establishes the initial situation and assigns the severity band.
- Monitor - watches incoming conditions and raises or updates an incident when something abnormal appears.
- Intake - interprets a resident's message and converts it into a structured, actionable request.
- Dispatch - matches the appropriate responder or shelter to the need and proposes the response.
- Alert - drafts warnings and updates in the resident's own language (Tamil or English).
- Safety / QA - reviews whether a high-risk action is appropriate before it is carried out.
The important design principle is that these nodes do not operate as independent bots. They are wired into a single directed workflow - an incident graph - so information flows in one coherent path from detection to decision, action, and verification. Each node's output becomes the next node's input, and the edges between them are conditional: the alert branch is only reachable when the Monitor raises an incident above normal, and the dispatch branch only when Intake produces a dispatch-eligible request.
This structure connects directly back to the central idea from Article 1:
Act. Ask. Stay Quiet.
The agent does not automatically take every possible action. A single escalation policy - the one authority for every autonomy decision in the system - determines, for each proposed action, whether the agent should:
➤ Act when the action is clear, reliable, and within its authority.
➤ Ask when a human's approval or additional information is required — for example, an irreversible dispatch or a mass-audience evacuation advisory, which pause and wait for a coordinator.
➤ Stay Quiet when there is nothing meaningful to do, recording the observation and moving on.
➤ Ask when a human's approval or additional information is required — for example, an irreversible dispatch or a mass-audience evacuation advisory, which pause and wait for a coordinator.
➤ Stay Quiet when there is nothing meaningful to do, recording the observation and moving on.
The key paragraph:
Strands gave us a way to turn thunAI_UGMDU from a conversational idea into a coordinated agent workflow. Instead of asking one agent to understand signals, communicate with residents, coordinate responders, and make safety decisions all at once, we separated those responsibilities into specialised nodes within a single incident graph. Each node has a focused role, while the graph as a whole allows information to move from detection through decision, action, and verification. That separation also gave us an essential safety boundary: not every situation should result in an automatic action. Through one escalation policy, thunAI_UGMDU decides whether to act on its own, ask a human for input, or simply stay quiet.
📍Giving the Agent the Ability to Act
A neighbourhood agent becomes genuinely useful only when it can do more than understand a situation. It has to take the right action at the right time, while respecting clear safety boundaries.
For thunAI_UGMDU, every action follows the same Act → Ask → Stay Quiet principle introduced earlier. When an event is clear and the response is safe, the agent carries out the appropriate action directly. When an action calls for human judgment or carries greater consequences, the agent pauses and asks for approval rather than acting on its own. And when there is nothing meaningful to do, it stays quiet instead of generating an unnecessary alert.
The action layer is what connects the agent's decisions to the systems that actually deliver those outcomes. In thunAI_UGMDU this is where the agent's tools reach real services: drafting and sending resident warnings, coordinating a responder, writing incident and audit records to persistent state, and notifying a coordinator out-of-band. Each of these is an explicit, auditable step - the agent does not "speak" an action into being; it invokes a tool that performs it, and the result is recorded in an append-only audit ledger.
The important distinction is this:
The agent does not act simply because it can. It acts because the situation, the available evidence, and the escalation policy together justify the action.
This is also where thunAI_UGMDU gains a meaningful safety boundary. Not every action carries the same weight, so not every action is treated the same way. Communicating an emerging risk to residents can be handled with more autonomy, while an irreversible operational action is deliberately gated. For example, publishing a status update or a warning can proceed automatically, whereas dispatching a boat rescue to non-ambulatory residents, or issuing a mass-audience evacuation advisory, is escalated to a human coordinator and held until they approve it. When the coordinator approves, the decision flows straight through to the responder as a live assignment; if no response arrives before the deadline, the escalation policy applies its safe default rather than guessing.
That is what turns thunAI_UGMDU from a chatbot that says something into a system that can do something meaningful - while keeping humans firmly in the loop wherever the consequences matter.
Once an agent can decide and act, the next challenge is connecting those decisions to reliable cloud services. That is where AWS becomes part of the story.
☸️ Connecting the Agent to AWS
Once the agent could reason about a situation and decide what should happen next, the next step was giving it access to the cloud services and tools it needs to operate in the real world.
thunAI_UGMDU uses AWS as the foundation around the agent. Amazon Bedrock AgentCore provides the managed runtime that hosts and supports the agent - with its Memory, Gateway, and Observability capabilities - while Amazon Nova models supply the reasoning. Around that core, a set of AWS services provides everything the agent needs to receive signals, maintain information, communicate with residents, and coordinate a response.
The architecture connects the agent to each service where it adds a specific capability:
- Amazon EventBridge runs the scheduled sweep every ten minutes and the one-minute timeout check, so the system acts on its own cadence rather than waiting for a human to trigger it.
- AWS Lambda carries the application logic - the ingestion, escalation, responder, resident-status, and stream-publishing functions that sit between the APIs and the runtime.
- Amazon DynamoDB holds persistent state across three tables: live incident and request state, an append-only audit ledger, and longer-term hazard baselines and coordinator preferences.
- Amazon SNS and Amazon SES deliver the out-of-band notifications - an SMS and an email to the coordinator whenever a decision needs human approval.
- Amazon API Gateway exposes the REST interfaces the three surfaces call, and Amazon Cognito handles identity and role separation between coordinators and responders.
- Amazon CloudWatch and AWS X-Ray provide the monitoring and end-to-end tracing that make the agent's behaviour observable in operation.****
- A Bedrock Knowledge Base over S3 Vectors lets the agent ground its answers in official guidance, and AWS Amplify hosts the React front end for residents, coordinators, and responders.
The important part is not simply that these services are connected. Each one gives the agent a capability it would not have on its own. A signal can enter the system, the agent can reason about it, information can be retrieved or stored, and an appropriate notification or response can be triggered - with every step recorded for accountability.
This is the bridge between agent intelligence and real-world usefulness:
AWS provides the nervous system around thunAI_UGMDU - connecting signals, decisions, people, and actions into one workflow.
The result is an agent that is not isolated inside a chat window. It works with the surrounding systems to detect a situation, understand its context, coordinate the appropriate response, and keep the relevant people informed - in real time, through DynamoDB Streams published to the surfaces over AppSync.
With the agent connected to its tools and cloud services, the next question was simple: what does the complete journey look like when a real neighbourhood signal arrives?
🐳 From Signal to Action
The real test of an agent is not whether it can produce a good response, but whether it can turn a real-world signal into the right outcome.
Consider heavy rainfall creating a potential flood risk in the neighbourhood. A signal enters thunAI_UGMDU through the scheduled monitoring sweep - river and rainfall readings arriving on a fixed cadence. The Rule Engine assigns a severity band to those readings, the Monitor opens or updates an incident, and the agent evaluates the situation to identify the appropriate response.
If the readings cross the evacuation threshold, thunAI_UGMDU moves from detection to action. It drafts an EVACUATE-level warning in the resident's own language, communicates it to the affected area, and begins turning inbound resident messages into structured requests. In parallel, the system prepares to coordinate with responders so that the people who need help can be identified and matched to the right capability.
Not every action is treated the same way. A community warning can follow an automated path when the conditions are clear, while a consequential action - such as dispatching a boat rescue to non-ambulatory residents - is held for human approval before it proceeds. This is exactly where the agent's Act, Ask, or Stay Quiet principle takes effect: the escalation policy decides, for each proposed action, whether it is safe to carry out, must be referred to a coordinator, or should not happen at all.
Once a coordinator approves, the workflow continues straight through to the responder side through a live handshake: the approved decision becomes an assignment in the responder's app. The responder can acknowledge it, indicate they are en route, and confirm when they are on scene, with each stage time-stamped on the timeline. The incident is then updated to resolved, and that outcome flows back to the coordinator console and to the public resident status page - so the community receives a final status rather than being left wondering what happened.
The complete journey can therefore be expressed simply:
Detect → Assess → Warn → Coordinate → Help → Verify
What makes this different from a conventional notification system is the coordination in between. thunAI_UGMDU does not simply detect an event and send an alert. It connects the signal, the decision, the people, the action, and the outcome into one continuous workflow - and records every step in an append-only audit ledger.
And that final step - Verify - matters just as much as the initial alert. Knowing that an evacuation message was sent is useful. Knowing that people actually reached safety and that the incident was resolved is what closes the loop.
Building this workflow taught us that the hardest part of an agent is not making it act. It is deciding when it should act, when it should ask, and when it should stay quiet.
🏗️ What We Learned Building thunAI_UGMDU
Building thunAI_UGMDU for the Agents for Humans hackathon taught us as much about restraint as about capability.
The first lesson was that the hardest part of an agent is not making it act - it is deciding when it should act, when it should ask, and when it should stay quiet. Giving an agent the ability to send alerts or dispatch responders is straightforward; giving it the judgment to do so only when the situation, the evidence, and the policy justify it is the real work. Concentrating every autonomy decision into a single escalation policy, rather than scattering that judgment across individual agents, was what made the system's behaviour predictable and safe to reason about.
The second lesson was the value of separating responsibilities. Rather than one large agent trying to interpret signals, talk to residents, coordinate responders, and make safety calls all at once, we built a fixed graph of focused nodes and let information flow through it in one direction - from detection to decision, action, and verification. Each node became simpler to build, test, and trust, and a deterministic rule engine at the front kept the system grounded even when a model's output was uncertain.
The third lesson was that verification is not an afterthought. Knowing an alert was sent is useful; knowing that people reached safety and that the incident was resolved is what actually closes the loop. Designing the workflow so that outcomes flow back to the coordinator and the community - and so that every step is recorded in an append-only audit ledger - turned out to matter as much as the initial detection.
The hackathon also changed how we thought about the idea itself. What began as an attempt to build an agent for one neighbourhood problem started to look like a reusable pattern for community-focused AI on AWS. As we worked through it, the interesting part was no longer detecting a single emergency or sending a single alert. It was the underlying pattern: an agent that can observe local signals, understand context, decide what should happen, coordinate people and systems, and verify the outcome - all under one clear rule for when to act, ask, or stay quiet.
That pattern is not specific to floods, or even to emergencies. Different communities have different signals, knowledge, policies, and response mechanisms, but the agent approach beneath them can stay the same. The signals could be sensor readings, resident reports, or official feeds; the knowledge could be local guidelines; the actions could be warnings, dispatches, or status updates - while the observe → understand → decide → coordinate → verify workflow, governed by a single autonomy policy, remains constant.
So the hackathon quietly changed the question we were trying to answer. We began by asking:
"Can we build an agent that helps a neighbourhood?"
We ended by asking:
"Can we build a reusable agent pattern that helps communities know when to act, when to ask, and when to stay quiet?"
That shift - from a single application to a reusable community-agent pattern on AWS - is the outcome of thunAI_UGMDU we are most interested in carrying forward.
⚛️ What's Next
The next step for thunAI_UGMDU is not simply to add more features, but to explore how the same agent pattern could be adapted to other communities and local challenges.
The underlying approach can stay the same: observe local signals, understand the situation, decide whether to act, ask, or stay quiet, coordinate the right people or systems, and verify the outcome. What changes from one community to another are the local signals, the knowledge the agent draws on, the response policies that govern its autonomy, and the tools available to it.
For one community, those signals might relate to flooding, severe weather, or forest fires. For another, they could involve infrastructure faults, local safety concerns, or public services where timely coordination matters most.
Consider a forest-fire scenario. The agent could bring together signals such as fire alerts, weather conditions, and reports from people nearby, assess the severity, and help coordinate warnings and response - with the same human-approval boundary applied to any high-consequence action. The Detect → Warn → Coordinate → Help → Verify pattern would be adapted to the local context rather than rebuilt as an entirely new system. In practice, adapting it means changing the signal sources the agent listens to, the knowledge base it consults, and the thresholds in its escalation policy - while the incident graph and the single autonomy authority beneath them remain the same.
The goal, therefore, is to make thunAI_UGMDU more than a single-purpose prototype. We want to explore a reusable community-agent pattern on AWS, where the intelligence and coordination model can be tuned to local needs while preserving the same principles: human oversight where the consequences matter, action only when it is justified, and responsible communication throughout.
The future we see is not one agent for every neighbourhood, but a pattern that lets every community build an agent that understands its own context.
👩🏻💻 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)
- 2Agents for Humans: Building thunAI_UGMDU with Strands Agents and AWS This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article