Knowledge Graphs in Litigation Agents — Tom Smoker, WhyHow.AI

How do scattered documents and public complaints become a potential class action or mass tort case? At WhyHow.AI, the task is to find those cases before lawyers do, then deliver the evidence to firms that might take them on. Tom Smoker, the company’s technical founder, brings roughly a decade of graph experience and a longstanding relationship with the Neo4j team to that problem. The workflow combines web scraping, stored information, agents, graphs, and proprietary lead qualification informed by daily work with lawyers.

Consider a pharmaceutical product used by many people. If the product causes harm and scientific evidence supports that connection, lawyers can bring affected people together to pursue a claim. The description already suggests a schema: individuals → products → ingredients → concentrations → identifiers. Each connection creates another way to investigate the evidence. A product name alone is less useful than a product connected to its ingredients, their concentrations, and the people exposed to them.

Smoker began studying graphs in graduate work in 2016, before their current prominence in AI applications. His working definition starts with relations: a graph lets someone see what connects to what, specify those connections explicitly, and run large-scale analytics over them. Those relations need not stop at a single edge. An investigation can follow multiple hops, branch into several paths, and connect evidence distributed across a much larger structure.

The visual accessibility of a graph can also conceal disagreement. Two people may look at the same network and both feel they understand it, while assigning different meanings to its connections. Definitions based on nodes and edges do not settle questions about how data is represented, stored, distributed, backed up, or used. As more teams adopt GraphRAG, a shared picture is not enough: they need a shared interpretation of the structure behind it.

The same need for a precise definition applies to multi-agent systems. They can mean tightly specified components chained together with an LLM connecting them. At WhyHow.AI, the useful unit is a step in a complicated white-collar workflow whose inputs and outputs can be tested. Different steps have different requirements, run at different frequencies, and maintain different state. A graph often controls that state.

Legal work makes these boundaries consequential. Correctness includes factual accuracy, proper format, and exact language; an isolated probabilistic language model does not provide enough control. A schema constrains what each step handles, while modular tests make it possible to locate a failure instead of treating the entire application as one opaque agent. The accompanying slide connects this approach to granular application control, delegation to models or domain experts, and incremental testing of individual modules.

Not every step deserves the same level of trust or scrutiny. Some decisions matter far more than others, and calling a component an agent does not make it capable: a poor prompt can produce a poor agent. WhyHow.AI puts substantial effort into guardrails and into memory that is episodic rather than limited to the immediate interaction. It captures information state over time, then prunes it.

Graph state supports a repeated cycle: capture, expand, prune, structure, and query. Extensibility matters, but so does the ability to remove an earlier extension. A system that can only accumulate information cannot exercise the same control over what remains available to later steps.

Smoker considers even 95% accuracy for an individual agent difficult to achieve. Guardrails and humans in the loop can make a system accurate enough to use, but chaining steps exposes another problem. In Smoker’s illustrative five-step workflow, five agents with 95% accuracy each yield about 77% end-to-end accuracy.

The calculation uses the series reliability model: every step must succeed, and multiplying standalone success rates assumes independence. Equivalently, the product applies if each step has a 95% probability of success conditional on all preceding steps succeeding.

This is an illustrative calculation, not measured production accuracy. It explains why the central engineering problem is decision-making under uncertainty across the workflow, rather than the quality of any single agent in isolation.

WhyHow.AI applies this skeptical approach to litigation agents that support class action and mass tort lawyers. The company does not itself litigate or sue. Its role is to help assemble the information lawyers need, in a field where exact details and correct presentation are the starting point for creative argument. The best lawyers, in Smoker’s account, combine painstaking attention to facts with unusual ways of applying them.

His example moves from Netflix’s collection of viewing information to an older dispute involving Blockbuster’s physical rental records. The proposed connection is that a privacy argument about physical rentals might inform one about digital viewing, despite changes in medium, scale, and recommendation technology. The anecdote illustrates analogical reasoning; it does not identify a verified retention precedent. The Video Privacy Protection Act distinguishes disclosure restrictions from requirements to destroy information no longer needed, rather than imposing a general quantitative ceiling on collected viewing data.

This creates a difficult combination for an AI system: accuracy is mandatory, useful creativity builds on that accuracy, and the underlying information lives in separate places. The connection between two apparently different situations may exist only in an expert’s memory. An agent that usually produces plausible work—and occasionally invents a connection—can frustrate precisely the person it is meant to help. Smoker frames these as broad observations from working with lawyers; he is not a lawyer, although his co-founder is.

Legal discovery brings the information problem into focus. Smoker imagines a pharmaceutical company producing 500 GB of largely irrelevant emails for a law firm to review. The lawyers must determine what happened and when, under a litigation deadline. Manual review remains common, but a sufficiently large production cannot be read in full within the available time, so shortcuts and prioritization become unavoidable.

Consistent extraction changes the form of that work. Instead of navigating a mountain of emails, a reviewer can dismiss irrelevant material and inspect a smaller body of useful, structured information. A graph can also augment discovery evidence and expose connections visually to an expert. The graph shown in the recording is generic: Smoker cannot display the client graphs he is working on.

Return to the pharmaceutical example. An ingredient appears at a particular concentration; the question is whether that concentration creates a problem, when the problem occurred, and which people are relevant. A graph could contain millions of nodes while only a few people matter to that investigation. Structuring the evidence makes it possible to focus computationally and visually, then present it in language whose significance the lawyer or domain expert understands.

The focused graph Smoker describes is relatively small and has a consistent schema, making retrieval more tractable. He does not claim retrieval is solved. He does report production agents that let lawyers ask natural-language questions about a lawsuit and the individuals they represent. The graph supplies an organized evidentiary context for those questions.

