DEV Community: Komal deep

FriendOS: I Built an AI That Tells My Panicking Friend What to Do Next

Komal deep — Mon, 05 Oct 2026 06:54:12 +0000

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

What I Built

I built FriendOS, a little AI thinking partner that answers one question: "What should I do next?"

I built it for a friend who is always one deadline away from panic.

She isn't lazy, and she isn't unorganized in the way people usually mean it. Her problem is that everything arrives at once. An assignment is due today. A message needs a reply. Something needs buying. Her room needs cleaning. And all of it is in her head at the same time, loud and tangled.

When that happens, she freezes. Not because she doesn't know what the tasks are, but because she doesn't know which one to start, or where to start with it.

Then comes the second problem. To actually do anything, she bounces between five or six places at once: a search tab for one thing, her email for another, a shopping site, a notes app, an AI chat, a study page. Nothing is connected. Every task needs its own hunt for the right resource, and by the time she's found it, she's lost the thread and the panic is worse than before.

A normal to-do app didn't help her. It gave her more information when she needed less thinking. So I built something different.

FriendOS skips the forms. You brain-dump everything, by typing or by speaking:

"I need to submit my assignment today, finish two sections, clean my room this weekend, and buy a charger because mine is damaged."

FriendOS turns that into:

🔥 DO NOW
🌼 DO SOON
🌿 CAN WAIT
⏱️ NEXT 30 MINUTES: one to three small, realistic steps

Then it helps her actually start, so she doesn't have to go hunting. Each task comes with a first move: a shopping task opens a search, an email task builds a prompt and opens Gmail, a study or writing task generates a breakdown prompt and opens an AI assistant. Instead of juggling tabs, she gets one place that says do this, start here.

The most important rule is that FriendOS only works with what you actually tell it. My first version kept adding things like "research potential topics for future assignments" that nobody asked for. For someone who is already overwhelmed, a planner that invents more work is the last thing she needs. So FriendOS never invents tasks or deadlines.

It works in English, Hindi, Punjabi, and Hinglish, because my friend doesn't think in only one language.

Demo

🔗 Live app: https://friendos-rizl.onrender.com/

Try this brain dump:

I need to submit my assignment to my professor today. I still need to finish two sections. I also need to clean my room this weekend. I want to buy a new charger because mine is damaged.

Code

KomalDeep355 / FriendOS

FriendOS 🌼

Your little thinking partner. It answers one question: "What should I do next?"

FriendOS turns a messy brain dump into a calm, realistic priority plan, then tells you exactly what small step to take in the next 30 minutes. It only works with what you actually tell it. It does not invent tasks or deadlines.

Demo: https://friendos-rizl.onrender.com/ Code: https://github.com/KomalDeep355/FriendOS

Why I built it

I built FriendOS for a friend who always has too many things to keep track of: assignments, errands, things to buy, things to clean. They didn't need another productivity dashboard. They already knew what was on their plate. The hard part was deciding which thing to do right now.

The problem isn't a lack of organization. It's decision overload.

Too many things in my head
        ↓
Brain dump instead of forms
        ↓
AI prioritization instead of manual sorting
        ↓
NEXT 30 MINUTES instead of

…

View on GitHub

How I Built It

Text or microphone
      ↓
FastAPI  →  ElevenLabs Scribe v2 (voice only)
      ↓
FastAPI  /api/organize
      ↓
Open-weight Llama
      ↓
Strict JSON → validation → plan
      ↓
DO NOW / DO SOON / CAN WAIT / NEXT 30 → contextual action

Frontend: plain HTML, CSS, and JavaScript, with a calm, cozy, Pinterest-style board look. Task completion is saved in localStorage, so there's no database.
Backend: Python and FastAPI.
AI: an open-weight Llama model, called through an OpenAI-compatible chat endpoint. Locally I ran it with Ollama (llama3.2:3b). For the public demo I point the same code at a hosted Llama endpoint, so anyone can try it without installing anything. Switching is two environment variables.
Voice: the browser records audio with MediaRecorder, FastAPI sends it to ElevenLabs Scribe v2, and the transcript goes straight into the planning pipeline. This is voice input only. FriendOS doesn't speak back.
Hosting: Render.

