DEV Community: Ayush Singh Tomar

I built a multi-agent AI system that researches any startup in under 90 seconds

Ayush Singh Tomar — Thu, 13 Aug 2026 03:30:05 +0000

Type a company name. Get funding history, competitors, strengths, risks, and a verdict — written by three AI agents that hand real work off to each other, not one model faking a team. Here's how StartupScope works, and what building it taught me about production LLM systems.

Quick facts: 3 sequential agents · Groq LLaMA 3.3 70B · live web search with fallback · MIT licensed · reports typically land in well under 90 seconds (my last Stripe run finished in 46s)

The problem

Every time I wanted to size up a company — for a job application, a comparison, or just curiosity — I'd end up with 15 tabs open: Crunchbase, TechCrunch, the company's own site, a couple of "top competitors" listicles, LinkedIn. Ten minutes of tab-switching to answer one question: what does this company actually do, and should I care?

So I built StartupScope. Type a company name, and three AI agents research, analyze, and write a structured intelligence report — funding history, business model, competitors, strengths, risks, a verdict. Compare two companies side by side if you want. Most runs finish in under 90 seconds.

Live demo: startupscope-ai.streamlit.app
Code: github.com/ayush-s-tomar/startupscope

Here's the single-company flow, start to finish:

And here's Compare Mode — two full intelligence reports generated and rendered side by side in one run:

Why three agents instead of one prompt

My first version was a single LLM call with a big prompt: "research this company and write a report." It worked, technically. It also hallucinated funding numbers with total confidence, blurred "what they do" into "why they're good," and produced the same generic paragraph shape no matter how much real data it had found.

The fix wasn't a better prompt — it was splitting the job into three roles that pass a shared, structured context object down the line:

User Input (Company Name)
        │
        ▼
[Agent 1 · Researcher]
Searches the web (Serper → DuckDuckGo fallback),
ranks sources by credibility, writes findings into
shared agent_context
        │
        ▼
[Agent 2 · Analyst]
Reads agent_context, extracts strengths, risks,
market opportunity, and a verdict
        │
        ▼
[Agent 3 · Writer]
Reads the fully-populated agent_context,
formats everything into a clean markdown report
        │
        ▼
Markdown Report (.md) + Structured JSON (.json)

Splitting finding information (Researcher), judging it (Analyst), and presenting it (Writer) into separate CrewAI agents made a bigger quality difference than any prompt tweak I tried. Each agent has one job and a narrow, well-defined output — which made the pipeline far easier to debug too, since I could inspect agent_context at each handoff instead of reverse-engineering one giant completion.

Three agents fixed the structure. They didn't, on their own, fix the lying.

The hard part: making it not lie

The real problem with a tool like this isn't "can an LLM summarize a company" — it's "can I stop it from confidently inventing a Series B round that never happened."

A few things mattered more than I expected:

Source credibility scoring. Search results are ranked by domain trust before the Researcher agent even reads them — Crunchbase, TechCrunch, and Reuters outrank random forum posts and SEO-farm "top 10 competitors" listicles. Garbage in, garbage out is very real when your input is live web search.

Explicit permission to say "I don't know." The agents are instructed to output "Not specified" rather than guess when a field — founding year, exact funding total, HQ — isn't in the source data. It's a small instruction with an outsized effect: it's what separates a tool you can trust from one that just sounds confident either way. Some companies genuinely don't disclose this stuff publicly, and the report should say that plainly instead of papering over the gap.

Search fallback. Serper is the primary search provider, but free-tier quotas run out and third-party APIs go down. DuckDuckGo is the fallback, so a quota hit doesn't mean a dead app.

Retries with backoff. Groq's free tier and Serper's free tier both rate-limit. Instead of the whole run crashing on a transient 429, failed steps retry with exponential backoff. Unglamorous, but it's what separates a demo that works once from a tool people can rely on.

None of that shows up on screen, though. The next problem was making the 60-plus seconds it takes actually feel trustworthy while it's happening.

Killing the silent spinner

Small thing, but it mattered a lot for how the tool felt to use: early versions had one spinner sitting there for 60–90 seconds with zero feedback. Users — including me — kept refreshing, assuming it had crashed.

Now every agent streams its status live:

🔍 Researcher is searching the web...
📊 Analyst is extracting insights...
✍️ Writer is composing the report...

Watching the three-stage pipeline actually work in real time, instead of staring at a spinner, changed how the tool felt — from "is this broken?" to "oh, it's doing three separate jobs." Same underlying latency, completely different perceived experience. The live step counter ("Step 2/4 · 34s elapsed") does double duty as a built-in performance readout. Nice side effect of building for UX: I get to watch my own regressions happen in real time too.

That's the experience layer. Underneath it, here's what's actually running the pipeline:

Tech stack

Layer	Tech
Agent framework	CrewAI
LLM	Groq API (LLaMA 3.3 70B)
Web search	Serper Dev API + DuckDuckGo (fallback)
Frontend	Streamlit
Deployment	Streamlit Community Cloud
CI	GitHub Actions

That's the core loop. A few things around the edges make it more than a one-shot demo:

What else it does

Try an example — one-click company buttons (OpenAI, Anthropic, Stripe, Razorpay, Notion) pre-fill the input so you can see a full report before typing anything
Compare Mode — research two companies in one run, view tabbed or side by side
Report history — every past report is saved and browsable from a sidebar
Dual export — every run saves both a .md and a structured .json (typed schema: funding, competitors, strengths, risks, verdict), so the output is usable programmatically, not just readable
CLI batch mode — point it at a CSV of company names and it researches all of them sequentially, with a built-in delay to respect rate limits
CI on every push — GitHub Actions lints with ruff and byte-compiles every module across Python 3.10–3.12 before anything reaches main