Case research starts earlier than discovery. People who have used a product may already be describing problems in niche subreddits, on Twitter, in forums, or on IRC. They use similar language about the same thing, but their complaints remain scattered. Traditional routes to a potential case—conversations with colleagues or a newsletter subscription—may never surface that pattern.

Smoker describes the collection ambition as scraping the entire web, but the distinguishing work comes after collection: qualifying the leads. WhyHow.AI develops schemas with particular lawyers and firms, then filters collected information to what those clients care about. Collection supplies possibilities; qualification determines which possibilities belong in a lawyer’s workflow.

There is no universally perfect lawsuit. Suitability depends on the lawyer, partner, or firm willing to pursue it. That makes the problem one of specificity and personalization. Different lawyers can have different multi-agent workflows and different supporting graphs, reflecting how each wants to work instead of forcing everyone into one compromise process.

Once a signal passes the lawyer’s qualification criteria, it can feed a further multi-agent workflow that generates a report. That workflow is backed by a consistent, pruned schema and controlled graph state. The personalization therefore extends beyond deciding which lead to surface: it also determines how the evidence is presented.

The content changes, while each lawyer’s report structure remains consistent. One lawyer’s preferred structure may differ from another’s, but each receives information in a familiar arrangement. Broad web collection thus narrows into an automated, individually tailored service: collect evidence, qualify it for the recipient, and compose the report that recipient needs.

A car begins to smoke during ordinary use, then catches fire. That is not what its owner expected from the brochure. Owners report these experiences on government websites, CarComplaints.com, subreddits, and forums. Those separate accounts become inputs to a repeatable process: scrape the complaints, structure them, map them to a schema, and analyze them by vehicle, model year, and problem.

Smoker describes complaint density as complaint count multiplied by complaint velocity, with velocity expressed as complaints per month over a period of months. This combines accumulated volume with the rate at which new complaints arrive. The talk does not specify the observation window or normalization, so it supplies a scoring concept rather than a complete scoring implementation.

Waiting for complaint velocity to develop is itself a delay. Smoker says the team is building models that use public, well-documented prior lawsuits and the sequence of events that led to them, allowing earlier recognition without immediately needing a strong velocity signal. He then contrasts three different stages:

The fifteen-minute clock has no defined starting event in the talk, and these are reported operational estimates rather than comparable benchmark latencies. Detecting a lead, gaining confidence in it, and deciding to take a lawsuit are distinct outcomes.

The vehicle-fire example still has to fit a particular lawyer. In the case Smoker describes, that lawyer wanted vehicle-fire matters meeting constraints on monetary amount, make and model, and jurisdiction. The same schema can apply throughout collection, filtering, and report production. A relevant complaint is not automatically a relevant lead for every firm.

A small TypeScript example makes those explicit filters concrete. Here, a proposed vehicle-fire lead is checked against a lawyer’s criteria before entering the reporting stage:

type Lead = {
  id: string;
  problem: string;
  make: string;
  model: string;
  jurisdiction: string;
  amount: number;
};

type Criteria = {
  problem: string;
  make: string;
  model: string;
  jurisdiction: string;
  minimumAmount: number;
};

function qualifies(lead: Lead, criteria: Criteria): boolean {
  return (
    lead.problem === criteria.problem &&
    lead.make === criteria.make &&
    lead.model === criteria.model &&
    lead.jurisdiction === criteria.jurisdiction &&
    lead.amount >= criteria.minimumAmount
  );
}

const proposedLead: Lead = {
  id: "lead-17",
  problem: "vehicle fire",
  make: "Example Motors",
  model: "Tourer",
  jurisdiction: "California",
  amount: 40_000,
};

const criteria: Criteria = {
  problem: "vehicle fire",
  make: "Example Motors",
  model: "Tourer",
  jurisdiction: "California",
  minimumAmount: 30_000,
};

const eligibleForReport = qualifies(proposedLead, criteria);

The example values make the filtering boundary visible; satisfying these fields means eligibility for the next workflow step, not proof of harm or a decision to litigate.

Lawyers can then filter results and feed information back into the system. The graph is not static: its extensible schema supports updates and queries across the structure. Preferences can become part of the state used by subsequent work instead of disappearing after a single interaction.

Although lawyers appreciate chat, Smoker describes report generation as the more prominent RAG application. An answer is useful, but so is the form in which it arrives. He reports that graphs are built each day, after which a subgraph is retrieved from the broader structure and composed into a report the lawyer can act on. The retrieval target is the evidence needed for a document, not only the context needed for a chat response.

The business aim is to find lawsuits earlier and help people obtain compensation for harm. Reaching that outcome involves web collection, structured data, and schemas that can be built iteratively. It is not exclusively a generative AI problem. Smoker argues that LLMs are not categorically better than traditional machine learning: their usefulness depends on the task.

Earlier multi-agent workflows could stall where two components could not exchange information cleanly. The information might be inconsistent or probabilistic, or the desired instruction might resist expression as a binary feature. A person could describe what they wanted in ordinary language, but the system had no practical way to connect that description to the next step. LLMs make some of those connections possible. Smoker characterizes WhyHow.AI’s architecture as an ML-filtered system connected by LLMs: language models help complete the workflow, while traditional ML continues to perform filtering.

The graph gives that connected workflow continuity. As the team builds, extends, and prunes it, the system can retain and revise what each lawyer wants. Smoker attributes improving reports to this management of state: each new report can draw on a more precise understanding of the recipient’s requirements, rather than starting the personalization process again.