DEV Community: Somay

Building for the Real World: What Winning an International Ideathon Taught Me

Somay — Wed, 19 Aug 2026 13:17:27 +0000

A few days ago, I made an international team for the Egoist Machines, Inc. (YC S26) International Ideathon.

We ended up winning the AI Passport Ideathon — For Work Winner with our idea, Fair Launch.

And honestly, the win was great.

But the part I found more interesting was everything that happened while building it.

The idea

Fair Launch started with a simple question:

What happens when we stop treating AI products as purely technical problems and start treating them as business problems too?

It is very easy to build something that technically works.

It is much harder to build something that works within the constraints of an actual business, for an actual customer, with an actual reason to exist.

That distinction shaped a lot of our thinking.

Instead of starting with "What cool AI system can we build?", we kept coming back to:

Who is actually going to use this?
What problem are we solving for them?
What constraints does the business have?
Where does AI genuinely add value?
What would make someone actually adopt this?

That changed how I approached the technical side of the project.

Technology is only half the problem

One thing I've increasingly realized while working on AI projects is that technical complexity can be misleading.

You can have an impressive architecture, sophisticated models, agents, RAG pipelines, evaluations, and all the terminology that comes with modern AI.

But none of that matters if the end user doesn't get meaningful value from the product.

The hardest part isn't always making the system work.

Sometimes it's figuring out what should be built in the first place.

For this project, we had to continuously balance the technical solution against the business constraints and the experience we wanted to create.

That was probably my favorite part of the ideathon.

Building across countries

Our team was spread across different countries:

Giannis Davarinos, Irini Hartzi, Katie Wan, and me.

Despite that, the collaboration felt surprisingly seamless.

Different backgrounds, different perspectives, different working environments — but very little friction when it came to actually building and making decisions.

That was another takeaway for me.

A strong team doesn't necessarily need everyone to think the same way.

It needs everyone to be able to move toward the same outcome.

And I genuinely enjoyed working with this team.

What I took away

This ideathon reinforced something I want to keep applying to the projects I build:

Don't build technology in isolation from the problem.

The technical solution should exist because there is a real problem, a real user, and a real constraint worth solving.

Especially with AI becoming easier to prototype, I think this distinction is becoming even more important.

When everyone can build a demo, the interesting question becomes:

Can you build something that deserves to exist?

That's the direction I want to keep exploring — right where human intelligence, technology, and real-world constraints meet.

And, of course, winning an international ideathon with this team was a pretty good way to learn that lesson.

Fair Launch — Winner, AI Passport Ideathon: For Work

A huge thank you to the team for making the week what it was.

I would genuinely love to build with all of you again.

The "1 Million Token" Trap: Why I Built a Bi-Temporal Memory Engine for AI Agents

Somay — Tue, 18 Aug 2026 10:12:21 +0000

Every team building AI agents right now faces the exact same wall: Context Degradation.

The industry is currently obsessed with massive context windows. We hear about 1-million or 2-million token limits and assume the "memory problem" is solved. But there is a fatal difference between how much data an LLM can hold and how well it processes that data.

Shoving 50 dense research papers into a standard vector database doesn't give an AI better memory—it creates a noisy, contradictory mess where old facts either get permanently overwritten or blindly appended, causing the agent to hallucinate.

I realized that for complex, autonomous AI, memory cannot just be a bolted-on vector database. Memory has to be the product itself.

To solve this, I built PaperPlanes—a stateful research assistant built on a bi-temporal memory layer. Here is a deep dive into the architecture and how I handled concurrent AI memory.

🏗️ The Architecture: Synthesizing 6 Research Papers

Instead of building another simple RAG pipeline, I synthesized the memory architectures of 6 groundbreaking academic papers (including Zep, Mem0, A-MEM, and Letta) and engineered them into a single production engine.

My core stack:

Database: CockroachDB
AI Models: AWS Bedrock (Amazon Nova Pro & Titan Embeddings)
Agent Logic: LangGraph & FastAPI

Here are the three engineering pillars that make it work:

1. The Bi-Temporal Solution

Most vector databases blindly append or overwrite data. If Paper A says X, and Paper B says Y, standard AI breaks.

PaperPlanes uses a bi-temporal schema in CockroachDB. I never DELETE knowledge. When facts contradict across different research papers, the engine flags both facts as disputed, holding the tension. Because CockroachDB tracks system time, I built a UI slider that uses AS OF SYSTEM TIME queries. You can literally drag a slider back in time to see exactly what the AI believed last week before it learned new, conflicting information.

2. Agent Self-Introspection via MCP