Making a small model behave. The system prompt tells the model never to invent tasks, deadlines, or events, never to duplicate tasks, not to force tasks into categories, and to keep NEXT 30 realistic. I don't trust the prompt alone, though. A normalization layer in the backend strips markdown fences, fills missing fields, removes empty and duplicate tasks, and drops any NEXT 30 item that points to a task that doesn't exist. That combination is what stopped the made-up tasks.

I deliberately left out auth, a database, React, RAG, and multi-agent setups. I wanted something small enough to actually finish and put in front of my friend.

Why Does Open Innovation Matter?

FriendOS is a very personal tool. People paste their half-formed worries and deadlines into it. An open-weight model made it possible to build around that.

Control over the experience. Because I could shape the model's behavior through prompting and then validate its output, I could fix the exact problem my friend would have noticed: the planner inventing work.
Privacy is a real option. With Ollama, the whole intelligence layer can run on your own machine, so your brain dump doesn't have to go to anyone's server. (The public demo uses a hosted Llama endpoint for convenience, and voice uses ElevenLabs, so I'm not claiming the live demo is fully local.)
No lock-in, and cost stays low. Because the model sits behind a standard API shape, I could develop for free locally and then switch to a hosted open-weight endpoint for deployment without rewriting the app. A solo developer building for one friend shouldn't need a paid proprietary API to get started.

Prize Categories

Best Use of ElevenLabs. FriendOS takes voice input: you tap the mic and speak your brain dump, and ElevenLabs Scribe v2 transcribes it. The transcript goes straight into the Llama planning pipeline, so the plan appears without typing. This fits the category's "transcribe audio for a language model" use. FriendOS uses voice input only, not voice output.

Best Use of Render. The FastAPI backend and the frontend are deployed on Render, which serves the live demo.

Connecting My Agent to SigNoz's MCP Server: A First-Timer's Debugging Diary

Komal deep — Sun, 26 Jul 2026 15:35:24 +0000

I want to start with the number that actually matters: three hours. That's roughly how long I spent just getting a connection to succeed, out of a five-day hackathon window. If you're building something similar and hit the same walls, this post should save you most of that time.

What I was building, and why this angle

This was my first hackathon. My background is data science and NLP — classification, prediction models, the kind of ML work where inputs and outputs are known quantities. Agents, MCP servers, observability — none of that was in my vocabulary two weeks ago. So this post is written from that specific angle: what actually trips someone up coming from ML into agent-plus-observability tooling for the first time.

For Agents of SigNoz (WeMakeDevs x SigNoz), I built an agent that connects to a self-hosted SigNoz instance through its MCP server, answers natural-language questions grounded in live telemetry, and then classifies what it finds — latency, error-rate, resource-exhaustion, dependency-failure, or healthy — with a confidence score traced back into SigNoz itself.

Setting up SigNoz via Foundry

bash
`curl -fsSL https://signoz.io/foundry.sh | bash`

yaml
`apiVersion: v1alpha1
kind: Installation
metadata:
  name: signoz
spec:
  deployment:
    flavor: compose
    mode: docker
  mcp:
    spec:
      enabled: true`

bash
`foundryctl cast -f casting.yaml`

This brought up SigNoz and its bundled MCP server as separate Docker containers — a detail that turned out to matter a lot more than I expected.

Bug #1: 401 Unauthorized

My first connection attempt to http://localhost:8000/mcp returned a flat 401. Self-hosted SigNoz's MCP server needs two specific headers, not the generic Bearer-token pattern I tried first:

python
`async with streamablehttp_client(
    MCP_URL,
    headers={
        "SIGNOZ-API-KEY": os.getenv("SIGNOZ_API_KEY"),
        "X-SigNoz-URL": "http://signoz-signoz-0:8080",
    },
) as (read_stream, write_stream, _):`

Bug #2: 400 Bad Request — the Docker networking trap

Adding the headers got me past the** 401*, straight into a **400*. I initially set X-SigNoz-URL to http://localhost:8080, since that's where SigNoz's UI loaded from my own machine. But the MCP server runs inside its own container — and inside that container, localhost refers to the container itself, not my SigNoz instance. The server's own logs said it plainly:

`"msg":"Invalid X-SigNoz-URL header" ... "error":"host \"localhost\" is not allowed"`

docker ps showed the actual container name — signoz-signoz-0 —, and that's what needed to go in the header instead. This is the single biggest lesson I'd hand to my past self: when a container-to-container request fails, check what hostname the containers actually use to reach each other on the Docker network. It's rarely localhost.

Bug #3: a plain variable-naming mistake

Once I fixed the headers, I hit a NameError: name 'read_stream' is not defined. I'd renamed the tuple unpacking on the async with line but hadn't updated where those names were used two lines later:

python
`) as (read_stream, write_stream, _):
    async with ClientSession(
        read_stream,
        write_stream,
    ) as session:`

Small, but the traceback pointed into the MCP library's internals, not my own line — a good reminder that an error surfacing deep in someone else's stack trace can still be your own typo.

Bug #4: 403 — a permissions gap, not a connection problem

With the connection finally working, calling signoz_list_services returned:

`403: only viewers/editors/admins can access this resource`

The API key itself was valid — the service account behind it just had no role assigned. The fix was in Settings → Service Accounts, assigning Editor or Admin. Worth remembering: a valid key and a valid role are two separate things.

What I actually built on top: reasoning, not just retrieval

SigNoz's MCP server gives you raw retrieval — service lists, traces, metrics, logs. It has no opinion about what any of that data means. Coming from a classification background, my instinct was to add exactly that missing layer:

python
`def classify_incident(user_question: str, telemetry_data: str) -> dict:
    classification_prompt = f"""You are classifying an observability finding.

User question: {user_question}
Telemetry data retrieved: {telemetry_data}`

Classify this into exactly ONE category: latency, error-rate, resource-exhaustion, dependency-failure, healthy, or unknown.

Respond with ONLY valid JSON, nothing else:
`{{"category": "", "confidence": , "reasoning": ""}}"""

response = hf_client.chat_completion(
    model=MODEL_ID,
    messages=[{"role": "user", "content": classification_prompt}],
    max_tokens=150,
    temperature=0,
)
raw = response.choices[0].message.content.strip()
return json.loads(raw)`

The part I actually care about is where the result goes — not just into the chat response, but into SigNoz's own trace:

python
`with tracer.start_as_current_span("incident_classification") as classify_span:
    classification = classify_incident(request.query, telemetry_data)
    classify_span.set_attribute("incident.category", classification["category"])
    classify_span.set_attribute("incident.confidence", classification["confidence"])`

That means my agent's own judgment becomes something you can trace inside SigNoz, the same way you'd trace any other part of the system. SigNoz observes the target service; this makes it also observe the agent's reasoning about that service.

What I'd tell someone starting this from an ML background

Docker networking will very likely be your biggest time sink — not the AI part. Budget for it honestly.
Read the server's logs the moment a request fails for an unclear reason — docker logs_ _ told me more in thirty seconds than an hour of guessing at headers did.
A service account's API key and its assigned role are two separate failure points — check both before assuming the key is broken.
Look for where your actual background transfers, instead of trying to become a full infra person overnight. For me that was "don't just retrieve data, judge it" — that's ML thinking applied to an observability tool, and it's the one piece of this that's genuinely mine.

What's next

With more time, I'd add a small retrieval layer surfacing similar past incidents, and wire a SigNoz alert to trigger the agent automatically instead of waiting on a question.

Conclusion

If you're self-hosting SigNoz's MCP server and hit a 401, 400, or 403 in that order — check your headers, your Docker hostnames, and your service account's role. That covered nearly everything that stood between a working agent and me, and I hope it saves you the three hours it cost me.