Daylight

Daylight turns everyday requests into routines you can review, refine, and trust.

Comment

Daylight: Routines That Start With a Conversation

Inspiration

I built Daylight for the Alexa+ hackathon track, inspired by the idea that an assistant should understand everyday intentions—not just execute a list of rigid commands. Many useful routines begin as simple requests: “Every weekday at 7:15, give me my calendar and the weather.” I wanted to explore how that request could become a routine a person can inspect, adjust, and approve before it is enabled.

Daylight is an Alexa+-inspired hackathon project, "not an official Amazon or Alexa integration". It is intentionally mock-only: no real provider APIs, API keys, calendar changes, messages, or device commands are used.

How I Built It

I built a conversational web demo with a React and TypeScript frontend, backed by a Node.js and Express service. A natural-language interpreter turns routine requests into structured drafts with schedules, conditions, ordered actions, and timezone details. The user can review the interpretation, edit it, and save it paused before separately approving activation.

The same routine lifecycle is available through a self-hosted MCP server. It supports Streamable HTTP and studio using MCP version 2025-11-25, with seven tools, four resources, and two prompts. The web interface and MCP server share the application’s service layer, so key approval rules are enforced on the server—not just represented in the UI. Routine and execution data is stored in a JSON-backed store, and timezone-aware scheduling uses Luxon.

The design principle can be summarized as: [ \text{Intent} \rightarrow \text{Draft} \rightarrow \text{Review} \rightarrow \text{Approval} ] A consequential change should happen only after the appropriate approval: [ \text{Mutation} \implies \text{Explicit approval} ]

What I Learned

I learned that a useful agent is more than a model connected to tools. It needs a clear lifecycle, structured data, and consistent rules across every interface. Supporting MCP also meant thinking beyond tool names: clients need discoverable capabilities, predictable schemas, and behavior that matches the web demo.

I also learned how much precision routine management needs. A natural-language time must be interpreted in the right timezone; daylight-saving changes and already-passed local times can affect what a schedule means. Making the interpretation visible gives people a chance to catch mistakes before a routine is saved or enabled.

Challenges

One challenge was balancing natural-language convenience with predictable scheduling. Another was keeping safety behavior consistent across the web API and both MCP transports. Approval gates, edits that require fresh review, and exact-phrase deletion checks needed to be enforced by shared server-side logic.

I also wanted the demo to show failure honestly. Daylight can simulate a step failure, record what happened, and demonstrate a retry—without pretending that a real external service was contacted. Keeping that boundary clear was part of building a trustworthy hackathon prototype.

Project Scope

Daylight demonstrates how conversational routine management and MCP can work together in a transparent, reviewable experience. For this submission, actions and providers are simulated; connecting real services would require a separate integration, security, and authorization design.

Built With

Share this project:

Updates

Submission history