The AI does not just blindly read vectors. I equipped the Amazon Nova agent with a CockroachDB Managed MCP Server tool. This allows the agent to dynamically write read-only SQL queries against its own database schema to introspect its own memory state and metadata.

3. Zero Data Loss Under Extreme Concurrency

When you have background reflection workers, ingestion pipelines, and active chat agents trying to write to memory simultaneously, standard databases drop writes or cause race conditions.

By leveraging CockroachDB's SERIALIZABLE isolation and C-SPANN distributed vector indexing, I stress-tested the engine by running 25 concurrent agent writers against a single memory node. The result? 58 transaction collisions were detected, gracefully auto-retried in the background, and I achieved 0 lost writes.

🧠 Ebbinghaus Memory Decay

I also learned that advanced retrieval isn't just about cosine similarity; it requires algorithmic decay. I successfully implemented an Ebbinghaus decay algorithm into my LangGraph retrieval logic:

R = e^(-t/S)

Retention (R) decays over time (t) unless the memory strength (S) is reinforced by frequent agent access. If the AI doesn't think about a fact, it fades. If it recalls it, the memory strengthens and persists.

I just submitted PaperPlanes for the CockroachDB × AWS Hackathon.

GitHub Repo: Somay-kousis/PaperPlanes

I'd love to hear from other engineers in the comments: How is your team handling context degradation and long-term memory for your AI agents? Are you building custom memory layers, or relying entirely on massive context windows?

Looking for people to build hackathon projects with, including people still learning to code

Somay — Mon, 10 Aug 2026 08:33:05 +0000

There's a hackathon almost every week right now, agentic AI, open source, AI infra, all of it. I want to enter more of them, and I want to build the team differently than most people do.

What I bring

I'm a computer science undergrad working as an AI Systems Engineer Intern at RYSE Technologies, where I built the main orchestrator agent that routes tasks across a registry of 3,000+ specialized subagents through intent classification, capability scoring, context assembly, and dispatch. That cut misrouted tasks by roughly 40% and brought dispatch latency to around 120ms.

Outside of that, I've built three agentic AI systems, all open source:

RabbitHole, a multi-agent "courtroom" system on LangGraph that runs adversarial debate personas. I fixed a token-budget overrun where agents were blowing 3 to 4x past budget per round with no shared memory, just prompts. Moving the constraint into a structured state schema cut latency 50% (19.8s to 9.8s) and input tokens 70%, measured in LangSmith.
PaperPlanes, an agentic memory engine for research papers on CockroachDB, with bi-temporal fact versioning and contradiction detection. It survives a live database crash mid-conversation and keeps 25 of 25 writes under concurrent contention, where a flat-file approach kept 1 and silently lost 24.
Co-Founder Memory, a 19-node LangGraph system with a self-correcting CRAG/SRAG retrieval loop and a daily cron pipeline for long-term personal context.

What I'm looking for

People who can code and want to get better at it fast, especially if you're still early in your learning curve. Here's how I want this to work:

You build the base layout and the parts you're comfortable with. When you get stuck, I help you work through it instead of just handing you the answer. When something is genuinely hard, the kind of bug that eats a whole night, I'll write that part myself so the project actually ships. You leave with a shipped, working project and real code review, not just a participation certificate.

This isn't me disappearing after kickoff and expecting a finished product back. I'm building alongside you. The RabbitHole fix above is the kind of problem I'm good at catching early, before it burns your weekend.

What I need from you

Someone who can actually write code, even if you're not confident in it yet, and who can commit to a real weekend, not just the idea-pitch phase. If you've got a hackathon on your radar and want a team, or you want to build toward one together, reply here or DM me.

An Idea or A company?

Somay — Fri, 31 Jul 2026 13:13:07 +0000

There's a specific kind of gap between "I have an idea" and "I have something an investor would call a company," and almost nobody talks about how wide it actually is.

You know your product. You don't know that a TAM without a cited source reads as an instant credibility flag, or that "SAM" and "SOM" mean different things to different investors, or that a cap table question at the wrong s
tage can stall a conversation that was otherwise going well.

None of this is written down in one place for a first-time founder. It's tribal knowledge, passed around accelerator cohorts and Twitter threads, assembled by osmosis if you're lucky enough to be near people who already know it.

