CrisisPilot

When household incidents change fast, CrisisPilot turns Alexa+ conversations into coordinated action with human-approved protected steps and verified outcomes.

Comment

Inspiration

Household incidents rarely stay simple.

A water leak can become an electrical hazard. A shutoff may be requested, but the user still needs to know whether it actually worked. In stressful situations, the hardest part is often not finding one answer, but keeping track of what changed, what has already been done, what still needs approval, and when automation should stop.

That became the idea behind CrisisPilot: instead of replacing human judgment, coordinate the decisions around it.

What it does

CrisisPilot turns an Alexa+ conversation into a stateful household incident workflow.

A user can report something naturally such as:

There’s water coming through my ceiling.

CrisisPilot triages the incident, keeps track of its state, gathers relevant household context, and proposes the next safe step.

For protected actions such as shutting off a utility, sending a notification, or booking a service provider, CrisisPilot cannot authorize the action itself. The user must explicitly approve it.

After execution, CrisisPilot does not immediately report success. It separately checks the resulting state before marking the action as verified.

If new information changes the risk, for example:

The water is coming through the ceiling light.

the same incident is re-triaged.

If the user then reports:

I see sparks near the light.

CrisisPilot enters Emergency mode, blocks protected automation, and surfaces reviewed emergency guidance.

The model can propose actions. It cannot authorize them.

How I built it

CrisisPilot uses a simulated Alexa+ experience through a React web interface.

The request flow is:

Alexa+ simulation → Amazon Bedrock → MCP tools → CrisisPilot safety layer → approved action

Amazon Bedrock interprets the conversation and selects tools.

A self-hosted Model Context Protocol (MCP) server exposes the product capabilities over Streamable HTTP, including:

  • incident triage
  • household context retrieval
  • utility-state checks
  • provider discovery
  • incident status
  • utility shutoff
  • contact notification
  • service booking
  • incident resolution

The MCP server does not delegate safety decisions to the language model.

Deterministic server-side logic manages:

  • incident state
  • re-triage
  • approval requirements
  • single-use approval tokens
  • action parameter validation
  • execution verification
  • emergency escalation
  • automation lockout

Approval tokens are scoped to the exact incident, action, and parameters, expire after a short period, and cannot be created by the model.

The simulator also exposes the live MCP calls and incident audit trail so the orchestration is visible rather than hidden behind the interface.

A workflow, not just a chatbot

One of the most important design decisions was making the incident persist across multiple turns.

A typical CrisisPilot workflow looks like:

Report → Triage → Recommend → Approve → Execute → Verify → Re-triage → Escalate if necessary

During testing, I validated this entire sequence as one continuous incident.

The same incident can move from a normal water leak to electrical proximity risk and finally to an emergency state without losing its history.

That statefulness is what separates CrisisPilot from simply asking an assistant a series of unrelated questions.

Challenges

One challenge was deciding what the LLM should control.

Allowing the model to directly perform safety-sensitive actions would have made the system simpler, but much less trustworthy. I instead separated reasoning from authorization: Bedrock can decide which tool may be useful, while the server decides whether that tool is currently allowed to run.

Another challenge was action verification. A successful API response does not necessarily mean the physical outcome occurred, so CrisisPilot treats execution and verification as separate stages.

I also implemented a DynamoDB-backed storage adapter, but live DynamoDB access in the AWS account was blocked by an organization-level Service Control Policy. The demo therefore uses SQLite through the same storage abstraction while Amazon Bedrock remains live.

Finally, designing emergency behavior required deliberately limiting automation. When an emergency indicator is detected, CrisisPilot stops trying to be helpful through more automation and instead locks protected actions.

What I learned

The biggest lesson was that good agentic systems need boundaries as much as they need intelligence.

LLMs are useful for understanding changing natural-language context and deciding which capability may be relevant. Deterministic software is better suited for enforcing state transitions, authorization, and safety constraints.

Combining the two produced a system that is more explainable and controllable than relying on either alone.

I also learned that verification is a separate product problem from execution. A system should not say it worked simply because an action request was accepted.

What I am proud of

CrisisPilot is not a collection of disconnected AI features.

It is one end-to-end incident workflow where:

  • context persists
  • risk can change over time
  • protected actions require human approval
  • approval is enforced outside the model
  • executed actions require verification
  • emergency escalation disables automation
  • every important transition is visible in an audit trail

Amazon Bedrock reasoning and MCP communication are live in the prototype. Physical household actions such as utility control, notifications, provider discovery, and bookings are intentionally simulated.

What's next

The next step would be connecting CrisisPilot to real smart-home and service-provider APIs while preserving the same approval and verification model.

Other extensions could include richer household profiles, multiple simultaneous incidents, shared family coordination, additional incident playbooks, and persistent cloud storage.

The long-term goal is not to make an AI that takes control during an emergency.

It is to build an assistant that helps people stay in control when a situation becomes difficult to coordinate.

Share this project:

Updates

Submission history