GatherGov CTO Hardik Bansal on Building Production AI

The Forbes 30 Under 30 engineer says the industry is optimizing the wrong variable after 10 years of shipping generative AI across consumer and enterprise products.

Recently, we chatted with Hardik Bansal, CTO of GatherGov, to understand the difference between AI that performs well in demos and AI that performs well in production. Many teams are optimizing the wrong variable, Bansal says, as much of the enterprise conversation continues to focus on models, benchmarks, and provider comparisons.

He told us that the model is not always the key to the success of a production AI system. “It’s the framework of the model.”

Bansal’s perspective is rooted in a long history of shipping. Since 2017, he has been developing production generative AI systems, from research to consumer scale systems as a co-founder and CTO of FRND, and enterprise deployments at GatherGov. In all those settings, he noted, the same theme emerged. Systems produce results, models produce output.

“Generative models are very good at generating plausible output,” Bansal said. “They, by themselves, are not reliable in producing correct output; the whole engineering challenge is to put structure around them so that the plausible output is also correct.”

Most enterprise AI projects fail at that point, Bansal says. Teams select a model, plug it into their data, and hope for accuracy. When it does, the system ships. If the accuracy is not good enough, the natural reaction is to replace the model with a more accurate one or to adjust the current model to make it more accurate. The assumption is that the model is the most important variable.

Bansal’s experience points in a different direction. The variable that determines whether a system holds up in production is the scaffolding: how the training data is curated, how outputs are evaluated, how errors are caught and fed back into the pipeline, and how domain knowledge is encoded into the system’s architecture rather than left to the model’s inference.

The clearest test of the principle came at FRND, where Bansal’s team used generative AI to power moderation systems that processed real-time unstructured speech across tens of millions of users. The pipeline had to balance cultural context against safety risk at a volume and speed that required the system, rather than any individual model, to carry the burden of accuracy.

“We were doing in 2020 what most enterprise AI teams are doing in 2025,” he said. “Generative AI in front of a real consumer audience, at scale, with zero tolerance for failure. That was a crash course. The systems that held up were the ones with structure underneath them: evaluation layers, feedback loops, and human-in-the-loop escalation paths. The model was a component. The architecture around it determined whether the product worked.”

The takeaway Bansal carried forward was that a production AI system needs to be designed so that every output can be traced, every failure can be diagnosed, and every correction can be fed back into the pipeline automatically. The model generates. The system verifies. At FRND’s scale, any gap between those two functions surfaced within hours.

“That is the discipline most teams learn after their first production incident,” he said. “We learned it across tens of millions of them.”

The principle Bansal returns to most often, and the one he considers most specific to AI builders, is that every architecture decision should be either reversible or traceable.

“Reversible, so you can change it when the world changes,” he said. “Or traceable, so you can understand why the system did what it did when it inevitably surprises you. Black boxes are a luxury production AI has never been able to support.”

GatherGov’s decision-making process follows this principle at all levels. The website handles numerous municipal government proceedings, and its output is accessible to institutional investors and newsrooms that require citation-quality assurance. When a system emits ambiguous signals about the zoning change or budget-stress indicator, the chain of reasoning must be subject to complete audit. All such factors must also be considered valid. Whenever the model is modified or a pipeline is reorganized, it is crucial for the team to be aware of the changes and their reasons for them in the output.

According to Bansal, an investment committee must verify information against the original source within seconds before acting on it. This is what drives our architecture.

Traceability is the feature. Everything is constructed to serve it. “…

Clarity, Feedback and Distribution are the additional three principles.

There are three other principles that Bansal applies across his entire engineering and operations framework:

1. Clarity is more important than complexity, and the simpler approach tends to be more scalable. “Real progress involves observing behavior and improving it.”. A small team’s most costly mistake is over-engineering.Feedback loops are everything. “The faster you can move from idea to execution to feedback to iteration, the more durable your decisions become,” he said. “Iteration is the cheapest form of intelligence. Every version teaches you something the first plan never could.”

2. Distribution and product evolve together. “You can build something technically excellent, and it will still fail if it reaches the wrong users, or the right users too late,” he said. “Engineering and go-to-market thinking have to develop in parallel.”

3. Underneath the architectural principles is a broader thesis that has guided both of Bansal’s companies: AI’s most durable contribution will be the reduction of information asymmetry.

“There is an enormous amount of valuable information in the world that is technically public but practically inaccessible,” he said. “Government meetings. Court filings. Regulatory dockets. Scientific literature. Earnings calls. Until very recently, the only way to make sense of any of it was to hire a small army of analysts. That is changing now, and it is changing fast.”

The implication, in Bansal’s view, is that the most consequential AI products of the next decade will be intelligence layers: structured systems that turn previously inaccessible information into decisions that ordinary professionals can act on. The chatbot era, he argues, is a transitional phase. What follows will be defined by systems that do the work of synthesizing, verifying, and structuring information that, until now, has required teams of specialists.

GatherGov is his current test of that thesis. Municipal government proceedings represent one of the largest and most actionable bodies of public information in the United States, and one of the least structured. The platform’s job is to close that gap at a scale and level of accuracy that institutional users can rely on daily.

“I am drawn to gaps,” he said. “Wherever real value is being left on the table because the tools to capture it have only recently become viable, that is where I want to be working.”

Asked where he expects enterprise AI to be in three years, Bansal is direct. “The novelty of being able to talk to your data is going to wear off,” he said. “What will remain is the demand for systems that can answer hard questions accurately, with citations, at scale, in domains where the stakes are real.”

The companies positioned to meet that demand, he argues, will have treated the model as one component inside a larger engineered system, rather than as the system itself. They will have built the evaluation pipelines, feedback loops, and traceability layers that turn raw model capabilities into something an institution can depend on.

It is a bet Bansal is making with his own career. GatherGov’s engineering team in New York is being built specifically around this thesis, with hiring benchmarks set by the requirements of institutional users who expect accuracy, consistency, and auditability at a level most AI products have yet to deliver.

“Build fast, but instrument everything,” Bansal said. “You can only scale what you can measure. Speed is a feature. Iteration is intelligence. And if your system only works at a small scale, it is a prototype, and you should treat it like one.”