If you're not, if you're a student, or building somewhere without a dense founder network, you're translating your own idea into a language you're learning in real time, usually under the exact conditions (a fast-approaching pitch, a warm intro that won't wait) where getting it wrong costs you the most.

What I Learned Building an AI Agent Whose Only Goal Is to Disagree With You

Somay — Thu, 09 Jul 2026 09:50:23 +0000

We just opened the waitlist for Something, and the part that surprised me most while building it wasn't the multi-agent orchestration — it was how hard it is to make an AI actually disagree.

Every model we tested defaults to being helpful, which in practice means agreeable. Even when explicitly prompted to "find flaws," the outputs would soften into "here are some considerations" instead of a real critique. We had to engineer around this specifically:

Separate system prompts with opposing reward framing — one agent optimizes for identifying growth potential, the other is explicitly told its only success metric is surfacing a disqualifying flaw
Structured output forcing a verdict, not a summary — the skeptic agent (Nothing) has to commit to a specific weakness category (unit economics, timing, technical feasibility) rather than hedging across all of them

A reconciliation step where both outputs get merged into one conviction score, so the founder isn't just reading two contradictory paragraphs

If anyone's built adversarial agent setups and hit the same "it just wants to agree with me" problem, curious how you solved it.

[Everyone who has a brain is a founder here]

something-waitlist.vercel.app

Building an AI System Designed to Argue Against You: The Architecture Behind Something

Somay — Wed, 08 Jul 2026 09:55:24 +0000

My co-founder Prapti and I just opened the waitlist for Something, a founder/investor matching platform — but I wanted to write for this audience specifically about the technical part, since that's usually more interesting here than the pitch.

The core problem with most AI feedback tools: they're sycophantic by default. Optimized for engagement, which nudges toward validation. We wanted the opposite for the moment someone's deciding whether a startup idea is worth building.

So before any idea on the platform goes public, it runs through an adversarial multi-agent pipeline:

One agent argues the strongest possible case for the idea
A second agent — we call it Nothing — is specifically rewarded for surfacing flaws: weak unit economics, bad market timing, technical infeasibility
Output is a structured critique + conviction score, not a vague "looks promising!"

Some of the architecture decisions behind it:

Multi-agent orchestration (LangGraph) instead of a single-prompt approach — lets the optimist and skeptic reason independently before reconciling
Hybrid retrieval (dense + sparse) to ground critiques in real market data instead of hallucinated reasoning
Cost-aware model routing across providers — routes to cheaper/faster models where the task doesn't need frontier reasoning, keeps inference costs sane at scale

Once an idea survives review and the founder has actual proof of work (repo, pilot, patent, live demo — no slide decks), it gets matched to investors based on their real deployment history instead of cold outreach.

Waitlist's open if you want to poke at it: https://something-waitlist.vercel.app

Happy to go deeper on any part of the architecture in the comments — genuinely want pushback if something sounds off.

Building RabbitHole broke my brain a little (in a good way)

Somay — Thu, 02 Jul 2026 16:53:29 +0000

ok so i've been sitting on this project for weeks now and finally the courtroom actually WORKS end to end so lemme just dump everything about it while it's fresh.

RabbitHole is this multi agent thing built on LangGraph where instead of asking one LLM "hey what's the answer" and getting one confident paragraph back, i make a bunch of agent personas actually argue about it. like a state advocate vs a privacy activist vs a compliance officer, all pulling from the same retrieved docs but arguing completely different sides, cross examining each other, and then a judiciary node has to actually rule on it with a confidence score.

why. because normal RAG flattens everything. you ask something with no clean answer (legal stuff, policy tradeoffs, anything genuinely contested) and it still hands you ONE tidy paragraph like the question wasn't messy in the first place. that always bugged me. the messiness is the point sometimes

not deployed yet btw, that's purely a money thing not a "not ready" thing, will get to that

it's actually two graphs

people ask me if it's one big graph and no, there's the outer Courtroom graph (refines your query, calls into RAG, moderator picks who debates, runs the debate in parallel, then stops and waits for you to weigh in before concluding) and then nested INSIDE that is a whole separate RAG sub-graph doing its own thing.

the RAG part alone has more going on than i expected when i started. hybrid search (pinecone dense + BM25 sparse bc keyword matches on legal citations matter a lot, semantic search alone misses those), jina reranker to cut noise, and then a CRAG loop — grader checks if the retrieved docs are actually decent, if not it falls back to web search instead of just yolo-ing with bad context. then on top of THAT theres a self-RAG hallucination check where the final brief gets audited against the raw source before it's even allowed to leave the subgraph.

splitting it into two graphs instead of one flat pipeline was honestly one of the better calls i made, purely bc when a verdict came out wrong i could isolate — was that bad retrieval or bad arguing. saved me so much debugging time lol

ok the bug that actually annoyed me the most

so early version, i'd ask for 2 perspectives and get like 6-8 back. system prompt literally said "use exactly 2 perspectives" in caps even lol and the model just. didn't listen. and under any real load this meant burning through groq's rate limit almost instantly, which was NOT fun to watch happen live

took me way too long to realize the fix isn't a better prompt, the fix is not trusting the prompt for this at all. moved the constraint into the state schema itself — moderator node reads a typed field for perspective count straight off state and only ever schedules that many nodes. the LLM literally never gets asked to count, the graph topology just doesn't let it

anyway that's the takeaway i keep repeating to myself now — if something is structural, encode it structurally, don't beg the model to behave

rate limits basically designed half the architecture

groq free tier is 30 req/min, 6000 tokens/min on the good models. a courtroom debate running perspectives in parallel eats that in seconds, no exaggeration. so i built this FallbackChatModel wrapper thing that catches 429s and connection errors and just fails over — cerebras to groq to gemini — without the graph state even noticing anything went wrong.

also at startup it checks whatever keys you actually have in .env and figures out routing order itself for heavy vs lite tasks. and the routing itself matters too, not just failover — structured synthesis (the actual arguments, the verdict) goes to the heavier model, llama 3.3 70b or gemini 1.5 pro, but boring boolean stuff like "is this doc relevant y/n" goes to a lite model, llama 3.1 8b or gemini flash. kept most node calls off the expensive quota entirely

latency thing that actually made me go woahhh

19.8s down to 9.8s. ~51% cut and honestly it came from like two changes only

running the perspective nodes concurrently with langgraph's async scheduler instead of one by one (should've done this from day 1 tbh), and reranking with jina before synthesis so the context going into the heavy models is smaller — which speeds up inference AND cuts token cost, kind of a two for one