# single company
python main.py --company Razorpay

# batch mode from CSV
python main.py --batch companies.csv

None of that means it's finished, though.

What I'd still change

Being honest about the rough edges:

Report quality is only as fresh as Serper/DuckDuckGo results — a funding round announced an hour ago might not surface yet.
Free-tier rate limits mean heavy back-to-back usage triggers the retry logic and slows things down.

None of this is secret; it's in the README's "Known Limitations" section on purpose. A report that's honest about its own gaps is more useful than one that pretends they don't exist.

Try it

Fifteen tabs down to one input box. That was the whole goal — go see if it holds up on a company you actually care about:

Live app: startupscope-ai.streamlit.app
Source: github.com/ayush-s-tomar/startupscope — MIT licensed, clone it and run it locally with your own free Groq + Serper keys

If you build multi-agent systems too, I'd genuinely like to hear how you handle agent-to-agent context passing. CrewAI's shared context object worked for me here, but I'm curious what else is out there for keeping a 3+ agent pipeline debuggable instead of a black box — drop your approach in the comments, I'm collecting ideas for the next iteration.

Built by Ayush Singh Tomar

I Built an AI Agent That Thinks Before It Answers — And Loops Back When It Doesn't Know Enough

Ayush Singh Tomar — Mon, 10 Aug 2026 03:30:04 +0000

Most AI projects look like this:

User Input → LLM → Output

That's not an agent. That's autocomplete with a UI.

AgentLoop is different. Give it a research topic and it:

Checks if it already researched something similar (long-term memory)
Breaks the topic into targeted sub-questions
Decides per sub-question whether to call a live web search tool
Re-reads its own notes and routes itself back into research if it finds gaps
Only then writes a structured, sourced report
Saves the run to memory for next time The loop in the middle — where the agent judges its own output and decides to keep going — that's what makes it genuinely agentic. Not the LLM. The decision-making around it.

Live demo: agentloop.streamlit.app
GitHub: github.com/ayush-s-tomar/agentloop

What It Does

You type a research topic. The agent runs a 6-node pipeline:

[Recall] → [Plan] → [Research] → [Reflect] → [Synthesize] → [Persist]
                                      ↑               |
                                      └───────────────┘
                                    (loops back if gaps found)

Recall — checks SQLite long-term memory for related past research. If it finds something relevant, it loads those notes as context before planning. Avoids re-researching the same ground twice.

Plan — the LLM breaks the topic into 3–5 specific sub-questions. Not "tell me about X" — actual targeted questions like "what companies are deploying X in production?" and "what are the failure modes of X?"

Research — for each sub-question, the LLM decides whether to call the Tavily web search tool. Not every sub-question needs a search — sometimes the answer follows from earlier notes. This is genuine tool-use, not hardcoded search-every-time.

Reflect — the node I'm most proud of. The agent re-reads everything it's gathered and asks: is this complete? Are there gaps? If yes, it routes back into Research for another loop. If no, it moves forward. Bounded at 3 iterations so it can't loop forever.

Synthesize — writes a structured markdown report from all gathered notes and search results. Citations included.

Persist — saves the full run to SQLite: topic, sub-questions, sources, report. Available for recall on future runs.

Architecture

The 6-node graph, including the reflect → research loop-back.

Topic input, live trace, and the generated report — all in one Streamlit view.

Stack: LangGraph · Streamlit · Groq (llama-3.1-8b-instant) · Tavily · SQLite · Streamlit Cloud

How Each Part Works

1. The Reflect Node — Conditional Loop-Back

This is the decision that separates AgentLoop from a linear pipeline.

After Research runs, instead of immediately synthesizing, the agent hits the Reflect node:

def reflect_node(state: AgentState) -> AgentState:
    notes = "\n".join(state["notes"])
    sub_questions = "\n".join(state["sub_questions"])

    prompt = f"""You researched these questions:
{sub_questions}

Here are your notes so far:
{notes}

Are there significant gaps? Answer YES or NO, then explain."""

    response = llm.chat([{"role": "user", "content": prompt}], system="Be critical.")

    has_gaps = response.strip().upper().startswith("YES")
    iterations = state.get("reflect_iterations", 0)

    return {
        **state,
        "needs_more_research": has_gaps and iterations < 3,
        "reflect_iterations": iterations + 1
    }

The LangGraph conditional edge routes based on needs_more_research:

graph.add_conditional_edges(
    "reflect",
    lambda state: "research" if state["needs_more_research"] else "synthesize"
)

The iteration cap (iterations < 3) is non-negotiable. Without it, a loop-happy LLM spins forever on ambiguous topics. With it, the worst case is 3 research passes — still far more thorough than one.

2. Two-Layer Memory

Short-term (within a run): state["notes"] — a list that accumulates across all Research iterations. Each tool call appends its findings. The Reflect and Synthesize nodes see the full accumulated picture, not just the last search.

