DEV Community: Karan Raj

Building a "Split-Brain" AI Trip Manager for the Backcountry 🏔️

Karan Raj — Mon, 12 Oct 2026 05:10:52 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

WHAT I BUILT

Trip-polama, is a colloquial term used in TamilNadu, a mix Tamil and English which means shall we go for a trip. From the header itself we can get to understand that this application can make people get off their seats and go offline for few days to explore the nature and experience the thrill.

DEMO

🚀 Live Demo: trip-polama.onrender.com

CODE

💻 GitHub Repository: karan-2004/trip-polama

🌟 What is trip-polama?

Most trip planning apps are great until you actually start your trip. The moment you hit a remote trail or a hill station with zero signal, your app becomes a glorified brick. Maps stop loading, expense tracking requires a server, and coordinating with your group becomes a game of "who has the last bit of LTE?"

trip-polama is an offline-first, "split-brain" trip manager designed specifically for hikers, trekkers, and outdoor groups. The goal is simple: get people off the screen and into the world, with open-source AI at the core.

🧠 The "Split-Brain" Architecture

I realized that the tools you need before a trip are fundamentally different from what you need during one. Instead of a monolithic app, I built two specialized "brains":

1. The Online Brain (The Planner)

When you have a connection, you need a powerhouse. The Online Brain uses larger open-weight models (like Gemma 4 or Llama 3) equipped with online research tools. It performs source-backed research using Wikipedia and other resources to suggest waypoints, check permits, and build a realistic itinerary.
Still need to work on the model to identify a better one which could infer budget and planning based on the current data available. It also needs to be fine tuned specifically for trip planning.

2. The Local Brain (The Manager)

Once you're offline, the brain shifts. The Local Brain is a lightweight system that lives entirely on your device. It handles the essentials with zero signal:

Offline Waypoints: Mark your path and track visited stops.
Expense Tracking: A local ledger to track spending and calculate "who owes whom" without a database.
Photo Log: Capture memories locally without worrying about cloud uploads.
Buddy Check-ins: Tracking last-known locations of group members.
"Next Up" Suggestions: Context-aware tips based on your device location, weather, and pace.

It’s still not a working model in deployment where I need to figure out an even more smaller model to accommodate in mobile and needs more fine tuning in order provide accurate and quick responses offline.

🛠️ How I Built It

I chose a stack that prioritizes user control and offline reliability:

PWA (Vite + React + TS): Built as a Progressive Web App so it installs on the home screen and works offline via service workers.
Dexie.js & IndexedDB: All trip data, photos, and expenses are stored in the browser's IndexedDB. Your data stays on your device, not on a corporate server.
MapLibre GL: Used for high-performance map rendering.
Open-Weight AI: Integrated via an Ollama/Groq adapter, ensuring the AI is inspectable and swap-able.
Node.js & Render: A lightweight gateway serves the frontend and manages the transition to larger online models.

🚧 Challenges I Faced

The biggest challenge was managing the "split" effectively. Ensuring that the chat history and trip context transitioned seamlessly between a massive online model (for planning) and a lightweight local logic (for managing) required a custom routing layer and a strict schema for AI actions.

Another hurdle was the PWA's background GPS behavior—modern mobile browsers are aggressive about killing background processes, which I had to account for in the "buddy tracking" design.

📚 What I Learned

This project taught me the power of local-first software. In an era of "everything-as-a-service," building something that intentionally doesn't need a server to be useful is a refreshing challenge. I also learned how to leverage open-weight models to create specialized roles (Planner vs. Manager) rather than relying on a single generic prompt.

🗺️ The Road Ahead

On-Device Intelligence: Integrating WebLLM to bring the "Manager" brain fully on-device.
Offline Maps: Implementing PMTiles for true offline map downloads.
P2P Coordination: Using WebRTC for live buddy tracking without a central server.
Privacy First: Automatic metadata stripping for photos.

🤖 AI Agent Session

Here is the transcript of the session where I deployed the app and drafted this post:

Building trip-polama: split-brain trip planning and protected Render deployment openai/gpt-6.1-sol

You

lets plan the archietecture and how to proceed forward
dont blindly urge to only submit a scrap

Agent

Curated milestone summary: We chose a no-rush PWA build with persistent trip conversations, local-first IndexedDB storage, manual trip tools, open-model integration, and versioned architecture plans. Supabase authentication/sync, on-device inference and peer-to-peer coordination were planned rather than represented as implemented.

You

lets have a plan copy within the repo with all versions of plan available, lets install specific skills within the repo to keep things smooth and lets maintain a memory bank to keep track of the project

Agent