nothing exotic here is the thing. the wins were architectural not "swap in a better model"

why not deployed

plws don't come at me for this lol — hosting a multi provider multi agent graph with a pinecone index and reranker calls running 24/7 is not free, and i'd rather wait till i can actually afford to keep it alive than ship it and watch it die in a month. everything runs locally and via docker compose right now, docker-compose up --build gets you fastapi backend + react frontend behind nginx in one go. it's a "when" not an "if"

whats next

now that the pipeline actually runs i wanna instrument it properly. order is: per-node cost tracing in langsmith first (rn i can tell a run was expensive but not WHICH node did it, driving me insane), then RAGAS eval on the live pipeline so i'm measuring quality instead of just vibes-checking verdicts, then prompt caching, then model routing/cascades on top of what's already there

repo's here if you wanna poke around: github.com/Somay-kousis/RabbitHole

happy to go deeper on any of this in a follow up if ppl want — the CRAG fallback, the state schema fix, the failover wrapper, whatever

The Yes-Man Swap

Somay — Sun, 28 Jun 2026 10:49:36 +0000

You ask AI something. It answers. You skim it, nod, copy-paste it, move on to the next tab.

Small moment. Happens fifty times a day. Nobody thinks twice about it.

But somewhere in that skim-nod-paste move, the roles flipped. The AI did the thinking. You did the agreeing. Agreeing without checking used to be your job's failure mode, not your habit.

We talk a lot about AI being too agreeable — the yes-man chatbot, the one that calls your bad idea genius because pushback might earn a thumbs-down. Fair complaint. Written about endlessly.

what about? you read what it gave you, feel that little hit of relief at not having to think anymore, and say "yeah, this works." Not because it actually works. Because checking takes effort, and effort was the whole thing you came here to skip.

That's not using a tool anymore. That's becoming one.

The AI ran the logic, weighed the options, picked an answer. That's the part of the job that used to require a brain in the room. You just rubber-stamped it. So really — who was the human in that exchange? The one doing the reasoning, or the one doing the nodding?

This isn't an anti-AI rant. AI being wrong sometimes is fine, expected even, that's what it is — a fast, confident, occasionally-wrong collaborator. The actual danger isn't the AI's mistake. It's your silence about it. A wrong answer that gets questioned is just a draft. A wrong answer that gets accepted is now load-bearing — under your work, your decision, your name.

It feels good to skip the checking, that's the trap. Feels like trust. Feels efficient. Feels like you levelled up your workflow. It's not any of that. It's just abdication wearing a productivity costume.

Using AI well isn't about typing the right prompt. It's about staying the one in the room who's still allowed to say "wait, no, that's wrong." Give that job away too, and you haven't gained a teammate — you've trained your own replacement to need zero supervision, including yours.

