Inspiration
Smart homes can detect a lot. Almost nothing decides what to do about it. A Ring alert, a door sensor trip, a motion event — today these all turn into the same thing: a push notification dumped on the owner to interpret and act on. That doesn't scale to a household with an elderly parent, a kid coming home alone, or just a normal day where most events are non-events. Guardian is an AI agent that sits between your devices and reasons about what's actually happening before deciding what to do — informing you, asking for confirmation, or escalating, depending on context and the safety policies you've set. It never takes an irreversible action (like unlocking a door) without explicit authorization, no matter how confident it is. Our core principle is simple: Smart homes detect. Guardian decides. You stay in control. What makes it different Three things built specifically to prove this isn't "event → push notification with extra steps":
*Context-aware reasoning with hard constraints. The identical "unknown person at the front door" event resolves differently depending on household context — a scheduled visitor gets a simple notify, a vulnerable member home alone triggers a wellness check offer, an away owner gets a Fire TV alert. What's constant across all of them: Guardian never proposes unlocking the door, regardless of tier or confidence level. That refusal is a hard constraint in the decision engine, not a canned line.
*Reasoning across events, not just one. Three individually unremarkable events — motion, then door activity, then window activity — across different parts of the house in a short window trigger an escalation that none of them would alone. This is pattern detection, not a rules list.
*Teachable by voice. Say "if someone knocks after 10pm, always wake me" — Guardian compiles it into a structured policy via Bedrock, not a stored string. The policy is immediately active and participates in future decisions.
What it does
Guardian is an AI household safety agent that connects smart-home events, household context, and user-defined safety rules to determine the appropriate next action. When an event occurs, Guardian evaluates:
- What happened?
- Where did it happen?
- Who is home or away?
- Was the event expected?
- What household policies apply?
- How risky would the proposed action be? Guardian then makes one of three decisions: INFORM — take a safe informational action, such as notifying the owner or displaying an alert. ASK — request human approval before taking a consequential action, such as starting a wellness check. BLOCK — refuse an unsafe action, such as automatically unlocking a door when household policy prohibits it. The experience brings these decisions together across Alexa+, Ring, and Fire TV, creating a single household safety workflow instead of isolated device alerts.
How we built it
Guardian is built around a policy-controlled AI agent architecture.
The core decision pipeline is:
Event → Context → Policy → Risk → Action → Explanation
Ring-style events enter Guardian through a webhook interface and are normalized into a common event model. Guardian then combines those events with household context and natural-language safety policies.
The Guardian Policy Engine evaluates proposed actions and returns an explicit INFORM, ASK, or BLOCK decision.
Guardian exposes its capabilities through a Model Context Protocol (MCP) server using Streamable HTTP, allowing an AI client such as Alexa+ to discover and invoke Guardian's tools.
The project also includes an AWS deployment path using Amazon Bedrock, AgentCore, DynamoDB, EventBridge, CloudWatch, and CDK, while the Fire TV command center provides a visual representation of household state and incident progression.
A key architectural decision was to never allow the language model to directly perform sensitive actions. The model can reason about an action, but the Guardian Policy Engine remains the final authority.
Challenges we ran into
One of our biggest challenges was designing an agent that could be useful without becoming dangerously autonomous. Household safety involves actions with very different consequences. Sending an informational alert is fundamentally different from contacting a family member or unlocking a door. We therefore had to separate reasoning from authorization. Another challenge was bringing multiple ecosystems together while keeping Guardian's internal model simple. Ring events, Alexa+ conversations, Fire TV state, and AWS services all have different interfaces and expectations. New-account Bedrock on-demand quota is 0 (not the documented 5.76B tokens/day default) with no self-service path to increase it. The quota console shows the AWS default prominently but doesn't surface the applied override. We also had to design the system so that a judge could understand the value quickly. Rather than demonstrating individual APIs independently, we built a single scenario that moves naturally from an event to context, policy evaluation, human approval, action, and resolution.
Accomplishments that we're proud of
We are particularly proud that Guardian demonstrates controlled autonomy rather than simply adding an LLM to a smart-home system. Guardian can recognize that an unexpected visitor is different from an expected delivery, understand that the owner is away, and recommend an appropriate response. More importantly, Guardian can say no. When asked to unlock a door automatically, Guardian blocks the action because the household policy prohibits it. When asked to check on a family member, Guardian recognizes that the action is consequential and asks for approval first. We also built a cross-device experience where the same household incident can be represented through the AI interaction and visualized on a Fire TV command center. The result is a prototype that demonstrates a broader idea: AI agents should not only know how to use tools—they should understand when they are allowed to use them. The hard constraint holds across every scenario, every tier, and both decision engines — rule-based and Bedrock. It's not a demo artifact. Pattern detection (Scenario D) is genuinely agentic — three low-signal events cluster into an escalation that none would trigger alone. Tests caught two real bugs before the demo did. Both are documented honestly in the README with what went wrong and how they were fixed. The entire stack deploys from zero with sam build && sam deploy --guided — no manual console steps.
What we learned
We learned that the hardest part of an AI agent is not giving it more capabilities. It is defining the boundaries around those capabilities.
Context matters enormously. The same event can require completely different responses depending on who is home, what was expected, what the household rules say, and how consequential the proposed action is.
We also learned that explicit policy decisions such as INFORM, ASK, and BLOCK make an agent's behavior easier to understand, test, explain, and trust.
Finally, building around MCP showed us how a reusable policy layer can sit between intelligent agents and real-world tools without requiring every agent to implement its own safety logic.
What's next for Guardian
The next step is to move Guardian from a hackathon prototype toward a production-ready household agent. We plan to add stronger identity and authorization, persistent household memory, richer Real Ring webhook integration (the EventBridge path is already wired — just needs a Ring adapter), Multi-household support, more Fire TV interactions, additional smart-home devices, and more sophisticated policy management. We also want to turn the Guardian Policy Engine into a reusable open-source policy-controlled MCP component that other AI agents can use when interacting with sensitive tools. Longer term, Guardian could become a household coordination layer where people define their rules once and AI agents consistently respect those rules across devices, services, and future smart-home technologies. The vision is not a home where AI makes every decision. It is a home where AI understands the situation, recommends the right action, and knows when the human should remain in charge.
Built With
- amazon-api-gateway
- amazon-bedrock
- amazon-cloudwatch
- amazon-dynamodb
- amazon-eventbridge
- aws-lambda
- aws-sam
- firetv
- github
- mcp
- mcp-(model-context-protocol-2025-11-25)
- nestjs
- node.js
- typescript
Log in or sign up for Devpost to join the conversation.