Evaluation had to come before the rest of the product because reliable measurement is what tells you whether an AI system works. Before Future AGI had a product name or website, Nikhil Pareek and Siddharth Rao kept returning to a spreadsheet that recorded LLM calls, responses, and manual scores.
The spreadsheet was slow and difficult to scale, and its scores sometimes differed. Still, it gave us more confidence than demos or intuition about whether the AI behaved correctly. That experience led us toward evaluation as a product.
The Recurring Problem
Before Future AGI, we had built with LLMs and found that capability was not the central issue. The harder question was whether a deployed system worked correctly for the users relying on it. We lacked a systematic way to answer it.
Demos and written test cases could pass while production exposed new problems. Users asked unexpected questions, retrieval returned documents that were relevant but misleading in context, and models produced answers that looked correct while containing subtle factual errors.
We usually discovered these failures through user feedback or occasional manual review, often after the same issue had happened many times. The feedback loop was slow. Logging and error rates showed operational health, but not output quality, so a system could appear healthy while returning poor answers.
What "Evaluation First" Meant
Future AGI began with a simple principle: improvement requires measurement. Without dependable quality measurement, prompt changes were tested against a few cases and deployed largely on instinct. There was no reliable way to know whether a change improved results across the full range of inputs.
Evaluation first meant creating the measurement layer before the rest of the product. The first working version was a library: wrap an LLM call, define a rubric, and receive a score. There was no dashboard, trace visualization, or alerting, only a number showing how well the response met the chosen criteria.
We used the library while working on other projects because we wanted something useful in practice, not merely in theory. Early versions were rough, manual, and slower than intended, but the signal was real and influenced decisions. That was enough reason to continue.
Why We Built It Ourselves
In early 2025, the existing tools left a gap. Research-oriented tools focused on notebook evaluations rather than production, while observability tools logged calls without scoring them. What was missing was continuous evaluation at production pace, connected to the feedback loop of a deployed system.
We expected that gap to narrow as the field matured, and it has begun to do so. Even so, in early 2025 the gap was large enough that building what we needed was faster than waiting for it to appear.
Evaluation also depends on the use case. A support bot, code assistant, and data extraction pipeline require different rubrics. A broadly useful evaluation tool must balance flexibility with structure. We wanted rubrics expressive enough for each use case without forcing users to select from a fixed list of quality dimensions.
Lessons From Early Access
Early access opened to a small group of teams in the first half of 2025. The most useful lesson came from comparing actual use with our expectations. We expected pre-deployment testing to lead: create a harness, run it before shipping, and find problems. Some teams did that, while more used continuous monitoring on sampled production calls and followed score distributions over time.
This showed that detecting issues after deployment was more urgent than preventing them before release. Teams needed to find problems while users were experiencing them. As a result, real-time alerting, drift detection, and integrations with existing observability stacks moved higher on the roadmap.
Where We Are Now
Future AGI remains bootstrapped and in early access. The product has grown beyond its original library into an evaluation and observability platform, with integrations for LangChain, LlamaIndex, and direct LLM provider clients. Its trace visualization was built by Siddharth Rao, CTO.
The founding question remains: how do you know whether your AI is working? We began with a spreadsheet because measurement was necessary, and we are building better tools for the same reason. Software should not be shipped without knowing whether it does what it is meant to do.
If this sounds familiar, that is why Future AGI exists.