This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.
What I Built
Meridian turns jet-lag planning into a premium service that independent travel advisors can sell to their clients.
Anyone can book a flight from London to Tokyo. The harder part is helping a traveller adjust to a completely different time zone—with a plan grounded in circadian science, tailored to their schedule, and realistic enough to follow.
Today, producing that kind of plan can mean hours of research and manual coordination. Meridian compresses the process into an approximately two-minute AI crew run.
Give it a flight itinerary, and Meridian produces a day-by-day plan with light exposure windows, sleep timing, caffeine cutoffs, research-backed explanations, and a calendar-ready .ics file. It can also account for calendar conflicts and learn from previous trips, so the next plan can reflect what actually worked for that traveller.
The business model is simple: help travel advisors sell expertise, not just flights.
An advisor could offer Meridian-generated plans as a £20–50 premium add-on per trip, with the potential to differentiate their service without spending hours on every itinerary. That price is a hypothesis to validate, not revenue I've earned.
What makes Meridian different is that it doesn't just generate recommendations. It scores them, rejects plans that violate deterministic constraints, records evidence, and makes the reasoning inspectable.
Demo
Try it live: https://meridian-afud.onrender.com
Choose a route, explore the resulting plan, and download the calendar file.
Meridian has three levels of transparency:
-
Calm (
/) — a clean, traveller-facing experience with daily recommendations and minimal technical detail. -
Guided (
/?depth=guided) — expand each recommendation to inspect its score, supporting research, rejected drafts, and relevant memory paths. -
Operator (
/crew) — watch the five-agent crew work through its live-feed interface, including tool activity and evaluation results.
The public demo uses a deterministic replay transcript. That means judges can explore the experience without waiting for external model calls or risking API costs. To run the live open-model crew locally, configure AGENT_PROVIDER=nebius and run bun run dev.
Code
GitHub: https://github.com/sneldao/meridian
Meridian
Agents that fly ahead of you. A crew of long-running agents resets your body clock before you land — turning a trip across time zones into a day-by-day circadian shift plan grounded in real literature and your actual calendar.
Built at Accel AI Innovate London, Oct 2026.
Agents propose, code disposes. A deterministic placement solver drafts the times, the crew debates intent, and a scorer backed by a phase-response model decides — a plan's declared shift is checked against what its zeitgeber timing can actually deliver.
Live: https://meridian-afud.onrender.com · deck: /pitch
Quickstart
bun install
cp .env.example .env.local # defaults to featherless (needs a key) — AGENT_PROVIDER=replay runs with zero keys
bun run dev # http://localhost:3000
Optional: SUPABASE_URL + SUPABASE_SERVICE_ROLE_KEY in .env.local persist
run history server-side (project vpeakvspljdoxbwfsdvw, see
providers.md).
The crew
| Agent | Job |
|---|---|
| Mara · ANALYST | Reads the wearable baseline + adherence profile |
| Jun · RESEARCH | Pulls |
Built from start to finish during the challenge window, with a public repository and a deployed demo.
How I Built It
Meridian is built around five AI agents, open-weight models, a deterministic planning and scoring layer, and a persistent graph memory.
The model provider is configurable: Nemotron models through Nebius Token Factory, or Qwen3-32B through Featherless, with Anthropic available as a comparison provider. The AGENT_PROVIDER environment variable lets me switch providers without redesigning the crew.
The architecture follows one principle:
Agents propose. Code disposes.
The models handle research, interpretation, planning, and evaluation. Deterministic code remains responsible for enforcing the constraints that the final plan must satisfy.
The crew has five roles:
- Mara — Analyst: interprets the traveller's baseline and adherence profile.
- Jun — Researcher: retrieves scientific literature through ScienceMadeReadable and Firecrawl, with DOI-level provenance for cited research.
- Otto — Planner: proposes daily interventions using destination context, including Qloo data.
- Iris — Evaluator: reviews the plan in a fresh context and explains the scoring verdict, including rejections.
-
Rex — Negotiator: coordinates movable calendar events and produces the final
.icsfile, with Google Calendar writes available through Composio MCP.
A deterministic placement solver drafts the plan's structure, and a circadian phase-response scorer evaluates proposed interventions before they are committed. The language models do not get to override those checks just because a recommendation sounds plausible.
The memory layer
Meridian uses FalkorDB to maintain a separate graph for each tenant. Trips, daily plans, interventions, citations, check-ins, and findings become connected nodes and edges.
Rather than asking an agent to invent a database query, Meridian exposes a fixed set of tools backed by human-written Cypher. These include recall_findings, prior_failures, calendar_conflicts, and record_finding.
Every lookup can return its graph traversal path. If the requested information isn't in the graph, the system reports that absence rather than pretending to remember something.
Over time, traveller check-ins feed back into the graph. A failed early-morning light recommendation, for example, can inform future planning instead of disappearing into an old conversation.
The rest of the stack
- ElevenLabs: distinct voices for each agent, streamed alongside the crew feed.
- Composio MCP: calendar integration and real Google Calendar writes.
-
MCP server: exposes eight tools through
POST /api/mcp. - Supabase: persists run history.
- Next.js PWA: keeps saved plans accessible offline.
- Render: deploys the application and private FalkorDB service through infrastructure-as-code.
The result is a system in which model reasoning, hard constraints, evidence, and memory have separate responsibilities.
Why Does Open Innovation Matter?
Open-weight models make the economics of a multi-agent side hustle more practical—and let me build a system around verification rather than blind trust in a model.
1. The cost structure matters
A crew run involves roughly 18–20 tool calls and reasoning across five agents. Running that workflow repeatedly can make inference costs a meaningful part of the product's margin.
Meridian can use Qwen3-32B or Nemotron through configurable providers, rather than requiring every task to run on a premium closed model. That gives the product more flexibility to experiment with providers, control costs, and build around the economics of a small business.
At a proposed £20–50 resale price per trip, that flexibility matters. The exact margin still needs to be validated against real usage, provider pricing, and support costs.
2. Verification matters more than confident prose
In one benchmarked run, the Nemotron-based crew took 143 seconds and made 18 tool calls. The deterministic scorer rejected two drafts before a retry recovered. Four of five days were locked at a score of 0.91, with 15 citations.
The run reached the same physiological-limit outcome as the corresponding Claude run.
That's the architectural result I'm most interested in: the model can change without removing the rules that constrain the final plan.
Open weights are not automatically safer or more accurate. Meridian's approach is to give the models useful work to do, then independently check the output against explicit constraints.
Because jet-lag advice concerns health-related behaviour, the scorer is a constraint layer—not proof of clinical safety or a substitute for professional medical guidance.
3. The system stays replaceable and inspectable
The model provider, graph database, research tools, and agent interface are separate components. That makes it possible to compare models, replace services, and inspect how a recommendation was produced without rebuilding the entire product around one vendor.
Open innovation made it practical to experiment with this combination of models, memory, and tooling as a small project, rather than treating the full system as an expensive enterprise-only architecture.
What I Learned
A cheap model inside a verifier can be more useful than an expensive model working without one. The scorer caught SHIFT_TOO_FAST violations across providers. The model's job is to reason about intent; deterministic code handles constraints that shouldn't depend on persuasive language.
Memory belongs in tools, not just prompt prose. Graph-backed retrieval returns evidence and traversal paths, allowing the interface to show where a remembered finding came from instead of simply claiming that the system remembers.
Provenance is a product feature. The Calm, Guided, and Operator views emerged from the same insight: travellers need simple recommendations, while advisors and technical users may need to inspect the evidence. When a recommendation doesn't have a supporting citation, the interface should say so rather than attach one artificially.
Design for failure during the demo. The public demo uses a deterministic replay, while graph functionality is isolated behind configuration. After a cloud database connection failed during development, the app could continue operating. A reliable demonstration is part of the product, not an afterthought.
My First User
Meridian does not have a paying customer yet. It was built during the challenge window, and the proposed pricing has not been validated with real buyers.
The initial customer hypothesis is independent travel advisors who want to differentiate their service with personalised, research-backed travel preparation.
The next step is to put Meridian in front of advisors, watch them create a plan for a real itinerary, and find out whether they would actually charge for it.
My first validation targets are straightforward:
- Can an advisor produce a useful plan without technical help?
- Does the evidence and personalisation justify a premium add-on?
- Would the advisor pay for the tool, resell the output, or prefer a different pricing model?
I would rather be explicit about what remains unproven than confuse an existing market for jet-lag products with evidence that Meridian itself has product-market fit.
Prize Categories
- Best Use of Render: The deployed application runs on Render, with a Blueprint-managed web service and private FalkorDB service. The long-lived Node.js process supports the extended server-sent event streams used by the agent crew.
Demo: https://meridian-afud.onrender.com
- Best Use of ElevenLabs: Each agent has a distinct voice, with streamed audio, synchronized text highlighting, and a multi-voice dialogue experience for the handoff between agents.
What I'd Build Next
The next priority is validating the side hustle with real travel advisors—not adding more agents.
Morning check-ins already feed into a replanning loop: a traveller can report how things went, and Meridian can rescore the remaining days. The /team route is an initial step toward managing multiple clients.
I'd next focus on multi-client workflows, a smoother advisor-facing experience, and structured feedback from the first real users. That would help establish whether the product saves enough time and creates enough client value to justify a recurring fee or per-trip price.
The bet behind Meridian is simple: small businesses shouldn't need enterprise-sized budgets to offer sophisticated, personalised services. Open-weight models make an agent crew more accessible; deterministic verification makes it more controllable; and graph memory gives it a way to improve from experience.
The goal is to turn those capabilities into something a travel advisor can confidently use—and eventually sell.
This project also serves as a write-up for Graph Hacks (FalkorDB × WeMakeDevs), Track 2 — Agent Memory and Coordination.
Top comments (0)