ATLAS: Alexa-Powered Infrastructure AI

Turning Alexa into real-world intelligence for homes and buildings, powered by local AI agents that monitor, investigate, act safely, and verify results.

Comment

ATLAS: Alexa-Powered Infrastructure AI

From smart homes to real-world infrastructure

Built in Ecuador by InnerChispa LLC | Powered by InnerOS | Local-first AI

What if Alexa could do more than control devices? What if it could understand an entire property, investigate failures, request permission to act, and prove what happened afterward?

💡 Inspiration: the problem we wanted to solve

A modern home can have Alexa, solar panels, batteries, smart alarms, access control, cameras, networking equipment, video doorbells, and automation platforms. A residential building adds CCTV recorders, switches, Wi-Fi access points, intercoms, VoIP and dozens of independent health signals.

The devices may be connected, but their knowledge is fragmented. When something goes wrong, people still check many dashboards, correlate timestamps, decide what to do, and hope the action worked.

We started with a simple challenge: make Alexa a safe voice interface to real operational intelligence, rather than another collection of isolated commands. Privacy and human control mattered from day one: an AI should never be able to authorize its own consequential physical operation.

🧭 The journey: Ambient Guardian → InnerOS / Inner Oz → Atlas Control → ATLAS

1. Ambient Guardian: ask what happened, not just what is on. Our first concept focused on home status, front-door activity, incident timelines, and persistent evidence. We built a working MCP backend and a repeatable browser demonstration rather than a slide-only prototype.

2. InnerOS / Inner Oz: naming collided with speech recognition. We initially tried to expose the name of our underlying agent platform directly to Alexa. Real Echo work revealed invocation-name pronunciation problems, accent-dependent recognition, regional settings, and English-Spanish language mismatches. Some natural requests were routed to the wrong system. We learned that a good software name is not necessarily a usable spoken name.

3. Atlas Control: a clearer voice entry point. We refined the Custom Skill identity and interaction models, added natural utterance variants, deterministic intent/topic routing, and language-aware replies. We learned to distinguish what the speech recognizer heard from what the infrastructure agent should do.

4. ATLAS: from home assistant to infrastructure intelligence. The product outgrew its original name. It now connects home energy and security contexts with site-specific building monitoring, local AI, governed operations, and verifiable incident history. The underlying platform remains InnerOS; the voice-facing product is ATLAS.

An important engineering lesson: voice interfaces have short response deadlines, while network diagnostics and corrective actions may take much longer. We separated immediate responses, durable jobs, owner approvals, and later evidence verification.

🏠 Real conversations: solar energy, home health, and context

A useful conversation is not a canned command such as “turn on the lights.” It sounds like:

“Alexa, how is the solar energy at home?”

ATLAS can draw on monitored energy context to explain generation, battery state, grid status, and relevant outage history. The aim is to answer in natural language, not simply read a sensor identifier. Solar history and timezone corrections were real parts of the development work.

Other home contexts include Home Assistant, the Intelbras alarm, UniFi networking, cameras/NVR, and authorized Echo speech announcements. The architecture preserves existing vendor integrations instead of indiscriminately duplicating devices.

🏢 From one home to a real building: Torres Bellini 1 and 2

Torres Bellini 1 and 2 in Guayaquil, Ecuador are a real infrastructure monitoring case, separate from the home. An InnerOS monitoring agent observes site-scoped networking, access points, video infrastructure, gateways, and communication equipment.

In one inspected monitoring snapshot:

  • 14 monitored infrastructure targets
  • 9 reachable
  • 5 not responding
  • A reachable gateway and functioning site monitoring connection

This is real building-monitoring data, not a fictional dashboard. It is also not proof that every proactive Alexa or phone notification has been delivered. We keep monitoring, spoken access, notification routing, and delivery receipts as separate verification layers.

ATLAS must be able to distinguish “How is my home?” from “What equipment is offline at Bellini?” Site identifiers, access permissions, severity, event deduplication, and tenant boundaries make that separation essential. Our authorized Bellini scope is Towers 1 and 2, not the rest of the surrounding complex.

🔐 A defining feature: Alexa cannot approve its own actions

This is where connecting AI to the physical world becomes serious.

Consider an operator asking ATLAS to restart a UniFi access point because it has become unreachable. The request is not equivalent to fetching a status report: a restart may temporarily interrupt Wi-Fi for users.

The governed flow is:

  1. Understand: identify the exact device, site, and proposed operation.
  2. Assess: check allowlists, current state, potential impact, duplicates, and safety policy.
  3. Prepare: generate a bounded action proposal and an evidence record.
  4. Request human authorization: send a separate approval request through the existing WhatsApp owner workflow, with an explicit approve/reject decision.
  5. Execute only after approval: use a bounded operation path that cannot be self-authorized by the model.
  6. Verify: observe the device returning to the intended state and attach the result to the incident record.
  7. Report: communicate success, failure, or incomplete verification without inventing a result.

UniFi restart and WhatsApp-approval workflows were implemented and tested during development, including recovery and duplicate-handling fixes. A prepared operation is not a completed restart; a valid approval is not proof of recovery. This separation is intentional.

We originally experimented with exposing preparation and approval as MCP tools. We recognized the security flaw: if the same AI could call both, approval would be meaningless. We changed the design so MCP can prepare but cannot independently approve or execute consequential actions. Tokens expire, replays are rejected, and positive outcomes depend on observed state.

🕒 Investigating incidents: “What happened at 3 AM?”

