Community_Mate

• 

  community_mate

• 

  Server.py

Inspiration

Apartment residents often navigate separate portals, documents, and office conversations to complete simple tasks. Booking a study room, reporting a broken refrigerator, or finding package pickup information should feel like one conversation.

CommunityMate explores how an Alexa-style concierge could bring those everyday interactions together. The goal was to build more than a question-answering chatbot: a resident should be able to find information, take an action, and check the saved result.

What it does

CommunityMate provides a minimal, voice-first web experience where residents can:

• Discover amenities, check availability, and make or cancel reservations.
• Submit maintenance requests and retrieve their status.
• Check packages received by the concierge and request assistance.
• Search community policies, office information, and resident guides.
• Retrieve read-only rent, autopay, and lease-renewal information.

The fictional community includes 17 facilities with distinct reservation, walk-in, and information-only access modes. Actions that change records require explicit confirmation through the application.

This is an independent simulated Alexa+ experience, not a direct Alexa integration or a connection to a real apartment-management system.

How I built it

The application follows this architecture:

Voice or text → Strands Agent → Amazon Bedrock → MCP server → SQLite and community documents

Amazon Bedrock, using Amazon Nova 2 Lite, interprets requests and generates responses. Strands Agents hosts the MCP client and coordinates tool execution.

The Python MCP server exposes operational tools, readable resources, and reusable workflow prompts. SQLite persists reservations, maintenance tickets, and other demo records. Searchable Markdown documents provide policy evidence and source metadata.

The browser interface supports speech recognition, spoken replies, text input, conversation history, and confirmation cards. Confirmation is controlled by application code rather than trusting a model-generated claim of consent.

What I learned

I built CommunityMate as a learning project, developing and testing each layer before connecting the full experience.

One important lesson was the distinction between tools, resources, and prompts: tools retrieve operational records or perform actions, resources provide context, and prompts describe reusable workflows.

I also learned that conversational instructions cannot replace database rules. Availability does not reserve a slot, a received maintenance ticket does not mean a technician is assigned, and a facility’s operating hours do not establish bookable times. Those distinctions need to exist in both the agent’s instructions and the backend.

Working on reservations taught me about transactions, foreign keys, conflict prevention, cancellation history, and safe retries. Building the voice interface taught me to separate response wording from speech delivery—and to treat unclear transcripts as uncertainty rather than facts.

Challenges I faced

Dependency differences between the MCP server and Strands client required separate Python environments. AWS authentication, IAM permissions, and an initial Bedrock account-verification delay added onboarding steps.

The Alexa developer pages available to my account displayed “Coming Soon,” so I built the independent web simulator path.

Making the conversation natural was another challenge. Early replies read database fields like a form and asked several questions at once. I refined the instructions toward short answers, contextual follow-ups, and one question at a time. Unclear speech also exposed the risk of carrying an incorrect interpretation into an action proposal; this remains an area for further evaluation.

Accomplishments

CommunityMate demonstrates a complete path from a spoken request to a confirmed, persistent operation. Booking transactions prevent conflicting reservations, cancellation preserves history, and residents can retrieve the resulting records through conversation.

The project also includes automated checks for booking behavior, resident scoping, maintenance workflows, MCP discovery, resource retrieval, and simulator confirmation handling.

What’s next

The next steps are stronger handling of ambiguous speech, authenticated resident identity, richer maintenance workflows, and integrations with actual property-management systems. The current MVP uses fictional data and a fixed demo resident, providing a foundation for exploring those capabilities without presenting simulated operations as real services.

Built With

• amazon-bedrock
• amazon-nova
• aws-cli
• css3
• html5
• javascript
• model-context-protocol
• python
• sqlite
• starlette
• strands-agents
• uvicorn
• web-speech-api