Long-term (across runs): SQLite with a simple schema — topic, sub-questions, notes, report, timestamp. The Recall node queries this by keyword similarity at the start of every run. Not vector search (that's the next step) — just SQL LIKE matching, which is good enough for a portfolio project and dead simple to reason about.

def recall_node(state: AgentState) -> AgentState:
    topic = state["topic"]
    words = [w for w in topic.lower().split() if len(w) > 4]

    past_runs = []
    for word in words[:3]:  # top 3 keywords
        results = db.search_by_keyword(word)
        past_runs.extend(results)

    context = format_past_runs(past_runs[:2])  # most recent 2 matches
    return {**state, "memory_context": context}

3. Tool-Calling — Decision Per Sub-Question

The LLM doesn't call web search blindly. It receives the tool schema and decides per sub-question:

TOOLS = [{
    "name": "web_search",
    "description": "Search the live web for current information",
    "parameters": {
        "type": "object",
        "properties": {
            "query": {"type": "string", "description": "Search query"}
        },
        "required": ["query"]
    }
}]

For factual sub-questions about current events, it calls the tool. For sub-questions it can reason about from existing notes, it doesn't. That's the distinction between a real agent and a search wrapper.

What Broke (The Honest Part)

1. Render Kept Suspending the Live Demo — So I Moved to Streamlit

The original architecture was FastAPI + React, streaming the live trace to the frontend via Server-Sent Events — each node completion fired an SSE event, the UI updated in real time.

It worked perfectly locally. On Render's free tier, SSE died after 30 seconds — Render closes long-lived HTTP connections on the free plan, and a 6-node agent with multiple web searches takes longer than that. I patched around it with background tasks + polling (the frontend polling /api/research/status/{job_id} every 2 seconds instead of holding a stream open), and that solved the timeout.

But the deeper problem was the platform itself. Render's free web services spin down on inactivity and get suspended monthly, so the live demo link kept going cold between visitors regardless of the polling fix. That's not something you patch — it's the tier's actual model. So I migrated off FastAPI + React entirely onto a single-file Streamlit app, reusing the agent/ and memory/ modules unchanged, deployed to Streamlit Community Cloud. No backend process to suspend, no SSE-vs-polling tradeoff to manage — Streamlit re-runs the script and renders state directly on each interaction.

Lesson: design for the deployment environment, not just localhost — and sometimes the right fix isn't a smarter workaround, it's picking a host whose free-tier model actually matches how the project gets used (an occasional demo click-through, not a service that needs to stay warm).

2. Model Deprecations — Three Times

Groq deprecated models mid-development, more than once:

llama-3.3-70b-versatile → deprecated
llama3-70b-8192 → decommissioned
llama3-groq-70b-8192-tool-use-preview → tool-calling broken Each one failed silently or with a cryptic error. Ended up on llama-3.1-8b-instant — smaller, but stable and actively maintained.

Lesson: never hardcode a model string. It belongs in an environment variable:

MODEL = os.getenv("GROQ_MODEL", "llama-3.1-8b-instant")

One env var change, no redeployment needed when the next deprecation hits.

3. Rate Limits Hit During Demo Recording

Groq's free tier is 100k tokens/day. Between development testing, debugging, and demo runs, I exhausted the quota on the same day I tried to record the LinkedIn screenshot. Two hours lost waiting for reset.

Lesson: keep a separate Groq API key for demos. Never use the dev key for production.

4. Python 3.14 Broke the Old Render Build

Back when this was still FastAPI on Render, pydantic-core had no wheel for Python 3.14 — silent build failure, no clear error, just a broken deploy. The fix was one environment variable (PYTHON_VERSION = 3.11.9) pinning the runtime explicitly instead of trusting the host default.

It's moot now that the app is Streamlit-only with a much smaller dependency surface, but the underlying lesson traveled with the migration: pin your Python version explicitly on any host, don't trust the default.

What I'd Do Differently

Replace SQL LIKE matching with vector search. Right now the Recall node finds past runs by keyword — it misses semantically similar research with different wording. ChromaDB or Supabase pgvector would fix this. It's the most meaningful upgrade this project needs.

Add a second tool. Right now the only tool is web_search. A calculator or structured data lookup would demonstrate the LLM genuinely choosing between tools — not just "search or not." That's a stronger tool-use story.

Instrument the reflect loop. I don't log how often the agent actually loops back vs. goes straight to synthesis. That metric would tell me whether the reflect node is earning its latency or just adding overhead.

Define the LLM interface contract on day one. Half my debugging time came from graph.py and llm.py making different assumptions about function signatures and return types. One typed contract file written before any agent logic would have caught all of it.

Try It

Live demo: agentloop.streamlit.app
GitHub: github.com/ayush-s-tomar/agentloop

(If you bookmarked the old agentloop.onrender.com link, it's retired — the app now lives on Streamlit Cloud, for the reasons above.)

Type any research topic and watch the pipeline run step by step — the trace panel shows every node as it executes, so you can see exactly when the agent decides to loop back.

If you're building something similar or have thoughts on the memory architecture, connect with me on LinkedIn.

My LLM App Was Charging Rent-Controlled Tenants Penthouse Prices — So I Built a Router to Fix It

Ayush Singh Tomar — Mon, 27 Jul 2026 03:30:15 +0000

Every LLM app I've built has the same expensive habit: one model, every request. "What is FastAPI?" and "compare these five architectures in depth" go to the same endpoint, at the same price. That's fine right up until you look at the bill — you're paying big-model rates for questions a much smaller model answers just as well.

So I built a router that sits in front of two models and decides which one actually earns the request.

Live demo: llm-cost-router.streamlit.app
Repo: github.com/ayush-s-tomar/llm-cost-router

What it does

Ask it anything. It classifies the question, then routes it to one of two models on Groq:

Llama 3.1 8B Instant — simple, direct questions
Llama 3.3 70B Versatile — genuinely complex, multi-part, or open-ended ones

Every request is logged with what it actually cost, and what it would have cost on the big model every time. The dashboard tracks all of it live — requests, actual spend, hypothetical spend, savings, percentage saved.

Watching it decide

Here's the router handling a simple and a complex question back to back, picking a different model each time without being told which to use:

"What is FastAPI?" → routed to the 8B model → complete, correct answer → $0.000020.

"Compare LangGraph and CrewAI in depth, covering architecture trade-offs" → routed to the 70B model → because a shallow answer here wouldn't hold up → $0.000691.

Same interface. Same person asking. Two different models, chosen automatically, with the price difference sitting right there instead of buried in a monthly invoice.

Across a mixed session like the one above, the dashboard lands around 33% cheaper than defaulting everything to the 70B model. That number isn't fixed — it moves with what you actually ask. A session of simple lookups saves more; a session of genuinely hard questions saves less, because more of them should be going to the big model. That's the entire design goal: not a flat discount, the right spend per question.

How the classifier decides

No embeddings. No cheap pre-classification LLM call — that would defeat the point of a cost router before it even started. Just a lightweight heuristic in router_logic.py:

Query length — long queries default to the big model
Complexity keywords — "compare," "analyze," "design," "trade-off," "step by step"
Simple-query patterns — "what is," "who is," "define," "list"

It won't catch everything — a short question that's secretly hard can slip through — but it costs nothing to run, which is the entire point. An LLM call to decide which LLM to call would eat the savings you're trying to create.

Here's the actual decision path — first match wins, everything else falls through to the cheap model by default:

What it doesn't do yet

No semantic caching — a near-identical question still hits the model every time
Only two tiers — a mid-size model would give the router more room to be precise instead of picking a side
The keyword heuristic can misfire on short-but-hard questions; a confidence threshold with a fallback path would help

Why this is the bigger lever

Most "cut your AI costs" content is prompt-engineering theater — shave a few tokens, cache a response, feel productive. None of it touches the actual lever. The model you pick is the cost. Everything else is rounding error.

Stack

FastAPI backend
React frontend
Streamlit for the live public demo
Groq for both models (Llama 3.1 8B Instant + Llama 3.3 70B Versatile)

Try it

Live demo: llm-cost-router.streamlit.app
Repo: github.com/ayush-s-tomar/llm-cost-router

If you're running LLM calls at any real volume, a router like this is one of the higher-ROI things you can build — a small amount of logic that pays for itself the first time it downgrades a request.

What's the one API call in your stack that's been quietly overpaying for a year and nobody's checked?

Two Bugs That Almost Shipped in My Agentic RAG Assistant

Ayush Singh Tomar — Mon, 13 Jul 2026 03:30:04 +0000

I built an agentic RAG assistant — upload a PDF, ask questions, get streamed answers grounded strictly in the document. It uses LangGraph for tool orchestration, Groq for inference, Qdrant Cloud for retrieval, and Streamlit for the UI, and it's self-contained: no separate backend service to keep alive for the live demo. If the answer isn't in the document, it says so instead of guessing.

It worked. Mostly. Every so often, a stray 【source】 tag — an internal citation marker never meant for the user — leaked straight into the answer on screen. Not always. Not predictably. That inconsistency turned out to be the whole puzzle, and chasing it down taught me more about streaming systems than the rest of the project combined.

That was the first of two bugs that surfaced during demo prep — the second one had nothing to do with streaming and everything to do with where I was storing state. Fixing it changed the deployment architecture entirely, which is why the finished version looks different from what I originally built.

(Screenshots below use a fictional test document — not a real product or person.)

Watching it decide — the agent retrieves, streams the answer token by token, and stays grounded in the uploaded document throughout.

What the project does

Ask a question, and the agent:

Retrieves relevant chunks from a Qdrant Cloud vector store built from your uploaded PDFs
Answers only from retrieved content — if nothing relevant is found, it says so instead of guessing
Routes queries between llama-3.1-8b-instant and openai/gpt-oss-120b based on complexity, so short factual questions don't pay large-model latency or cost

A LoRA fine-tuned resume screener also exists as a separate service, callable via screen_resume — it's not wired into the live demo's default flow, so I'm calling that out here rather than letting someone discover the gap themselves.

Stack: LangGraph (ReAct-style agent) · Groq running gpt-oss-120b (primary) and llama-3.1-8b-instant (routed, low-complexity queries) · Qdrant Cloud for the vector store (originally local Chroma — more on that below) · HuggingFace bge-small-en-v1.5 embeddings · Streamlit frontend, fully self-contained.

The assistant answering only from the uploaded document — quoting specifics like latency numbers and tech stack directly from the source, and correctly refusing to answer when the document has no relevant info ("What is Arjun's favorite hobby?").

Architecture — and where each bug lived

A user question goes into the Streamlit app, the LangGraph agent either retrieves from Qdrant Cloud or routes to a small or large Groq model depending on complexity, and the answer streams back. Bug #2 lived at the storage step — it's why Qdrant Cloud replaced local Chroma entirely. Bug #1 lived at the streaming step, one layer downstream.

Bug #1: a marker that only sometimes leaked

The agent tags its retrieval citations internally with a marker like 【source】, which is supposed to get stripped before the answer reaches the user. Simple enough — clean each chunk of streamed text with a regex as it comes in.

Except sometimes it didn't get stripped.

The cause: streaming breaks text into arbitrary token chunks, and the marker was getting split across two of them. One chunk would end with 【sour, the next would start with ce】. Since I was running the regex on each chunk in isolation, neither half ever matched the full pattern — both leaked straight through, untouched.

The fix wasn't a smarter regex. It was buffering: hold back any text that could be the start of an incomplete marker, and only release it once you're sure you're not sitting mid-tag.

_CITATION_ARTIFACT_RE = re.compile(r"【[^】]*】")

def stream_agent(question: str):
    """Yield the answer as it streams in, with citation markers
    stripped even when a marker is split across chunk boundaries."""
    buffer = ""
    for chunk in agent.stream(question):
        buffer += chunk

        while True:
            start = buffer.find("【")
            if start == -1:
                if buffer:
                    yield buffer
                    buffer = ""
                break

            if start > 0:
                yield buffer[:start]
                buffer = buffer[start:]

            end = buffer.find("】")
            if end == -1:
                break

            buffer = buffer[end + 1:]

Streaming still feels instant to the user. Nothing incomplete ever reaches them — the buffering adds negligible overhead, invisible in normal use.

The broader lesson: streaming systems fail in ways batch systems simply can't. A batch-mode version of this same assistant would never have hit this bug — it processes the full response as one string before cleaning it. This bug only existed because I was processing partial state in real time, and for a doc-QA tool, a leaked internal marker is exactly the kind of thing that quietly erodes trust in the answer itself, even when the answer underneath it is correct.

Bug #2: it felt broken because it was, structurally

Bug #1 was a parsing problem. Bug #2 turned out to be an architecture problem wearing a parsing-problem costume.

Once the streaming issue was fixed, a different problem showed up during demo prep: every time the backend went idle and spun back down, the app "forgot" everything. Users had to re-upload the same PDF and re-ingest it before asking anything, even though nothing about the workflow suggested that should be necessary.

The cause here wasn't a code bug — it was an architecture mismatch. At the time, the backend was deployed on Render's free tier, which uses an ephemeral filesystem: anything written to local disk, including the Chroma vector store, gets wiped on every restart or spin-down. Free-tier services spin down automatically after 15 minutes of inactivity, which is basically guaranteed for a portfolio demo that isn't getting constant traffic.

One giveaway made this obvious in hindsight: a response that came back in 0.86 seconds. That's far too fast for a real embed → retrieve → LLM round trip. It wasn't a fast correct answer — it was an empty vector store returning nothing, instantly.

The fix was to stop treating the vector store as something that lives on a server's local disk at all, and move it to a hosted vector database that persists independently of any backend's lifecycle:

# src/vectorstore.py — shared, persistent vector store client
import os
from langchain_qdrant import QdrantVectorStore
from langchain_huggingface import HuggingFaceEmbeddings
from qdrant_client import QdrantClient

embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-small-en-v1.5")

client = QdrantClient(
    url=os.getenv("QDRANT_URL"),
    api_key=os.getenv("QDRANT_API_KEY"),
)

def get_vectorstore(collection_name: str = "documents"):
    return QdrantVectorStore(
        client=client,
        collection_name=collection_name,
        embedding=embeddings,
    )

Ingestion writes to Qdrant instead of a local Chroma folder, and retrieval reads from the same remote collection — so a restart no longer wipes anything out. Once retrieval no longer depended on local state surviving a restart, the "upload every time" problem disappeared along with it.

This fix ended up reshaping the whole deployment. With persistence handled by Qdrant Cloud, the Streamlit frontend no longer needed a standalone backend to talk to at all — it calls Groq and Qdrant directly. The FastAPI backend (src/api.py) still exists in the repo for local development and HTTP access to the agent, but the live demo doesn't depend on it being up. One bug fix turned into a simpler, more resilient architecture than the one I started with.

One more thing that broke after the fact: a model deprecation

Not a bug in my code, but worth logging alongside the other two: this project originally ran llama-3.3-70b-versatile. Groq deprecated that model on 2026-06-17, with a shutdown date of 2026-08-16. The agent is now migrated to openai/gpt-oss-120b — Groq's recommended replacement, with full tool-calling support and a higher free-tier token budget (200K TPD vs 100K TPD).

Same lesson as the Groq deprecations I hit on a different project: never assume a hosted model string is permanent. If a production system depends on one, it belongs in a config value, not hardcoded — the day it gets deprecated shouldn't be a surprise.

What I'd tell someone building something similar

Don't clean streamed text chunk-by-chunk if the pattern you're removing can span chunk boundaries. Buffer first, clean second.
A suspiciously fast response is a bug signal, not a win. If retrieval-augmented generation ever responds faster than a real embed-plus-inference round trip should take, check whether it actually retrieved anything.
Free-tier hosting often means ephemeral disk. If your app's state needs to survive restarts, it can't live on the same filesystem as the compute — put it in a database or hosted store that's decoupled from the app's lifecycle. In my case, fixing this also let me drop a backend service entirely.
Hosted model strings aren't permanent. Keep them in config, not hardcoded, and expect at least one deprecation on any project that lives long enough.

Known limitations

Being upfront about what isn't polished yet:

gpt-oss-120b's tool-calling via Groq occasionally malforms a function call on ambiguous questions, surfacing as a 500 error — not yet hardened.
screen_resume expects a separate deployed service and fails gracefully if it's unreachable; this feature isn't live in the deployed demo.
route_query's complexity gate is a word-count heuristic, not a trained classifier — it will occasionally misroute a short-but-hard question to the cheaper model.

Try it / see the code

Code: github.com/ayush-s-tomar/agentic-rag-research-assistant
Live demo: agentic-rag-groq.streamlit.app

The live demo runs entirely on Streamlit Community Cloud now — no separate backend to wake up, so no cold-start wait on first request.

If you've hit a bug that only showed up because of streaming, chunking, or an ephemeral filesystem, I'd love to hear about it in the comments.

Stack: LangGraph · Groq (gpt-oss-120b + llama-3.1-8b-instant) · Qdrant Cloud · HuggingFace embeddings · Streamlit

Tags: #ai #python #rag #buildinpublic

I Got Tired of My Portfolio Looking Like a List of Links. So I Built an MCP Server for It.

Ayush Singh Tomar — Mon, 06 Jul 2026 03:30:13 +0000

The obvious fix for "my projects all look similar" is a better README — more screenshots, clearer descriptions, maybe a comparison table. I considered that for about five minutes and decided it was still just a nicer list of links.

What actually made a portfolio project feel different was making it something you could talk to instead of read. That's what MCP (Model Context Protocol) is built for — it's the standard that lets AI clients like Claude Desktop call external tools directly, not just process text. So I built a server that exposes my 9 projects as queryable tools instead of static entries.

What is MCP, and why does it matter here

Almost every AI-developer portfolio I've seen is a list of links. Mine now includes something you can actually talk to. Open Claude Desktop, connect my server, and ask "what has Ayush built with FastAPI?" — it doesn't guess from a cached README, it calls a real tool and answers from structured, live data.

What I built

A Python MCP server (FastMCP, stdio transport) exposing five tools:

list_projects — short summary of all 9 projects
get_project_details(project_name) — full stack, GitHub link, demo URL for one project, fuzzy-matched by name
search_projects_by_stack(technology) — "show me everything using Groq" or "LangGraph" or "React"
get_flagship_project — the single best project to look at first
get_resume_summary — background, target role, core stack

The data itself lives in plain Python dictionaries right now — no database needed for something this size. Each tool is a thin function around that data, decorated with @mcp.tool().

@mcp.tool()
def search_projects_by_stack(technology: str) -> list[dict]:
    """Find all projects that use a given technology or tool."""
    query = technology.lower().strip()
    matches = [
        {"name": p["name"], "stack": p["stack"], "github": p["github"]}
        for p in PROJECTS
        if any(query in tech.lower() for tech in p["stack"])
    ]
    return matches or [{"message": f"No projects found using '{technology}'"}]

What actually broke

The concept is simple. The setup had four separate rabbit holes:

1. MCP Inspector defaults to uv, not plain Python. Running mcp dev server.py opens a UI that assumes your project uses the uv package manager by default. If you're on a plain venv + pip setup, the command field needs to be manually changed to python with server.py as the argument, or it never connects.

2. Claude Desktop as a Windows Store app uses a different config path entirely. I'd installed it via the Microsoft Store first. The standard setup instructions all point to %APPDATA%\Claude\claude_desktop_config.json — which doesn't exist for the Store version, which stores its config somewhere under AppData\Local\Packages\... instead. Uninstalling and reinstalling the direct .exe from claude.ai/download fixed it.

3. Two nearly-identical config files. Once the real app was installed, there's a config snippet file in your own project folder (for reference) and the actual app config file (found via Settings → Developer → Edit Config). They can look identical at a glance. I edited the wrong one twice before I noticed the tab breadcrumb showing which was real.

4. The model doesn't always call your tool just because it's connected. My first test — "what projects has Ayush built with FastAPI?" — got answered from Claude's own internal guesswork instead of actually calling my server, and got a detail wrong as a result (called ResumeIQ a FastAPI project; it's Flask). Naming the tool or server explicitly in the prompt ("use the portfolio tool to search for...") forced an actual tool call, which then returned correct data every time.

Seeing it work

Once connected, this is what a real session looks like:

Me: What's Ayush's flagship project and why?

(Claude Desktop shows: "Claude wants to use Get flagship project from portfolio" — Always Allow / Deny)

Claude: Your flagship is SalesAgent — an autonomous B2B sales agent that takes a LinkedIn URL, researches the lead, scores them with an ML model (84/100 accuracy), and drafts a hyper-personalized cold email, all in under 45 seconds. Why it's the flagship: full-stack complexity (LangGraph + FastAPI + React + scikit-learn scoring), not a thin API wrapper around an LLM call...

That permission dialog matters — it's proof this is a real, sandboxed tool call happening live, not a scripted response.

Try it yourself

Repo: https://github.com/ayush-s-tomar/portfolio-mcp-server
Connect it to your own Claude Desktop in under 10 minutes — full setup instructions in the README.

If you're building an AI-developer portfolio and every project you have looks the same shape as the last one, this is a cheap way to add something structurally different: not another agent, but the plumbing that lets other agents actually use what you've built.

What would you expose if you built one of these for yourself?

I Got Tired of Writing Cold Emails. So I Built an AI Agent to Do It for Me.

Ayush Singh Tomar — Mon, 29 Jun 2026 04:22:18 +0000

B2B sales reps spend hours researching a single lead — reading LinkedIn profiles, Googling the company, checking for recent news, then writing a personalized email that doesn't sound like a template. Most of that work is repetitive pattern-matching, not judgment. I wanted to see if an agent could do it better, faster, and without the copy-paste.

The result is SalesAgent — paste a LinkedIn URL, get a researched lead profile, an ML-based score (0–100), and a hyper-personalized cold email. End to end in under 45 seconds. No templates. No manual research. Just paste and go.

Live demo: salesagent-ai.streamlit.app
GitHub: github.com/ayush-s-tomar/salesagent

What It Does

You paste a LinkedIn profile URL into the frontend
A LangGraph agent kicks off
The agent runs live Tavily web searches to research the lead and their company
A scikit-learn model scores the lead 0–100 based on six signals
Groq's LLaMA generates a personalized cold email referencing real company events
You get: lead summary, score with breakdown, and a ready-to-send email

Here's what it looks like in action — I ran it on Satya Nadella's LinkedIn profile. It found real Microsoft Build 2026 keynote news and referenced it directly in the email:

Subject: Congrats on Build 2026

Satya, the Microsoft Build 2026 keynote on June 2–3 featured the native Windows AI agent rollout and an expanded Copilot runtime — a strong signal of where Microsoft is taking the platform.

That's not a template. The agent found that news in real time and wrote around it — no preamble, no filler. (More on how I got it to write like this below.)

Architecture

Three nodes. Each one enriches the context for the next. The scoring node doesn't call an LLM — it runs a trained ML model, which is faster and more deterministic for a classification task like this.

Stack: LangGraph · FastAPI · React · scikit-learn · Groq LLaMA 3.1 · Tavily · Streamlit Community Cloud

How Each Part Works

1. Research Node — Tavily + LangGraph

The agent calls Tavily's search API twice per lead:

Search 1: "{name} {company} LinkedIn" — pulls profile signals (title, summary, skills)
Search 2: "{company} news funding jobs 2024" — checks for recent company activity

Tavily returns structured results with titles, URLs, and content snippets. The LangGraph research node processes these into six binary/numeric signals that feed the scorer:

signals = {
    "has_company": bool,      # Is company name known?
    "has_title": bool,        # Is job title known?
    "skills_count": int,      # Number of skills (0–15)
    "has_summary": bool,      # Does profile have a summary?
    "has_news": bool,         # Did Tavily find company news?
    "has_jobs": bool,         # Did Tavily find job postings?
}

has_news and has_jobs are the most valuable signals — they tell you whether the company is active and growing right now. That matters more than whether a LinkedIn summary exists.

2. Scoring Node — scikit-learn

The scorer uses a Gradient Boosting Classifier trained on 500 synthetic samples generated with numpy. Labels were assigned using a weighted formula:

score = (
    has_news    * 0.30 +   # Company is in the news = hot lead
    has_jobs    * 0.25 +   # Hiring = growing, budget exists
    has_title   * 0.20 +   # We know who we're targeting
    has_summary * 0.15 +   # They invest in their profile
    skills_count * 0.05 +  # Proxy for profile completeness
    has_company * 0.05     # Basic data quality check
)

Why ML instead of just an LLM scoring the lead? Two reasons: speed and determinism. An LLM call adds 2–3 seconds and gives you a different score every run. A trained classifier runs in milliseconds and gives you the same score for the same inputs every time — which matters when you're building something people actually use.

In production, you'd retrain on real CRM data — won vs lost deals — with richer features like funding stage, company size, industry vertical, and email response rate. But for a portfolio project with no CRM access, synthetic training with domain-informed weights gets you a working, explainable scorer.

3. Email Generation Node — Groq + LLaMA

The email node takes the full lead context — name, title, company, recent news, job postings — and injects it into a structured prompt. Getting this right took a second pass.

The first version technically worked but still sounded like AI. It pulled real company news in, but the LLM kept wrapping those facts in filler:

"I hope this email finds you well. I was thrilled to see the exciting news about your company's recent innovative advancements..."

Real news, buried in template language. A recipient skims the first line, sees "I hope this finds you well," and stops reading — even if paragraph two has something genuinely specific to say.

So I went back into the prompt and made one change: forbid the filler outright, and force the email to open with a fact, not a greeting.

System: You are an expert B2B sales copywriter. Never use generic openers
like "I hope this email finds you well" or "I was excited to see." Open
with a specific fact about the company. Reference only real information
provided — no invented details.

The difference was immediate. Same research, same lead, same model — just a tighter constraint on how it's allowed to start.

Before: "I hope this email finds you well. I was excited to see..."
After: "Congrats on the Build 2026 keynote on June 2 — the native Windows AI agent rollout and the expanded Copilot runtime were a strong signal of where Microsoft is taking the platform."

No preamble. It leads with the thing that makes the email worth reading.

Running it again on the same lead (Satya Nadella, against real Microsoft Build 2026 news) pushed the lead score from 84/100 to 90/100 — not because the scoring model changed, but because a fact-first email correlates with a more complete signal set (news found, jobs found, title confirmed) that the scorer weighs directly. Worth being honest about what that means: the scorer is still trained on synthetic data, not real won/lost deals, so it's a good relative signal between two runs of the same agent — not a claim that 90/100 means "this lead will convert."

What Broke (The Honest Part)

This is where I spent most of my time. Real projects break in ways tutorials never show you.

1. Groq Model Deprecations — Three Times

llama-3.3-70b-versatile failed. Switched to llama3-70b-8192. That was decommissioned. Tried llama3-groq-70b-8192-tool-use-preview — tool-calling didn't work properly. Ended up on llama-3.1-8b-instant, which is smaller but stable.

The lesson: never hardcode a model string. In a production system, this belongs in a config file or environment variable so you can swap it without touching code.

2. Tool-Calling Schema Bug — 400 Failed Generation

Groq was rejecting my tool schemas with a failed_generation 400 error. After multiple attempts to isolate it, the issue was that I was passing input_schema directly instead of extracting properties and required separately.

Wrong:

"input_schema": tool.input_schema

Right:

"parameters": {
    "type": "object",
    "properties": tool.input_schema["properties"],
    "required": tool.input_schema.get("required", [])
}

This took longer than it should have because the error message (failed_generation) gave no hint about the schema structure. If you're hitting this — check your tool schema first.

3. Interface Mismatch Between graph.py and llm.py

graph.py was calling run_with_tools(prompt=..., system=...) and expecting a (text, tool_log) tuple back. llm.py was written to accept messages=[] and return a dict. Classic interface mismatch between two files written in isolation.

Every bug from this — the prompt vs messages confusion, the system kwarg error, the tuple vs dict return type — cost me hours of debugging that a typed interface contract would have caught in seconds.

4. Python 3.14 on Render

pydantic-core failed to build because no wheel exists for Python 3.14. Fix: force PYTHON_VERSION=3.11.9 in the environment variables.

If you're deploying to a platform like Render: always pin your Python version explicitly. Don't trust the platform default.

5. The Cached ML Model That Wouldn't Let Go

After I rebalanced the scoring weights to favor the fact-first signals, the lead score stayed frozen — every run, no matter what I changed in the prompt or the code. I checked the prompt, checked the API response, checked the signal extraction. All correct. The score still didn't move.

The actual culprit: model.pkl, the trained scorer, was cached on disk from a previous deploy and never got retrained when the weighting logic changed underneath it. The code was right. The model on disk was stale. Nothing in the logs said so — it just quietly kept scoring against old assumptions.

Fix was one line in the build command: rm -f ml/model.pkl before every deploy, forcing a retrain from scratch each time. Cheap fix, expensive to find — because a stale artifact doesn't throw an error, it just gives you a plausible-looking wrong answer.

6. The Render Free Tier Got Suspended

Mid-project, my backend host (Render) suspended the free-tier deployment. No warning I saw in time — just a "This service has been suspended" page where the API docs used to be.

I didn't fight it. I pulled every reference to the old backend URL out of the README, replaced the curl example with a localhost version so anyone cloning the repo can still test the endpoint locally, and added an explicit line to the README's Known Limitations section rather than leaving a dead link for someone to discover on their own:

"Backend is not hosted live — the free-tier Render deployment was suspended, so the API is not reachable at a public URL right now. Run it locally with the steps above."

I ended up migrating the live demo to Streamlit Community Cloud instead, which is why the link above looks different from earlier screenshots.

Lesson: on a portfolio project, a dead link someone finds themselves is worse than an honest sentence explaining why it's dead.

7. Demo Assets and Docs Drifted From the Code

Between the screenshot, the GIF, and the README's "Demo Output" text block, I'd updated the code but not all three assets — so the README was showing an 84/100 score with old email copy while the actual screenshot showed 90/100 with the new fact-first output. Small inconsistency, but exactly the kind of thing a careful reader (or a hiring manager) notices.

Separately, the README's file tree still listed demo.mp4 as "optional" — leftover from before I'd actually recorded and embedded it — and didn't mention demo.gif at all, even though both were live in docs/. Nothing broken, just stale comments describing a folder that had since changed shape.

Fixed both by treating all demo assets as one unit: screenshot, GIF, and the "Demo Output" text get regenerated and reviewed together, not independently.

What I'd Do Differently

Define the LLM interface contract on day one.

The biggest source of bugs was graph.py and llm.py making different assumptions about function signatures, return types, and argument names — and those assumptions were never written down anywhere.

If I rebuilt SalesAgent today, the first file I'd create:

# contracts.py — written before any other code

def run_with_tools(prompt: str, system: str) -> tuple[str, list[dict]]:
    """Run LLM with tool-calling. Returns (response_text, tool_call_log)."""
    ...

def chat(messages: list[dict], system: str) -> str:
    """Simple chat completion. Returns response string."""
    ...

One typed file, agreed upfront. Every bug from the interface mismatch would have been caught before a single line of agent logic was written.

Walk through the whole project as a stranger would before sharing it. Click every link, rerun the pipeline end to end, read every README claim against what's actually running. None of the bugs above were algorithm problems — they were discipline problems: a prompt that quietly regressed into filler, a model artifact that silently went stale, docs that drifted from the code. This is the cheapest QA pass available, and it's the one that catches stale caches and dead links before someone else does.

Beyond that — in a production version, I'd replace synthetic training data with real CRM data (won/lost deals) and add email open tracking to close the feedback loop, so the scorer retrains on actual outcomes instead of assumed weights.

Try It

Paste any LinkedIn URL into the live demo and watch the full research → score → draft pipeline run in real time. The email quality scales with how much public news exists about the company — well-covered companies get sharper, more specific emails.

Live demo: salesagent-ai.streamlit.app
GitHub: github.com/ayush-s-tomar/salesagent

If you're building something similar, or have hit similar prompt-drift, stale-cache, or deploy-suspension issues on your own projects, I'd genuinely like to hear about it — connect with me on LinkedIn.

Stack: LangGraph · FastAPI · React · scikit-learn · Groq LLaMA 3.1 · Tavily · Streamlit Community Cloud

Tags: #ai #python #machinelearning #langchain #buildinpublic