Ambuj Kumar Tripathi is an independent GenAI engineer building agentic RAG systems and AI workspaces from Gorakhpur, India.
His 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.
We 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.
From telecom to agentic AI
Ambuj 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.
He stepped away from the role for surgery in August 2024 and decided during his recovery that he wanted to move into AI.
Instead 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.
“Each project built on the failures and lessons of the one before it.”
About 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.
Building AI that knows when it doesn’t know
Ambuj’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.
Instead 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.
A 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.
It also uses metadata filtering to find specific sections of legal documents and masks sensitive identifiers before queries reach third-party LLM APIs.
“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.”
Today, 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.
One health check, two problems solved
Running the Agentic Financial Parser on Render’s free tier keeps costs down, but it comes with a catch.
After 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.
His solution was to have UptimeRobot send a HEAD request to the app’s /health endpoint every five minutes.
That keeps the Render container active without adding another process to an already tight 512 MB RAM budget.
But 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.
“Every UptimeRobot ping simultaneously keeps Render alive and prevents Supabase from pausing — one HTTP request solving two infrastructure problems.”
Ambuj also uses the UptimeRobot 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.
What happens when something breaks
With 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.
External 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.
If 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.
But the failure Ambuj would most like to catch is harder to see.
“I’d want to know when the pipeline’s behavior changes even if nothing technically ‘breaks.’”
A 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.
Right now, Ambuj can investigate those changes through traces, but only after he knows to look for them.
The least reliable part of the stack
After building and running these systems in production, Ambuj’s biggest reliability lesson is surprisingly simple.
“The LLM is the least reliable part of your entire stack, and you have to architect around that reality from day one.”
Unlike 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.
Ambuj discovered that the problem can start even earlier in the pipeline.
His 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.
“I was feeding hallucinated input into a system designed to prevent hallucinated output.”
The 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.
What monitoring still can’t see
Traditional monitoring can tell Ambuj when his application goes down or starts responding slowly. But agentic AI introduces another category of failure. A system can be technically healthy while the quality of what it produces is getting worse.
That’s the gap he’d most like monitoring tools to address.
“The system can be ‘up’ with perfect latency, but the quality of its outputs is degrading.”
For Ambuj, that could mean tracking retrieval confidence over time and flagging a downward trend before it becomes an obvious problem.
He’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.
Cost 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.
For 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.
“There’s a gap in between — something that understands both the infrastructure health and the semantic health of what the AI is actually doing.”
It’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.
See what Ambuj is building next
Follow Ambuj’s work on GitHub and Hugging Face, or connect with him on LinkedIn to keep up with what he’s working on.
