Trading Desks to Clinical Trials: Parallels in Applied Vertical AI

What changes when an applied-AI engineer leaves a hedge fund for a pharmaceutical startup? Ayush Bhardwaj made that move, taking responsibility for technology and applied AI at Allos. The setting changed, but the practical problem remained: build a system that can perform a specific industry job well enough to be useful.

Applied vertical AI means AI built for one particular industry. Google Translate is a general-purpose application that can serve many industries; Allos uses AI for drug development. Legal-tech applications offer another example: the product is organized around a professional task, rather than a capability that happens to have many uses.

Bhardwaj expected the move to change his work substantially. A hedge fund wants decisions fast and mostly right: individual losses can be acceptable if the overall strategy wins. Pharma puts much more weight on correctness. He illustrates that difference with a fifteen-year development horizon and a willingness to allow another week to get something right. Those are very different operating environments, yet the core applied-AI work felt remarkably similar. Conversations with practitioners in legal AI and property technology suggested that the development steps could be shared across industries.

The first shared requirement is economic. Asking whether agents reach production sets a low bar—Bhardwaj jokes that even teenagers deploy them. The harder question is whether the system makes or saves more money than the complete investment required to build and operate it. He reports that agents delivered economic value at both of his employers, based on his own experience. Deployment is a milestone; useful return on investment is the test.

The recipe begins with problem formulation. A request to find the top three investment opportunities leaves almost everything unspecified: the market, the industry, the comparison criteria, and what makes an opportunity attractive. Narrow it in sequence:

1. Choose a market: US equities.
2. Choose an industry: information technology.
3. Define the task: rank the stocks.
4. Specify the ranking criteria: capital expenditure or AI investment.

The resulting job is small enough to describe and inspect. It also gives the next step—finding the right data—a concrete target.

There is no requirement that one agent own the entire workflow. Bhardwaj’s joke is that there is no tax on building more agents: give each one a specific task instead of expecting a single agent to do everything. Pharma follows the same pattern. Break the process into steps, then ask pointed questions at each step.

Next, identify the data. News and sell-side reports from JPMorgan or Morgan Stanley are common financial inputs. In scientific work, arXiv, PubChem, and published research are widely available. Those sources can be useful without distinguishing your application from ChatGPT or Claude. The differentiating input is often proprietary evidence.

That evidence may be expensive to buy, or its owners may refuse to sell it. Start by looking inside the organization. Bhardwaj imagines a company with three years of accumulated, unstructured records and suggests that an LLM workflow could structure them overnight. The practical opportunity is to turn existing work into usable records; the overnight estimate is an illustration, without a specified corpus size or validation requirement.

These records contain the reasoning and negative evidence that a collection of public documents may miss. A failed experiment can matter precisely because it did not become a successful result worth publicizing.

With a task and data in hand, write the prompt around how a practitioner would solve the problem. Bhardwaj initially frames this as modeling the person whose work the system might replace, then qualifies that he is not advocating replacing people. The useful engineering instruction is to encode the human process as multiple steps, rather than merely request a polished answer.

For the US IT equities example, a prompt can make that decomposition explicit. This Python representation separates the task from the supplied records and gives the output a reviewable structure:

import json


def ranking_prompt(records: list[dict[str, object]]) -> str:
    return "\n\n".join([
        "Task: rank US information-technology equities "
        "by capital expenditure using the supplied records.",
        "1. Identify each company's reported capital expenditure "
        "and reporting period.",
        "2. Identify missing values or incompatible reporting periods "
        "before comparing companies.",
        "3. Rank comparable records by reported capital expenditure, "
        "highest first.",
        "4. Return the ranking, supporting record identifiers, "
        "and records excluded from comparison.",
        "Records:\n" + json.dumps(records, ensure_ascii=False),
    ])

The comparison and output rules make the earlier narrow task concrete. Whether those rules capture a useful investment question still requires a practitioner’s judgment.

Then add observability. Traces let the team see what the application did, understand its behavior, and debug it. Bhardwaj characterizes the first four steps—task definition, data, prompting, and observability—as the easy part, pointing to an agent implementation that fits on one screen. His image of a highly productive engineer building it in minutes makes a competitive point: the basic implementation is easy to reproduce. Proprietary data is his explicit exception.

Iteration seems like the obvious next step. At the hedge fund, however, Bhardwaj discovered that he could build the application without being able to tell whether its output was good. He was not a trader; later, in pharma, he was not a specialist in biology or chemistry. The missing capability was judgment, not implementation.

Engineers already have a mental model for assessing generated code. They can recognize weak code or decide that a much-hyped model is less useful than advertised. That competence does not automatically transfer to a trade thesis or a specialist scientific task. A vertical AI project can therefore look finished to its builders while producing outputs its intended customers would reject—just as engineers reject an inferior coding assistant.

Bhardwaj tried to solve this with LLM-as-judge. In his account, the attempt failed because fluent specialist language was not a reliable signal of useful specialist reasoning. A judge can reward jargon without recognizing whether an output creates financial alpha or other practical value. His qualification matters: the model needs some way to learn the domain’s standards. Asking another ungrounded model to evaluate the answer does not supply those standards by itself.

Reinforcement learning with verifiable rewards benefits from tasks with accessible checks. Math may have an answer key; code can be checked for compilation and subjected to further tests. The specialist tasks Bhardwaj describes do not offer an equally straightforward verification signal. A convincing trade thesis is not validated merely by being well formed. Errors can also propagate through subsequent reasoning steps, a concern he associates with Yann LeCun.

The other bottleneck is evidence that never became public. For finance and pharma, Bhardwaj argues, the data needed to learn valuable professional judgments is often held by organizations that have strong reasons to protect it.