ATLAS normalizes events from different systems into a timeline and creates persistent Incident Receipts. The demo illustrates how a front-door motion event, visitor activity, nearby camera or intercom context, and subsequent state changes can become a readable explanation backed by evidence.

Ring: we implemented a Ring-compatible simulation and an official-provider adapter with signed-webhook validation and event normalization. The public Ring scenario is explicitly labeled SIMULATED unless an authenticated official provider event has actually been verified. We do not pretend to own a Ring doorbell or portray generated surveillance imagery as actual footage.

Persistent SQLite receipts record the event, interpretation, relevant evidence, prepared action, and verification state. This makes the system auditable beyond a one-off chatbot answer.

🧠 How it works: local intelligence with governed tools

Alexa / physical Echo Custom Skill       Browser Judge Mode
                 \                      /
                  Signed voice/demo gateway
                            |
                  ATLAS / InnerOS context
                            |
          Official MCP Python SDK v2 (Streamable HTTP)
                            |
        AWS Strands read-only synthesis + local Qwen/vLLM
                            |
       Deterministic intent and authorization policies
                            |
 Home Assistant | Intelbras | UniFi | Cameras/NVR | Solar
 Grandstream/VoiceOps | Ring-compatible events | Bellini
                            |
        Separate human approval where required
                            |
              Execute → Observe → Verify → Receipt
  • Local-first: Qwen through vLLM on our own compute nodes keeps sensitive infrastructure reasoning closer to the source.
  • AWS Builder: we integrated the real AWS Strands Agents SDK with an explicit OpenAI-compatible local provider for read-only reasoning and incident synthesis.
  • MCP: an official MCP Python SDK v2 server exposes a tested Streamable HTTP tool interface.
  • Deterministic safeguards: parsing, allowlists, authorization, action execution, and post-action verification are not delegated to free-form model guesses.
  • VoiceOps / Grandstream: bounded call preparation and evidence-driven communications workflows extend the concept beyond dashboards.
  • Testing: automated regression tests, official MCP client smokes, Docker packaging, CI, and reproducible Judge Mode scenarios support independent evaluation.

Our Alexa Custom Skill and self-hosted MCP server are distinct from direct Alexa+ MCP Toolkit partner entitlement, which has not been established. We do not claim private partner access merely because consumer Alexa+ is available on an Echo.

🌎 Built in Ecuador: bilingual development was a real engineering challenge

English and Spanish were not just translation toggles. We worked through invocation pronunciation, an English-configured Echo receiving Spanish requests, regional locale compatibility, mixed-language terminology, natural command phrasing, and accurate routing between home and building contexts.

Interaction models span en-US, es-US, es-MX, and es-ES, but real-device behavior still depends on the Echo account, locale, and tested utterance. Our learning was to implement language-aware routes and reliable fallbacks rather than promise universal speech recognition.

🛠️ Challenges, failures, and solutions

Challenge What happened What we changed
Alexa invocation and accents InnerOS / Inner Oz was hard to recognize consistently Evolved to Atlas Control and broadened bilingual utterances
Alexa response limits Infrastructure operations exceed voice deadlines Separated quick speech, durable jobs, and later confirmation
MCP SDK generation conflict Existing shared Python environments used incompatible MCP versions Isolated dependencies and tested with the official MCP client
AI self-approval risk A model could theoretically prepare and approve its own operation Removed approval/execution from MCP and required an external human boundary
Strands + strict vLLM Empty tools: [] caused HTTP 400 in one provider path Added a bounded compatibility fix
Amazon Bedrock access A test returned ValidationException: Operation not allowed Used real AWS Strands with local Qwen; no false Bedrock success claim
Alexa+ partner tooling Direct MCP add-on tooling was not generally available to hackathon entrants Built an accepted self-hosted MCP + Judge Mode approach
Ring without hardware Judges must reproduce events without private Ring credentials Signed-provider adapter plus clearly labeled event simulator
Site-specific truth A home question must not be mistaken for Bellini status Explicit site context, scope, and source labels

We documented the failed approaches and actionable developer feedback in our friction log.

🎬 What the judges can test

The public repository includes source, a browser Judge Mode (voice-edge simulation over the real backend), MCP tests, three reproducible scenarios, security documentation, and a video walkthrough. The demo distinguishes:

  • REAL: local server, MCP protocol, policy logic, incident receipts, and separately evidenced physical integrations.
  • SIMULATED: browser Alexa+ voice edge and Ring-compatible test events.
  • CODE_READY: provider integration code not yet validated against an authenticated live account.
  • REQUIRES RECEIPT: physical corrective operations, WhatsApp approvals, and proactive delivery claims without current execution evidence.

Watch the demo: https://www.youtube.com/watch?v=Fyyie6btDw0

Explore the MIT-licensed code: https://github.com/Rafa-Innerchispa/inneros-ambient-guardian-amazon-2026

🚀 Why ATLAS matters

We built ATLAS to cross a boundary that conversational AI rarely crosses responsibly: from answering a question to understanding a physical system, requesting permission for consequential actions, and proving what actually changed.

Homes are the starting point. Buildings like Bellini show why the same local-first, site-aware, accountable intelligence layer can matter to infrastructure operators and entire communities.

ATLAS is Alexa-powered intelligence for the real world.

Built by InnerChispa LLC | Powered by InnerOS | Guayaquil, Ecuador

Built With

  • alexa+
  • amd-rocm
  • aws-strands-agents-sdk
  • docker
  • github-actions
  • model-context-protocol
  • python
  • qwen
  • starlette
  • uvicorn
  • vllm
Share this project:

Updates

Submission history