Ask the question. Read the answer like you don't trust it yet. Then decide. That's the whole difference between using the tool and becoming one.

Building RabbitHole (Even While It Breaks)

Somay — Fri, 19 Jun 2026 16:26:47 +0000

Some projects reach a stage where they're not "finished", not even close, but they're finally alive.

RabbitHole reached that point today.

There are still more bugs than I'd like to admit, conversations occasionally go off the rails but the core infrastructure is finally in place, and that's worth celebrating.

Current progress

Multi-agent architecture with LangGraph
Perspective generation and courtroom-style debates
State management and memory layers
Human-in-the-loop flow
Graph orchestration running locally

There are still countless things left to improve, but the foundation exists now.

Another thing that made this month special:

I was fortunate enough to make it to the second round of two different fellowship programs. Regardless of the outcome, I'm grateful that something in my work and ideas resonated with people.

One thing I've been learning recently:

You don't need to wait until a project is perfect before sharing it.

Sometimes progress deserves to be documented while things are still messy.

A lot of engineering is just:

Build.
Break.
Debug.
Repeat.

And honestly, that's where most of the fun is.

RabbitHole Repository

🔗 GitHub: https://github.com/Somay-kousis/RabbitHole

Still a long way to go, but we're moving.

RabbitHoles while learning AI

Somay — Sun, 14 Jun 2026 07:46:42 +0000

I was supposed to stop at LangGraph.

That was the plan.

Instead, the rabbit hole decided otherwise.

Some of the things I unexpectedly picked up while chasing Agentic AI:

⚙️ Docker

Multi-stage Dockerfiles
Docker Compose
Volumes
Building images from my own projects instead of just pulling them
Finally understanding why "works on my machine" isn't enough

🤖 GitHub Actions

Automated builds and tests
CI/CD pipelines
Branch protection rules
Secrets management
Automatic Docker image publishing
Realizing how satisfying it is when pushing code triggers everything for you

🌿 Git & Engineering Practices

Conventional commits
Pull requests even for solo projects
Trunk Based Development
Small, rapid merges instead of week-long branches
Keeping main always deployable

🚀 Deployment

Actually shipping things instead of leaving them in localhost prison

And somehow, while trying to learn AI, I ended up appreciating software engineering just as much.

Still left:

• LlamaIndex
• Cloud
• Terraform

Apparently the roadmap had other plans.

Curious what unexpected rabbit holes everyone else fell into while learning AI.

Built my first proper agentic AI project

Somay — Wed, 10 Jun 2026 09:39:11 +0000

Over the last few weeks, while learning LangGraph and agentic systems, I ended up building Co-Founder Memory.

It's a stateful AI assistant with:

• long-term memory

• planning loops

• self-correcting RAG

• web search fallback

• automated timeline summaries

• project and preference tracking

Nothing revolutionary — many ideas already exist. The goal wasn't to reinvent memory, but to understand how these systems work by actually building one.

A lot of concepts only started making sense once I had to connect them together:

graph-based workflows with LangGraph
memory extraction and storage
retrieval and validation loops
routing and planning nodes
maintaining context across sessions

Building it taught me far more than watching tutorials ever did.

Repo:
https://github.com/Somay-kousis/Co-Founder-Memory

I'm currently entering my 3rd year at IIITM Gwalior and looking for ML / GenAI internships. If you're building interesting things around LLMs, agents, RAG, or AI products, I'd love to connect.

Always happy to chat with fellow builders as well 🚀

AI #GenerativeAI #LangGraph #RAG #LLM #MachineLearning #Internship

A few months ago, I wouldn't have picked myself

Somay — Tue, 02 Jun 2026 03:24:06 +0000

Back in February, a friend asked me to join his hackathon team.

My first reaction wasn't excitement.

It was:

"Can I even contribute anything?"

I remember repeatedly telling him not to add dead weight to the team and to find someone better. He kept insisting that it didn't matter and that I should just join.

The funny thing is, I still don't think I've done anything extraordinary since then.

No big startup.
No crazy achievement.
No overnight success story.

Mostly just hundreds of hours of learning, building random things, breaking them, fixing them, and realizing how much I still don't know.

But today I caught myself doing something weird.

I'm the one thinking about who to bring into a team.

And for the first time, I don't immediately feel like I'd be dead weight.

Not because I know everything now.

Just because I've reached the point where I can look at a problem and genuinely believe that, given enough time, I'll figure out how to contribute.

It's a small shift, but it feels important.

A few months ago I was wondering if I belonged on a team at all.

Today I'm wondering who should be on mine. 👀