Relay

Relay turns wearable voice commands into trusted-contact help and AI agent tasks. Share context, connect with your people and review coding work through one companion built around consent and control.

Comment

Inspiration

Most assistants focus on what happens after you give a command. I wanted to explore something more personal: what happens when you need someone to answer?

Sending an alert is only the beginning. Has anyone acknowledged it? Can they connect with you? Do they have useful context? Has the request actually been resolved?

That became Relay’s central idea: a wearable companion that helps you stay connected to your people and your work, with consent and human control built into the experience.

What it does

Relay brings together two workflows:

Trusted-contact help: Request support through a button, a missed check-in, or an exact help phrase received during an armed session. Accepted contacts receive in-app alerts in their open dashboards. A contact can acknowledge the request, join permission-based live audio, and view location when the owner chooses to share it. The session remains open until explicitly cancelled or resolved.

Coding-agent assistance: Prepare a task from text, browser dictation, or a Bee-compatible transcript event. Review the request before starting a real Codex investigation. The agent inspects a bounded checkout fixture, runs its tests, and returns evidence and a proposed fix for review.

The principle connecting both workflows is simple: a command should lead to a visible, understandable outcome.

How I built it

I built Relay as a browser companion using JavaScript, Node.js, Express, Zod and SQLite, with a responsive interface in warm off-white and cobalt blue.

The backend persists help sessions, contact consent, escalation deadlines, check-ins and agent results. WebRTC provides live audio, while the browser’s Geolocation API supplies optional location sharing with timestamps and accuracy.

For the wearable pathway, I implemented a bridge around Bee’s documented real-time utterance format and official CLI. Every event carries provenance so documentation examples, synthetic rehearsals and CLI-ingested events remain distinguishable.

The coding connector invokes an authenticated local Codex CLI in a read-only sandbox with a dedicated task directory and a runtime limit. Relay never automatically applies the proposed patch.

I deployed the browser service to Azure over HTTPS. The hosted demo also presents the report from a verified local Codex run.

Challenges I faced

The hardest challenge was distinguishing requesting help, acknowledgement and an actual audio connection. These are separate events, so Relay displays them separately rather than treating a queued alert as proof that someone is responding.

Wearable transcripts introduced another challenge: speech can arrive late, be repeated, or come from an unverified speaker. I added armed sessions, exact-phrase matching, duplicate suppression and timestamp checks. These controls reduce accidental triggers without pretending to authenticate the speaker.

I also had to handle audio connection timing, contact access boundaries and session cleanup. Cancelling or resolving a session now stops the browser audio workflow and removes shared location from the server.

What I learned

I learned that useful agent systems need more than an impressive response. They need clear permissions, durable state, observable failures and evidence that a task actually ran.

I also learned to distinguish integration compatibility from hardware validation. Implementing Bee’s documented event contract is useful progress, but it does not establish that the complete physical-device pathway works.

Accomplishments

  • Built the complete browser help-request and acknowledgement workflow.
  • Established WebRTC audio between two independent browser contexts using synthetic microphone input.
  • Verified permission-based location sharing and session cleanup.
  • Completed a real Codex investigation that reproduced a discount-calculation bug and proposed a fix.
  • Passed 12 automated backend tests and eight browser workflow checks.

Current scope and what’s next

Relay currently delivers in-app alerts, not emergency-service dispatch. Browser tests used synthetic audio and mocked Mumbai location; no physical Bee device has been tested.

The next milestone is testing with authorised real Bee or Apple Watch data, which is also needed to establish eligibility for the Bee track. After that, I want to validate transcript latency, improve notification delivery and test the experience with real users.

What it does

How we built it

We built Relay using JavaScript, Node.js, Express, Zod and SQLite, with a responsive off-white and cobalt interface. The backend persists contact consent, help sessions, escalation deadlines, check-ins and agent reports.

WebRTC enables live audio between consenting participants. Browser geolocation provides optional location sharing, including timestamps and accuracy.

A companion bridge consumes Bee’s documented real-time utterance format through the official CLI. Events retain their provenance, distinguishing documentation examples, synthetic rehearsals and CLI-ingested input.

For coding assistance, Relay invokes a real, authenticated local Codex CLI in a read-only sandbox. The owner reviews each task before execution and receives test evidence and a proposed fix. We deployed the browser service to Azure over HTTPS.

Challenges we ran into

The biggest challenge was separating an alert from an actual response. Relay tracks requesting help, contact acknowledgement and audio connection as distinct states.

Transcript input also requires care: events may be delayed, duplicated or spoken by an unverified person. We implemented armed sessions, exact-phrase matching, duplicate suppression and timestamp checks.

We worked through WebRTC connection timing and session cleanup, ensuring that cancellation or resolution stops the audio workflow and removes shared location. Without physical Bee hardware, we also had to distinguish a working browser rehearsal from a validated device integration.

Accomplishments that we're proud of

  • Built a complete browser workflow from contact consent through help requests, acknowledgement, connection and resolution.
  • Established real WebRTC transport between two independent browser contexts using synthetic microphone input.
  • Verified permission-based location sharing and cleanup.
  • Completed a real Codex investigation that reproduced a checkout discount bug and returned a proposed fix.
  • Passed 12 backend tests and eight browser workflow checks.
  • Deployed a working HTTPS demo and produced a landscape product video.

What we learned

Reliable assistance depends on clear state, explicit permissions and visible outcomes. A queued alert does not establish that someone has received it, and acknowledgement does not establish that audio is connected.

We learned to keep agent execution bounded and reviewable, preserve evidence of what actually ran, and make failures understandable.

We also learned that API compatibility and physical-device validation are separate milestones. Supporting Bee’s documented event format is a foundation; genuine device testing is still necessary.

What's next for Relay

Our next priority is validating the complete pathway with authorised real Bee or Apple Watch data, including transcript latency and disconnection behaviour. This is also necessary to establish Bee-track eligibility.

We then want to add dependable external notifications, strengthen cross-network audio connectivity, and conduct usability testing with real users.

For agent assistance, we plan to expand beyond the checkout fixture into explicitly authorised project workspaces while preserving task review, bounded permissions and execution evidence.

Relay currently provides in-app alerts and does not contact emergency services.

Built With

Share this project:

Updates