Always Near

Wearer-approved insights from Bee conversations, designed to help a wearer and their trusted circle notice possible concerns and decide when to check in.

Comment

Inspiration

My inspiration was the idea that people living independently, including those experiencing memory difficulties or other challenges, could benefit from an extra layer of support without giving up control of their lives. I built Always Near to extend the growing capabilities of AI recorders such as Bee, helping trusted family, friends and caregivers notice possible concerns and know when a check-in might matter.

An everyday conversation can contain an unexpected financial request, a concerning interaction or a change in how someone says they are doing. Those moments are easy to miss in a long conversation feed. With the wearer's approval and control over sharing, Always Near surfaces possible signals to their care circle, supporting awareness without claiming complete monitoring or replacing human judgment.

The wearer owns the Bee connection and decides what to share. A care circle is a group of trusted contacts invited by that wearer, not a substitute account owner. Always Near is not an emergency service, medical or diagnostic product, or a guarantee that every concern will be detected.

What it does

Always Near processes conversation parts that the Bee wearer personally approves and presents structured, dated findings. The owner can review a recording day, see the observed processing count, and inspect categorized findings with their attention level, time, short paraphrase and uncertainty warning.

For the demo, I recorded a scripted gift-card scam conversation on a Bee device and personally approved its upload to Always Near. The walkthrough follows Robert, the wearer, and his brother Sam, a trusted contact, showing how a possible concern becomes visible to Robert and is shared with Sam within the wearer's permissions. Robert and Sam are fictional roles; the app results come from the actual Bee recording, not a confirmed real-world incident.

How I built it

The local Node.js collector calls Bee's official CLI at runtime. It reads the selected Bee conversation data, maps the source into bounded parts and lets the wearer review each part locally. The wearer approves selected parts and separately confirms the final upload. This is a controlled Windows developer bridge, not a supported hosted multi-user Bee connection or automatic background sync.

An authenticated Amazon API Gateway endpoint accepts approved input into an SQS processing path designed for encrypted, short-retention handling. AWS Lambda calls Amazon Bedrock for structured extraction, validates the output and stores structured findings in DynamoDB. The system is designed not to retain full approved conversation text in the results database or operational logs. The current trial's result cards do not display a source transcript.

The browser application uses Next.js and React, with separate Cognito wearer and trusted-contact logins demonstrated in the video. Static assets are hosted on S3 behind CloudFront. Terraform describes the production infrastructure. Source boundaries separate the collector, modular Python backend, web application and infrastructure.

I built Always Near as a one-person project, using GPT-6.1 Sol-High for primary development and Claude Opus 5.5 High for reviews. Amazon Bedrock powers the deployed conversation analysis. I used OpenAI Cedar for the demo narration, with transcription-aligned captions and a separate audio-quality assessment; those media checks do not certify the product or video.

The revised input flow is explicitly unfiltered. The wearer must personally accept the applicable Data and AI policies and approve the parts; approved speech can include spoken secrets. Output checks and narrow structured storage are separate protections and do not mean the input is redacted. The demo does not expose source conversation text, sensitive values, credentials, pairing codes or contact details.

Challenges I ran into

The organizers' Bee API forum clarification for this prototype (https://amazonappdev2026.devpost.com/forum_topics/45413-bee-api-how-can-a-third-party-app-get-its-own-app-id) described custom app IDs, non-Developer-Mode authorization and hosted third-party integration as unsupported. I use the provided official CLI identity in a wearer-controlled local bridge and do not collect Bee passwords in my application. Existing developer CLI, API and MCP tools are useful, but they are not the same as a consumer-ready hosted connection.

Another challenge was preserving the source's meaning without overstating coverage. Separate scripted scenes can arrive within a Bee conversation container. Always Near's adapter preserves Bee conversation IDs and can combine transcription blocks within one source conversation before making bounded parts; an analyzed part is not a promise that every individual call or scene was independently identified. The app shows observed processing and explicitly warns that missing or empty results are not an all-clear.

I also separated generation from delivery. A saved schedule preference is not proof that a message was sent, and a summary snapshot is not a live transcript. Refresh reads an existing snapshot; generation and recipient delivery remain separate actions.

Accomplishments I'm proud of

I completed a working Bee-to-AWS-to-dashboard flow using wearer-approved recordings. The dashboard separates informational from higher-attention findings and keeps uncertainty and incomplete-coverage messages visible. The final video also shows Sam's separate invitation acceptance and limited helper portal, rather than implying that the wearer can act or consent for him.

The data path uses wearer-owned authorization, explicit local approval and content-free deduplication. The results database is designed to hold structured outputs rather than full conversations. I verified saved daily summaries separately from contact delivery.

What I learned

Developer access and a consumer-ready integration are different milestones. A working local CLI connection is useful for a controlled demonstration, but it must not be presented as an ordinary user's hosted Connect Bee experience.

I also learned to distinguish a possible conversational concern from a confirmed event, and observed analysis from complete monitoring. A useful interface needs dates, coverage and limits alongside the finding, not just a prominent warning label.

What's next

I recognize that manually transferring wearer-approved Bee conversation parts into Always Near is not the long-term experience this product needs. For this beta and hackathon, the controlled bridge demonstrates the overall idea I've built. Longer term, I hope Amazon and the Bee team will offer publicly available OAuth connectivity and/or a permission-gated hosted Model Context Protocol (MCP) service, with scoped wearer authorization and revocation, so users can connect products such as Always Near more easily. This is a feature request, not an announced capability or promised release date.

Built With

Share this project:

Updates

Submission history