His finance example is portfolio disclosure. Form 13F reporting applies to institutional investment managers exercising investment discretion over at least $100 million in covered securities, with quarterly filings generally due within 45 days after quarter-end. Bhardwaj points to a chart connecting disclosure with lower hedge-fund returns: competitors can inspect holdings and reverse-engineer a strategy. The useful mechanism here is the incentive to protect an informational advantage; he does not supply a numerical return decrease in the spoken explanation.

The pharma example needs a narrower legal scope than the talk’s description of every trial. Federal reporting obligations apply to certain applicable clinical trials, not every trial or failed laboratory experiment. The FDA’s 2026 reminder found no submitted results for 29.6% of studies highly likely to require reporting—not 29.6% of firms. It reports reminders to more than 2,200 companies and researchers associated with more than 3,000 trials; some recipients may instead have needed to complete quality-control review. Missing public evidence is the relevant problem, but those figures do not establish that every omission concealed an unfavorable result.

Bhardwaj compares valuable private evidence to a chicken that lays golden eggs: selling it can mean giving away the source of future advantage. He argues that frontier-model providers such as OpenAI and Anthropic consequently lack crucial protected data. Nor, in his hypothetical example, can a lab simply hire a trader for $100 an hour to annotate it: confidentiality agreements and the economics of specialist labor obstruct that route. This is his explanation for why public-model capability alone does not eliminate the need for internal expertise.

The practical response is to hire the person you want to sell to. At the hedge fund, this relationship already existed: the trader was Bhardwaj’s boss and collaborator. At Allos, the engineering team had to bring in a scientist. Bhardwaj reports that the hire changed the direction of the tools and improved their reception with large pharmaceutical companies. The outputs began to speak the customer’s language instead of generic LLM jargon.

The expert’s role starts before final evaluation. They can sharpen an overly broad query and help curate the evidence used to answer it. Engineers know which research sources and practitioners deserve attention; traders and scientists bring the equivalent discrimination to their own fields. Source selection is therefore part of the learning loop, alongside prompt refinement.

The expert also supplies the order of operations. A problem with five steps cannot necessarily be solved by performing those steps in any order. Decomposition, gradual refinement, and final judgment need a logical flow. Repeatedly translating that flow into the application is how lived professional experience becomes agent behavior. The expert is not merely an approver at the end of an otherwise fixed pipeline.

Expert feedback can enter the system through several mechanisms:

Bhardwaj describes the rubric approach as reinforcement learning from AI feedback. It can make expert criteria reusable, but self-grading against a rubric can also create an echo chamber. The criteria and the grader still need scrutiny.

His preferred starting point is error analysis: inspect the logs collected through observability, identify where the model went wrong, and correct the problem. This does not require changing model weights. He calls it the cheapest and highest-return starting point, a practitioner recommendation rather than a measured comparison in the talk. Once the team understands which errors remain, it can decide whether more expensive adaptation is warranted. He presents RLHF as an eventual gold standard in his industry, not a prerequisite for the first useful improvement.

Model adaptation also creates recurring work. After a team fine-tunes a base model, a new release from a provider such as Alibaba Cloud or DeepSeek can make another round of fine-tuning attractive or necessary. The cost is therefore not just the first training run; it includes maintaining the adaptation as the underlying models change.

As more practitioners join the loop, they bring more queries and expose additional tasks. Scope and data grow together. The development process itself now produces a proprietary dataset: examples of what works, what fails, and how experts distinguish the two. When the application becomes useful enough, release it to external paying users. The learning loop continues rather than ending at launch.

Bhardwaj returns here to the difference between deployment and value. He invokes a high enterprise-agent non-production percentage attributed to Stanford’s AI Index, but the exact percentage and attribution are not established well enough to use as a statistic. His substantive objection stands independently: a system may be easy to deploy and still fail to work well enough to justify its cost.

In his experience, finance and pharma demand economic usefulness quickly. A promise that the system may improve in two years, or become cheaper in three, is not enough. The development sequence matters: formulate the task, source the data, model the work in prompts, observe execution, bring in the user, and sustain an expert-led learning loop. Ship when that process produces meaningful value beyond what customers can already get from Claude or ChatGPT.

This deployment model puts responsibility with the expert. Bhardwaj distinguishes AI in the loop, or AITL, from human in the loop, or HITL. The latter suggests an AI-led workflow that a person checks. In the finance and pharma applications he describes, the expert owns the work and AI assists.

For a trader, the assistant might generate five candidate trade theses. Those are proposals, not executed trades: the trader decides which, if any, might work in the market. In pharma, AI can assist with drug candidates, but the expert still chooses which to pursue. The value is reduced expert effort while preserving professional control over the consequential decision. Bhardwaj does not quantify the time saved.

He expects that arrangement to persist because he sees causal reasoning as a boundary for autonomous decisions. Correlation with past examples is not, in his view, sufficient to decide what will happen next. Invoking LeCun’s distinction between text-based statistical learning and models of the real world, he argues that the system needs to reason about causes. This is Bhardwaj’s proposed threshold, not an established test of autonomy.

He calls that threshold an AGI line. Beyond it, he imagines people creating drugs or market strategies through something resembling vibe coding. Those are speculative future possibilities; the working product described here remains an assistant to an expert.

The durable advantage is the expertise and evidence accumulated through that work. Models, infrastructure, and ecosystem subscriptions are available to competitors too. The harder asset to reproduce is a body of domain judgment joined to internal records and other valuable data that is not on the public internet. No subscription supplies that complete advantage. The team has to curate it.