{"slug": "uptimerobot-featured-my-journey-from-telecom-to-genai", "title": "UptimeRobot featured my journey from Telecom to GenAI", "summary": "Independent GenAI engineer Ambuj Kumar Tripathi, based in Gorakhpur, India, has built the open-source Agentic Financial Parser, which has gained more than 100 GitHub stars and processes over 32,000 document chunks on 512 MB of RAM. He uses UptimeRobot to send HEAD requests every five minutes to keep his Render free-tier service active and prevent Supabase from pausing, solving cold starts of 30 to 45 seconds. Tripathi, who transitioned from British Telecom after surgery in August 2024, focuses on hallucination-resistant RAG systems that score retrieval confidence and stop if it falls below 45%.", "body_md": "Ambuj Kumar Tripathi is an independent GenAI engineer building agentic RAG systems and AI workspaces from Gorakhpur, India.\n\nHis open-source Agentic Financial Parser has picked up **more than 100 GitHub stars**, while his latest projects explore everything from hallucination-resistant document retrieval to AI agents that can work across GitHub, Gmail, financial data, and the web.\n\nWe caught up with Ambuj to talk about what he’s building, the reliability problems that come with handling AI workloads, and the unique way he uses UptimeRobot to keep his infrastructure running.\n\n## From telecom to agentic AI\n\nAmbuj didn’t start out working with LLMs. Before moving into GenAI, he spent around two and a half years at British Telecom working on network planning, GIS-based optimization, and internal automation.\n\nHe stepped away from the role for surgery in August 2024 and decided during his recovery that he wanted to move into AI.\n\nInstead of taking a course or bootcamp,** he learned by building**. Rules-based chatbots led him to RAG, then LangChain, LangGraph, and eventually stateful agentic systems.\n\n“Each project built on the failures and lessons of the one before it.”\n\nAbout six months later, his open-source Agentic RAG project had passed 100 GitHub stars, with other developers forking it and building on top of his work.\n\n## Building AI that knows when it doesn’t know\n\nAmbuj’s main open-source project is the **Agentic Financial Parser**, a RAG system made to tackle dense Indian financial and legal documents such as Income Tax Acts, Finance Bills, RBI circulars, and the Constitution of India.\n\nInstead of relying on a general-purpose AI assistant to interpret hundreds of pages of legal or financial text, users can upload documents and ask questions against the source material itself.\n\nA big part of the project is knowing when *not* to generate an answer. The pipeline scores retrieval confidence and, if it falls below 45%, stops and asks the user for permission before searching the web.\n\nIt also uses metadata filtering to find specific sections of legal documents and masks sensitive identifiers before queries reach third-party LLM APIs.\n\n“I wanted to build a system where you could upload these heavy documents and ask precise questions — and get answers that are actually grounded in the document text, with source citations, and with the system being honest when it doesn’t know something.”\n\nToday, the project processes more than 32,000 document chunks and runs on just 512 MB of RAM on Render’s free tier.** Ambuj has also built a separate Agentic AI Workspace **that connects an AI agent to tools including GitHub, Gmail, stock data, and web search.\n\n## One health check, two problems solved\n\nRunning the Agentic Financial Parser on Render’s free tier keeps costs down, but it comes with a catch.\n\nAfter 15 minutes without activity, the service spins down. The next request then has to wait for the container to start, the FastAPI app to load, and connections to MongoDB and Pinecone to initialize. Ambuj was seeing cold starts of 30 to 45 seconds.\n\nHis solution was to have UptimeRobot send a HEAD request to the app’s /health endpoint every five minutes.\n\nThat keeps the Render container active without adding another process to an already tight 512 MB RAM budget.\n\nBut the health check does more than keep Render awake. Each request also triggers a lightweight Supabase query, preventing the database from being paused after seven days of inactivity on its free tier.\n\n“Every UptimeRobot ping simultaneously keeps Render alive and prevents Supabase from pausing — one HTTP request solving two infrastructure problems.”\n\nAmbuj also uses the [UptimeRobot API](https://uptimerobot.com/api/) to pull his 30-day uptime ratio and latest response latency into the app itself. If the Render container does go down during a redeployment or for another reason, UptimeRobot’s email alerts let him know when it goes offline and when it comes back.\n\n## What happens when something breaks\n\nWith a 10-node pipeline and several external services in the mix, there isn’t one tool responsible for telling Ambuj when something goes wrong. Different failures show up in different places.\n\nExternal API calls are protected by circuit breakers that open after three consecutive failures, preventing the pipeline from hanging or crashing when services such as OpenRouter, Jina Embeddings, or Tavily Search go down.\n\nIf the entire container becomes unavailable, **UptimeRobot catches it and sends an email alert**. Langfuse and LangSmith handle another layer, tracing individual LLM calls, retrieval steps, and node transitions to surface latency and other performance problems.\n\nBut the failure Ambuj would most like to catch is harder to see.\n\n“I’d want to know when the pipeline’s behavior changes even if nothing technically ‘breaks.’”\n\nA gradual decline in retrieval confidence, for example, could point to problems with embeddings or the way a new document type is being chunked. The application could still be online and responding normally while the quality of its answers gets worse.\n\nRight now, Ambuj can investigate those changes through traces, but only after he knows to look for them.\n\n## The least reliable part of the stack\n\nAfter building and running these systems in production, Ambuj’s biggest reliability lesson is surprisingly simple.\n\n“\n\nThe LLM is the least reliable part of your entire stack, and you have to architect around that reality from day one.”\n\nUnlike a traditional API failure, an LLM doesn’t always return an obvious error. It can time out or hit a rate limit, but it can also keep working while producing confident answers that are completely wrong.\n\nAmbuj discovered that the problem can start even earlier in the pipeline.\n\nHis original document parser used a Vision LLM to extract text, tables, and other content from complex PDFs. On certain documents, it would invent table structures that weren’t actually there. The output looked perfectly clean, which meant fabricated information could enter the system before the RAG pipeline ever had a chance to verify it.\n\n“I was feeding hallucinated input into a system designed to prevent hallucinated output.”\n\nThe fix was a hybrid approach. Complex documents still go through the Vision LLM parser, while text-heavy documents use PyMuPDF locally. Ambuj has added other safeguards throughout the system, too, including metadata filtering for legal text and a separate verification step that checks whether an answer is actually supported by the retrieved source material.\n\n## What monitoring still can’t see\n\nTraditional monitoring can tell Ambuj when his application goes down or starts responding slowly. But [agentic AI](https://uptimerobot.com/ai-agent-monitoring/) introduces another category of failure. **A system can be technically healthy while the quality of what it produces is getting worse.**\n\nThat’s the gap he’d most like monitoring tools to address.\n\n“The system can be ‘up’ with perfect latency, but the quality of its outputs is degrading.”\n\nFor Ambuj, that could mean tracking retrieval confidence over time and flagging a downward trend before it becomes an obvious problem.\n\nHe’d also like visibility into individual nodes within an agentic pipeline, where one retrieval node could quietly stop returning useful results while the rest of the system continues running normally.\n\nCost is another blind spot. A sudden jump in tokens per response can become expensive without affecting uptime at all, while memory pressure is particularly important for projects like Ambuj’s that run within tight free-tier resource limits.\n\nFor now, he sees tools such as Langfuse and LangSmith covering the tracing side and UptimeRobot covering infrastructure availability. What’s missing is the layer between them.\n\n“There’s a gap in between — something that understands both the infrastructure health and the semantic health of what the AI is actually doing.”\n\nIt’s another problem Ambuj is approaching the same way he learned to build with LLMs in the first place. He finds the gaps, figures out why they exist, and keeps experimenting until he finds a better solution.\n\n## See what Ambuj is building next\n\nFollow Ambuj’s work on GitHub and Hugging Face, or connect with him on LinkedIn to keep up with what he’s working on.", "url": "https://wpnews.pro/news/uptimerobot-featured-my-journey-from-telecom-to-genai", "canonical_source": "https://uptimerobot.com/blog/community-spotlight-ambuj-kumar-tripathi/", "published_at": "2026-08-21 09:32:20+00:00", "updated_at": "2026-08-21 09:43:53.891204+00:00", "lang": "en", "topics": ["artificial-intelligence", "generative-ai", "ai-agents", "ai-tools"], "entities": ["Ambuj Kumar Tripathi", "Agentic Financial Parser", "UptimeRobot", "British Telecom", "Render", "Supabase", "MongoDB", "Pinecone"], "alternates": {"html": "https://wpnews.pro/news/uptimerobot-featured-my-journey-from-telecom-to-genai", "markdown": "https://wpnews.pro/news/uptimerobot-featured-my-journey-from-telecom-to-genai.md", "text": "https://wpnews.pro/news/uptimerobot-featured-my-journey-from-telecom-to-genai.txt", "jsonld": "https://wpnews.pro/news/uptimerobot-featured-my-journey-from-telecom-to-genai.jsonld"}}