Curated milestone summary: Added versioned plans, repository agent rules, AGENTS.md, a maintained README and a memory bank. Built an npm-workspaces foundation with a React/TypeScript/Vite PWA, deterministic geographic and expense logic, Dexie repositories, tests and CI.

You

lets go with the light theeme with natural skyblue, green colours to blend with nature

add it to any design rules so that I dont need to reiterate

Agent

Curated milestone summary: Implemented a light nature palette and persistent design rules. Added trip creation, expenses and settlement, waypoints, next-stop suggestions, and group check-ins. Replaced coordinate entry/display with device or map selection and human-readable location labels. Photos gained an image picker and actual getUserMedia camera capture, with previews and local Blob persistence.

You

lets remove the locations options in photos and add stripping location metadata from the photo to plan whhich we can implement later

Agent

Curated milestone summary: Removed photo geolocation requests, tags and location display. Existing image files were not rewritten. Embedded GPS/location-metadata stripping was explicitly added as deferred work; no claim was made that original uploads were already location-free.

You

In the home page along with the trips section lets mainly focus on to a chat session per trip which needs to be the heart of the application where the model acts as the manager if the trip is already created or a planner if the trip is newly being added or being explored. Let the chat handle all the actions of the application along with the manual application usage.

Agent

Curated milestone summary: Made chat the primary home workspace. Exploratory chats persist before creation and become manager conversations after confirmed trip creation. Chat and manual tools share local records. Model actions use strict runtime schemas, scoped transactions, confirmation/dismissal, audit statuses and duplicate-execution protection.

You

lets be clear that the planner needs to opt a big llm to access online resources and provide efficient planner and the local agents role is to manage the trip read/write all the data via chat and provide summary and quick responses.

Agent

Curated milestone summary: Implemented separate routes: a server-configured online planner with a bounded resource-tool loop, and a local Ollama manager. Existing conversations can explicitly switch to Research/Replan and back. Local failures never silently escalate to cloud inference. Online research uses Wikipedia, with optional Brave Search; credentials remain server-side.

You

now we can test the model

Agent

Curated testing summary: Live llama3.2:3b checks revealed malformed or unrelated action proposals, so response schemas and a one-action manager policy were tightened. The configured deepseek-v4.1-flash cloud model was denied with HTTP 402; after the user switched to gemma4:31b, live Wikipedia-backed research and gateway requests succeeded. Name-only creation also exposed incomplete action envelopes and fenced JSON. Added clarification examples, one bounded output correction and strict validation after removing only an outer JSON fence.

You

Before creation of trip lets suggest the spot in the destination and use that data to create waypoints for the trip.for any creation or updation confirmation dont use json structure rather just confirm the data. read only actions to local model should not ask any confirmations. lets test more on the local model on data retrieval including summary, quick responses and other actions. lets also add an icon to add photos via chat(multi select).

Agent

Curated milestone summary: Added sourced nearby-place suggestions and selectable stop reviews, with selected waypoints saved atomically during trip creation. Confirmation cards show readable values rather than JSON. Read-only tools execute without approval; known short commands use deterministic local reads, while natural retrieval requests select a compact read tool and facts come from complete saved records. Added multi-photo chat previews and local album/history linkage without sending images to models. Expanded live local tests found hallucinated retrieval answers and later intermittent 90-second timeouts; the final expanded live run was interrupted and must not be described as all-green. Deterministic reads were accurate and fast.

You

lets change the app name to trip-polama
from code base level to UI and every where

Agent

Curated milestone summary: Renamed UI, page title, PWA, workspace packages/imports, source symbols, prompts and documentation to trip-polama. Preserved legacy database/preference IDs for saved-data compatibility. Rebrand verification passed 93 regression tests, typecheck, lint and production build. Created and pushed the public repository https://github.com/karan-2004/trip-polama; master contains commit b8598b1. Actual environment credentials were excluded.

You

create a new branch deployment and add those changes and commit

Agent

Curated deployment summary: Created deployment from master and committed 9fdbc54, feat: prepare protected Render deployment. Added one Node production server for the built frontend/API, Render PORT binding on [REDACTED], /healthz, production startup, shared demo sign-in with expiring Secure/HttpOnly/SameSite cookies, request budgets, safe static serving, render.yaml and deployment instructions. Verified 105 regression tests, typecheck, lint and PWA build; actual production-start smoke checks passed with synthetic secrets and no paid inference. At this checkpoint, deployment was committed locally but not pushed or provisioned on Render.

You

submit_agent_session

Agent

Session preservation summary: This is a curated milestone record, not a complete verbatim transcript. Secrets, session cookies and private machine paths have been omitted. Remaining work includes actual Render deployment and browser/device verification, faster and consistently reliable local inference, Supabase identities/sync, WebLLM, peer-to-peer coordination, offline map downloads, photo metadata sanitization and measured test coverage. Shared demo access and in-memory request limits are not a full production account or durable spending-control system.

Check out the repo and join me in building the future of private, autonomous outdoor exploration!

Prize Categories

I have used render for deployment which made my work much easier to take my project to the world. I would like to enter in render category.
I have used Gemma model through illama for the online brain for trip planner. I would also like to enter in this category.

TriageAgent: a fully local AI that triages support tickets for my dev team(HALF BAKED)

Karan Raj — Sun, 04 Oct 2026 19:10:57 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

My dev team's biggest time-sink isn't writing code — it's triaging support tickets. Every morning someone reads a wall of messages, figures out which tickets we've already solved and which need a real engineer, and routes them.

TriageAgent does that automatically. You paste in our support chat log — no strict format, just messages that mention a ticket ID like #123 — and it:

groups messages into ticket threads by their ticket ID,
builds a local index of every past thread and of each developer's past work,
for a new ticket, either writes a short internal note to the support team (when a similar resolved thread exists) or routes it to the right dev based on whose past responses it most resembles,
and prints case-based reports: open tickets per dev, critical cases, and a full case list.

No cloud, no API keys, nothing leaves the machine.

Demo

It runs as a CLI and a small web UI. Two real examples from the sample data:

$ python cli.py triage "#999 the login page crashes on Safari"
action: note
note: "Duplicate of #101. Fix applied: Safari-specific JS bug in login
       handler fixed in v2.3.1. Handled by: alice."

$ python cli.py triage "#999 our webhook receiver is returning 500s"
action: route
assigned_dev: carol
reason: "A very similar ticket already exists (#108) but is still open,
         so I routed to 'carol' — their past work is closest."

Code

The whole thing is on GitHub:

karan-2004 / triage-agent

TriageAgent

A local, open-source support-ticket triage agent for a dev team. Point it at a chat log; it groups messages into ticket threads, builds an index, then for any new ticket it either writes a short internal note to the support team (when a similar resolved thread exists) or routes it to the developer whose past responses it most resembles. It also prints case-based reports (open tickets per dev, critical cases, and a full case list).

Built with local AI at its core (Ollama + open models). No data leaves your machine.

How it works

Ingest — parse a free-form chat log, group messages by ticket ID embed each thread (nomic-embed-text), store in a local vector index. It also builds one "profile" embedding per developer from every message they wrote.
Triage — embed the new ticket and search
- if a past resolved thread is similar enough (≥ threshold)…

View on GitHub

How I Built It

The open-source AI is the point, so everything runs locally:

Ollama serving two open-weight models:
- nomic-embed-text — embeddings for similarity search,
- llama3.2:1b — writes the internal notes.
Python glue: a tiny numpy vector store (cosine similarity), a free-form chat-log parser that groups messages by ticket ID, and a simple RAG flow.
Streamlit for the browser UI.

The flow: parse the chat log → embed each thread and each developer's profile → store locally. For a new ticket, embed it and search. If the best resolved match clears a similarity threshold, the LLM drafts the note from that thread's resolution; otherwise it routes to the dev whose profile is closest.

One detail I'm proud of: it only auto-notes from resolved threads. An open duplicate gets routed instead of answered with a hallucinated fix — that alone cut the wrong answers to near zero. The suite of 26 pytest tests covers the parser, reports, store, and triage decisions.

Why Does Open Innovation Matter?

Support tickets are full of things you don't want on someone else's server: customer emails, login problems, billing details. Because Ollama and the models are open-weight, this all runs on a laptop with the Wi-Fi off — the tickets never leave the machine.

That's what a closed API wouldn't let us do. A hosted model means shipping every ticket thread to a vendor. An open stack let us:

keep the data local — no upload, no retention policy to worry about;
swap models freely — if we outgrow llama3.2:1b, point TRIAGE_CHAT_MODEL at a bigger model, no code change;
run it for free — no per-token bill for triaging our own backlog.

Open innovation isn't a nice-to-have here; it's the reason the tool is safe to point at real tickets. Hope we devs really needs to keeps the bugs not to fly onto third party server exposing its source.

Also Context of tickets need to be shared between the devs so that anyone can respond to it at the earliest. This agent acts as the context manager with autonomous response generator.

Honestly it is still half baked and untested in the real environment. Need to involve in several iterations to make it helpful for my friends. So let it be outside rewarding category.

Credits: Opencode with Deepseek 4(helped to convert my idea into code)